From hengist.podd at virgin.net Tue Mar 1 00:16:44 2005 From: hengist.podd at virgin.net (has) Date: Tue Mar 1 00:16:49 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: <2209330ca399ef1145650a3d08a2ce3f@redivi.com> References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> Message-ID: Bob wrote: >>>Well I can verify that there definitely are serious problems with >>>CFURL after screwing around with it a bit. >> >>Figures. Yuck. Must be bgen's revenge for all the nasty things we >>ever said about it. > >All the nasty things I ever said about it are because of things like this :) But it's so quick! As long as you're Jack and know how to use it. If you're not Jack, I guess you're screwed. On second thoughts, given Jack's existing To-Do list is probably the size of K2 he's probably screwed too. :p I wonder if it'd be easier just to hand-code wrappers using Pyrex, perhaps with a very basic macro system that automates only the simplest of tasks. A lower level automation that works well might ultimately be more productive than total automation that tends towards flakiness. While a single person wouldn't be able to wrap nearly as many APIs, the wrappers that did get done would probably be more reliable due to the extra attention; maybe a bit nicer to use too. Plus it'd make it easier for more folk to write these wrappers, taking some pressure off Jack. >>>Too bad :) If you're writing Mac OS X specific code you >>>**really** should have PyObjC anyway. >> >>Oh, I have. It's all the casual users who don't that present the >>problem. If PyObjC is going to be so essential to all aspects of >>MacPython usage then it's really time for it to join the standard >>library. > >So let's offer a package that includes appscript, PyObjC, and py2app >in one installer. I do recall Jack saying something about maybe having a smaller core library and moving a lot of the non-essential stuff to an external package that could be managed independently; kind of a 'second tier'. Perhaps that would be the way to do it: more flexibility for individual package developers since they're not tied to the official Python upgrade cycle while still providing a quick and simple one-stop installation for users. Even modules that are destined for the core library would benefit from spending some time at this halfway house first while all the kinks are worked out (e.g. OSA.so). Might be worth exploring to see what sort of infrastructure it would require to run. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Tue Mar 1 00:31:20 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 1 00:31:27 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> Message-ID: On Feb 28, 2005, at 6:16 PM, has wrote: > Bob wrote: > >>>> Well I can verify that there definitely are serious problems with >>>> CFURL after screwing around with it a bit. >>> >>> Figures. Yuck. Must be bgen's revenge for all the nasty things we >>> ever said about it. >> >> All the nasty things I ever said about it are because of things like >> this :) > > But it's so quick! As long as you're Jack and know how to use it. If > you're not Jack, I guess you're screwed. On second thoughts, given > Jack's existing To-Do list is probably the size of K2 he's probably > screwed too. :p > > I wonder if it'd be easier just to hand-code wrappers using Pyrex, > perhaps with a very basic macro system that automates only the > simplest of tasks. A lower level automation that works well might > ultimately be more productive than total automation that tends towards > flakiness. While a single person wouldn't be able to wrap nearly as > many APIs, the wrappers that did get done would probably be more > reliable due to the extra attention; maybe a bit nicer to use too. > Plus it'd make it easier for more folk to write these wrappers, taking > some pressure off Jack. Actually, the easiest way is to just use PyObjC! It is extremely well suited to tackle wrapping CoreFoundation functions and types since they conform to the NSObject protocol. Many of them have toll-free bridges into their Objective-C types, which have a richer interface, and PyObjC understands this too. Additionally, since PyObjC wraps the functions with the signature they actually have, it's obvious (given Apple documentation or headers) how to use them. The way bgen wraps them attempts to objectify them, which tends to cause more problems than it solves -- at least for me. I wouldn't think to look for a method of CFStringRef to create a CFURL! >>>> Too bad :) If you're writing Mac OS X specific code you **really** >>>> should have PyObjC anyway. >>> >>> Oh, I have. It's all the casual users who don't that present the >>> problem. If PyObjC is going to be so essential to all aspects of >>> MacPython usage then it's really time for it to join the standard >>> library. >> >> So let's offer a package that includes appscript, PyObjC, and py2app >> in one installer. > > I do recall Jack saying something about maybe having a smaller core > library and moving a lot of the non-essential stuff to an external > package that could be managed independently; kind of a 'second tier'. > Perhaps that would be the way to do it: more flexibility for > individual package developers since they're not tied to the official > Python upgrade cycle while still providing a quick and simple one-stop > installation for users. Even modules that are destined for the core > library would benefit from spending some time at this halfway house > first while all the kinks are worked out (e.g. OSA.so). Might be worth > exploring to see what sort of infrastructure it would require to run. The Windows guys seem to get along just fine with this approach (re: win32all). There are a select few Win32-specific modules in the core, but most of the things you actually need are elsewhere. -bob From brendansimons at yahoo.ca Tue Mar 1 00:49:49 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Tue Mar 1 00:49:53 2005 Subject: [Pythonmac-SIG] SciPy installer for Panther Python, anyone? In-Reply-To: <20050228110039.9D9101E4009@bag.python.org> References: <20050228110039.9D9101E4009@bag.python.org> Message-ID: <8a96b6622bf194c61e8910d2ba0cf7dc@yahoo.ca> On 28-Feb-05, at 6:00 AM, pythonmac-sig-request@python.org wrote: > From: Peter Maxwell > Date: February 27, 2005 11:22:51 PM EST > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] SciPy installer for Panther Python, anyone? > > > No guarantees, but my latest attempt to compile SciPy seems to have > worked: > > http://cbis.anu.edu.au/misc/SciPy_complete-0.3.2.mpkg.zip > > -- Peter Maxwell Sweet. Thanks Peter. I was just about to resign myself to writing my own non-linear function optimizer. You just saved me a lot of work! Brendan ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From rogerb at rogerbinns.com Tue Mar 1 05:50:24 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Tue Mar 1 05:50:27 2005 Subject: [Pythonmac-SIG] Qualcomm Purevoice codec References: <031601c518af$9aa7d180$3501a8c0@rogersqyvr14d3> <43420c810c20ebbfd65369f2bda69027@cwi.nl> Message-ID: <018401c51e1a$2ea97e50$04000100@rogersqyvr14d3> > The quicktime module for Python 2.4 has a lot of new functionality (and > it's also available as an addon for Python 2.3, through my experimental > database for Package Manager). Access to codecs is one of the things > that has been added. Can you please give me some direction on how to get this into Python 2.3? (The documentation, whats installed, various urls etc all contradict each other on what packaging systems are actually currently in use and maintained). > But, of course, I've only tested it very lightly and it's very possible > I forgot some essential things. Could you please check whether Python > 2.4 (or its Carbon.Qt module used in 2.3) allows you to access the > codec you need? I will do so for Python 2.3. Roger From bob at redivi.com Tue Mar 1 06:01:25 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 1 06:01:30 2005 Subject: [Pythonmac-SIG] Qualcomm Purevoice codec In-Reply-To: <018401c51e1a$2ea97e50$04000100@rogersqyvr14d3> References: <031601c518af$9aa7d180$3501a8c0@rogersqyvr14d3> <43420c810c20ebbfd65369f2bda69027@cwi.nl> <018401c51e1a$2ea97e50$04000100@rogersqyvr14d3> Message-ID: <3f9e0345069471dcfbebbe282e3d3a5b@redivi.com> On Feb 28, 2005, at 11:50 PM, Roger Binns wrote: >> The quicktime module for Python 2.4 has a lot of new functionality >> (and it's also available as an addon for Python 2.3, through my >> experimental database for Package Manager). Access to codecs is one >> of the things that has been added. > > Can you please give me some direction on how to get this into Python > 2.3? (The documentation, whats installed, various urls etc all > contradict each other on what packaging systems are actually currently > in use and maintained). Easier still is Python23Compat: http://bob.pythonmac.org/archives/2005/02/02/python23compat/ -bob From rogerb at rogerbinns.com Tue Mar 1 06:24:13 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Tue Mar 1 06:24:16 2005 Subject: [Pythonmac-SIG] Qualcomm Purevoice codec References: <031601c518af$9aa7d180$3501a8c0@rogersqyvr14d3> <43420c810c20ebbfd65369f2bda69027@cwi.nl> <018401c51e1a$2ea97e50$04000100@rogersqyvr14d3> <3f9e0345069471dcfbebbe282e3d3a5b@redivi.com> Message-ID: <019701c51e1e$e800b5e0$04000100@rogersqyvr14d3> > Easier still is Python23Compat: > http://bob.pythonmac.org/archives/2005/02/02/python23compat/ Ok, I installed that and did: import Carbon.Qt help(Carbon.Qt) I couldn't see any methods for getting codecs or feeding them wav/pcm information. Roger From bob at redivi.com Tue Mar 1 06:37:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 1 06:37:12 2005 Subject: [Pythonmac-SIG] Qualcomm Purevoice codec In-Reply-To: <019701c51e1e$e800b5e0$04000100@rogersqyvr14d3> References: <031601c518af$9aa7d180$3501a8c0@rogersqyvr14d3> <43420c810c20ebbfd65369f2bda69027@cwi.nl> <018401c51e1a$2ea97e50$04000100@rogersqyvr14d3> <3f9e0345069471dcfbebbe282e3d3a5b@redivi.com> <019701c51e1e$e800b5e0$04000100@rogersqyvr14d3> Message-ID: <4246a1d033e5e840d37d30ac30260ade@redivi.com> On Mar 1, 2005, at 12:24 AM, Roger Binns wrote: >> Easier still is Python23Compat: >> http://bob.pythonmac.org/archives/2005/02/02/python23compat/ > > Ok, I installed that and did: > > import Carbon.Qt > help(Carbon.Qt) > > I couldn't see any methods for getting codecs or feeding them > wav/pcm information. I believe it's Quicktime.Quicktime and Quicktime.Qt -- it doesn't override anything that's implemented in 2.3 -bob From rogerb at rogerbinns.com Tue Mar 1 07:52:08 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Tue Mar 1 07:52:10 2005 Subject: [Pythonmac-SIG] Qualcomm Purevoice codec References: <031601c518af$9aa7d180$3501a8c0@rogersqyvr14d3> <43420c810c20ebbfd65369f2bda69027@cwi.nl> <018401c51e1a$2ea97e50$04000100@rogersqyvr14d3> <3f9e0345069471dcfbebbe282e3d3a5b@redivi.com> <019701c51e1e$e800b5e0$04000100@rogersqyvr14d3> <4246a1d033e5e840d37d30ac30260ade@redivi.com> Message-ID: <01b701c51e2b$3019ee80$04000100@rogersqyvr14d3> > I believe it's Quicktime.Quicktime and Quicktime.Qt -- it doesn't > override anything that's implemented in 2.3 Those are the ones. The former has hundreds of constants and the latter has hundreds of methods. Needless to say I have absolutely no idea what to call to get my conversion done. Roger From bob at redivi.com Tue Mar 1 08:16:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 1 08:16:43 2005 Subject: [Pythonmac-SIG] Qualcomm Purevoice codec In-Reply-To: <01b701c51e2b$3019ee80$04000100@rogersqyvr14d3> References: <031601c518af$9aa7d180$3501a8c0@rogersqyvr14d3> <43420c810c20ebbfd65369f2bda69027@cwi.nl> <018401c51e1a$2ea97e50$04000100@rogersqyvr14d3> <3f9e0345069471dcfbebbe282e3d3a5b@redivi.com> <019701c51e1e$e800b5e0$04000100@rogersqyvr14d3> <4246a1d033e5e840d37d30ac30260ade@redivi.com> <01b701c51e2b$3019ee80$04000100@rogersqyvr14d3> Message-ID: <9b76112751d751d6f0ab82b380013f97@redivi.com> On Mar 1, 2005, at 1:52 AM, Roger Binns wrote: >> I believe it's Quicktime.Quicktime and Quicktime.Qt -- it doesn't >> override anything that's implemented in 2.3 > > Those are the ones. The former has hundreds of constants and the > latter has hundreds of methods. Needless to say I have absolutely > no idea what to call to get my conversion done. Yeah, well, I don't think anyone else here has much of an idea, but would be a good place to start. I can tell you from experience that QuickTime is a bit of a pain (why is the Python module named Quicktime?). If you can get ahold of Kevin Marks, he would probably be able to at least point you in the right direction. -bob From rogerb at rogerbinns.com Tue Mar 1 09:22:12 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Tue Mar 1 09:22:13 2005 Subject: [Pythonmac-SIG] Qualcomm Purevoice codec References: <031601c518af$9aa7d180$3501a8c0@rogersqyvr14d3> <43420c810c20ebbfd65369f2bda69027@cwi.nl> <018401c51e1a$2ea97e50$04000100@rogersqyvr14d3> <3f9e0345069471dcfbebbe282e3d3a5b@redivi.com> <019701c51e1e$e800b5e0$04000100@rogersqyvr14d3> <4246a1d033e5e840d37d30ac30260ade@redivi.com> <01b701c51e2b$3019ee80$04000100@rogersqyvr14d3> <9b76112751d751d6f0ab82b380013f97@redivi.com> Message-ID: <000e01c51e37$c4e03630$04000100@rogersqyvr14d3> > Yeah, well, I don't think anyone else here has much of an idea, but > would > be a good place to start. I can tell you from experience that > QuickTime is a bit of a pain I had hoped from Jack's original message that it would be a lot easier than it looks like it will be. Check out the text on this page: http://developer.apple.com/documentation/QuickTime/Carbon-date.html 2,000 different functions is absolutely insane. Due to the huge scope of all this, I won't be spending any of my own time on it, and instead leave it up to other BitPim developers on Mac. > (why is the Python module named Quicktime?). It isn't - the modules do have the correct camelcase. Roger From chris_py006 at psychofx.com Tue Mar 1 15:01:29 2005 From: chris_py006 at psychofx.com (Chris Miles) Date: Tue Mar 1 15:02:07 2005 Subject: [Pythonmac-SIG] malloc error with imaplib or socket on OS X Message-ID: <57e1bca19f1534d8abd7325f5734cdbb@psychofx.com> Hi, I have recently come across what looks like a serious bug with Python on OS X. While writing a program using imaplib to connect to some IMAP4 servers I encountered a MemoryError exception with a malloc() error which was easily reproducible with my data at the time. The malloc error was: *** malloc: vm_allocate(size=9252864) failed (error code=3) *** malloc[1522]: error: Can't allocate region A thread on comp.lang.python shows that this bug has been encountered by others as well. http://groups-beta.google.com/group/comp.lang.python/browse_thread/ thread/cd5a8f28b021c269/cf7e574e3bc566df I tested my program on my standard OS X 10.3 Python (2.3) as well as a build of 2.4 and found the same MemoryError. (btw: I had plenty of free RAM at the time. Over 1/4 of 1GB on a powerbook G4) I tested the exact same program connecting to the exact same IMAP4 server (Exchange actually) on a Linux box and it worked fine (actually a Linux host running in VPC on the very same Mac). The data that was causing the MemoryError was a 9 MB mail message on the IMAP server. After I deleted this message the program on the Mac ran fine. The other messages were max 1 MB in size and there were about 114 of them. (The program downloads every message from a user's IMAP account, amongst other things.) Attached is a full Traceback of the MemoryError (as formatted by iPython). Is this a known issue, or should I submit it somewhere? Cheers, Chris -- Chris Miles http://chrismiles.info/ -------------- next part -------------- *** malloc: vm_allocate(size=9244672) failed (error code=3) *** malloc[1436]: error: Can't allocate region --------------------------------------------------------------------------- exceptions.MemoryError Traceback (most recent call last) /Users/chris/ /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/imaplib.py in fetch(self, message_set, message_parts) 415 """ 416 name = 'FETCH' --> 417 typ, dat = self._simple_command(name, message_set, message_parts) 418 return self._untagged_response(typ, dat, name) 419 /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/imaplib.py in _simple_command(self, name, *args) 998 def _simple_command(self, name, *args): 999 -> 1000 return self._command_complete(name, self._command(name, *args)) 1001 1002 /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/imaplib.py in _command_complete(self, name, tag) 832 raise self.abort('command: %s => %s' % (name, val)) 833 except self.error, val: --> 834 raise self.error('command: %s => %s' % (name, val)) 835 self._check_bye() 836 if typ == 'BAD': /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/imaplib.py in _get_tagged_response(self, tag) 934 if self.debug >= 1: 935 self.print_log() --> 936 raise 937 938 /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/imaplib.py in _get_response(self) 891 if self.debug >= 4: 892 self._mesg('read literal size %s' % size) --> 893 data = self.read(size) 894 895 # Store response with literal as tuple /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/imaplib.py in read(self, size) 229 def read(self, size): 230 """Read 'size' bytes from remote.""" --> 231 return self.file.read(size) 232 233 /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/socket.py in read(self, size) 299 left = size - buf_len 300 recv_size = max(self._rbufsize, left) --> 301 data = self._sock.recv(recv_size) 302 if not data: 303 break MemoryError: From hengist.podd at virgin.net Tue Mar 1 15:55:55 2005 From: hengist.podd at virgin.net (has) Date: Tue Mar 1 15:56:04 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> Message-ID: Bob wrote: >>I wonder if it'd be easier just to hand-code wrappers > >Actually, the easiest way is to just use PyObjC! Maybe that's the way to go for CF stuff then: delegate the problem to PyObjC and get rid of the Carbon.CF extension completely (no sense in keeping broken modules if they're not worth fixing). This still leaves Carbon APIs to deal with, however. For example, OSA.so is currently pretty broken, and I would happily go in and fix it myself but there's little point in doing so if all my changes have to be rewritten for bgen before they'll be accepted into the standard library. Plus Jack's very busy these days, so who knows when that would happen? And then there's stuff like Carbon.File, which could do with both bug fixes (the FSSpec problem) plus a new layer on top that abstracts away all the various and frequently crusty file types under one or two standard wrapper classes (might be possible to turn most of them into NSURLs, for example). How should these sorts of problems be tackled? >Additionally, since PyObjC wraps the functions with the signature >they actually have, it's obvious (given Apple documentation or >headers) how to use them. The way bgen wraps them attempts to >objectify them, which tends to cause more problems than it solves -- >at least for me. I don't mind that so much as I object to the lack of documentation to tell you what's actually there and where to find it. These undocumented APIs are a serious PITA to grok. I end up generating my own erstaz docs by scraping an extension's type/method/function names and minimal docstrings into a text file and then cutting and pasting from Apple's original API docs or header file comments until I've got something that's at least minimally readable. >>I do recall Jack saying something about maybe having a smaller core >>library and moving a lot of the non-essential stuff to an external >>package that could be managed independently > >The Windows guys seem to get along just fine with this approach (re: >win32all). There are a select few Win32-specific modules in the >core, but most of the things you actually need are elsewhere. So what would it take to get MacPython from its current state into that position? has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Tue Mar 1 16:39:51 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 1 16:40:01 2005 Subject: [Pythonmac-SIG] malloc error with imaplib or socket on OS X In-Reply-To: <57e1bca19f1534d8abd7325f5734cdbb@psychofx.com> References: <57e1bca19f1534d8abd7325f5734cdbb@psychofx.com> Message-ID: <70587d1eda9535ff74e83c8772d1b77f@redivi.com> On Mar 1, 2005, at 9:01 AM, Chris Miles wrote: > Hi, I have recently come across what looks like a serious bug with > Python on OS X. While writing a program using imaplib to connect to > some IMAP4 servers I encountered a MemoryError exception with a > malloc() error which was easily reproducible with my data at the time. > The malloc error was: > > *** malloc: vm_allocate(size=9252864) failed (error code=3) > *** malloc[1522]: error: Can't allocate region > > A thread on comp.lang.python shows that this bug has been encountered > by others as well. > > http://groups-beta.google.com/group/comp.lang.python/browse_thread/ > thread/cd5a8f28b021c269/cf7e574e3bc566df > > I tested my program on my standard OS X 10.3 Python (2.3) as well as a > build of 2.4 and found the same MemoryError. (btw: I had plenty of > free RAM at the time. Over 1/4 of 1GB on a powerbook G4) > > I tested the exact same program connecting to the exact same IMAP4 > server (Exchange actually) on a Linux box and it worked fine (actually > a Linux host running in VPC on the very same Mac). > > The data that was causing the MemoryError was a 9 MB mail message on > the IMAP server. After I deleted this message the program on the Mac > ran fine. The other messages were max 1 MB in size and there were > about 114 of them. (The program downloads every message from a user's > IMAP account, amongst other things.) > > Attached is a full Traceback of the MemoryError (as formatted by > iPython). > > Is this a known issue, or should I submit it somewhere? You can try it on Python CVS and see if it has been fixed. The bug in question is . -bob From bob at redivi.com Tue Mar 1 16:54:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 1 16:54:08 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> Message-ID: On Mar 1, 2005, at 9:55 AM, has wrote: > Bob wrote: > >>> I wonder if it'd be easier just to hand-code wrappers >> >> Actually, the easiest way is to just use PyObjC! > > Maybe that's the way to go for CF stuff then: delegate the problem to > PyObjC and get rid of the Carbon.CF extension completely (no sense in > keeping broken modules if they're not worth fixing). Unfortunately getting rid of an extension is a lot harder than it sounds. Better is to just stop using it, and possibly deprecate it. I don't think anyone is really using that module anyway. > This still leaves Carbon APIs to deal with, however. For example, > OSA.so is currently pretty broken, and I would happily go in and fix > it myself but there's little point in doing so if all my changes have > to be rewritten for bgen before they'll be accepted into the standard > library. Plus Jack's very busy these days, so who knows when that > would happen? And then there's stuff like Carbon.File, which could do > with both bug fixes (the FSSpec problem) plus a new layer on top that > abstracts away all the various and frequently crusty file types under > one or two standard wrapper classes (might be possible to turn most of > them into NSURLs, for example). How should these sorts of problems be > tackled? It's unlikely that anyone is going to ever bother doing a better job wrapping Carbon than is already done, because it's a hell of a lot of work and Carbon isn't really the best way to do most things anyway. Instead of fixing OSA, you can write an alternative that isn't bgen based. *What* FSSpec problem with Carbon.File? Although there is generally not a very good reason to use FSSpec or FSRef, unless you're working with resource forks or Aliases, I haven't had problems with Carbon.File at all. This is probably the most robust module in the bgen Carbon wrappers, as it's the one that actually gets used. >> Additionally, since PyObjC wraps the functions with the signature >> they actually have, it's obvious (given Apple documentation or >> headers) how to use them. The way bgen wraps them attempts to >> objectify them, which tends to cause more problems than it solves -- >> at least for me. > > I don't mind that so much as I object to the lack of documentation to > tell you what's actually there and where to find it. These > undocumented APIs are a serious PITA to grok. I end up generating my > own erstaz docs by scraping an extension's type/method/function names > and minimal docstrings into a text file and then cutting and pasting > from Apple's original API docs or header file comments until I've got > something that's at least minimally readable. Well the problem I have is that even if you know the C API then you will stumble with the Pythonized version of it (with bgen generated stuff). >>> I do recall Jack saying something about maybe having a smaller core >>> library and moving a lot of the non-essential stuff to an external >>> package that could be managed independently >> >> The Windows guys seem to get along just fine with this approach (re: >> win32all). There are a select few Win32-specific modules in the >> core, but most of the things you actually need are elsewhere. > > So what would it take to get MacPython from its current state into > that position? Just tell people to stop using standard library stuff and use the more robust alternatives. The standard library bits can't disappear, because that would break compatibility. Of course, this is assuming that more robust alternatives to the standard library's exists. -bob From speno at isc.upenn.edu Tue Mar 1 16:54:34 2005 From: speno at isc.upenn.edu (John P Speno) Date: Tue Mar 1 16:54:36 2005 Subject: [Pythonmac-SIG] malloc error with imaplib or socket on OS X In-Reply-To: <57e1bca19f1534d8abd7325f5734cdbb@psychofx.com> References: <57e1bca19f1534d8abd7325f5734cdbb@psychofx.com> Message-ID: <20050301155434.GA14249@isc.upenn.edu> On Tue, Mar 01, 2005 at 02:01:29PM +0000, Chris Miles wrote: > The data that was causing the MemoryError was a 9 MB mail message on > the IMAP server. After I deleted this message the program on the Mac > ran fine. The other messages were max 1 MB in size and there were > about 114 of them. (The program downloads every message from a user's > IMAP account, amongst other things.) Are you perhaps running into a resource limit for the user who is running the applicaiton? By default, OS X has pretty low limits: % limit cputime unlimited filesize unlimited datasize 6144 kbytes stacksize 8192 kbytes coredumpsize 0 kbytes memoryuse unlimited descriptors 256 memorylocked unlimited maxproc 100 Try raising the datasize limit. In tcsh, that's as simple as saying 'unlimit'. In sh variants, you need some specific flags. From bob at redivi.com Tue Mar 1 17:06:58 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 1 17:07:10 2005 Subject: [Pythonmac-SIG] malloc error with imaplib or socket on OS X In-Reply-To: <20050301155434.GA14249@isc.upenn.edu> References: <57e1bca19f1534d8abd7325f5734cdbb@psychofx.com> <20050301155434.GA14249@isc.upenn.edu> Message-ID: <376dcfd85c27f4efb793a2a2f8bc5ee9@redivi.com> On Mar 1, 2005, at 10:54 AM, John P Speno wrote: > On Tue, Mar 01, 2005 at 02:01:29PM +0000, Chris Miles wrote: >> The data that was causing the MemoryError was a 9 MB mail message on >> the IMAP server. After I deleted this message the program on the Mac >> ran fine. The other messages were max 1 MB in size and there were >> about 114 of them. (The program downloads every message from a user's >> IMAP account, amongst other things.) > > Are you perhaps running into a resource limit for the user who is > running the applicaiton? > By default, OS X has pretty low limits: > > % limit > cputime unlimited > filesize unlimited > datasize 6144 kbytes > stacksize 8192 kbytes > coredumpsize 0 kbytes > memoryuse unlimited > descriptors 256 > memorylocked unlimited > maxproc 100 > > Try raising the datasize limit. In tcsh, that's as simple as saying > 'unlimit'. > In sh variants, you need some specific flags. Bumping up against a resource limit would cause a very different error. This bug is caused by the fact that realloc on Darwin never actually relinquishes any memory when shrinking an allocation, and Python expects it to. In this case, there is/was some gnarly code in the socket module that is really optimistic about realloc's behavior. http://bob.pythonmac.org/archives/2005/01/01/realloc-doesnt/ http://python.org/sf/1092502 -bob From hengist.podd at virgin.net Tue Mar 1 17:58:57 2005 From: hengist.podd at virgin.net (has) Date: Tue Mar 1 17:59:09 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> Message-ID: Bob wrote: >>Maybe that's the way to go for CF stuff then: delegate the problem >>to PyObjC and get rid of the Carbon.CF extension completely (no >>sense in keeping broken modules if they're not worth fixing). > >Unfortunately getting rid of an extension is a lot harder than it >sounds. Better is to just stop using it, and possibly deprecate it. Getting rid of junky crap takes time, but adding a warning and deprecating it at the nearest opportunity is a good start. > I don't think anyone is really using that module anyway. All the more reason to deprecate it before they start to. :) >>This still leaves Carbon APIs to deal with, however. > >It's unlikely that anyone is going to ever bother doing a better job >wrapping Carbon than is already done, because it's a hell of a lot >of work and Carbon isn't really the best way to do most things >anyway. True and semi-true (there's still functionality in Carbon that's not in Cocoa). However, it's not a case of wrapping all of Carbon simply as a point of principle, but rather individuals wrapping the bits they need themselves as needed and that code ultimately making it into the official distribution. >Instead of fixing OSA, you can write an alternative that isn't bgen based. If I do that, will the current OSA.so be thrown out (preferably right now) and replaced with my version once it's done? >*What* FSSpec problem with Carbon.File? http://sourceforge.net/tracker/index.php?func=detail&aid=706592&group_id=5470&atid=105470 >Although there is generally not a very good reason to use FSSpec or FSRef, Legacy mostly, e.g. when dealing with Carbon APIs that use them. In my case, because they're still heavily used by scriptable apps and Apple's built-in coercions aren't sufficiently up to snuff to let me ignore them outright (which is damned annoying, especially when they're the ones telling us we should now be ignoring these and using their shiny new types instead). >>So what would it take to get MacPython from its current state into >>that position? > >Just tell people to stop using standard library stuff and use the >more robust alternatives. What when there's overlap, e.g. the 'robust alternative' is a modified version of the original - say, a partially rewritten OSA.so extension? >The standard library bits can't disappear, because that would break >compatibility. Add warnings to these modules and deprecate them now. Strip all their documentation out of the main Python docs and leave it in a separate 'Deprecated Docs' package preserved for legacy use only. Get all the crap well away from ordinary decent users as quickly as possible. Depending on how much a deprecated item is used it could be removed completely in the following major release, moved to 'MacAll' at some point or left in the core library indefinitely. There's quite a bit of obsolete stuff in the standard library that's been broken or non-functional since OS9. With 2.4 finally throwing off OS9 commitments it seems the ideal time to get brutal with the useless baggage and strike a red marker through everything that doesn't measure up. You'll inevitably be leaving folks behind anyway, so make the most of the opportunity. Even if modules don't go completely, scrubbing the code to get rid of the cruft leaving only warnings and non-functional stubs might be a good idea. It's not worth twisting oneself into religious knots to preserve some perceived 100% backwards-compatibility over code that probably hasn't worked or been used in years. Future health, vitality and growth are much more important, and worth an occasional minor break with the ancient past. >Of course, this is assuming that more robust alternatives to the >standard library's exists. Even if there isn't, leaving broken stuff in the core library isn't doing any favours. If it's recoverable, why not punt it into MacAll where its failings can be addressed more easily? If it's terminal, put it on the road to disposal. I don't have a problem throwing out stuff that's definitely had it: you may see this as leaving a void, but I see it as creating a fresh new opportunity. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Tue Mar 1 18:11:44 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 1 18:11:46 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> Message-ID: <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> On Mar 1, 2005, at 11:58 AM, has wrote: > Bob wrote: > >>> This still leaves Carbon APIs to deal with, however. >> >> It's unlikely that anyone is going to ever bother doing a better job >> wrapping Carbon than is already done, because it's a hell of a lot of >> work and Carbon isn't really the best way to do most things anyway. > > True and semi-true (there's still functionality in Carbon that's not > in Cocoa). However, it's not a case of wrapping all of Carbon simply > as a point of principle, but rather individuals wrapping the bits they > need themselves as needed and that code ultimately making it into the > official distribution. > >> Instead of fixing OSA, you can write an alternative that isn't bgen >> based. > > If I do that, will the current OSA.so be thrown out (preferably right > now) and replaced with my version once it's done? Unlikely, but what does it matter? We're talking about making a package separate from the standard library. Even if it did happen "right now", that would mean Python 2.5, which really means "probably next year". >> *What* FSSpec problem with Carbon.File? > > http://sourceforge.net/tracker/index.php? > func=detail&aid=706592&group_id=5470&atid=105470 Ah, right. I ran into that problem once with QuickTime, but it turned out that there was another way. >> Although there is generally not a very good reason to use FSSpec or >> FSRef, > > Legacy mostly, e.g. when dealing with Carbon APIs that use them. In my > case, because they're still heavily used by scriptable apps and > Apple's built-in coercions aren't sufficiently up to snuff to let me > ignore them outright (which is damned annoying, especially when > they're the ones telling us we should now be ignoring these and using > their shiny new types instead). Does that FSSpec bug really effect you? When do you need to pass FSSpecs to files that do not exist across processes? >>> So what would it take to get MacPython from its current state into >>> that position? >> >> Just tell people to stop using standard library stuff and use the >> more robust alternatives. > > What when there's overlap, e.g. the 'robust alternative' is a modified > version of the original - say, a partially rewritten OSA.so extension? I don't see what its origins have to do with anything.. You obviously can't give it the same __name__ as something in the standard library. -bob From hengist.podd at virgin.net Tue Mar 1 19:21:26 2005 From: hengist.podd at virgin.net (has) Date: Tue Mar 1 19:21:32 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> Message-ID: Bob wrote: >>>Instead of fixing OSA, you can write an alternative that isn't bgen based. >> >>If I do that, will the current OSA.so be thrown out (preferably >>right now) and replaced with my version once it's done? > >Unlikely, but what does it matter? 1. What's the point of adding a new extension to the standard library when that extension is not only untested but _already known_ to be broken? 2. What's the point of me going to the effort of writing a brand new fully functioning OSA.so extension if it has to play perpetual third fiddle to some known-to-be-broken-but-inviolable-now-as-it's-in-the-standard-library-neener-neener version? Aside from the self-evident foolishness of loading the standard library full of worthless crap, it's also rather insulting to folk who spend the time and effort to write and thoroughly field-test code before even thinking of submitting it for possible future inclusion, only to see rubbish getting fast-tracked right past them. Come to think of it, it's somewhat insulting to MacPython users in general: "Sure the quality sucks ass, but just feel the quantity!" If bulk's all you want, just pack line noise into modules and release that; it'll work just as well and be even easier to produce. I may not know much about programming, but I know what a bullethole in the foot looks like. If nobody cares enough about using these new wrappers to test and debug them thoroughly before inclusion, they should not go in, period. Simple as that. All it does is create a mess that then can't be cleaned up properly, because throwing out a busted-ass module that _nobody can actually use_ will somehow - oh noes!!!!!!1!1! - 'break compatibility'. >>>*What* FSSpec problem with Carbon.File? >> >>http://sourceforge.net/tracker/index.php?func=detail&aid=706592&group_id=5470&atid=105470 > >Ah, right. I ran into that problem once with QuickTime, but it >turned out that there was another way. Do tell! >Does that FSSpec bug really effect you? When do you need to pass >FSSpecs to files that do not exist across processes? Most commonly when saving new documents to file, as in: app('TextEdit').documents[1].save(in_=FSSpec('/Path/To/NewFile.txt') >>>Just tell people to stop using standard library stuff and use the >>>more robust alternatives. >> >>What when there's overlap, e.g. the 'robust alternative' is a >>modified version of the original - say, a partially rewritten >>OSA.so extension? > >I don't see what its origins have to do with anything.. You >obviously can't give it the same __name__ as something in the >standard library. That would be my point. Python users don't want, need or deserve to thrash through a dozen different first- and third-party implementations of the same module to find one that works. There should be one way to do it, and that solution should NOT be in the standard library unless it can swear, hand on heart, that it's the Right One. Kicking a lot of this stuff back out the standard library would be a good start, because it's clearly not qualified to be there. Push it into 'MacAll', and take it from there. has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Tue Mar 1 19:55:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 1 19:55:30 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> Message-ID: <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> On Mar 1, 2005, at 1:21 PM, has wrote: > Bob wrote: > >>>> Instead of fixing OSA, you can write an alternative that isn't bgen >>>> based. >>> >>> If I do that, will the current OSA.so be thrown out (preferably >>> right now) and replaced with my version once it's done? >> >> Unlikely, but what does it matter? > > 1. What's the point of adding a new extension to the standard library > when that extension is not only untested but _already known_ to be > broken? They're automatically generated, these things happen. > 2. What's the point of me going to the effort of writing a brand new > fully functioning OSA.so extension if it has to play perpetual third > fiddle to some > known-to-be-broken-but-inviolable-now-as-it's-in-the-standard-library- > neener-neener version? Ok, there are three options: (1) Fix the current implementation (2) Write another, outside the standard library (unless you only care about Python 2.5+) (3) Live with a broken implementation Pick one. It's not hard to usurp something from the Carbon namespace because most of the stuff in there isn't documented anyway. The third fiddle problem is only relevant to people like you who like to complain about dependencies and try to do things the hard way for very little benefit. >>>> *What* FSSpec problem with Carbon.File? >>> >>> http://sourceforge.net/tracker/index.php? >>> func=detail&aid=706592&group_id=5470&atid=105470 >> >> Ah, right. I ran into that problem once with QuickTime, but it >> turned out that there was another way. > > Do tell! This was specific to QuickTime, not a general solution. I don't remember what it was specifically. >> Does that FSSpec bug really effect you? When do you need to pass >> FSSpecs to files that do not exist across processes? > > Most commonly when saving new documents to file, as in: > > > app('TextEdit').documents[1].save(in_=FSSpec('/Path/To/NewFile.txt') What you *actually* want is a Finder alias anyway. Something like this will probably work: import Carbon.File import MacOS import os def alias(path): try: return Carbon.File.FSRef(path).FSNewAliasMinimal() except MacOS.Error: pass file(path, 'w').close() rval = Carbon.File.FSRef(path).FSNewAliasMinimal() os.unlink(path) return rval >>>> Just tell people to stop using standard library stuff and use the >>>> more robust alternatives. >>> >>> What when there's overlap, e.g. the 'robust alternative' is a >>> modified version of the original - say, a partially rewritten OSA.so >>> extension? >> >> I don't see what its origins have to do with anything.. You >> obviously can't give it the same __name__ as something in the >> standard library. > > That would be my point. Python users don't want, need or deserve to > thrash through a dozen different first- and third-party > implementations of the same module to find one that works. There > should be one way to do it, and that solution should NOT be in the > standard library unless it can swear, hand on heart, that it's the > Right One. Kicking a lot of this stuff back out the standard library > would be a good start, because it's clearly not qualified to be there. > Push it into 'MacAll', and take it from there. Well obviously that's not an option, so pretend that the Carbon namespace doesn't exist, except for the modules that work as you expect them to. -bob From hengist.podd at virgin.net Tue Mar 1 21:08:02 2005 From: hengist.podd at virgin.net (has) Date: Tue Mar 1 21:09:15 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> Message-ID: Bob wrote: >>1. What's the point of adding a new extension to the standard >>library when that extension is not only untested but _already >>known_ to be broken? > >They're automatically generated, these things happen. Absolutely. I have no problem with mistakes being made. It's setting them in stone that's the trouble. >>2. What's the point of me going to the effort of writing a brand >>new fully functioning OSA.so extension if it has to play perpetual >>third fiddle to some >>known-to-be-broken-but-inviolable-now-as-it's-in-the-standard-library-neener-neener >>version? > >Ok, there are three options: >(1) Fix the current implementation >(2) Write another, outside the standard library (unless you only >care about Python 2.5+) >(3) Live with a broken implementation > >Pick one. The only person in a position to do (1) is Jack, which is unfair on both Jack and any third-party who might otherwise fix it themselves, (2) is just ducking the issue and (3) is obviously a non-option. (4) Remove the current implementation from the standard library. In OSA.so's case this could be done completely painlessly as it's not like anyone's actually using it. Older material may require more delicate extraction and a proper repackaging to allow separate installation, but it's still perfectly doable. >>>Does that FSSpec bug really effect you? When do you need to pass >>>FSSpecs to files that do not exist across processes? >> >>Most commonly when saving new documents to file, as in: >> >> >>app('TextEdit').documents[1].save(in_=FSSpec('/Path/To/NewFile.txt') > >What you *actually* want is a Finder alias anyway. Umm, no, I don't. I've been using file specs to refer to non-existent files for years. It was the standard solution in OS9, and while fileURL is supposed to supercede it in OS X it persists for legacy reasons and because fileURL support still isn't quite what it should be. And I've really no desire to start kludging up Python; I've already endured enough kludges in AppleScript to last a lifetime and the whole point of shifting to Python was to get away from all that crap. >>Kicking a lot of this stuff back out the standard library would be >>a good start, because it's clearly not qualified to be there. Push >>it into 'MacAll', and take it from there. > >Well obviously that's not an option, Why? All it means users have to do two installs instead of one to get set up which is no huge effort, and in practice the MacPython installer could bundle and run a recent copy of the MacAll installer for convenience. And once all this stuff is out the standard library it's free to be working on without the onerous scheduling restrictions and personnel bottleneck that comes from being locked up in the standard library. Have I missed something? has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Tue Mar 1 21:28:44 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 1 21:28:43 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> Message-ID: <6b9708d0c3f21835c36d39d7f1be2bac@redivi.com> On Mar 1, 2005, at 3:08 PM, has wrote: > Bob wrote: > >>> 1. What's the point of adding a new extension to the standard >>> library when that extension is not only untested but _already known_ >>> to be broken? >> >> They're automatically generated, these things happen. > > Absolutely. I have no problem with mistakes being made. It's setting > them in stone that's the trouble. Not stone, just molasses. If you learn bgen and submit proper patches, you can fix existing modules in the 2.4 maintenance branch and add/or features to the 2.5 branch. >>> 2. What's the point of me going to the effort of writing a brand new >>> fully functioning OSA.so extension if it has to play perpetual third >>> fiddle to some >>> known-to-be-broken-but-inviolable-now-as-it's-in-the-standard- >>> library-neener-neener version? >> >> Ok, there are three options: >> (1) Fix the current implementation >> (2) Write another, outside the standard library (unless you only care >> about Python 2.5+) >> (3) Live with a broken implementation >> >> Pick one. > > The only person in a position to do (1) is Jack, which is unfair on > both Jack and any third-party who might otherwise fix it themselves, > (2) is just ducking the issue and (3) is obviously a non-option. > > (4) Remove the current implementation from the standard library. > > In OSA.so's case this could be done completely painlessly as it's not > like anyone's actually using it. Older material may require more > delicate extraction and a proper repackaging to allow separate > installation, but it's still perfectly doable. You can learn bgen and fix it the correct way, and submit a patch. Jack doesn't need to commit the patch. I did this once or twice, it's possible for someone other than Jack to do it. You're confusing issues here. The problem is that you need OSA functionality. Removing something from the standard library does nothing to solve that problem. Removing the extension may or may not be a good idea. If /some/ of it works, it might be worth keeping. >>>> Does that FSSpec bug really effect you? When do you need to pass >>>> FSSpecs to files that do not exist across processes? >>> >>> Most commonly when saving new documents to file, as in: >>> >>> >>> app('TextEdit').documents[1].save(in_=FSSpec('/Path/To/NewFile.txt') >> >> What you *actually* want is a Finder alias anyway. > > Umm, no, I don't. I've been using file specs to refer to non-existent > files for years. It was the standard solution in OS9, and while > fileURL is supposed to supercede it in OS X it persists for legacy > reasons and because fileURL support still isn't quite what it should > be. And I've really no desire to start kludging up Python; I've > already endured enough kludges in AppleScript to last a lifetime and > the whole point of shifting to Python was to get away from all that > crap. FSSpec is legacy. It should not ever be used in any code except to reference nonexistent files or to deal with legacy APIs. You shouldn't use them if the API will take an FSRef or an Alias. In this case, the API *asks* for an Alias. So, yeah, you do actually want an Alias. >>> Kicking a lot of this stuff back out the standard library would be a >>> good start, because it's clearly not qualified to be there. Push it >>> into 'MacAll', and take it from there. >> >> Well obviously that's not an option, > > Why? All it means users have to do two installs instead of one to get > set up which is no huge effort, and in practice the MacPython > installer could bundle and run a recent copy of the MacAll installer > for convenience. And once all this stuff is out the standard library > it's free to be working on without the onerous scheduling restrictions > and personnel bottleneck that comes from being locked up in the > standard library. Have I missed something? It can't happen until Python 2.6 at the earliest. I don't think it's very likely to go away anyway. Good luck! My point is that it's perfectly fine to IGNORE THE STANDARD LIBRARY. Whether or not the Carbon package exists in the standard library has no effect whatsoever on a "MacAll" package! The only harm it's doing is taking up the name 'Carbon' in the sys.modules namespace. For compatibility reasons, the MacAll package can't use the name Carbon anyway. -bob From hengist.podd at virgin.net Wed Mar 2 15:00:54 2005 From: hengist.podd at virgin.net (has) Date: Wed Mar 2 15:51:28 2005 Subject: [Pythonmac-SIG] CFURL Pain Message-ID: Bob wrote: >FSSpec is legacy. It should not ever be used in any code except to >reference nonexistent files or to deal with legacy APIs. You >shouldn't use them if the API will take an FSRef or an Alias. Neither FSRef or Alias can be used to refer to non-existent files. FileURL does, but I'm not sure it can yet be used safely in place of FSSpecs in all cases, plus their standard Carbon.CF implementation is busted. FSSpecs suck, but I'm not sure they can be completely ignored just yet - any time I've tried to streamline aem/appscript to save the user from dealing with crap like this I've ended up having to re-expose it again in all its ugliness after something else ralphed on the 'clean and elegant' version. Rock, hard place. What's really needed is for MacPython to provide a standard high-level File class that abstracts over all this mess so module authors can have a solid and reliable API to implement against and end users don't normally need to futz directly with this stuff. No doubt an interesting and challenging problem for anyone that wanted to tackle it. > In this case, the API *asks* for an Alias. So, yeah, you do >actually want an Alias. No, the TextEdit dictionary says 'alias', but the dictionary is merely documentation, not the API itself, and dictionaries are regularly incorrect. It should almost certainly read 'file'. IIRC, the sdef format doesn't even list 'alias' as one of the standard primitive types, so I've no idea where TextEdit gets it from. Probably a blow on the head or something. Cocoa Scripting APIs are _also_ frequently buggy and ill-designed, and specifying files was one of its classic blunders in earlier incarnations which they've been trying to rectify ever since. So it is possible that they've buggered things up differently in 10.3 such that you do have to specify an existing file in a 'save' command; I don't have 10.3 so can't check offhand. If they have, I'm sure there's bugs filed on that as well, but I can't recall hearing anything about it. Nevertheless, 'save' commands have always traditionally accepted a file handle specifying an as-yet non-existent file for saving documents to a new file, and ignoring periodic Apple incompetence I don't believe this policy has formally changed for one moment. Apply one dose of healthy skepticism and a large dollop of plain common sense - both absolutely essential when it comes to Mac application scripting - and this should be obvious. has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Wed Mar 2 15:51:14 2005 From: hengist.podd at virgin.net (has) Date: Wed Mar 2 15:51:29 2005 Subject: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain) In-Reply-To: <6b9708d0c3f21835c36d39d7f1be2bac@redivi.com> References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> <6b9708d0c3f21835c36d39d7f1be2bac@redivi.com> Message-ID: Bob wrote: >>Absolutely. I have no problem with mistakes being made. It's >>setting them in stone that's the trouble. > >Not stone, just molasses. Near enough as makes no practical difference. It's a situation that should not occur in the first place. These molasses are entirely man-made. >If you learn bgen and submit proper patches Without proper documentation and tutorials? Sorry, but masochistic self-flagellation is not my thing. This is somebody else's house of cards to sort out before everyone else can seriously be expected to play in it. Besides, what's the point in me going to the trouble of properly patching something if the fix won't percolate into the main distribution for another year when I need it now? >You're confusing issues here. The problem is that you need OSA >functionality. Removing something from the standard library does >nothing to solve that problem. No, I'm using OSA.so as an illustrative example because I'm already familiar with it. The point is that potentially broken modules should not be going into standard library. And until they've been tested, all modules should be considered potentially broken. OSA.so is a prime example: I _know_ it hasn't been tested, because it took me five minutes to discover the first deal-killer bug. Other modules may be just as untested, but I can't speak for them as I've not tried them myself. In the case of OSA.so and any other new MacPython 2.4 additions that haven't been tested, until Jack posts a final MacPython 2.4 distribution then it ought to be safe to revoke their inclusion. >Removing the extension may or may not be a good idea. If /some/ of >it works, it might be worth keeping. In OSA.so's case the breakage is pretty fundamental, e.g. not being able to compile scripts from source is pretty much a deal-breaker by itself, never mind the other bugs and huge chunk of missing API. I hear no great clamour from the gallery to use this module, broken or otherwise, so just punt the bastard out. It's virtually worthless as it is, and sticking it in will only make it harder to clean up the mess later on. Other modules I can't speak for, other than to say that if nobody's tested them yet then it would be better to keep them out than until they are. If folk really care about them, they'll whip together and run some tests quickly enough. And if they don't care about them, it means those modules aren't worth including in the standard library in the first place. (Seriously, what are the justifications for putting stuff nobody needs or wants into the standard library?) >>>>Kicking a lot of this stuff back out the standard library would >>>>be a good start, because it's clearly not qualified to be there. >>>>Push it into 'MacAll', and take it from there. >>> >>>Well obviously that's not an option, >> >>Why? All it means users have to do two installs instead of one to >>get set up which is no huge effort, and in practice the MacPython >>installer could bundle and run a recent copy of the MacAll >>installer for convenience. And once all this stuff is out the >>standard library it's free to be working on without the onerous >>scheduling restrictions and personnel bottleneck that comes from >>being locked up in the standard library. Have I missed something? > >It can't happen until Python 2.6 at the earliest. I don't think >it's very likely to go away anyway. Good luck! Why so long? Merely refactoring the distribution doesn't break backwards compatibility so I don't see why the reorganisation couldn't be done during 2.4's tenure? >My point is that it's perfectly fine to IGNORE THE STANDARD LIBRARY. It's fine for users to avoid the standard library. But that doesn't excuse filling it up with crap and then saying we shouldn't be concerned by this behaviour because users can always go elsewhere if they don't like it. Different issue. If you can't see any problems in having two parallel libraries: one an officially sanctioned and bundled broken-ass POS and the other a giant third-party band-aid, then you really need to start looking harder. The damage it could cause MacPython's public image and credibility alone should be of significant concern. It's like letting your house get covered in three feet of rotting unwashed dishes and cat poop and then wondering why nobody wants to come round and visit any more. It does a disservice to Python's reputation, its developers and its end-users, and it's the sort of behaviour that'll eventually turn folk off Python and onto something else. My point? Doing a job badly is the _worst_ thing possible. If you can't or won't do it properly, you shouldn't to do it at all. has -- http://freespace.virgin.net/hamish.sanderson/ From berkowit at silcom.com Wed Mar 2 18:28:54 2005 From: berkowit at silcom.com (Paul Berkowitz) Date: Wed Mar 2 18:28:58 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: Message-ID: On 3/2/05 6:00 AM, "has" wrote: >> In this case, the API *asks* for an Alias. So, yeah, you do >> actually want an Alias. > > No, the TextEdit dictionary says 'alias', but the dictionary is > merely documentation, not the API itself, and dictionaries are > regularly incorrect. It should almost certainly read 'file'. IIRC, > the sdef format doesn't even list 'alias' as one of the standard > primitive types, so I've no idea where TextEdit gets it from. > Probably a blow on the head or something. The type 'alias' for the Save command in the Standard Suite is a long, longstanding bug in AppleScript. It should say 'file specification', or 'file', I guess. There's a special problem in AppleScript applications which have their own 'file' keywords meaning something else (like Outlook Express and Entourage), as you can imagine. Fortunately there is an equally longstanding coercion, performs by AppleScript itself, that allows you to use a string or Unicode text there. In OS X, the coercion is now to fileURL, I believe. Whether this coercion takes place at a deep enough level (AppleEvent?) that it will work also for appscript and MacPython, I don't know. If you try it, what happens? In _any_ AppleScriptable application, you can always just use the text file path for 'save' in AppleScript, and it works. -- Paul Berkowitz From bob at redivi.com Wed Mar 2 19:31:58 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 2 19:32:08 2005 Subject: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain) In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> <6b9708d0c3f21835c36d39d7f1be2bac@redivi.com> Message-ID: <2923862af13c29f20638bf30c12a826e@redivi.com> On Mar 2, 2005, at 9:51, has wrote: > Bob wrote: > >> If you learn bgen and submit proper patches > > Without proper documentation and tutorials? Sorry, but masochistic > self-flagellation is not my thing. This is somebody else's house of > cards to sort out before everyone else can seriously be expected to > play in it. Yet you screw around with the Carbon modules, which also have no documentation or tutorials? > Besides, what's the point in me going to the trouble of properly > patching something if the fix won't percolate into the main > distribution for another year when I need it now? If the fix didn't consist of adding new features, and you submitted it today, it could be in 2.4.1 in less than two weeks. >> You're confusing issues here. The problem is that you need OSA >> functionality. Removing something from the standard library does >> nothing to solve that problem. > > No, I'm using OSA.so as an illustrative example because I'm already > familiar with it. The point is that potentially broken modules should > not be going into standard library. And until they've been tested, all > modules should be considered potentially broken. OSA.so is a prime > example: I _know_ it hasn't been tested, because it took me five > minutes to discover the first deal-killer bug. Other modules may be > just as untested, but I can't speak for them as I've not tried them > myself. > > In the case of OSA.so and any other new MacPython 2.4 additions that > haven't been tested, until Jack posts a final MacPython 2.4 > distribution then it ought to be safe to revoke their inclusion. The extension(s) are part of Python 2.4, and follow the same policy as anything else in there. The lack of a binary release doesn't really mean anything. >> Removing the extension may or may not be a good idea. If /some/ of >> it works, it might be worth keeping. > > In OSA.so's case the breakage is pretty fundamental, e.g. not being > able to compile scripts from source is pretty much a deal-breaker by > itself, never mind the other bugs and huge chunk of missing API. I > hear no great clamour from the gallery to use this module, broken or > otherwise, so just punt the bastard out. It's virtually worthless as > it is, and sticking it in will only make it harder to clean up the > mess later on. > > Other modules I can't speak for, other than to say that if nobody's > tested them yet then it would be better to keep them out than until > they are. If folk really care about them, they'll whip together and > run some tests quickly enough. And if they don't care about them, it > means those modules aren't worth including in the standard library in > the first place. (Seriously, what are the justifications for putting > stuff nobody needs or wants into the standard library?) It's already there, so it's not going anywhere in 2.4. The justification is that people *did* ask for an OSA wrapper -- I believe you were one of the larger proponents. It's partially your fault for not testing it *before* final release. >>>>> Kicking a lot of this stuff back out the standard library would be >>>>> a good start, because it's clearly not qualified to be there. Push >>>>> it into 'MacAll', and take it from there. >>>> >>>> Well obviously that's not an option, >>> >>> Why? All it means users have to do two installs instead of one to >>> get set up which is no huge effort, and in practice the MacPython >>> installer could bundle and run a recent copy of the MacAll installer >>> for convenience. And once all this stuff is out the standard library >>> it's free to be working on without the onerous scheduling >>> restrictions and personnel bottleneck that comes from being locked >>> up in the standard library. Have I missed something? >> >> It can't happen until Python 2.6 at the earliest. I don't think it's >> very likely to go away anyway. Good luck! > > Why so long? Merely refactoring the distribution doesn't break > backwards compatibility so I don't see why the reorganisation couldn't > be done during 2.4's tenure? As I stated before, "MacAll" can't use the Carbon namespace, so this trivial reorganization is not possible. >> My point is that it's perfectly fine to IGNORE THE STANDARD LIBRARY. > > It's fine for users to avoid the standard library. But that doesn't > excuse filling it up with crap and then saying we shouldn't be > concerned by this behaviour because users can always go elsewhere if > they don't like it. Different issue. If you can't see any problems in > having two parallel libraries: one an officially sanctioned and > bundled broken-ass POS and the other a giant third-party band-aid, > then you really need to start looking harder. The damage it could > cause MacPython's public image and credibility alone should be of > significant concern. It's like letting your house get covered in three > feet of rotting unwashed dishes and cat poop and then wondering why > nobody wants to come round and visit any more. It does a disservice to > Python's reputation, its developers and its end-users, and it's the > sort of behaviour that'll eventually turn folk off Python and onto > something else. > > My point? Doing a job badly is the _worst_ thing possible. If you > can't or won't do it properly, you shouldn't to do it at all. Very few people care that undocumented modules don't work correctly. You have to look pretty hard to even notice their existence in the first place. I've never heard of a broken undocumented standard library module becoming a deal-breaker for someone new to Python. -bob From hengist.podd at virgin.net Wed Mar 2 22:02:33 2005 From: hengist.podd at virgin.net (has) Date: Wed Mar 2 22:02:43 2005 Subject: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain) In-Reply-To: <2923862af13c29f20638bf30c12a826e@redivi.com> References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> <6b9708d0c3f21835c36d39d7f1be2bac@redivi.com> <2923862af13c29f20638bf30c12a826e@redivi.com> Message-ID: Bob wrote: >>>If you learn bgen and submit proper patches >> >>Without proper documentation and tutorials? Sorry, but masochistic >>self-flagellation is not my thing. This is somebody else's house of >>cards to sort out before everyone else can seriously be expected to >>play in it. > >Yet you screw around with the Carbon modules, which also have no >documentation or tutorials? No more than I can help. And there is documentation if you're willing to work through docstrings and Apple docs to extract the relevant info. It's not much fun, but it's doable. >>Besides, what's the point in me going to the trouble of properly >>patching something if the fix won't percolate into the main >>distribution for another year when I need it now? > >If the fix didn't consist of adding new features With specific regard to OSA.so, of course it would consist of adding new features: half the damn OSA API is missing from the stupid thing. >>In the case of OSA.so and any other new MacPython 2.4 additions >>that haven't been tested, until Jack posts a final MacPython 2.4 >>distribution then it ought to be safe to revoke their inclusion. > >The extension(s) are part of Python 2.4, and follow the same policy >as anything else in there. The lack of a binary release doesn't >really mean anything. Whatever; if it's too late to change then write it off; leave it in the standard library but expunge all mention of it and maybe add a warning to let the unwary know it's duff. Anyway, let's not lose site of the big picture: what really matters is to change the rules so this kind of nonsense doesn't happen again. Do you agree with that? >It's already there, so it's not going anywhere in 2.4. The >justification is that people *did* ask for an OSA wrapper -- I >believe you were one of the larger proponents. No, I wanted a Python OSA component. Different thing. The only person I know was asking for an OSA wrapper was Donovan, and he went off to work on Nevow yonks ago and AFAIK never did anything with it. >It's partially your fault for not testing it *before* final release. No, don't you try dumping this on me. It's _entirely_ the fault of whoever decided to include an untested module in the standard library. Doesn't matter if there's a hundred or a thousand or a million people screaming for it; doesn't matter how loud they scream, throw tantrums or turn blue in the face. As I already said, it's really simple: if nobody cares about it enough to test it then don't put it in. No exceptions. Look, if I submitted a completely unused, untested and potentially broken module for inclusion in the standard library I'd be told to get lost and not come back until I'd fully addressed that, and quite right too. Please tell me the justification for the apparent double standard here. In addition, I believe submission rules for the standard Python distribution require modules not only to work but also be in widespread usage before it'll even get looked at. Why should MacPython not be following this rule too? This is not personal: I'm not looking for blood, to cause embarassment, assign guilt, score petty points, etc. I am simply trying to show there is an ongoing problem here that folk should acknowlege and try to address. >>>It can't happen until Python 2.6 at the earliest. I don't think >>>it's very likely to go away anyway. Good luck! >> >>Why so long? Merely refactoring the distribution doesn't break >>backwards compatibility so I don't see why the reorganisation >>couldn't be done during 2.4's tenure? > >As I stated before, "MacAll" can't use the Carbon namespace, so this >trivial reorganization is not possible. It could if you just punted the _entire_ Carbon namespace into MacAll. Or are there dependencies in the core Python framework that prevent this? And if there is, hell, why not just deprecate the whole thing and create a new 'carbon' namespace in MacAll and tell folk to use that in future? You might never get rid of Carbon, but at least it'll get it sufficiently out the way for a clean new officially sanctioned version to set up shop. >>My point? Doing a job badly is the _worst_ thing possible. If you >>can't or won't do it properly, you shouldn't to do it at all. > >Very few people care that undocumented modules don't work correctly. >You have to look pretty hard to even notice their existence in the >first place. I've never heard of a broken undocumented standard >library module becoming a deal-breaker for someone new to Python. "MacPython: We've all this great Mac-specific stuff, but we won't tell you how to use any of it. Also, quite a bit of it is broken because we couldn't be bothered to do do a decent job of it." This is not the way to make a great impression with users. And really, what is the point of wasting valuable time and effort doing a half-assed job? It could be spent much more profitably elsewhere doing something more productive: writing modules you actually care about yourself, providing better documentation for existing modules, spending time with the kids, getting pleasantly hammered down the pub, etc. And it does matter, because sooner or later folk will want to use Mac-specific features either directly or indirectly - it's one of the reasons for choosing MacPython in the first place. It's the same BS that Apple pull with AppleScript: looks ultra-tasty from the outside, but some munching later and you start to realise there's this really really bad taste in your mouth, plus a wriggling sensation you don't even want to think about. Apple are just a bunch of classy tarts only interested in my wallet, but I expect better from the honest and hardworking artisans behind MacPython. And I expect the folk at the top - the ones directly responsible for the project's current and future well-being - to be the most stringent, selective and disciplined of all. has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Wed Mar 2 22:39:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 2 22:39:14 2005 Subject: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain) In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> <6b9708d0c3f21835c36d39d7f1be2bac@redivi.com> <2923862af13c29f20638bf30c12a826e@redivi.com> Message-ID: <49cb45e7cc96ade6e069936d747b5404@redivi.com> On Mar 2, 2005, at 16:02, has wrote: > Bob wrote: > >>>> It can't happen until Python 2.6 at the earliest. I don't think >>>> it's very likely to go away anyway. Good luck! >>> >>> Why so long? Merely refactoring the distribution doesn't break >>> backwards compatibility so I don't see why the reorganisation >>> couldn't be done during 2.4's tenure? >> >> As I stated before, "MacAll" can't use the Carbon namespace, so this >> trivial reorganization is not possible. > > It could if you just punted the _entire_ Carbon namespace into MacAll. > Or are there dependencies in the core Python framework that prevent > this? And if there is, hell, why not just deprecate the whole thing > and create a new 'carbon' namespace in MacAll and tell folk to use > that in future? You might never get rid of Carbon, but at least it'll > get it sufficiently out the way for a clean new officially sanctioned > version to set up shop. If you punted the entire Carbon namespace into MacAll, it wouldn't be compatible with any current Python, which is a non-starter. If you named it carbon, it would definitely be the cause of headaches and confusion due to the default case insensitivity of HFS+ and the similarity to the existing namespace. Anyway, many of the things in the Carbon namespace aren't Carbon at all. QuickTime, for example. -bob From n8gray at gmail.com Thu Mar 3 04:02:44 2005 From: n8gray at gmail.com (Nathaniel Gray) Date: Thu Mar 3 04:03:30 2005 Subject: [Pythonmac-SIG] EasyDialogs + Appscript + iPhoto = zombies! Message-ID: Hi, I've written a small appscript that exports an iPhoto album using the "album" photo album tool (written in Perl, but I don't have time to rewrite it... :-/). I wrote the Python script and installed it as /Library/Scripts/Applications/iPhoto/iphoto2album so I can use it from the global Scripts menu. It works fine, but it leaves a zombie Python process lying around every time I run it. I don't know a whole lot about unix process control, but I found that to avoid zombie processes you need to "double-fork". So here's a mock-up of my current code, mostly copied from http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012: #### BEGIN #! /usr/bin/env pythonw import os, sys import EasyDialogs as dialogs, datetime from appscript import * def main(): # This is obviously a dummy main function errfile = open("/Users/n8gray/ip2a.errors", "w") errfile.write("Made it!") errfile.close() dialogs.Message( "Everything works ok." ) try: pid = os.fork() if pid > 0: # exit first parent sys.exit(0) except OSError, e: print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno, e.strerror) sys.exit(1) # decouple from parent environment #os.chdir("/") # I've tried with and without this line. os.setsid() os.umask(0) # do second fork try: pid = os.fork() if pid > 0: # exit from second parent, print eventual PID before # print "Daemon PID %d" % pid sys.exit(0) except OSError, e: print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno, e.strerror) sys.exit(1) # Open file descriptors if not sys.stderr: sys.stderr = sys.stdout si = file('/dev/null', 'r') so = file('/dev/null', 'a+') se = file('/dev/null', 'a+', 0) # Redirect standard file descriptors. os.dup2(si.fileno(), sys.stdin.fileno()) os.dup2(so.fileno(), sys.stdout.fileno()) os.dup2(se.fileno(), sys.stderr.fileno()) # start the daemon main loop main() #### END Unfortunately, it still produces a zombie after each run and I don't see the dialog either. The error log file does get written to, though, so I know the double-fork succeeds. Can anybody help me figure out what the problems are? Also, is there any way to get rid of all the damn zombie processes on my system without rebooting? Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> From dp at ulaluma.com Thu Mar 3 07:09:17 2005 From: dp at ulaluma.com (Donovan Preston) Date: Thu Mar 3 07:09:22 2005 Subject: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain) In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> <6b9708d0c3f21835c36d39d7f1be2bac@redivi.com> <2923862af13c29f20638bf30c12a826e@redivi.com> Message-ID: On Mar 2, 2005, at 1:02 PM, has wrote: >> It's already there, so it's not going anywhere in 2.4. The >> justification is that people *did* ask for an OSA wrapper -- I >> believe you were one of the larger proponents. > > No, I wanted a Python OSA component. Different thing. The only person > I know was asking for an OSA wrapper was Donovan, and he went off to > work on Nevow yonks ago and AFAIK never did anything with it. I wanted an OSA module so that it would be possible to write a Python OSA component using a more inside out approach. Writing a Python OSA component is going to require accessing much of the functionality in OSA.h from Python, and bgen is a reasonably expedient way to expose Carbon headers in the Universal Headers format. Unfortunately, unless you try the resulting module, things do tend to be broken without manual tweaking. I was able to write bgen wrappers for CarbonEvents and IBCarbon and tweak the bgen module by hand until the resulting modules were actually usable for trivial applications, but obviously nobody ever tried this with the OSA module. I am still interested in producing a Python OSA component, hopefully with the OSA module, but unfortunately it is a lot more work than I have free time for at the moment. I lost my drive to work on it when it became clear that HAS was far more energetic in this space than I was, and HAS didn't seem willing to listen to what I had to say about the subject or collaborate with anybody. dp From colby at astro.berkeley.edu Wed Mar 2 00:51:53 2005 From: colby at astro.berkeley.edu (Colby Gutierrez-Kraybill) Date: Thu Mar 3 11:11:40 2005 Subject: [Pythonmac-SIG] Using PIL/Compiling/_imagingtk Message-ID: <8afbff9667825af7d7e97a8c3bb78b81@astro.berkeley.edu> Howdie, I'm attempting to use the Python Imaging Library on a mac os x (panther 10.3.8) box with the standard python install, along with the macpython addons and the tcltkaqua packages. I first installed the macpython addons (http://ftp.cwi.nl/jack/python/mac/MacPython-Panther-2.3-2.dmg) for 10.3, then ran the package manager, which lead to a 404 error, and in-turn lead me to this post about the 10.3 package manager being unmaintained: http://mail.python.org/pipermail/pythonmac-sig/2005-February/013230.html I got the latest tclTkAqua-BI from: http://tcltkaqua.sourceforge.net/ (8.4.9.0) When I run python, I can now import Tkinter, and run a helloworld program to pop up a window, etc... The package manager, using Bob Ippolito's list http://undefined.org/python/pimp/darwin-7.2.0-Power_Macintosh.plist Specifies installing PIL from source, by hand... So, I got the latest 1.1.4 tgz from Pythonware, got through the ligImaging configure process but the make fails with: ... cc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/Library/Frameworks/Tcl.framework/Headers -I/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c _imagingtk.c -o build/temp.darwin-7.8.0-Power_Macintosh-2.3/_imagingtk.o In file included from /Library/Frameworks/Tk.framework/Headers/tk.h:96, from _imagingtk.c:20: /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.8.0-Power_Macintosh-2.3/_imagingtk.o build/temp.darwin-7.8.0-Power_Macintosh-2.3/Tk/tkImaging.o -LlibImaging -lImaging -o build/lib.darwin-7.8.0-Power_Macintosh-2.3/_imagingtk.so ld: Undefined symbols: _Tcl_AppendResult _Tcl_CreateCommand _Tk_FindPhoto _Tk_PhotoBlank _Tk_PhotoPutBlock_NoComposite error: command 'gcc' failed with exit status 1 Very Very Annoying... Based on other similar posts, this appears to be some recent inconsistency between the builds. Where do the above routines live and what's the proper direction to follow in getting some patch back to the 1.1.4 Imaging release to make sure this compiles? - Colby From bob at redivi.com Thu Mar 3 11:39:33 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 3 11:39:31 2005 Subject: [Pythonmac-SIG] Using PIL/Compiling/_imagingtk In-Reply-To: <8afbff9667825af7d7e97a8c3bb78b81@astro.berkeley.edu> References: <8afbff9667825af7d7e97a8c3bb78b81@astro.berkeley.edu> Message-ID: <037edbf6d886fd549c48c2b73fa07a52@redivi.com> On Mar 1, 2005, at 6:51 PM, Colby Gutierrez-Kraybill wrote: > I'm attempting to use the Python Imaging Library > on a mac os x (panther 10.3.8) box with the standard > python install, along with the macpython addons > and the tcltkaqua packages. The package manager repository at undefined.org is unmaintained, and probably will never be updated. The good news is that I've got another one that doesn't use PackageManager at all: http://undefined.org/python/packages.html PIL 1.1.5c1 is available. It was built from unmodified source about half an hour ago, linked against tiff 3.7.1, jpeg 6b, freetype 2.1.9 rev 1, Tcl/Tk 8.4 (frameworks). -bob From hengist.podd at virgin.net Thu Mar 3 16:29:42 2005 From: hengist.podd at virgin.net (has) Date: Thu Mar 3 16:30:41 2005 Subject: [Pythonmac-SIG] Re: repackaging MacPython (was: Re: broken modules) In-Reply-To: <49cb45e7cc96ade6e069936d747b5404@redivi.com> References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> <6b9708d0c3f21835c36d39d7f1be2bac@redivi.com> <2923862af13c29f20638bf30c12a826e@redivi.com> <49cb45e7cc96ade6e069936d747b5404@redivi.com> Message-ID: Bob wrote: >If you named it carbon, it would definitely be the cause of >headaches and confusion due to the default case insensitivity of >HFS+ and the similarity to the existing namespace. 'lo-carb'? :) I wasn't exactly putting any thought into it; nit-picky details really aren't important here. To summarise: My main suggestion was that the whole Carbon package plus other Mac-specific modules might be moved out of the Python.framework distribution and into a separate 'MacAll' distribution (c.f. Win32All), leaving Python.framework as basically just a plain-vanilla framework build of the standard Python distribution. That'd allow the Mac community to evolve the Mac-specific stuff at its own rate, rather than being inextricably tied to the slower (and slowing?) upgrade cycle of standard Python. IOW, loosen the couplings between standard Python and Mac-specific extensions without changing any of the content or behaviour, because Loose Coupling = Better. I know Jack's mulled over this idea of repackaging MacPython (though I dunno to what extent) and I personally believe it has serious merit, even if this thread does seem to keep losing sight of it by sidetracking into nitpicky details (hey, mea-culpa, seeing as it's my thread:p). Anyway, I've probably said my bit about as well as I can and I'm off for the next week, so I'm going to leave it there and maybe someone else can run with the thought if they want to. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Thu Mar 3 16:30:06 2005 From: hengist.podd at virgin.net (has) Date: Thu Mar 3 16:30:43 2005 Subject: OSA.so (was: Re: [Pythonmac-SIG] CFURL Pain) Message-ID: Donovan Preston wrote: > > No, I wanted a Python OSA component. Different thing. The only person > > I know was asking for an OSA wrapper was Donovan, and he went off to > > work on Nevow yonks ago and AFAIK never did anything with it. > >I wanted an OSA module so that it would be possible to write a Python >OSA component using a more inside out approach. There's basically two halves to OSA. One half is used to implement OSA language components. The other half allows client apps to use them. OSA.so implements the API for the second of these, allowing Python to load and execute scripts written in any OSA language. The Carbon equivalent to Cocoa's NSAppleScript, except with a much more powerful and much less friendly API. To implement a PythonOSA component, you need to write a C wrapper around the Python interpreter's C API [1]. That wrapper then exports a bunch of callbacks (UUPs to be precise) that OSA calls to compile/decompile/execute/load/store/etc a Python script on behalf of a client. I don't think there's anything in OSA.so that'd help with that. I've been looking at OSA.so recently as I'd like to implement attachability in a PyObjC-based app I'm writing and NSAppleScript is too limited for what I want to do. While I've occasionally given the PythonOSA problem a passing glance, it's not something I'm as interested in solving myself as I haven't had any personal need for it to date and my C isn't good enough anyway. >I am still interested in producing a Python OSA component, hopefully >with the OSA module, but unfortunately it is a lot more work than I >have free time for at the moment. I lost my drive to work on it when it >became clear that HAS was far more energetic in this space than I was, >and HAS didn't seem willing to listen to what I had to say about the >subject or collaborate with anybody. I do remember being very grateful for advice when I was starting out on appscript. Can't recall ever being anti-collaborative or that; I may be abrasive and critical and behave differently to other programmers, but then I'm from a different background so maybe there was some accidental culture clash? Apologies if any offence was caused; it certainly wasn't intentional. Cheers, has [1] It might be possible to write a smaller C wrapper that allows you to install Python functions as callbacks for handling the compile/decompile/execute/etc. stuff within Python using exec and friends rather than doing the whole lot in C, which might be a bit more convenient than doing everything in C. I don't know enough about how the Python interpreter works to say if this would be practical or not. -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Thu Mar 3 16:31:29 2005 From: hengist.podd at virgin.net (has) Date: Thu Mar 3 16:31:36 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: Message-ID: Paul Berkowitz wrote: >The type 'alias' for the Save command in the Standard Suite is a long, >longstanding bug in AppleScript. Replacing (as of 10.3) a previous long, longstanding implementation bug where it was specified as a POSIX path string. :p I take it 'alias' is just a documentation error then, and the application will also accept a file spec/file url type identifying an existing/not-yet-created file. >Fortunately there is an equally >longstanding coercion, performs by AppleScript itself, that allows you to >use a string or Unicode text there Presumably there's a POSIX path string-to-file object coercion introduced in 10.3 to maintain compatibility scripts written for Cocoa apps in 10.2, where 'save...in' took a POSIX path string instead of a file object. In aem's case at least, I'd be extremely reluctant simply to replace all use of Mac file objects with POSIX path strings. I've already tried this once and it just caused problems. I really would like an elegant, easy-to-use solution that respects AE file objects and provides user-friendly Python equivalents that hide as much of the underlying clumsiness without introducing any new problems. Might be a non-trivial task, but I think it'd be worth doing, especially if Python's to become a genuine replacement for AppleScript. >In OS X, the coercion is now to fileURL, >I believe. Whether this coercion takes place at a deep enough level >(AppleEvent?) that it will work also for appscript and MacPython, I don't >know. If you try it, what happens? I've tried supplying FileURLs to Tex-Edit Plus in 10.2 and it seemed to work ok. If CFURL worked properly I'd probably just sling in the code to coerce AEDescs of typeFSSpec and typeFSRef to typeFileURL and spit out CFURLs, then wait and see if anyone runs into problems. NSURL is an alternative, though I'm still a little uncomfortable about coupling aem to PyObjC just for the sake of one little type; I'll think about this a bit more. It would definitely be nice if the whole Mac file type muddle could be reduced - at least at the end-user level - to high-level, user-friendly FileURL and Alias classes. The only questions are: can we get there safely, and if so, how? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From berkowit at silcom.com Thu Mar 3 16:54:43 2005 From: berkowit at silcom.com (Paul Berkowitz) Date: Thu Mar 3 16:54:47 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: Message-ID: On 3/3/05 7:31 AM, "has" wrote: > Paul Berkowitz wrote: > >> The type 'alias' for the Save command in the Standard Suite is a long, >> longstanding bug in AppleScript. > > Replacing (as of 10.3) a previous long, longstanding implementation > bug where it was specified as a POSIX path string. :p Bo, that one was quite short-standing (OS 10.1 and 10.2) and only for TextEdit. Only TextEdit specified a POSIX path string for 'save' - it has now been changed to standard AppleScript colon-delimited paths to correspond with all other apps. > > I take it 'alias' is just a documentation error then, and the > application will also accept a file spec/file url type identifying an > existing/not-yet-created file. Yes. > > >> Fortunately there is an equally >> longstanding coercion, performs by AppleScript itself, that allows you to >> use a string or Unicode text there > > Presumably there's a POSIX path string-to-file object coercion > introduced in 10.3 to maintain compatibility scripts written for > Cocoa apps in 10.2, where 'save...in' took a POSIX path string > instead of a file object. No, that's broken - it was only TextEdit in OS 10.1 and 10.2 that ever did the POSIX paths. ( 'save document 1 in "/Volumes/PB G5 HD Panther/Users/berkowit/Desktop/TestDoc.rtf"' saves the document in a file of that exact entire name - complete with forward slashes - on my root startup disk!!) Only colon-delimited paths work correctly now, not POSIX paths. I can't imagine that there are too many broken scripts since TextEdit's scriptability is so limited in the first place that there's not much you can do with it. -- Paul Berkowitz From pecora at anvil.nrl.navy.mil Thu Mar 3 20:04:32 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Thu Mar 3 20:04:33 2005 Subject: [Pythonmac-SIG] One IDE can find sys._buf, the other can't. What's going on? Message-ID: <42275FC0.5030300@anvil.nrl.navy.mil> I ran some test code in the MacPython IDE and then from BBEdit (should be same as TextWrangle that some of you use). It runs in the Mac IDE, but I get this error in BBEdit: File "Drive:Users:louispecora:Code:python:general:general.py"; Line 132: AttributeError: 'file' object has no attribute '_buf' That line of code is this one import sys,Carbon sys.stdout._buf = say or '? ' # This line and the next print out the prompt 'say' <------ bad line I cannot figure this one out. I'm suspecting it's some sort of Python path or multiple Python version problem, but I have no clue. I am running OS X 10.3.8 on a 1.25 GHz PB. I was really enjoying the BBEdit approach since it is a great code editor and seemed to run generic stuff well until I hit this problem. Maybe I need to run that Panther stuff that fixes the Mac version. Any help greatly appreciated. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From bob at redivi.com Thu Mar 3 20:56:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 3 20:56:46 2005 Subject: [Pythonmac-SIG] One IDE can find sys._buf, the other can't. What's going on? In-Reply-To: <42275FC0.5030300@anvil.nrl.navy.mil> References: <42275FC0.5030300@anvil.nrl.navy.mil> Message-ID: <4725b574c17969308e73752745a3bd26@redivi.com> On Mar 3, 2005, at 14:04, Louis Pecora wrote: > I ran some test code in the MacPython IDE and then from BBEdit (should > be same as TextWrangle that some of you use). It runs in the Mac IDE, > but I get this error in BBEdit: > > File "Drive:Users:louispecora:Code:python:general:general.py"; Line > 132: AttributeError: 'file' object has no attribute '_buf' > > That line of code is this one > > import sys,Carbon > sys.stdout._buf = say or '? ' # This line and the next print out > the prompt 'say' <------ bad line > > I cannot figure this one out. I'm suspecting it's some sort of Python > path or multiple Python version problem, but I have no clue. > > I am running OS X 10.3.8 on a 1.25 GHz PB. > > I was really enjoying the BBEdit approach since it is a great code > editor and seemed to run generic stuff well until I hit this problem. > > Maybe I need to run that Panther stuff that fixes the Mac version. > Any help greatly appreciated. Uh.. I have no idea where you got the idea to do that, but that _buf attribute is specific to the MacPython IDE. It works *nowhere else*. If you could explain what it does, I'm sure there's an alternative that works elsewhere. Leading underscores in Python typically mean "don't touch this". -bob From Martina at Oefelein.de Thu Mar 3 21:31:09 2005 From: Martina at Oefelein.de (Martina Oefelein) Date: Thu Mar 3 21:31:14 2005 Subject: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain) In-Reply-To: <2923862af13c29f20638bf30c12a826e@redivi.com> References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> <6b9708d0c3f21835c36d39d7f1be2bac@redivi.com> <2923862af13c29f20638bf30c12a826e@redivi.com> Message-ID: <62590feab56afbed5dc0fec9cbdbf36d@Oefelein.de> Hi Bob: > Very few people care that undocumented modules don't work correctly. > You have to look pretty hard to even notice their existence in the > first place. I've never heard of a broken undocumented standard > library module becoming a deal-breaker for someone new to Python. Looking at the Global module index http://python.org/doc/2.4/modindex.html it's hard not to notice the existence of the long list of Carbon.something modules in the left column. I think it would be a good idea to replace this with a single entry for Carbon, that explains that those modules are deprecated and one should use PyObjC instead. ciao Martina From bob at redivi.com Thu Mar 3 21:39:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 3 21:39:49 2005 Subject: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain) In-Reply-To: <62590feab56afbed5dc0fec9cbdbf36d@Oefelein.de> References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> <2209330ca399ef1145650a3d08a2ce3f@redivi.com> <4faea3bede1248cbbc063b80ea2bfebc@redivi.com> <49bb0f1dac78aa2d429c2c64d4ff00fd@redivi.com> <6b9708d0c3f21835c36d39d7f1be2bac@redivi.com> <2923862af13c29f20638bf30c12a826e@redivi.com> <62590feab56afbed5dc0fec9cbdbf36d@Oefelein.de> Message-ID: On Mar 3, 2005, at 15:31, Martina Oefelein wrote: > Hi Bob: > >> Very few people care that undocumented modules don't work correctly. >> You have to look pretty hard to even notice their existence in the >> first place. I've never heard of a broken undocumented standard >> library module becoming a deal-breaker for someone new to Python. > > Looking at the Global module index > http://python.org/doc/2.4/modindex.html > it's hard not to notice the existence of the long list of > Carbon.something modules in the left column. > > I think it would be a good idea to replace this with a single entry > for Carbon, that explains that those modules are deprecated and one > should use PyObjC instead. They're not deprecated because nothing technically replaces them. PyObjC, via Cocoa, gives you a lot of the functionality in a different (and likely more sensible) way. The CoreFoundation bits can and should (but are not currently) be replaced by a PyObjC implementation, but something like QuickTime, for example, isn't so easy. -bob From pecora at anvil.nrl.navy.mil Thu Mar 3 22:57:50 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Thu Mar 3 22:57:54 2005 Subject: Getting stdin using TextWrangler or BBEdit, but not MacPython (was: [Pythonmac-SIG] One IDE can find sys._buf, the other can't. What's going on?) In-Reply-To: References: <42275FC0.5030300@anvil.nrl.navy.mil> <4725b574c17969308e73752745a3bd26@redivi.com> <42277BC7.70808@anvil.nrl.navy.mil> Message-ID: <4227885E.8040407@anvil.nrl.navy.mil> Bob Ippolito wrote: > As far as this code goes, you might be able to just get away with it > if you do: > > # check for MacPython IDE > if hasattr(sys.stdout, '_buf'): > sys.stdout._buf = ... You're right this is a test that would shut off the _buf part of the code if I were not using MacPython. > > It really depends on what the rest of your code looks like. If it > does sys.stdout.readline() for example, it's still going to be broken, > because you can't normally read from stdout. The rawinput() function > might do what you want everywhere else, though. I can't seem to get rawinput or raw_input() to work. Ignoring my previous code. I just want something that can take standard input so, for instance, when I prompt with print "Input 2 ints and a float" The program will wait until I type, say 2 5 5.476 (return) Then hand back the three numbers either as a string, a list, or individual int and float types so I can process them with my program. Sort of like int i1, i2; float f1; scanf(" %d %d %e", i1, i2, f1); would do in C using stdin. Or even a gets() which I could then process to pull out the two ints and a float. I'm just looking for simple input of numbers and strings. I'd like to do this from BBEdit rather than MacPython. Anyone out there done this with TextWrangler? -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From bob at redivi.com Thu Mar 3 23:16:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 3 23:16:19 2005 Subject: Getting stdin using TextWrangler or BBEdit, but not MacPython (was: [Pythonmac-SIG] One IDE can find sys._buf, the other can't. What's going on?) In-Reply-To: <4227885E.8040407@anvil.nrl.navy.mil> References: <42275FC0.5030300@anvil.nrl.navy.mil> <4725b574c17969308e73752745a3bd26@redivi.com> <42277BC7.70808@anvil.nrl.navy.mil> <4227885E.8040407@anvil.nrl.navy.mil> Message-ID: On Mar 3, 2005, at 16:57, Louis Pecora wrote: > Bob Ippolito wrote: > >> As far as this code goes, you might be able to just get away with it >> if you do: >> >> # check for MacPython IDE >> if hasattr(sys.stdout, '_buf'): >> sys.stdout._buf = ... > > You're right this is a test that would shut off the _buf part of the > code if I were not using MacPython. >> >> It really depends on what the rest of your code looks like. If it >> does sys.stdout.readline() for example, it's still going to be >> broken, because you can't normally read from stdout. The rawinput() >> function might do what you want everywhere else, though. > > I can't seem to get rawinput or raw_input() to work. Ignoring my > previous code. I just want something that can take standard input so, > for instance, when I prompt with > > print "Input 2 ints and a float" > > The program will wait until I type, say > > 2 5 5.476 (return) > > Then hand back the three numbers either as a string, a list, or > individual int and float types so I can process them with my program. > Sort of like > int i1, i2; > float f1; > > scanf(" %d %d %e", i1, i2, f1); > would do in C using stdin. Or even a gets() which I could then > process to pull out the two ints and a float. > I'm just looking for simple input of numbers and strings. I'd like to > do this from BBEdit rather than MacPython. Anyone out there done this > with TextWrangler? I don't know a damn thing about TextWrangler, but this works with any Python that has a working stdin: while True: text = raw_input("Input 2 ints and a float: ") try: i1, i2, f1 = [t(v) for (t, v) in zip((int, int, float), text.split())] except ValueError, e: print 'Invalid Entry: %s' % (e,) continue break -bob From pecora at anvil.nrl.navy.mil Thu Mar 3 23:22:46 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Thu Mar 3 23:22:48 2005 Subject: [Pythonmac-SIG] Re: Getting stdin using TextWrangler or BBEdit, but not MacPython In-Reply-To: <188cb9953e253e01b07ddea4a98239f5@conncoll.edu> References: <42275FC0.5030300@anvil.nrl.navy.mil> <4725b574c17969308e73752745a3bd26@redivi.com> <42277BC7.70808@anvil.nrl.navy.mil> <4227885E.8040407@anvil.nrl.navy.mil> <188cb9953e253e01b07ddea4a98239f5@conncoll.edu> Message-ID: <42278E36.9090908@anvil.nrl.navy.mil> Charles Hartman wrote: > In TextWrangler something like this > while 1: > c = raw_input() > if c == 'quit': break > print c > works fine, if you choose Run in Terminal or Run with Debugger. If you > try to choose Output to New Window, it just quits immediately. But you > can certainly run it from within TW. Yes, that works. Thank you. I would have liked using the Output to keep it all in BBEdit, but I may have to go with the TW. Better than nothing. Thanks again. > > > Charles Hartman > Professor of English, Poet in Residence ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And you program computers. Cool. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From pecora at anvil.nrl.navy.mil Thu Mar 3 23:32:01 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Thu Mar 3 23:32:02 2005 Subject: [Pythonmac-SIG] Re: Getting stdin using TextWrangler or BBEdit, but not MacPython In-Reply-To: References: <42275FC0.5030300@anvil.nrl.navy.mil> <4725b574c17969308e73752745a3bd26@redivi.com> <42277BC7.70808@anvil.nrl.navy.mil> <4227885E.8040407@anvil.nrl.navy.mil> Message-ID: <42279061.4000305@anvil.nrl.navy.mil> Bob Ippolito wrote: > > I don't know a damn thing about TextWrangler, but this works with any > Python that has a working stdin: > > while True: > text = raw_input("Input 2 ints and a float: ") > try: > i1, i2, f1 = [t(v) for (t, v) in zip((int, int, float), > text.split())] > except ValueError, e: > print 'Invalid Entry: %s' % (e,) > continue > break > Yes, it works in a terminal. But it doesn't work in TextWrangler. Must be something about how that code editing app handles the Python I/O. But I can't expect you to fix that. :-) Thanks for your help. Will deal with the terminal approach. Muchas gracias. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From pecora at anvil.nrl.navy.mil Thu Mar 3 23:34:54 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Thu Mar 3 23:34:54 2005 Subject: [Pythonmac-SIG] Re: Getting stdin using TextWrangler or BBEdit, but not MacPython In-Reply-To: References: <42275FC0.5030300@anvil.nrl.navy.mil> <4725b574c17969308e73752745a3bd26@redivi.com> <42277BC7.70808@anvil.nrl.navy.mil> <4227885E.8040407@anvil.nrl.navy.mil> Message-ID: <4227910E.90205@anvil.nrl.navy.mil> Bob Ippolito wrote: > > I don't know a damn thing about TextWrangler, but this works with any > Python that has a working stdin: > > while True: > text = raw_input("Input 2 ints and a float: ") > try: > i1, i2, f1 = [t(v) for (t, v) in zip((int, int, float), > text.split())] > except ValueError, e: > print 'Invalid Entry: %s' % (e,) > continue > break > > -bob I should add that calling raw_input() gives the following error: File "Drive:Users:louispecora:Code:python:test_folder:junk.py"; Line 12: EOFError: EOF when reading a line Not sure what that tells you, but it seems to be how TextWrangler is dealing with stdin. Almost sounds like it is expecting input to be right there when called and seeing none, just sees an EOF. Oh, well. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From charles.hartman at conncoll.edu Fri Mar 4 00:59:50 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri Mar 4 00:59:55 2005 Subject: [Pythonmac-SIG] Re: Getting stdin using TextWrangler or BBEdit, but not MacPython In-Reply-To: <4227910E.90205@anvil.nrl.navy.mil> References: <42275FC0.5030300@anvil.nrl.navy.mil> <4725b574c17969308e73752745a3bd26@redivi.com> <42277BC7.70808@anvil.nrl.navy.mil> <4227885E.8040407@anvil.nrl.navy.mil> <4227910E.90205@anvil.nrl.navy.mil> Message-ID: <286b2eb0c78fa97f535d294e13394ba3@conncoll.edu> (Tried to answer before but it didn't go through) It works fine in TextWrangler if you choose (from TW's Run submenu) Run in Terminal; you're still doing your work in TW, just using Terminal for i/o. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Mar 3, 2005, at 5:34 PM, Louis Pecora wrote: > Bob Ippolito wrote: > >> >> I don't know a damn thing about TextWrangler, but this works with any >> Python that has a working stdin: >> >> while True: >> text = raw_input("Input 2 ints and a float: ") >> try: >> i1, i2, f1 = [t(v) for (t, v) in zip((int, int, float), >> text.split())] >> except ValueError, e: >> print 'Invalid Entry: %s' % (e,) >> continue >> break >> >> -bob > > I should add that calling raw_input() gives the following error: > > File "Drive:Users:louispecora:Code:python:test_folder:junk.py"; Line > 12: EOFError: EOF when reading a line > > Not sure what that tells you, but it seems to be how TextWrangler is > dealing with stdin. Almost sounds like it is expecting input to be > right there when called and seeing none, just sees an EOF. Oh, well. > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora@anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From juntunen at well.com Fri Mar 4 04:57:51 2005 From: juntunen at well.com (Thomas Juntunen) Date: Fri Mar 4 04:57:47 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <16888.25101.340579.859752@montanaro.dyndns.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/05, Skip Montanaro imposed order on a stream of electrons to say: > > Bob> It wouldn't be the worst thing in the world to buy 10.3 now, > Bob> because 10.4 is definitely more than a few weeks away, but you > Bob> certainly wouldn't be getting "full value" from it because it's 15 > Bob> months old (Oct 24 2003) already. > >Where would an interested person find a log of release dates? I don't know where to find the release dates for different Mac OS X revs, but Other World Computing is offering Panther for $49: http://eshop.macsales.com/shop/specials/ HTH, Thomas Juntunen -----BEGIN PGP SIGNATURE----- Version: PGP SDK 3.2.2 iQA/AwUBQifOqtFoei/9T3YdEQITwwCfTLvdlx464bBbqA9+hzMnkLyemAwAn3tY 2+n4IY7oFV+kmCe75UUqKoKf =Pkhs -----END PGP SIGNATURE----- From skip at pobox.com Fri Mar 4 05:08:39 2005 From: skip at pobox.com (Skip Montanaro) Date: Fri Mar 4 05:07:20 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: References: <16888.25101.340579.859752@montanaro.dyndns.org> Message-ID: <16935.57159.835689.507408@montanaro.dyndns.org> Thomas> I don't know where to find the release dates for different Mac Thomas> OS X revs, but Other World Computing is offering Panther for Thomas> $49: Thomas> http://eshop.macsales.com/shop/specials/ Thanks. I'll have to check to see if that will work for my laptop. I have plenty of other stuff on my plate though, so this particular issue has sort of moved to the back burner... Skip From bob at redivi.com Fri Mar 4 05:16:25 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 4 05:16:11 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <16935.57159.835689.507408@montanaro.dyndns.org> References: <16888.25101.340579.859752@montanaro.dyndns.org> <16935.57159.835689.507408@montanaro.dyndns.org> Message-ID: <117f017b6009270b23391e58d9f1f111@redivi.com> On Mar 3, 2005, at 11:08 PM, Skip Montanaro wrote: > > Thomas> I don't know where to find the release dates for different > Mac > Thomas> OS X revs, but Other World Computing is offering Panther > for > Thomas> $49: > > Thomas> http://eshop.macsales.com/shop/specials/ > > Thanks. I'll have to check to see if that will work for my laptop. I > have > plenty of other stuff on my plate though, so this particular issue has > sort > of moved to the back burner... > If it runs 10.2, it'll run 10.3. You'll probably notice better performance, too. -bob From skip at pobox.com Fri Mar 4 05:52:47 2005 From: skip at pobox.com (Skip Montanaro) Date: Fri Mar 4 05:51:26 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <117f017b6009270b23391e58d9f1f111@redivi.com> References: <16888.25101.340579.859752@montanaro.dyndns.org> <16935.57159.835689.507408@montanaro.dyndns.org> <117f017b6009270b23391e58d9f1f111@redivi.com> Message-ID: <16935.59807.135234.816068@montanaro.dyndns.org> >> Thanks. I'll have to check to see if that will work for my laptop. >> I have plenty of other stuff on my plate though, so this particular >> issue has sort of moved to the back burner... Bob> If it runs 10.2, it'll run 10.3. You'll probably notice better Bob> performance, too. Thanks. The check is in the mail... S From pecora at anvil.nrl.navy.mil Fri Mar 4 19:40:16 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Fri Mar 4 19:40:16 2005 Subject: [Pythonmac-SIG] More on stdin and python scripts in BBEdit and TextWrangler Message-ID: <4228AB90.90502@anvil.nrl.navy.mil> I contacted the software company for BBEdit and TextWrangler re: my problem with using stdin (e.g raw_input) when running a script from within the program (Unix Output window, not a terminal run window). Several people were interested so I thought I'd post the reply: scripts which are run directly within BBEdit cannot read from STDIN. In order to accomplish that, you'll need to either run them in the Terminal, or within a BBEdit shell worksheet (File -> New -> Shell Worksheet). (If you haven't used shell worksheets before, and don't require a fully interactive terminal session, you might want to give them a try, as they can be quite handy.) ------ The worksheet seems to solve that problem, but it does not enable me to use TextWrangler or BBEdit as an IDE-type environment. In fact what I want to do won't even work in the terminal window. I have some simple functions that require interactive use, i.e. Apple events (e.g. file open and saves using EasyDialogs). Using them terminates the program in a terminal, a python session (with the >>> prompt), or a worksheet with the message: MacOS.Error: (-1713, 'no user interaction is allowed') Sigh. Back to MacPython IDE. Seems to be the only option. Thanks for the feedback from many people. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From Martina at Oefelein.de Fri Mar 4 21:42:50 2005 From: Martina at Oefelein.de (Martina Oefelein) Date: Fri Mar 4 21:42:53 2005 Subject: [Pythonmac-SIG] More on stdin and python scripts in BBEdit and TextWrangler In-Reply-To: <4228AB90.90502@anvil.nrl.navy.mil> References: <4228AB90.90502@anvil.nrl.navy.mil> Message-ID: Hello Louis, > The worksheet seems to solve that problem, but it does not enable me > to use TextWrangler or BBEdit as an IDE-type environment. well, many people have been looking for a good python IDE on the Mac - in fact, there has been a really long discussion about this a few weeks ago. You might look it up in the archives. > In fact what I want to do won't even work in the terminal window. I > have some simple functions that require interactive use, i.e. Apple > events (e.g. file open and saves using EasyDialogs). Using them > terminates the program in a terminal, a python session (with the >>> > prompt), or a worksheet with the message: > > MacOS.Error: (-1713, 'no user interaction is allowed') just use pythonw instead of python. ciao Martina From pecora at anvil.nrl.navy.mil Fri Mar 4 22:23:26 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Fri Mar 4 22:23:26 2005 Subject: [Pythonmac-SIG] More on stdin and python scripts in BBEdit and TextWrangler In-Reply-To: References: <4228AB90.90502@anvil.nrl.navy.mil> Message-ID: <4228D1CE.8090400@anvil.nrl.navy.mil> Martina Oefelein wrote: > just use pythonw instead of python. > > ciao > Martina I have been tempted to look into several variations on Python, but I am wary of having to spend too much time installing other packages that are interdependent and having to tweak them to get it all to work. Maybe I'm making more of this than there really is. Can you say what is necessary to get Pythonw up and running over a plain Apple installation on OS X 10.3 and MacPython add ons? Thanks for any help. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From charles.hartman at conncoll.edu Fri Mar 4 22:38:30 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri Mar 4 22:38:37 2005 Subject: [Pythonmac-SIG] More on stdin and python scripts in BBEdit and TextWrangler In-Reply-To: <4228AB90.90502@anvil.nrl.navy.mil> References: <4228AB90.90502@anvil.nrl.navy.mil> Message-ID: Well, one other option -- not free, but not very expensive -- is WingIDE (wingware.com). I've gotten to like it very much, even though I don't much like (on Mac) having to run under X11. That gives it a small performance hit as compared with the Windows version (which I've used only a little). But for me at least, it's a very nice debugging environment. TextWrangler is better as an editor for big tasks, but Wing's is quite OK, especially for the editing required while debugging. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Mar 4, 2005, at 1:40 PM, Louis Pecora wrote: > > I contacted the software company for BBEdit and TextWrangler re: my > problem with using stdin (e.g raw_input) when running a script from > within the program (Unix Output window, not a terminal run window). > Several people were interested so I thought I'd post the reply: > > scripts which are run directly within BBEdit cannot read from STDIN. > In order to accomplish that, you'll need to either run them in the > Terminal, or within a BBEdit shell worksheet (File -> New -> Shell > Worksheet). > (If you haven't used shell worksheets before, and don't require a > fully interactive terminal session, you might want to give them a try, > as they can be quite handy.) > > ------ > The worksheet seems to solve that problem, but it does not enable me > to use TextWrangler or BBEdit as an IDE-type environment. In fact > what I want to do won't even work in the terminal window. I have some > simple functions that require interactive use, i.e. Apple events (e.g. > file open and saves using EasyDialogs). Using them terminates the > program in a terminal, a python session (with the >>> prompt), or a > worksheet with the message: > > MacOS.Error: (-1713, 'no user interaction is allowed') > > > Sigh. Back to MacPython IDE. Seems to be the only option. > > Thanks for the feedback from many people. > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora@anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From charles.hartman at conncoll.edu Fri Mar 4 22:39:59 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri Mar 4 22:40:04 2005 Subject: [Pythonmac-SIG] More on stdin and python scripts in BBEdit and TextWrangler In-Reply-To: <4228D1CE.8090400@anvil.nrl.navy.mil> References: <4228AB90.90502@anvil.nrl.navy.mil> <4228D1CE.8090400@anvil.nrl.navy.mil> Message-ID: <2e8aa8102e60d4f281f27f5f0f5e91c2@conncoll.edu> No no, pythonw is simply part of OS X Python. Just change the command that your editor or whatever runs, probably from /usr/bin/python to /usr/bin/pythonw. You need to do that for *any* GUI app. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Mar 4, 2005, at 4:23 PM, Louis Pecora wrote: > Martina Oefelein wrote: > >> just use pythonw instead of python. >> >> ciao >> Martina > > I have been tempted to look into several variations on Python, but I > am wary of having to spend too much time installing other packages > that are interdependent and having to tweak them to get it all to > work. Maybe I'm making more of this than there really is. Can you > say what is necessary to get Pythonw up and running over a plain Apple > installation on OS X 10.3 and MacPython add ons? Thanks for any help. > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora@anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From troy.rollins at gmail.com Sat Mar 5 14:29:13 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Sat Mar 5 14:29:20 2005 Subject: [Pythonmac-SIG] More on stdin and python scripts in BBEdit and TextWrangler In-Reply-To: References: <4228AB90.90502@anvil.nrl.navy.mil> Message-ID: <31ac537c0503050529586e8164@mail.gmail.com> On Fri, 4 Mar 2005 16:38:30 -0500, Charles Hartman wrote: > Well, one other option -- not free, but not very expensive -- is > WingIDE (wingware.com). I've gotten to like it very much, even though I I would agree with that. I've tested every available IDE for Mac, and WingIDE is the most complete, as well as the most stable. The debugging tools, and the project management capabilities also are very beneficial. The X11 requirement is a bit of a PITA though, I'll agree. Performance in screen redraw is probably the biggest victim of it. I'm moving on to a faster Mac shortly (from my Powerbook to a dual tower) and hoping that I see some improvement. I'm very glad there is WingIDE, but still very much hoping that something better will come along. For me, I would prefer something commercial, with the polish and support and ongoing development that comes with it. Open source, and volunteer efforts are great, but not for the tools that we drive the company on. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From lanceboyle at cwazy.co.uk Sat Mar 5 05:18:20 2005 From: lanceboyle at cwazy.co.uk (Lance Boyle) Date: Sat Mar 5 15:54:20 2005 Subject: [Pythonmac-SIG] Status of PyOXIDE Message-ID: <20475428694634de4840b0a64fdd0691@cwazy.co.uk> What is the status of PyOXIDE? This has looked extremely promising for a while, but the recent versions are very crashy. Jerry From pecora at anvil.nrl.navy.mil Sat Mar 5 20:55:13 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Sat Mar 5 20:55:12 2005 Subject: [Pythonmac-SIG] Using Matplotlib interactive/GUI - How to? Message-ID: <422A0EA1.9010700@anvil.nrl.navy.mil> I installed Chris Barker's compiled matplotlib and it works fine for producing a graphics file (THANK YOU CHRIS. NICELY DONE!). I've used it from interactive, MacPython, and BBEdit (TextWrangler will probably work, too, since it's related). I would like to use matplot lib in the GUI and, most probably, Interactive mode. I've been looking over the documents and examples. From what I've read so far (and I don't pretend to understand it all) I have the following two "problems:" 1) I need to install Tkinter. Attempts to use TkAgg or other things warns me that _Tk or some such module cannot be imported or needs to be installed. Is this right? Any tricks or difficulties I need to be aware of to do this? 2) I need to set the Interactive flag in .matplotlibrc to true to do interactive plotting. But I can't find .matplotlibrc in my home directory (yes, it should be a hidden file and I looked through the hidden files). Where is this one kept on the Mac? A Finder Find show nothing, but I know that doesn't search everywhere. Is there anything else I'm missing to accomplish GUI and interactive use of Matplotlib? I am running 10.3.8 on a 12" Al PB 1.25 GHz. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From bmackenzie at avpress.com Sat Mar 5 00:17:26 2005 From: bmackenzie at avpress.com (Bill MacKenzie) Date: Sat Mar 5 23:29:20 2005 Subject: [Pythonmac-SIG] system, popen, tarfile on OS X Message-ID: <9273BD4A-8D03-11D9-AFB8-000393816E90@avpress.com> Hi, I'm preparing a script which will launch an external program (a JAR), process the XML file that results, tar the files output from the processed XML, and FTP the tarball to a remote location. The middle and the end are just fine, but running the external program and tarring the results have me hung up. I see system, popen and tarfile available in the modules list, but not on the Mac version. I need to be able to give the external (JAR) command line arguments based on the system clock. I could adapt a Perl script that currently does this task, but where would be the fun in that? I'm running OS X.3.7 and Python 2.3. Thanks for your help. Bill Bill MacKenzie Special Projects Antelope Valley Press bill.mackenzie@avpress.com From brendansimons at yahoo.ca Sat Mar 5 23:44:09 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Sat Mar 5 23:44:14 2005 Subject: [Pythonmac-SIG] Re: More on stdin and python scripts in BBEdit and In-Reply-To: <20050305110003.AC1601E4005@bag.python.org> References: <20050305110003.AC1601E4005@bag.python.org> Message-ID: > Martina Oefelein wrote: > >> just use pythonw instead of python. >> >> ciao >> Martina Yup, I ran into the same issue with TextWrangler recently. I wrote Bare Bones Software, and they gave me this hint: Textwrangler and BBEdit launch python scripts with /usr/bin/python by default, with which, as you've discovered 'no user interaction is allowed'. To allow your script to use gui elements, simply add: #!/usr/bin/pythonw to the top of your script. The editor is smart enough to override it's default with the interpreter you specify in the #! line Cheers Brendan -- Brendan SImons ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From bob at redivi.com Sat Mar 5 23:50:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 5 23:50:39 2005 Subject: [Pythonmac-SIG] system, popen, tarfile on OS X In-Reply-To: <9273BD4A-8D03-11D9-AFB8-000393816E90@avpress.com> References: <9273BD4A-8D03-11D9-AFB8-000393816E90@avpress.com> Message-ID: <5b3bbcb60498e214d8bcbf17f859dc72@redivi.com> On Mar 4, 2005, at 6:17 PM, Bill MacKenzie wrote: > I'm preparing a script which will launch an external program (a JAR), > process the XML file that results, tar the files output from the > processed XML, and FTP the tarball to a remote location. > > The middle and the end are just fine, but running the external program > and tarring the results have me hung up. > > I see system, popen and tarfile available in the modules list, but > not on the Mac version. > > I need to be able to give the external (JAR) command line arguments > based on the system clock. > > I could adapt a Perl script that currently does this task, but where > would be the fun in that? > > I'm running OS X.3.7 and Python 2.3. Python 2.3 on OS X definitely has everything that you say it doesn't. What is this "modules list" you're referring to? -bob From pecora at anvil.nrl.navy.mil Sun Mar 6 15:49:59 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Sun Mar 6 15:49:56 2005 Subject: [Pythonmac-SIG] Trouble installing Tk binary on OS X 10.3.8. Help. Message-ID: <422B1897.1040606@anvil.nrl.navy.mil> I need to install the Tk binary to get matplotlib to display plots. When I ran the package manager I got the error: Cannot open http://www.python.org/packman/version-0.3/darwin-7.8.0-Power_Macintosh.plist: HTTP Error 404: Not found I went to the MacPython site and got the URL for MacOSX 10.3, Apple-installed Python 2.3, PackMan version 0.3 and used Open URL in the package manager to go there. That worked up to that point, but when I tried to install _Tkbinary I get the error: Problem with dependency: (TclTkAqua): This package cannot be installed automatically (no Download-URL field) Now I'm stuck. Anyone know what's going on? Why didn't the package manager find the URL in the first place? And why can't it find the TclTkAqua site (I assume that's what it's looking for -- maybe this is wrong)? Any clues? Thanks. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From cmoad at indiana.edu Sun Mar 6 16:10:38 2005 From: cmoad at indiana.edu (Charles Moad) Date: Sun Mar 6 16:10:47 2005 Subject: [Pythonmac-SIG] Using Matplotlib interactive/GUI - How to? In-Reply-To: <422A0EA1.9010700@anvil.nrl.navy.mil> References: <422A0EA1.9010700@anvil.nrl.navy.mil> Message-ID: <422B1D6E.10306@indiana.edu> > 2) I need to set the Interactive flag in .matplotlibrc to true to > do interactive plotting. But I can't find .matplotlibrc in my home > directory (yes, it should be a hidden file and I looked through the > hidden files). Where is this one kept on the Mac? A Finder Find > show nothing, but I know that doesn't search everywhere. I don't think this file is ever explicitly made for you. You can download a sample from his website, http://matplotlib.sourceforge.net/.matplotlibrc. Download this and put it in your home dir. For some strange reason I had to comment out all the lines that specify a color because they would cause errors. I changed TKAgg to WXAgg after I installed wxPython for 10.3, and I changed Numeric to numarray, since numarray doesn't have the dependency that Numeric does, hence it is a little easier install. Good Luck, Charlie From enrike at altern.org Sun Mar 6 23:11:49 2005 From: enrike at altern.org (altern) Date: Mon Mar 7 10:19:01 2005 Subject: [Pythonmac-SIG] pygtk Message-ID: <422B8025.7020302@altern.org> hi all i was wondering if it is possible to use pyGTK to program crossplarform python apps. I have been it checking, downloaded the installer from pygtk website but i cannot compile it so far. I have been trying to install it with packman but i cannot see it. I want it to create a opengl window. So far i have been using wxpython but as i want to do something simple somebody suggested me that GTK might be good solution. thanks -- enrike From piet at cs.uu.nl Mon Mar 7 11:11:34 2005 From: piet at cs.uu.nl (Piet van Oostrum) Date: Mon Mar 7 11:11:37 2005 Subject: [Pythonmac-SIG] pygtk In-Reply-To: <422B8025.7020302@altern.org> (altern's message of "Sun, 06 Mar 2005 23:11:49 +0100") References: <422B8025.7020302@altern.org> Message-ID: >>>>> altern (E) wrote: >E> hi all >E> i was wondering if it is possible to use pyGTK to program crossplarform >E> python apps. I have been it checking, downloaded the installer from pygtk >E> website but i cannot compile it so far. I have been trying to install it >E> with packman but i cannot see it. >E> I want it to create a opengl window. So far i have been using wxpython but >E> as i want to do something simple somebody suggested me that GTK might be >E> good solution. You should be aware that pygtk works only with X11, it won't give you a native Aqua interface. This is because GTK is not native on MacOSX. And yes, it can be compiled (I did it myself). -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP] Private email: piet@vanoostrum.org From bob at redivi.com Mon Mar 7 12:35:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 7 12:35:15 2005 Subject: [Pythonmac-SIG] pygtk In-Reply-To: References: <422B8025.7020302@altern.org> Message-ID: <7c41d19f75bd1fb67c21bee57dc8de25@redivi.com> On Mar 7, 2005, at 5:11, Piet van Oostrum wrote: >>>>>> altern (E) wrote: > >> E> hi all >> E> i was wondering if it is possible to use pyGTK to program >> crossplarform >> E> python apps. I have been it checking, downloaded the installer >> from pygtk >> E> website but i cannot compile it so far. I have been trying to >> install it >> E> with packman but i cannot see it. >> E> I want it to create a opengl window. So far i have been using >> wxpython but >> E> as i want to do something simple somebody suggested me that GTK >> might be >> E> good solution. > > You should be aware that pygtk works only with X11, it won't give you a > native Aqua interface. This is because GTK is not native on MacOSX. > And yes, it can be compiled (I did it myself). To my knowledge, here is a pretty complete list of how you can get an Aqua OpenGL window from Python: - wxPython - PyObjC (not cross-platform, but light and easy) - PyOpenGL (via GLUT, which kinda sucks, but good enough for some things) - pygame (only one window per app) - Tkinter (via Togl, if that still compiles) -bob From sw at wordtech-software.com Mon Mar 7 14:28:39 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Mon Mar 7 14:28:47 2005 Subject: [Pythonmac-SIG] Tcl/Tk Aqua In-Reply-To: <20050307110039.631721E4002@bag.python.org> References: <20050307110039.631721E4002@bag.python.org> Message-ID: <422C5707.8040808@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lou, TkAqua is a separate installation that is available from this URL: http://tcltkaqua.sourceforge.net You'll find the current version (8.4.9) there. The tkinter binary that is installed by PackMan is just a thin wrapper over those frameworks. I've noticed a great number of questions about PackMan recently, as it seems the repository has been more or less abandoned in favor of the individual package installers from the undefined.org/python site. While that's fine, to say that this transition has been graceful or even minimally well-documented would be an understaement. There is a continuing need for the PackMan repository, if only for legacy components like tkinter that will not be updated by anyone nor available elsewhere. Would it be a bad idea to set up a permanent URL/plist address for these legacy packages that could be plugged into PackMan, and make this address a) easily discoverable on the Internet in a FAQ somewhere, and b) as the default address in the next iteration of PackMan? Because the default URL that is supposed to open when you open PackMan seems permanently broken (I've seen a dozen questions about that on the mailing list in the past few months). For what it's worth, here is what seems to be the (current) canonical list of PackMan URL references: http://www.python.org/packman/ I guess that would do as the permanent address. If anyone can amplify/clarify this, please do so. Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCLFcGJmdQs+6YVcoRAmE1AKCIJEH0MGCerfaQhq7ajUY6EoVbQwCeLeQI a6S55ij+zsJ9SP33E2hKBuY= =MOgo -----END PGP SIGNATURE----- From bob at redivi.com Mon Mar 7 14:44:44 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 7 14:44:53 2005 Subject: [Pythonmac-SIG] Tcl/Tk Aqua In-Reply-To: <422C5707.8040808@wordtech-software.com> References: <20050307110039.631721E4002@bag.python.org> <422C5707.8040808@wordtech-software.com> Message-ID: On Mar 7, 2005, at 8:28, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lou, > > TkAqua is a separate installation that is available from this URL: > > http://tcltkaqua.sourceforge.net > > You'll find the current version (8.4.9) there. The tkinter binary that > is installed by PackMan is just a thin wrapper over those frameworks. > > I've noticed a great number of questions about PackMan recently, as it > seems the repository has been more or less abandoned in favor of the > individual package installers from the undefined.org/python site. While > that's fine, to say that this transition has been graceful or even > minimally well-documented would be an understaement. There is a > continuing need for the PackMan repository, if only for legacy > components like tkinter that will not be updated by anyone nor > available > elsewhere. > > Would it be a bad idea to set up a permanent URL/plist address for > these > legacy packages that could be plugged into PackMan, and make this > address a) easily discoverable on the Internet in a FAQ somewhere, and > b) as the default address in the next iteration of PackMan? Because the > default URL that is supposed to open when you open PackMan seems > permanently broken (I've seen a dozen questions about that on the > mailing list in the past few months). > > For what it's worth, here is what seems to be the (current) canonical > list of PackMan URL references: > > http://www.python.org/packman/ > > I guess that would do as the permanent address. What you don't see is the stupid messages I get off-list because the PackMan UI sucks and confuses people. I'm tempted to just take it down entirely so I don't have to see these messages (I have removed references to the plist files from my site, but the plists themselves should still be there). If Jack intends to maintain the official repository, or not, that's fine with me -- but mine is dead. It would be trivial to build a new installer for _tkinter.so. It's *one file*. It could be packaged up with the TclTkAquaBI pkg, so you can do the whole thing in one fell swoop. -bob From sw at wordtech-software.com Mon Mar 7 15:44:38 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Mon Mar 7 15:44:41 2005 Subject: [Pythonmac-SIG] Tcl/Tk Aqua In-Reply-To: References: <20050307110039.631721E4002@bag.python.org> <422C5707.8040808@wordtech-software.com> Message-ID: <422C68D6.2040006@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob Ippolito wrote: | | | | What you don't see is the stupid messages I get off-list because the | PackMan UI sucks and confuses people. I'm tempted to just take it down | entirely so I don't have to see these messages (I have removed | references to the plist files from my site, but the plists themselves | should still be there). If Jack intends to maintain the official | repository, or not, that's fine with me -- but mine is dead. | | It would be trivial to build a new installer for _tkinter.so. It's *one | file*. It could be packaged up with the TclTkAquaBI pkg, so you can do | the whole thing in one fell swoop. | | -bob | | I sympathize, and agree that PackMan is confusing. Some clarification from Jack about how the how repositiories about python.org will be maintained, or not maintained, would be helpful. Since I do a lot with Tcl/Tk, I would also be willing to look into putting together a package installer of the tkinter module and of IDLE. That would be useful to me for several reasons, not the least of which is that I actually find IDLE to be a useful editor. Since it's packaged as an applet, that would be consistent with the other stuff I maintain. What I don't know how to do is build _tkinter.so. Any advice on that front? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCLGjVJmdQs+6YVcoRAjU8AJ92IsQpgOi67xGNXMPgoXjPMNOj4wCfc9Mi Zki0vzSdSJY2yvwY1I5sEi0= =G2BH -----END PGP SIGNATURE----- From bob at redivi.com Mon Mar 7 16:07:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 7 16:07:25 2005 Subject: [Pythonmac-SIG] Tcl/Tk Aqua In-Reply-To: <422C68D6.2040006@wordtech-software.com> References: <20050307110039.631721E4002@bag.python.org> <422C5707.8040808@wordtech-software.com> <422C68D6.2040006@wordtech-software.com> Message-ID: <3e5f0f0d0c729fa4c4d815e6eb1d1c5a@redivi.com> On Mar 7, 2005, at 9:44, Kevin Walzer wrote: > Bob Ippolito wrote: > | > | > | What you don't see is the stupid messages I get off-list because the > | PackMan UI sucks and confuses people. I'm tempted to just take it > down > | entirely so I don't have to see these messages (I have removed > | references to the plist files from my site, but the plists themselves > | should still be there). If Jack intends to maintain the official > | repository, or not, that's fine with me -- but mine is dead. > | > | It would be trivial to build a new installer for _tkinter.so. It's > *one > | file*. It could be packaged up with the TclTkAquaBI pkg, so you can > do > | the whole thing in one fell swoop. > > I sympathize, and agree that PackMan is confusing. Some clarification > from Jack about how the how repositiories about python.org will be > maintained, or not maintained, would be helpful. Personally I'd much rather see an official MacPython build of 2.4.1.. but I guess I could build it myself and redistribute it Jack doesn't get around to it in time. > Since I do a lot with Tcl/Tk, I would also be willing to look into > putting together a package installer of the tkinter module and of IDLE. > That would be useful to me for several reasons, not the least of which > is that I actually find IDLE to be a useful editor. Since it's packaged > as an applet, that would be consistent with the other stuff I maintain. Doesn't an IDLE applet come with the add-ons? IDLE is useful as an interactive interpreter because it's (in my experience) the only one that actually does it right by running the sub-interpreters out of process. I wish the other IDEs would learn. > What I don't know how to do is build _tkinter.so. Any advice on that > front? You need to rip apart Python's source a bit to build _tkinter.so. You can just cherry-pick the _tkinter.so you already have, though. There isn't anything terribly wrong with it, is there? -bob From kerfue+pythonmac-sig at herocamp.org Mon Mar 7 16:09:15 2005 From: kerfue+pythonmac-sig at herocamp.org (Truls A. Tangstad) Date: Mon Mar 7 16:09:18 2005 Subject: [Pythonmac-SIG] pygtk In-Reply-To: <7c41d19f75bd1fb67c21bee57dc8de25@redivi.com> References: <422B8025.7020302@altern.org> <7c41d19f75bd1fb67c21bee57dc8de25@redivi.com> Message-ID: <20050307150915.GA12422@sakura.chem.ntnu.no> On Mon, Mar 07, 2005 at 06:35:07AM -0500, Bob Ippolito wrote: > On Mar 7, 2005, at 5:11, Piet van Oostrum wrote: > > wrote: > >> hi all > >> i was wondering if it is possible to use pyGTK to program > >> crossplarform python apps. I have been it checking, downloaded > >> the installer from pygtk website but i cannot compile it so far. > >> I have been trying to install it with packman but i cannot see > >> it. I want it to create a opengl window. So far i have been > >> using wxpython but as i want to do something simple somebody > >> suggested me that GTK might be good solution. > >You should be aware that pygtk works only with X11, it won't give > >you a native Aqua interface. This is because GTK is not native on > >MacOSX. And yes, it can be compiled (I did it myself). > To my knowledge, here is a pretty complete list of how you can get > an Aqua OpenGL window from Python: > - wxPython > - PyObjC (not cross-platform, but light and easy) > - PyOpenGL (via GLUT, which kinda sucks, but good enough for some > things) > - pygame (only one window per app) > - Tkinter (via Togl, if that still compiles) Shouldn't PyQt be added to the mix? -- Truls A. Tangstad - From sw at wordtech-software.com Mon Mar 7 16:13:23 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Mon Mar 7 16:13:28 2005 Subject: [Pythonmac-SIG] Tcl/Tk Aqua In-Reply-To: <3e5f0f0d0c729fa4c4d815e6eb1d1c5a@redivi.com> References: <20050307110039.631721E4002@bag.python.org> <422C5707.8040808@wordtech-software.com> <422C68D6.2040006@wordtech-software.com> <3e5f0f0d0c729fa4c4d815e6eb1d1c5a@redivi.com> Message-ID: <422C6F93.40107@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob Ippolito wrote: | | | Doesn't an IDLE applet come with the add-ons? | | IDLE is useful as an interactive interpreter because it's (in my | experience) the only one that actually does it right by running the | sub-interpreters out of process. I wish the other IDEs would learn. Oh yes, I think you're right. It just doesn't work without tkinter. | |> What I don't know how to do is build _tkinter.so. Any advice on that |> front? | | | You need to rip apart Python's source a bit to build _tkinter.so. You | can just cherry-pick the _tkinter.so you already have, though. There | isn't anything terribly wrong with it, is there? No, it works fine. Let me see what I can do with packaging it. Kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCLG+RJmdQs+6YVcoRAtyuAJ9fRkC+VHy0mTlHNAi9uiNU2iH0EwCeLXbL EuW/2/vWa6RLz/GSGSwcJ9o= =EUgN -----END PGP SIGNATURE----- From cmoad at indiana.edu Mon Mar 7 17:02:23 2005 From: cmoad at indiana.edu (Charles Moad) Date: Mon Mar 7 17:02:27 2005 Subject: [Pythonmac-SIG] PackageMaker and bdist_mpkg Message-ID: <422C7B0F.5040302@indiana.edu> I am trying to make a mpkg using PackageMaker that includes a combination of frameworks wrapped as pkg's, and bdist_mpkg outputs. Each of these pkg's work fine when installed separately, but die when I try running the resulting mpkg. One machine gave me a horribly long stack trace that I think amounted to a NULL pointer and another said, "There was an error in the package (999)" (might not be exact). Has anybody every been successful doing something similar? Thanks, - Charlie From bob at redivi.com Mon Mar 7 17:20:39 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 7 17:20:47 2005 Subject: [Pythonmac-SIG] PackageMaker and bdist_mpkg In-Reply-To: <422C7B0F.5040302@indiana.edu> References: <422C7B0F.5040302@indiana.edu> Message-ID: On Mar 7, 2005, at 11:02 AM, Charles Moad wrote: > I am trying to make a mpkg using PackageMaker that includes a > combination of frameworks wrapped as pkg's, and bdist_mpkg outputs. > Each of these pkg's work fine when installed separately, but die when > I try running the resulting mpkg. One machine gave me a horribly long > stack trace that I think amounted to a NULL pointer and another said, > "There was an error in the package (999)" (might not be exact). > Has anybody every been successful doing something similar? Nesting packages works fine if it's done by bdist_mpkg. I've never tried using PackageMaker on the outside, but I suspect either you did something wrong with PackageMaker, or PackageMaker has bugs. The mpkgs and pkgs that bdist_mpkg outputs are perfectly compliant with the specfiications. If you put together a minimal example that demonstrates the problem, I'll look at it. -bob From bob at redivi.com Mon Mar 7 17:27:19 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 7 17:27:25 2005 Subject: [Pythonmac-SIG] PackageMaker and bdist_mpkg In-Reply-To: References: <422C7B0F.5040302@indiana.edu> Message-ID: On Mar 7, 2005, at 11:20 AM, Bob Ippolito wrote: > > On Mar 7, 2005, at 11:02 AM, Charles Moad wrote: > >> I am trying to make a mpkg using PackageMaker that includes a >> combination of frameworks wrapped as pkg's, and bdist_mpkg outputs. >> Each of these pkg's work fine when installed separately, but die when >> I try running the resulting mpkg. One machine gave me a horribly >> long stack trace that I think amounted to a NULL pointer and another >> said, "There was an error in the package (999)" (might not be exact). >> Has anybody every been successful doing something similar? > > Nesting packages works fine if it's done by bdist_mpkg. I've never > tried using PackageMaker on the outside, but I suspect either you did > something wrong with PackageMaker, or PackageMaker has bugs. The > mpkgs and pkgs that bdist_mpkg outputs are perfectly compliant with > the specfiications. > > If you put together a minimal example that demonstrates the problem, > I'll look at it. Ok, I just put a minimal example together and it worked fine. It appears you are using PackageMaker incorrectly. By default, it sets its IFPkgFlagComponentDirectory to "..", which means that all of the sub-packages must be siblings of the mpkg. If they are not there, you will get an error 999. PackageMaker does not copy the sub-packages anywhere, you have to do this on your own. bdist_mpkg creates mpkgs that have an IFPkgFlagComponentDirectory of "Packages", which means it looks *inside* the mpkg for the pkg files. Perhaps you thought that PackageMaker also did this kind of encapsulation by default? -bob From cmoad at indiana.edu Mon Mar 7 18:11:28 2005 From: cmoad at indiana.edu (Charles Moad) Date: Mon Mar 7 18:11:39 2005 Subject: [Pythonmac-SIG] PackageMaker and bdist_mpkg In-Reply-To: References: <422C7B0F.5040302@indiana.edu> Message-ID: <422C8B40.6070908@indiana.edu> Sounds like that is probably it. So I should manually copy the packages into the mpkg? What would be a simple python script to make bdist_mpkg do that given a list of pkgs. Thanks again, Bob Ippolito wrote: > > On Mar 7, 2005, at 11:20 AM, Bob Ippolito wrote: > >> >> On Mar 7, 2005, at 11:02 AM, Charles Moad wrote: >> >>> I am trying to make a mpkg using PackageMaker that includes a >>> combination of frameworks wrapped as pkg's, and bdist_mpkg outputs. >>> Each of these pkg's work fine when installed separately, but die when >>> I try running the resulting mpkg. One machine gave me a horribly >>> long stack trace that I think amounted to a NULL pointer and another >>> said, "There was an error in the package (999)" (might not be exact). >>> Has anybody every been successful doing something similar? >> >> >> Nesting packages works fine if it's done by bdist_mpkg. I've never >> tried using PackageMaker on the outside, but I suspect either you did >> something wrong with PackageMaker, or PackageMaker has bugs. The >> mpkgs and pkgs that bdist_mpkg outputs are perfectly compliant with >> the specfiications. >> >> If you put together a minimal example that demonstrates the problem, >> I'll look at it. > > > Ok, I just put a minimal example together and it worked fine. It > appears you are using PackageMaker incorrectly. By default, it sets its > IFPkgFlagComponentDirectory to "..", which means that all of the > sub-packages must be siblings of the mpkg. If they are not there, you > will get an error 999. PackageMaker does not copy the sub-packages > anywhere, you have to do this on your own. > > bdist_mpkg creates mpkgs that have an IFPkgFlagComponentDirectory of > "Packages", which means it looks *inside* the mpkg for the pkg files. > Perhaps you thought that PackageMaker also did this kind of > encapsulation by default? > > -bob > > From bob at redivi.com Mon Mar 7 18:22:40 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 7 18:22:39 2005 Subject: [Pythonmac-SIG] PackageMaker and bdist_mpkg In-Reply-To: <422C8B40.6070908@indiana.edu> References: <422C7B0F.5040302@indiana.edu> <422C8B40.6070908@indiana.edu> Message-ID: <07ed8bbf1aae9e567a0414bee623021c@redivi.com> bdist_mpkg can't do this simply yet. It's not designed as a general package creation tool, it's designed to do what it does and little else. As I said, by default, PackageMaker creates mpkgs that use ".." as the path, so you need to manually copy the packages *next to* the mpkg. Not inside. If you want to put them inside, you have to edit the plist and change the component directory. -bob On Mar 7, 2005, at 12:11 PM, Charles Moad wrote: > Sounds like that is probably it. So I should manually copy the > packages into the mpkg? What would be a simple python script to make > bdist_mpkg do that given a list of pkgs. > > Thanks again, > > Bob Ippolito wrote: >> On Mar 7, 2005, at 11:20 AM, Bob Ippolito wrote: >>> >>> On Mar 7, 2005, at 11:02 AM, Charles Moad wrote: >>> >>>> I am trying to make a mpkg using PackageMaker that includes a >>>> combination of frameworks wrapped as pkg's, and bdist_mpkg outputs. >>>> Each of these pkg's work fine when installed separately, but die >>>> when I try running the resulting mpkg. One machine gave me a >>>> horribly long stack trace that I think amounted to a NULL pointer >>>> and another said, "There was an error in the package (999)" (might >>>> not be exact). >>>> Has anybody every been successful doing something similar? >>> >>> >>> Nesting packages works fine if it's done by bdist_mpkg. I've never >>> tried using PackageMaker on the outside, but I suspect either you >>> did something wrong with PackageMaker, or PackageMaker has bugs. >>> The mpkgs and pkgs that bdist_mpkg outputs are perfectly compliant >>> with the specfiications. >>> >>> If you put together a minimal example that demonstrates the problem, >>> I'll look at it. >> Ok, I just put a minimal example together and it worked fine. It >> appears you are using PackageMaker incorrectly. By default, it sets >> its IFPkgFlagComponentDirectory to "..", which means that all of the >> sub-packages must be siblings of the mpkg. If they are not there, >> you will get an error 999. PackageMaker does not copy the >> sub-packages anywhere, you have to do this on your own. >> bdist_mpkg creates mpkgs that have an IFPkgFlagComponentDirectory of >> "Packages", which means it looks *inside* the mpkg for the pkg files. >> Perhaps you thought that PackageMaker also did this kind of >> encapsulation by default? >> -bob From bmackenzie at avpress.com Mon Mar 7 18:47:37 2005 From: bmackenzie at avpress.com (Bill MacKenzie) Date: Mon Mar 7 18:47:42 2005 Subject: [Pythonmac-SIG] system, popen, tarfile on OS X In-Reply-To: <5b3bbcb60498e214d8bcbf17f859dc72@redivi.com> References: <9273BD4A-8D03-11D9-AFB8-000393816E90@avpress.com> <5b3bbcb60498e214d8bcbf17f859dc72@redivi.com> Message-ID: On Mar 5, 2005, at 2:50 PM, Bob Ippolito wrote: > > On Mar 4, 2005, at 6:17 PM, Bill MacKenzie wrote: > >> I'm preparing a script which will launch an external program (a JAR), >> process the XML file that results, tar the files output from the >> processed XML, and FTP the tarball to a remote location. >> >> The middle and the end are just fine, but running the external >> program and tarring the results have me hung up. >> >> I see system, popen and tarfile available in the modules list, but >> not on the Mac version. >> >> I need to be able to give the external (JAR) command line arguments >> based on the system clock. >> >> I could adapt a Perl script that currently does this task, but where >> would be the fun in that? >> >> I'm running OS X.3.7 and Python 2.3. > > Python 2.3 on OS X definitely has everything that you say it doesn't. > What is this "modules list" you're referring to? > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > The module list is the Python Global Module Index at http://www.python.org/doc/current/modindex.html. Apparently, just sending the question caused a few lightbulbs to go off in my head. I've been launching Python scripts from the GUI by double clicking. That was pointed at the Python Interpreter in Applications/Python 2.2 NOT PythonLauncher (2.3). Once I straightened that out, I can now tar and (I assume) launch scripts. I'll run some more tests today and should be out of the woods by sunset. Thanks for being there, Bob. Bill Bill MacKenzie Special Projects Antelope Valley Press bill.mackenzie@avpress.com From pecora at anvil.nrl.navy.mil Mon Mar 7 20:06:21 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon Mar 7 20:06:17 2005 Subject: [Pythonmac-SIG] Re: Binary Matplotlib package, working. Need to keep script running after plotting. In-Reply-To: <422C9E93.2050009@noaa.gov> References: <42017A10.7040505@noaa.gov> <420232BF.9080705@anvil.nrl.navy.mil> <420278A0.9050903@noaa.gov> <422A0082.4000006@anvil.nrl.navy.mil> <422C9E93.2050009@noaa.gov> Message-ID: <422CA62D.9060300@anvil.nrl.navy.mil> Chris Barker wrote: > How about the developer tools and/or X-windows? > > -Chris Hi Chris, Yes, I have the dev. tools and and X11 stuff. I have some old code that opens an X window and does very simple drawing. That works after compiling using g++ and linking to /usr/X11R6/lib/libX11.a. But note, I am very much an X windows novice. I have since also installed wxPython. The few tests I've done seem to work with it and using the WXAgg option in matplotlib I can get the plot window to appear after doing a show(). Very nice. Can zoom, pan, save, etc. BUT. (Users are never satisfied are they/we? :-) ). My ultimate goal is to not wait until the end of the script to do the plot, but to be able to plot and keep the script running. This can be done either by pausing the script (in some way) or by leaving the matplotwindow open and continuing with the script. Most of my numerical code is menu driven with VERY simple menus through stdout and stdin printing and reading. I am not sure how to do this type of plotting. Thus far matplotlib wants to quit after a show(). Putting python code after show() never gets run. Clicking the close button on the matplotlib window crashes Python. I am running from a terminal window for now using Pythonw since I also use EasyDialogs. I've been looking over the docs and examples and haven't seen how to do this. I've played with matplotlibrc setting "interactive" to True, but that did nothing. After I do some time-pressing stuff, I'll get back to investigating this problem. Overall matplotlib looks fabulous and along with wxPython I can see the potential to have plot windows and some simple GUI interaction without getting smothered in GUI programming. And I have to say your binary and the wxPython binary were trivial to install and get running. Thanks, again. If you have any suggestions, just send them along. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From Chris.Barker at noaa.gov Mon Mar 7 20:07:32 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Mar 7 20:09:32 2005 Subject: [Pythonmac-SIG] Using Matplotlib interactive/GUI - How to? In-Reply-To: <422B1D6E.10306@indiana.edu> References: <422A0EA1.9010700@anvil.nrl.navy.mil> <422B1D6E.10306@indiana.edu> Message-ID: <422CA674.2080005@noaa.gov> Charles Moad wrote: > I don't think this file is ever explicitly made for you. You can > download a sample from his website, > http://matplotlib.sourceforge.net/.matplotlibrc. Download this and put > it in your home dir. Yes, there is one there by default: /System/Library/Frameworks/Python.framework/Versions/2.3/share/matplotlib/.matplotlibrc By the way, Lou, once you get Tkinter working right, I think the version of matplotlib you got from me won't work with it. I think I've got a version now that does, but I don't need it at the moment, and I got distracted with other things. I was hoping Robert Kern would put it out with MacEnthon soon, but he doesn't seem to have it released yet. I've corresponded with him about it, and I think he's got it all set to go, but I don't know where he's intending to put his stuff, or when. If anyone wants a mpkg of matplotlib that works with wx, TK, and Agg, let me know and I'll put one together, and give it to Bob to put on his site. I'm not going to do a GTK one, as it doesn't make sense. If you're using GTK, you're using fink or darwinports, and you should install matplotlib through them. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker at noaa.gov Mon Mar 7 20:29:41 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Mar 7 20:31:41 2005 Subject: [Pythonmac-SIG] Re: Binary Matplotlib package, working. Need to keep script running after plotting. In-Reply-To: <422CA62D.9060300@anvil.nrl.navy.mil> References: <42017A10.7040505@noaa.gov> <420232BF.9080705@anvil.nrl.navy.mil> <420278A0.9050903@noaa.gov> <422A0082.4000006@anvil.nrl.navy.mil> <422C9E93.2050009@noaa.gov> <422CA62D.9060300@anvil.nrl.navy.mil> Message-ID: <422CABA5.4050503@noaa.gov> Louis Pecora wrote: > BUT. (Users are never satisfied are they/we? :-) ). My ultimate goal > is to not wait until the end of the script to do the plot, but to be > able to plot and keep the script running. This can be done either by > pausing the script (in some way) or by leaving the matplotwindow open > and continuing with the script. The problem here is the interaction between the event loops of the terminal and whatever GUI toolkit matplotlib is using. For instance, with wx, when you call show(), matpotlib brings up a wx Window, then the wx Event loop is called, and blocks all control. You might try using ipython (http://ipython.scipy.org/) a fair bit of work has been put into making it work well with matplotlib. However, it doesn't sound like what you want is truly interactive. If I understand, what you're looking for is a way to write a procedural script that pops up a dialog box now and again to ask a question, and creates, shows, and destroys plot windows as it needs to. Have I got that right? The problem you're running into is that GUI toolkit use an event-driven model, rather than a procedural one. Once the event loop is stated, the script halts there. A few years back I was trying to do that same thing. I'm not sure why, but I don't feel the need for it anymore. Perhaps it's because I'm used to wxPython now, and just write a full event driven app when I need one. > Clicking the close button on the matplotlib window crashes Python. hmm. I don't think that should happen. > I am running from a terminal window for now using Pythonw since I also > use EasyDialogs. Here's a trick: EasyDialogs used Carbon (I think). In general, things get messy when you mix GUI toolkits. I think you're going to need to go to writing your dialogs in the same toolkit as matplotlib is using. It's too bad that no one has written a PyObjC back-end for matplotlib, as that would probably be the best option on OS-X. However, wxPython and/or Tkinter should work. I'd have to probe the mailing lists, but I think some one wrote a little code to make it easy to write procedural apps with using wx dialog boxes, and adding matplotlib to that mix should be easy from there. I'm interested in helping out if you want to go that route. > I've played with matplotlibrc setting > "interactive" to True, but that did nothing. What that setting does is set the back-end to re-draw whenever you change something in the plot, rather than waiting for a show() call. > And I have to say your binary > and the wxPython binary were trivial to install and get running. glad to here it, they should be. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From pecora at anvil.nrl.navy.mil Mon Mar 7 20:42:41 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon Mar 7 20:42:36 2005 Subject: [Pythonmac-SIG] Using Matplotlib interactive/GUI - How to? In-Reply-To: <422CA674.2080005@noaa.gov> References: <422A0EA1.9010700@anvil.nrl.navy.mil> <422B1D6E.10306@indiana.edu> <422CA674.2080005@noaa.gov> Message-ID: <422CAEB1.70806@anvil.nrl.navy.mil> Chris Barker wrote: > > > Charles Moad wrote: > >> I don't think this file is ever explicitly made for you. You can >> download a sample from his website, >> http://matplotlib.sourceforge.net/.matplotlibrc. Download this and >> put it in your home dir. > > > Yes, there is one there by default: > > /System/Library/Frameworks/Python.framework/Versions/2.3/share/matplotlib/.matplotlibrc > > > By the way, Lou, once you get Tkinter working right, I think the > version of matplotlib you got from me won't work with it. I think I've > got a version now that does, but I don't need it at the moment, and I > got distracted with other things. I was hoping Robert Kern would put > it out with MacEnthon soon, but he doesn't seem to have it released > yet. I've corresponded with him about it, and I think he's got it all > set to go, but I don't know where he's intending to put his stuff, or > when. > > If anyone wants a mpkg of matplotlib that works with wx, TK, and Agg, > let me know and I'll put one together, and give it to Bob to put on > his site. I'm not going to do a GTK one, as it doesn't make sense. If > you're using GTK, you're using fink or darwinports, and you should > install matplotlib through them. > > -Chris Chris, I got matplotlib working by installing wxPython. It was a trivial install and seems to work well. I just posted some other issues with matplotlib that I have. They are not real problems, but rather questions about using matplotlib in a more interactive way. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From newsletter at theflow.de Mon Mar 7 23:11:12 2005 From: newsletter at theflow.de (Florian Munz) Date: Mon Mar 7 23:11:15 2005 Subject: [Pythonmac-SIG] Using UKKQueue with PyObjC Message-ID: <1gt2svk.6008fm11jey9cM%newsletter@theflow.de> Hi, I'm currently trying to use the UKKQueue class to monitor file changes from my PyObjC application. After some fiddling I got the basics working, but encountered some problems and questions: * What is the minimal way to include such an ObjC wrapper class with py2app? I am using the setup.py from RestEdit [1] right now, but this looks overly complicated. Also this setup doesn't work when using --alias * I'm using the notifications provided by NSWorkspace: NSWorkspace.sharedWorkspace().notificationCenter().addObserver_selector_ name_object_( self, "documentChanged:", None, None) Is there a way to register an observer which listens to specific objects only? UKKQueue sends notifications with the filename as object, but as and simply replacing the last None in the above method with the filename string didn't work. * This is more a PyObjC question: Can I use any Python class as a delegate for UKKQueue? Or have these to subclass NSObject or something else? thanks a lot, Florian [1] http://svn.red-bean.com/restedit/trunk/source/setup.py From dave.opstad at monotypeimaging.com Mon Mar 7 23:24:38 2005 From: dave.opstad at monotypeimaging.com (Dave Opstad) Date: Mon Mar 7 23:24:41 2005 Subject: [Pythonmac-SIG] py2app troubles Message-ID: I've got a Tkinter application that works fine when I launch it via pythonw. This is on 10.3.7, default 2.3.0 Python install, added the MacPython stuff and installed _tkinter from Package Manager. After successfully installing py2app 0.1.7, I modified my setup.py file and then did a "python setup.py py2app" to build my app as a standalone, and again everything worked fine. No error messages, and the app was sitting in the dist folder. However, upon launching the app I get an immediate error: ----------------------------------------------------- TclError: Can't find a usable init.tcl in the following directories: @TCL_IN_FRAMEWORK@ /System/Library/Frameworks/Python.framework/Versions/2.3/lib/tcl8.4 /System/Library/Frameworks/Python.framework/Versions/lib/tcl8.4 /System/Library/Frameworks/Python.framework/Versions/2.3/library /System/Library/Frameworks/Python.framework/Versions/library /System/Library/Frameworks/Python.framework/Versions/tcl8.4.7/library /System/Library/Frameworks/Python.framework/tcl8.4.7/library @TCL_IN_FRAMEWORK@ This probably means that Tcl wasn't installed properly. ----------------------------------------------------- Since I'm able to use the app via pythonw, is it really the case that Tcl isn't properly installed? I do have a Tcl.framework that contains an init.tcl, but there isn't one anywhere in the Python framework. Anybody have an idea how I've goofed up here? Thanks! Dave Opstad From Chris.Barker at noaa.gov Tue Mar 8 00:14:07 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Mar 8 00:17:31 2005 Subject: [Pythonmac-SIG] Re: Binary Matplotlib package, working. Need to keep script running after plotting. In-Reply-To: <422CB229.3020609@anvil.nrl.navy.mil> References: <42017A10.7040505@noaa.gov> <420232BF.9080705@anvil.nrl.navy.mil> <420278A0.9050903@noaa.gov> <422A0082.4000006@anvil.nrl.navy.mil> <422C9E93.2050009@noaa.gov> <422CA62D.9060300@anvil.nrl.navy.mil> <422CABA5.4050503@noaa.gov> <422CB229.3020609@anvil.nrl.navy.mil> Message-ID: <422CE03F.1090504@noaa.gov> Louis Pecora wrote: > You pretty much got it. OK. I've enclosed a little script that demonstrates calling up some stock dialogs in a script with wxPython. really the only trick is that you need to initialize an app first. Look through the wx docs to see what standard dialogs there are. Plus there is an example of a custom one. It wouldn't take much to write some quickie function wrappers around those dialogs if you want to be able to call them with one line of code. > Well, EasyDialogs has given me no trouble so far now that I know to run > it with Pythonw. I never use calls to it and matplotlib at the same time. However, there can only be one wxApp per instance of Python, and it can only be initialized once, so you may not be able to switch back and forth between matplotlib wx stuff and EasyDialogs. That being said, I just tested it, and it crashed Python when I closed a matplotlib window too. Using matplotlib in a procedural script like this will take a little bit of work. As it stands, the pylab interface expects to set up and deal with all the GUI stuff itself. If you have a wxApp running already, I don't think it's going to work. Check out the "embedded in wx" examples that come with matplotlib, to see how to use it inside an existing wx app. Also, Matt Newville just posted a message to the matplotlib mailing list that might be what you need: Matt Newville wrote: > Hi Andrea, > > The pylab interface is generally the non-Class-based approached, > suitable for small, procedural scripts. Personally, I'd say > this is good for interactive use, 'one-time' scripts, and very > simple uses of matplotlib, but that's just my opinion: it seems > many people use pylab for more demanding apps. > > But: you don't need to import pylab at all if you're creating a > matplotlib figure in a wxPython (or other) GUI. And, for me at > least, toggling the grid and interacting with gui Events work > fine. > > If the embedding_in_wx*.py and the docs aren't enough, you may > find it useful to look at the wxPython plotting widget (MPlot) > I've been working on. The code is currently at > http://cars.uchicago.edu/~newville/Epics/Python/MPlot > > This provides a simple wxPython Panel (and/or Frame) widget that > has simple plot() and oplot() methods. This widget responds to > events for zoom, etc and several of the plot attributes (title, > labels, line symbol/color,etc) can be altered through the GUI, > and you can export plot images and/or use the Printer interface. > > The documentation is scant but there are a couple examples and a > README. I'm intending to improve the functionality and docs and > have at least one other person interested and helping out on > this. Anyway, feel free to steal from this (that goes for > anyone else on the list as well!!). Any suggestions for > improvement would be great. > > Cheers, > > --Matt > Thanks for all your feedback. > -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov -------------- next part -------------- #!/usr/bin/env pythonw """ This is a little script that tried to demonstrate a simple "procedural" program using wxPython. tHe goal is to have a script that runs through a few questions for the user, poppin up dialogs as it goes, but wittout a main frame, and all the baggage that usually comes with writing a full, event drive app. """ import wx from sys import exit ## Here's an example of a custom dialog with no parent class MyCheckDialog(wx.Dialog): def __init__(self, Choices): wx.Dialog.__init__(self, None, -1, 'wxDialog') self.Choices = Choices self.clb = wx.CheckListBox(self, -1, wx.DefaultPosition, wx.DefaultSize, self.Choices) ok = wx.Button(self, wx.ID_OK, 'Ok') sizer = wx.BoxSizer(wx.VERTICAL) sizer.Add(self.clb, 1, wx.EXPAND|wx.ALL, 5) sizer.Add(ok, 0, wx.ALIGN_RIGHT|wx.ALL^wx.TOP, 5) self.SetSizer(sizer) #self.Fit() self.Center() # make it come up on the center of the screen def GetChecked(self): Checked = [] for (index, item) in enumerate(self.Choices): if self.clb.IsChecked(index): Checked.append(item) return Checked # You could put some code here, to run before initializing wx. # you need to start by initializing a wxApp app = wx.PySimpleApp() ## now you can run your script, bringing up various dialogs. fd = wx.FileDialog(None,"Pick a File") if fd.ShowModal() != wx.ID_OK: exit(1) else: print "You choose the file: ", fd.GetFilename() md = wx.MessageDialog(None, 'Continue?') if md.ShowModal() != wx.ID_OK: exit(1) else: print "You chose to continue" scd = wx.SingleChoiceDialog(None, 'Pick One', 'A Single Choice Dialog', ['single', 'choice', 'dialog','with','some','choices']) if scd.ShowModal() != wx.ID_OK: exit(1) else: print "You chose:", scd.GetStringSelection() myd = MyCheckDialog(['check', 'list', 'box', 'another']) if myd.ShowModal() != wx.ID_OK: exit(1) else: print "You checked:", myd.GetChecked() From pecora at anvil.nrl.navy.mil Tue Mar 8 00:27:14 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Tue Mar 8 00:27:11 2005 Subject: [Pythonmac-SIG] Re: Binary Matplotlib package, working. Need to keep script running after plotting. In-Reply-To: <422CE03F.1090504@noaa.gov> References: <42017A10.7040505@noaa.gov> <420232BF.9080705@anvil.nrl.navy.mil> <420278A0.9050903@noaa.gov> <422A0082.4000006@anvil.nrl.navy.mil> <422C9E93.2050009@noaa.gov> <422CA62D.9060300@anvil.nrl.navy.mil> <422CABA5.4050503@noaa.gov> <422CB229.3020609@anvil.nrl.navy.mil> <422CE03F.1090504@noaa.gov> Message-ID: <422CE352.200@anvil.nrl.navy.mil> Chris Barker wrote: > Louis Pecora wrote: > >> You pretty much got it. > > > OK. I've enclosed a little script that demonstrates calling up some > stock dialogs in a script with wxPython. really the only trick is that > you need to initialize an app first. Look through the wx docs to see > what standard dialogs there are. Plus there is an example of a custom > one. It wouldn't take much to write some quickie function wrappers > around those dialogs if you want to be able to call them with one line > of code. [Cut a lot of stuff] Wow, Chris! Thanks very much. I hate to give up EasyDialogs because, well, they're so easy, but your approach may be the answer. The embedding of matplotlib in wx looks like a good thing to check out. Will do all. Thanks very much for all the code. Examples like this are great. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From bob at redivi.com Tue Mar 8 01:07:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 8 01:07:30 2005 Subject: [Pythonmac-SIG] py2app troubles In-Reply-To: References: Message-ID: <173ed26cd3f8972351555670908e1c21@redivi.com> On Mar 7, 2005, at 5:24 PM, Dave Opstad wrote: > I've got a Tkinter application that works fine when I launch it via > pythonw. > This is on 10.3.7, default 2.3.0 Python install, added the MacPython > stuff > and installed _tkinter from Package Manager. > > After successfully installing py2app 0.1.7, I modified my setup.py > file and > then did a "python setup.py py2app" to build my app as a standalone, > and > again everything worked fine. No error messages, and the app was > sitting in > the dist folder. Use py2app from svn trunk, or wait for the next release. i think 0.1.7 had a bug with the TCL framework. -bob From bob at redivi.com Tue Mar 8 01:23:16 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 8 01:23:22 2005 Subject: [Pythonmac-SIG] Using UKKQueue with PyObjC In-Reply-To: <1gt2svk.6008fm11jey9cM%newsletter@theflow.de> References: <1gt2svk.6008fm11jey9cM%newsletter@theflow.de> Message-ID: <437e378df346cf64b9a374a174a8632d@redivi.com> On Mar 7, 2005, at 5:11 PM, Florian Munz wrote: > Hi, > > I'm currently trying to use the UKKQueue class to monitor file changes > from my PyObjC application. > > After some fiddling I got the basics working, but encountered some > problems and questions: > > * What is the minimal way to include such an ObjC wrapper class with > py2app? I am using the setup.py from RestEdit [1] right now, but this > looks overly complicated. Also this setup doesn't work when using > --alias It's automatically generated from the Xcode project and is a relatively general solution, so it's not minimal. Works fine with --alias here, you should try it with py2app svn trunk. > * I'm using the notifications provided by NSWorkspace: > > NSWorkspace.sharedWorkspace().notificationCenter().addObserver_selector > _ > name_object_( > self, "documentChanged:", > None, > None) > > Is there a way to register an observer which listens to specific > objects > only? UKKQueue sends notifications with the filename as object, but as > and simply replacing the last None in the > above method with the filename string didn't work. Yes you can register a notification that listens for specific objects, but that doesn't mean what you think it does. > * This is more a PyObjC question: Can I use any Python class as a > delegate for UKKQueue? Or have these to subclass NSObject or something > else? You probably can use any Python class, but the most well tested solution is to use a NSObject subclass whenever you have code that is going to be called from Objective-C, so I would recommend doing that. -bob From n8gray at gmail.com Tue Mar 8 01:45:19 2005 From: n8gray at gmail.com (Nathaniel Gray) Date: Tue Mar 8 01:45:23 2005 Subject: [Pythonmac-SIG] Again: EasyDialogs + Appscript + iPhoto = zombies! In-Reply-To: References: Message-ID: I sent this last week and haven't seen it come through on the list yet. Sorry if it's a duplicate... ---------- Forwarded message ---------- From: Nathaniel Gray Date: Wed, 2 Mar 2005 19:02:44 -0800 Subject: EasyDialogs + Appscript + iPhoto = zombies! To: Pythonmac-Sig Hi, I've written a small appscript that exports an iPhoto album using the "album" photo album tool (written in Perl, but I don't have time to rewrite it... :-/). I wrote the Python script and installed it as /Library/Scripts/Applications/iPhoto/iphoto2album so I can use it from the global Scripts menu. It works fine, but it leaves a zombie Python process lying around every time I run it. I don't know a whole lot about unix process control, but I found that to avoid zombie processes you need to "double-fork". So here's a mock-up of my current code, mostly copied from http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012: #### BEGIN #! /usr/bin/env pythonw import os, sys import EasyDialogs as dialogs, datetime from appscript import * def main(): # This is obviously a dummy main function errfile = open("/Users/n8gray/ip2a.errors", "w") errfile.write("Made it!") errfile.close() dialogs.Message( "Everything works ok." ) try: pid = os.fork() if pid > 0: # exit first parent sys.exit(0) except OSError, e: print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno, e.strerror) sys.exit(1) # decouple from parent environment #os.chdir("/") # I've tried with and without this line. os.setsid() os.umask(0) # do second fork try: pid = os.fork() if pid > 0: # exit from second parent, print eventual PID before # print "Daemon PID %d" % pid sys.exit(0) except OSError, e: print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno, e.strerror) sys.exit(1) # Open file descriptors if not sys.stderr: sys.stderr = sys.stdout si = file('/dev/null', 'r') so = file('/dev/null', 'a+') se = file('/dev/null', 'a+', 0) # Redirect standard file descriptors. os.dup2(si.fileno(), sys.stdin.fileno()) os.dup2(so.fileno(), sys.stdout.fileno()) os.dup2(se.fileno(), sys.stderr.fileno()) # start the daemon main loop main() #### END Unfortunately, it still produces a zombie after each run and I don't see the dialog either. The error log file does get written to, though, so I know the double-fork succeeds. Can anybody help me figure out what the problems are? Also, is there any way to get rid of all the damn zombie processes on my system without rebooting? Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> From bob at redivi.com Tue Mar 8 02:01:12 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 8 02:01:21 2005 Subject: [Pythonmac-SIG] Again: EasyDialogs + Appscript + iPhoto = zombies! In-Reply-To: References: Message-ID: It's a duplicate here... You can't do a fork and then call into Carbon or Cocoa. You can only call into Carbon or Cocoa in a fresh process. You'll need to fork/execve instead. Not sure if that will toss the zombies, but that is at least one thing wrong with this code. -bob On Mar 7, 2005, at 7:45 PM, Nathaniel Gray wrote: > I sent this last week and haven't seen it come through on the list > yet. Sorry if it's a duplicate... > > > ---------- Forwarded message ---------- > From: Nathaniel Gray > Date: Wed, 2 Mar 2005 19:02:44 -0800 > Subject: EasyDialogs + Appscript + iPhoto = zombies! > To: Pythonmac-Sig > > > Hi, > > I've written a small appscript that exports an iPhoto album using the > "album" photo album tool (written in Perl, but I don't have time to > rewrite it... :-/). I wrote the Python script and installed it as > /Library/Scripts/Applications/iPhoto/iphoto2album so I can use it from > the global Scripts menu. It works fine, but it leaves a zombie Python > process lying around every time I run it. I don't know a whole lot > about unix process control, but I found that to avoid zombie processes > you need to "double-fork". So here's a mock-up of my current code, > mostly copied from > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012: > > #### BEGIN > #! /usr/bin/env pythonw > import os, sys > import EasyDialogs as dialogs, datetime > from appscript import * > def main(): > # This is obviously a dummy main function > errfile = open("/Users/n8gray/ip2a.errors", "w") > errfile.write("Made it!") > errfile.close() > dialogs.Message( "Everything works ok." ) > > try: > pid = os.fork() > if pid > 0: > # exit first parent > sys.exit(0) > except OSError, e: > print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno, > e.strerror) > sys.exit(1) > > # decouple from parent environment > #os.chdir("/") # I've tried with and without this line. > os.setsid() > os.umask(0) > > # do second fork > try: > pid = os.fork() > if pid > 0: > # exit from second parent, print eventual PID before > # print "Daemon PID %d" % pid > sys.exit(0) > except OSError, e: > print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno, > e.strerror) > sys.exit(1) > > # Open file descriptors > if not sys.stderr: sys.stderr = sys.stdout > si = file('/dev/null', 'r') > so = file('/dev/null', 'a+') > se = file('/dev/null', 'a+', 0) > > # Redirect standard file descriptors. > os.dup2(si.fileno(), sys.stdin.fileno()) > os.dup2(so.fileno(), sys.stdout.fileno()) > os.dup2(se.fileno(), sys.stderr.fileno()) > > # start the daemon main loop > main() > #### END > > Unfortunately, it still produces a zombie after each run and I don't > see the dialog either. The error log file does get written to, > though, so I know the double-fork succeeds. > > Can anybody help me figure out what the problems are? Also, is there > any way to get rid of all the damn zombie processes on my system > without rebooting? > > Thanks, > -n8 > > -- >>>> -- Nathaniel Gray -- Caltech Computer Science ------> >>>> -- Mojave Project -- http://mojave.cs.caltech.edu --> > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From newsletter at theflow.de Tue Mar 8 16:54:06 2005 From: newsletter at theflow.de (Florian Munz) Date: Tue Mar 8 16:54:09 2005 Subject: [Pythonmac-SIG] Using UKKQueue with PyObjC In-Reply-To: <437e378df346cf64b9a374a174a8632d@redivi.com> Message-ID: <1gt468s.1ay0cb61dawo00M%newsletter@theflow.de> Bob Ippolito wrote: > It's automatically generated from the Xcode project and is a relatively > general solution, so it's not minimal. Works fine with --alias here, > you should try it with py2app svn trunk. Okay, since I'm am not using XCode I thought there must be a simpler way. > You probably can use any Python class, but the most well tested > solution is to use a NSObject subclass whenever you have code that is > going to be called from Objective-C, so I would recommend doing that. I tried subclassing NSObject but now I am not sure about the right way to create an object. Take this minimal example: class Converter (NSObject): def init(self): self = NSObject.init(self) NSWorkspace.sharedWorkspace().notificationCenter(). addObserver_selector_name_object_( self, "documentChanged:", None, None) return self def documentChanged_(self, notification): print 'handleChange' If I instantiate this class from the Main-Class with Converter.alloc().init() my application dies quickly (Crash Reporter, nothing in the logs). If I however instantiate it from Interface Builder it works. Is this a bug or a feature? :) I don't want to instantate it from IB, because I have 4 of these classes and don't need all of them everytime. thanks, Florian From Cameron at Phaseit.net Tue Mar 8 18:36:20 2005 From: Cameron at Phaseit.net (Cameron Laird) Date: Tue Mar 8 18:36:24 2005 Subject: [Pythonmac-SIG] Pygame installation Message-ID: <20050308173620.GA32416@lairds.us> I want Pygame for OS X (10.3, preferably). appears to direct me to , but I can't reach undefined.org (or www.undefined.org, or ...). I've written Pygame lead Pete Shinners. I've received no response. I'm open to suggestion. 'Anyone happen to have installa- tion bundles handy? Does anyone know whether the sources generate cleanly under 10.3? From bob at redivi.com Tue Mar 8 19:35:59 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 8 19:36:15 2005 Subject: [Pythonmac-SIG] Using UKKQueue with PyObjC In-Reply-To: <1gt468s.1ay0cb61dawo00M%newsletter@theflow.de> References: <1gt468s.1ay0cb61dawo00M%newsletter@theflow.de> Message-ID: <25384cd137a2f3db5aaaa61eaf9b2563@redivi.com> On Mar 8, 2005, at 10:54, Florian Munz wrote: > Bob Ippolito wrote: > >> It's automatically generated from the Xcode project and is a >> relatively >> general solution, so it's not minimal. Works fine with --alias here, >> you should try it with py2app svn trunk. > > Okay, since I'm am not using XCode I thought there must be a simpler > way. There is, but not much simpler. You still have to build an extension that the Objective-C code is going to live in. If it was a pre-built framework or plug-in it would be a different story, but compiling one of those is harder than having distutils build an extension. >> You probably can use any Python class, but the most well tested >> solution is to use a NSObject subclass whenever you have code that is >> going to be called from Objective-C, so I would recommend doing that. > > I tried subclassing NSObject but now I am not sure about the right way > to create an object. Take this minimal example: > > class Converter (NSObject): > def init(self): > self = NSObject.init(self) > NSWorkspace.sharedWorkspace().notificationCenter(). > addObserver_selector_name_object_( > self, "documentChanged:", > None, > None) > return self > > def documentChanged_(self, notification): > print 'handleChange' > > If I instantiate this class from the Main-Class with > Converter.alloc().init() my application dies quickly (Crash Reporter, > nothing in the logs). If I however instantiate it from Interface > Builder > it works. Is this a bug or a feature? :) > I don't want to instantate it from IB, because I have 4 of these > classes > and don't need all of them everytime. You forgot to specify WHICH notification in Converter.. you're saying "add my documentChanged: selector as an observer to... nothing". Also, use self = super(Converter, self).init() -bob From bob at redivi.com Tue Mar 8 19:38:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 8 19:38:18 2005 Subject: [Pythonmac-SIG] Pygame installation In-Reply-To: <20050308173620.GA32416@lairds.us> References: <20050308173620.GA32416@lairds.us> Message-ID: On Mar 8, 2005, at 12:36, Cameron Laird wrote: > I want Pygame for OS X (10.3, preferably). http://www.pygame.org/download.shtml > appears to > direct me to , > but I can't reach undefined.org (or www.undefined.org, > or ...). I've written Pygame lead Pete Shinners. I've > received no response. undefined.org is down, probably for another day -- maybe two. Pete probably isn't going to respond, he hasn't really been involved with pygame for the past few months. > I'm open to suggestion. 'Anyone happen to have installa- > tion bundles handy? Does anyone know whether the sources > generate cleanly under 10.3? You'll need lots of dependencies in order to get pygame up and running. I suggest just waiting until 1.7 installation packages are released, which should be a matter of days. -bob From newsletter at theflow.de Tue Mar 8 21:35:36 2005 From: newsletter at theflow.de (Florian Munz) Date: Tue Mar 8 21:35:40 2005 Subject: [Pythonmac-SIG] Using UKKQueue with PyObjC In-Reply-To: <25384cd137a2f3db5aaaa61eaf9b2563@redivi.com> Message-ID: <1gt4j35.ka7gfo1ddep0sM%newsletter@theflow.de> Bob Ippolito wrote: > You forgot to specify WHICH notification in Converter.. you're saying > "add my documentChanged: selector as an observer to... nothing". The object and name are None, because I want to listen to all notifications (just for this test, but adding a specific name doesn't change anyting in this example). However, if I instantiate the Converter class over IB everything works as intended, but if I delete the instance from IB and create the object via Converter.alloc().init() from the other class the App crashes. I get segfaults and bus error from pdb. I uploaded the crash-log [1] if this is any help, but I think I am just doing something fundamental wrong, but I don't know how to debug this any further. Florian [1] http://theflow.de/TestCocoa_crash.log From bob at redivi.com Tue Mar 8 22:06:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 8 22:06:55 2005 Subject: [Pythonmac-SIG] Using UKKQueue with PyObjC In-Reply-To: <1gt4j35.ka7gfo1ddep0sM%newsletter@theflow.de> References: <1gt4j35.ka7gfo1ddep0sM%newsletter@theflow.de> Message-ID: <6ca159abeb2b8cb3af725865db5e5b74@redivi.com> On Mar 8, 2005, at 15:35, Florian Munz wrote: > Bob Ippolito wrote: > >> You forgot to specify WHICH notification in Converter.. you're saying >> "add my documentChanged: selector as an observer to... nothing". > > The object and name are None, because I want to listen to all > notifications (just for this test, but adding a specific name doesn't > change anyting in this example). > > However, if I instantiate the Converter class over IB everything works > as intended, but if I delete the instance from IB and create the object > via Converter.alloc().init() from the other class the App crashes. I > get > segfaults and bus error from pdb. > > I uploaded the crash-log [1] if this is any help, but I think I am just > doing something fundamental wrong, but I don't know how to debug this > any further. > > [1] http://theflow.de/TestCocoa_crash.log The crash log makes it obvious, thanks. Not all Objective-C objects retain other objects, similar to a weakref in Python. When they use a dead object, the application crashes (where a weakref in Python would raise an exception, because they're safer). In this case, your Controller object is: (a) getting deallocated because you're not storing away a reference to it anywhere (b) not getting retained by NSNotificationCenter, because notification centers don't retain their observers (c) not removing itself from NSNotificationCenter on __del__, which is bad. What you need to do here is: (a) implement a __del__ that removes it as an observer or otherwise ensure that the Controller object is never an observer after it's dead (i.e. by making sure it never dies, or removing it manually before it goes away). (b) make sure it's alive for the duration that you want it to receive notifications, by storing away a reference to it somewhere.. if you are just testing and you want it to never go away, do self.retain() -bob From newsletter at theflow.de Tue Mar 8 22:59:53 2005 From: newsletter at theflow.de (Florian Munz) Date: Tue Mar 8 22:59:55 2005 Subject: [Pythonmac-SIG] Using UKKQueue with PyObjC In-Reply-To: <6ca159abeb2b8cb3af725865db5e5b74@redivi.com> Message-ID: <1gt4ncb.1jk25u51u8r8nvM%newsletter@theflow.de> Bob Ippolito wrote: > What you need to do here is: > (a) implement a __del__ that removes it as an observer or otherwise > ensure that the Controller object is never an observer after it's dead > (i.e. by making sure it never dies, or removing it manually before it > goes away). > (b) make sure it's alive for the duration that you want it to receive > notifications, by storing away a reference to it somewhere.. if you are > just testing and you want it to never go away, do self.retain() Thanks a lot, that solved all my problems and I know a significant bit more about PyObjC now ;-) thanks, Florian From bob at redivi.com Tue Mar 8 23:25:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 8 23:25:41 2005 Subject: [Pythonmac-SIG] Using UKKQueue with PyObjC In-Reply-To: <1gt4ncb.1jk25u51u8r8nvM%newsletter@theflow.de> References: <1gt4ncb.1jk25u51u8r8nvM%newsletter@theflow.de> Message-ID: <636b1a0c4793eb97ddbecd9cb857f319@redivi.com> On Mar 8, 2005, at 16:59, Florian Munz wrote: > Bob Ippolito wrote: > >> What you need to do here is: >> (a) implement a __del__ that removes it as an observer or otherwise >> ensure that the Controller object is never an observer after it's dead >> (i.e. by making sure it never dies, or removing it manually before it >> goes away). >> (b) make sure it's alive for the duration that you want it to receive >> notifications, by storing away a reference to it somewhere.. if you >> are >> just testing and you want it to never go away, do self.retain() > > Thanks a lot, that solved all my problems and I know a significant bit > more about PyObjC now ;-) FYI the best way to debug a crash that happens on objc_msgSend is to use the same technique you would use when debugging Objective-C code: NSZombie. Some information is available: http://developer.apple.com/technotes/tn2004/tn2124.html http://www.cocoadev.com/index.pl?DebuggingAutorelease Essentially, what I do is this (with an --alias build): env NSZombieEnabled=YES USE_PDB=1 ./dist/MyApp.app/Contents/MacOS/MyApp If it's really bad, I'll use GDB: env NSZombieEnabled=YES USE_PDB=1 gdb --args ./dist/MyApp.app/Contents/MacOS/MyApp USE_PDB is an environment variable that PyObjCTools.AppHelper.runEventLoop() inspects. When it's set, it will: (1) enable PyObjCTools.Debugging in verbose mode, so you get a stack trace at every exception that Objective-C sees (caught or otherwise). Python exceptions that cross the bridge will have additional information. (2) on uncaught exceptions, it'll drop you to pdb (though the runloop will catch many exceptions) Unfortunately, by the time runEventLoop kicks in it is too late to twiddle NSZombieEnabled and other Foundation debugging hooks, so you have to set it explicitly. -bob From bob at redivi.com Wed Mar 9 01:58:36 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 9 01:58:48 2005 Subject: [Pythonmac-SIG] Installer mpkg repository moved Message-ID: <0824bdebb4e1ef53073539527d73f1b1@redivi.com> I've moved my repository of installer packages for Mac OS X Python to: http://pythonmac.org/packages/ Of particular interest is a new matplotlib package from Chris Barker: """ This is an upgrade to matplotlib 0.72.1, and it should work with Agg, Wx and TK (not PyGTK). I haven't included Numeric this time, as you have a Numeric package on the same sight already. """ -bob From sw at wordtech-software.com Wed Mar 9 05:00:24 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Mar 9 05:00:28 2005 Subject: [Pythonmac-SIG] Weirdness with ld/PyQt-Mac build Message-ID: <422E74D8.5040603@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm working on a new build of PyQt-Mac. Everything seemed to build fine (Qt 3.3.4, latest versions of QScintilla, SIP, and PyQt), and install without incident. However, PyQt applications no longer launch: it seems they don't see libqscintilla. Here's a typical message: Contents/MacOS/Eric 3 can't open library: libqscintilla.5.dylib (No such file or directory, errno = 2) This is puzzling because that library is correctly installed in /Developer/qt/lib, which is where it should be. So I don't see why these other apps can't see it. Looking at the logs from building PyQt, I ran across this strange warning: ld: warning -L: directory name (/Users/kevin/Desktop/qt-mac-free-3.3.4-shared/lib) does not exist The directory that "does not exist" is the build directory for Qt. After ~ building Qt, I moved the build folder to /Developer and renamed it qt. Then I began building PyQt and the other bits. I'm pretty sure that these other apps think that libqscintilla.dylib should be in /Users/kevin/Desktop/qt-mac-free-3.3.4-shared/lib. But why? ~ What difference does it make, especially when I have $QTDIR set in my path to point to /Developer/qt? And if this is a problem, how do I fix it (short of rebuilding Qt in /Developer/qt--groan...) Thanks for any advice. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCLnTYJmdQs+6YVcoRAgjYAJ9kzjb8w+UrDqbjJgox9M4AV70BKQCfcIk6 9hCtXY4zhqRnBm8wiYR2dRY= =FabY -----END PGP SIGNATURE----- From bob at redivi.com Wed Mar 9 05:24:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 9 05:24:27 2005 Subject: [Pythonmac-SIG] Weirdness with ld/PyQt-Mac build In-Reply-To: <422E74D8.5040603@wordtech-software.com> References: <422E74D8.5040603@wordtech-software.com> Message-ID: On Mar 8, 2005, at 11:00 PM, Kevin Walzer wrote: > I'm working on a new build of PyQt-Mac. Everything seemed to build fine > (Qt 3.3.4, latest versions of QScintilla, SIP, and PyQt), and install > without incident. However, PyQt applications no longer launch: it seems > they don't see libqscintilla. Here's a typical message: > > Contents/MacOS/Eric 3 can't open library: libqscintilla.5.dylib (No > such file or directory, errno = 2) > > This is puzzling because that library is correctly installed in > /Developer/qt/lib, which is where it should be. So I don't see why > these > other apps can't see it. > > Looking at the logs from building PyQt, I ran across this strange > warning: > > ld: warning -L: directory name > (/Users/kevin/Desktop/qt-mac-free-3.3.4-shared/lib) does not exist > > The directory that "does not exist" is the build directory for Qt. > After > ~ building Qt, I moved the build folder to /Developer and renamed it > qt. > Then I began building PyQt and the other bits. > > I'm pretty sure that these other apps think that libqscintilla.dylib > should be in /Users/kevin/Desktop/qt-mac-free-3.3.4-shared/lib. But > why? > ~ What difference does it make, especially when I have $QTDIR set in my > path to point to /Developer/qt? And if this is a problem, how do I fix > it (short of rebuilding Qt in /Developer/qt--groan...) The problem here is that the Qt developers did a poor job of porting to the Mac and don't set the proper install_name on these libraries. You will need to run install_name_tool over them after putting them in the bundle. Better yet, run macho_standalone from py2app svn on the app. -bob From troy.rollins at gmail.com Wed Mar 9 16:58:50 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Wed Mar 9 16:58:53 2005 Subject: [Pythonmac-SIG] Pygame installation In-Reply-To: References: <20050308173620.GA32416@lairds.us> Message-ID: <31ac537c05030907584eab9ce6@mail.gmail.com> > You'll need lots of dependencies in order to get pygame up and running. > I suggest just waiting until 1.7 installation packages are released, > which should be a matter of days. > A pyGame install package sounds awesome, this would take care of all the dependencies for pyGame? It was a nightmare trying to do it with the package installer, since many of the sites are no longer found, etc. I'd love to get pyUI running, and pyGame is a dependency for that... which has all those dependencies of it own. Without some help in the form of packaged installers, it is pretty rough traveling for a newbie. So, thanks for these efforts! -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From mark at mophilly.com Wed Mar 9 20:42:13 2005 From: mark at mophilly.com (Mark Phillips) Date: Wed Mar 9 20:42:16 2005 Subject: [Pythonmac-SIG] GUI design tools Message-ID: This may be a perennial subject. If this is an oft-repeated request, I sincerely apologize for wasting bandwidth. I have a database application I would like to build in Python. I use MacOS X as my primary machine, but historically I have supported old MacOS and Windows machines. This makes it hard for me to abandon the "cross-platform" mindset. I like tools that ease the creation and deployment of applications. The ideal solution for me would be a tool set that is similar to popular RAD tools such as 4D, Omnis Studio and the like. Using these have spoiled me rotten as a programmer, and I find myself balking at the installation requirements of the pythonic stuff I have looked at. That is, as I work through the steps I wonder how on earth an end user will deal with this. I have experience with OOP, OOA&D and have about 16 years experience writing various stand-alone, client/server and n-tier business applications. I am getting a handle on Python, and I have written a couple of "faceless" applications with it. Perhaps I just need a good "not quite a dummy" article, book or something. I have read "Learning Python" and make good use of python.org resources. Still, I haven't found joy with user experience tools yet. I would be most grateful for any links or suggestions. TIA, Mark Phillips From bob at redivi.com Wed Mar 9 20:53:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 9 20:53:15 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: References: Message-ID: <478476d7f98e17d06acdcb959ea9003e@redivi.com> On Mar 9, 2005, at 2:42 PM, Mark Phillips wrote: > This may be a perennial subject. If this is an oft-repeated request, I > sincerely apologize for wasting bandwidth. > > I have a database application I would like to build in Python. I use > MacOS X as my primary machine, but historically I have supported old > MacOS and Windows machines. This makes it hard for me to abandon the > "cross-platform" mindset. I like tools that ease the creation and > deployment of applications. > > The ideal solution for me would be a tool set that is similar to > popular RAD tools such as 4D, Omnis Studio and the like. Using these > have spoiled me rotten as a programmer, and I find myself balking at > the installation requirements of the pythonic stuff I have looked at. > That is, as I work through the steps I wonder how on earth an end user > will deal with this. First off, I'm pretty sure you're not going to find a toolset of that calibre for cross-platform Python development. End users don't deal with this (unless the developer hates them)! The responsible developer takes their application and its dependencies (including Python itself in most cases) and simply create a self-contained application out of it. The end user doesn't need to know nor care about anything but the application. The developer tools for doing this are py2app on Mac OS X, py2exe or cx_Freeze on Windows, and cx_Freeze on Linux (possibly other *nix too). > I have experience with OOP, OOA&D and have about 16 years experience > writing various stand-alone, client/server and n-tier business > applications. I am getting a handle on Python, and I have written a > couple of "faceless" applications with it. > > Perhaps I just need a good "not quite a dummy" article, book or > something. I have read "Learning Python" and make good use of > python.org resources. Still, I haven't found joy with user experience > tools yet. > > I would be most grateful for any links or suggestions. For cross-platform applications, general consensus seems to be that wxPython is the best approach. -bob From mwh at python.net Wed Mar 9 21:37:19 2005 From: mwh at python.net (Michael Hudson) Date: Wed Mar 9 21:37:21 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: (Mark Phillips's message of "Wed, 9 Mar 2005 11:42:13 -0800") References: Message-ID: <2mekeoo8sg.fsf@starship.python.net> Mark Phillips writes: > This may be a perennial subject. If this is an oft-repeated request, I > sincerely apologize for wasting bandwidth. It's .. not entirely unfamiliar :) > MacOS X as my primary machine, but historically I have supported old > MacOS and Windows machines. This makes it hard for me to abandon the > "cross-platform" mindset. I like tools that ease the creation and > deployment of applications. If you can lose that mindset, you will probably find pyobjc + Interface Builder to be about as painless as it's going to get. > The ideal solution for me would be a tool set that is similar to > popular RAD tools such as 4D, Omnis Studio and the like. Using these > have spoiled me rotten as a programmer, and I find myself balking at > the installation requirements of the pythonic stuff I have looked > at. That is, as I work through the steps I wonder how on earth an end > user will deal with this. As Bob said, you really shouldn't make the end user deal with this. OTOH, PyObjC is hardly traumatising to install -- "double click this pkg". Not x-platform of course, unless Gnustep suddenly happens in a way that it hasn't yet. Cheers, mwh -- ARTHUR: But which is probably incapable of drinking the coffee. -- The Hitch-Hikers Guide to the Galaxy, Episode 6 From matsakis at mit.edu Wed Mar 9 22:13:25 2005 From: matsakis at mit.edu (Nick Matsakis) Date: Wed Mar 9 22:13:27 2005 Subject: [Pythonmac-SIG] Using Python with Terminal Message-ID: Is there a simple way to use python with the Mac Terminal so that the arrow keys will allow you to execute previously executed statements? I'm using python 2.3.0 on 10.3. Also, a random Python question. I'd like to get an arbitrary element from a sets.Set _without_ mutating the sets. The most concise way I could find is this: for item in someset: break Which will assign item to an arbitrary element in someset. This expression really annoys me, though. Is there a better way? Nick From kerfue+pythonmac-sig at herocamp.org Wed Mar 9 22:22:49 2005 From: kerfue+pythonmac-sig at herocamp.org (Truls A. Tangstad) Date: Wed Mar 9 22:22:53 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: References: Message-ID: <20050309212249.GA30521@sakura.chem.ntnu.no> On Wed, Mar 09, 2005 at 11:42:13AM -0800, Mark Phillips wrote: > This may be a perennial subject. If this is an oft-repeated request, I > sincerely apologize for wasting bandwidth. > > I have a database application I would like to build in Python. I use > MacOS X as my primary machine, but historically I have supported old > MacOS and Windows machines. This makes it hard for me to abandon the > "cross-platform" mindset. I like tools that ease the creation and > deployment of applications. > > The ideal solution for me would be a tool set that is similar to > popular RAD tools such as 4D, Omnis Studio and the like. Using these > have spoiled me rotten as a programmer, and I find myself balking at > the installation requirements of the pythonic stuff I have looked at. > That is, as I work through the steps I wonder how on earth an end user > will deal with this. > > I have experience with OOP, OOA&D and have about 16 years experience > writing various stand-alone, client/server and n-tier business > applications. I am getting a handle on Python, and I have written a > couple of "faceless" applications with it. > > Perhaps I just need a good "not quite a dummy" article, book or > something. I have read "Learning Python" and make good use of > python.org resources. Still, I haven't found joy with user experience > tools yet. > > I would be most grateful for any links or suggestions. It's not that mature on OS X yet, but I've been developing with Trolltech's Qt[1] framework using python for quite a while, and really like it, especially for its cross platform usage. Kevin Walzer has a binary installer for the libraries[2]. With PyQt i usually program a unit-tested backend with all the functionality, while creating a nice GUI in Qt's graphical Designer[3] tool. The files created in the Designer can be loaded runtime by a simple statement like: widget = QWidgetFactory.create("mainwindow.ui") Using Qt's signal/slot system (just a twist on the observer pattern), you can say which python-functions should respond to which buttons, or get triggered by which changes of textfields etc. You can achieve the same effect using GTK's python bindings with the glade designer and libglade for loading GUIs runtime, and I assume wxPython works the same way, but I have little experience with GTK and none with wxPython. Packaging tools[4] can go a long way at making the end user have an easy time of an install. Using py2app makes it easy to package the entire application and its dependencies into one easy to install application bundle, but you'd have to repeat the procedure on windows and other operating systems to create OS-specific packages there. That's one of the reasons it's often easier to create a slim python-only package that can be run on all operating systems, but then end up with alot of listed requirements which the end user would have to fulfill on his/her computer. As far as learning python goes, I prefer the interactive approach using the help/dir-functions to see what's available, supplemented by the official documentation[5]. I've also heard Dive into Python[6] recommended alot, but haven't read it myself. I guess the conclusion is that you can achieve the end result you're after for users, but it's more often done by using a set of applications/frameworks (eg. qtdesigner, your favourite editor and py2app) instead of a do-all IDE. Feel free to correct me if i misunderstood your request. [1] - http://www.trolltech.com/products/qt/index.html [2] - http://www.wordtech-software.com/pyqt-mac.html [3] - http://doc.trolltech.com/3.3/designer-manual-1.html [4] - http://www.wordtech-software.com/python-applet-tutorial.html [5] - http://www.python.org/doc/ [6] - http://diveintopython.org/ -- Truls A. Tangstad - From kerfue+pythonmac-sig at herocamp.org Wed Mar 9 22:36:35 2005 From: kerfue+pythonmac-sig at herocamp.org (Truls A. Tangstad) Date: Wed Mar 9 22:36:42 2005 Subject: [Pythonmac-SIG] Using Python with Terminal In-Reply-To: References: Message-ID: <20050309213635.GA30979@sakura.chem.ntnu.no> On Wed, Mar 09, 2005 at 04:13:25PM -0500, Nick Matsakis wrote: > > Is there a simple way to use python with the Mac Terminal so that the > arrow keys will allow you to execute previously executed statements? > I'm using python 2.3.0 on 10.3. Still haven't solved that one myself, but I usually interact with python interactively through emacs, or an xterm. > Also, a random Python question. I'd like to get an arbitrary element from > a sets.Set _without_ mutating the sets. The most concise way I could find > is this: > > for item in someset: break > > Which will assign item to an arbitrary element in someset. This > expression really annoys me, though. Is there a better way? Well.. for an uncertain definition of "better", the following is a possibility: item = list(someset)[0] # a more random choice from random import choice item = choice(list(someset)) -- Truls A. Tangstad - From bob at redivi.com Wed Mar 9 23:11:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 9 23:11:29 2005 Subject: [Pythonmac-SIG] Using Python with Terminal In-Reply-To: References: Message-ID: <47fa697da45ed745e6481a65de19d4fe@redivi.com> On Mar 9, 2005, at 4:13 PM, Nick Matsakis wrote: > > Is there a simple way to use python with the Mac Terminal so that the > arrow keys will allow you to execute previously executed statements? > I'm using python 2.3.0 on 10.3. install readline, pyrep, or the like.. I'll have a readline installer up at http://pythonmac.org/packages/ later today. After installing readline, you may want to take a look at IPython to further enhance the experience. > Also, a random Python question. I'd like to get an arbitrary element > from > a sets.Set _without_ mutating the sets. The most concise way I could > find > is this: > > for item in someset: break > > Which will assign item to an arbitrary element in someset. This > expression really annoys me, though. Is there a better way? item = iter(someset).next() has the same semantics as the above statement, except for empty sets it will raise a StopIteration right away, instead of a NameError when you try and use "item" :) -bob From bob at redivi.com Wed Mar 9 23:29:59 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 9 23:30:08 2005 Subject: [Pythonmac-SIG] Missing extensions for Panther Python Message-ID: <775b72830a4187383aadd4adef1c5046@redivi.com> The Python 2.3.0 distributed with Mac OS X 10.3 is missing three extensions typically found on other platforms: _bsddb _tkinter readline Since these are part of the standard library, it is somewhat annoying to build them after the fact. I have put together a little svn repository with the relevant setup scripts and sources: http://svn.red-bean.com/bob/MacPythonPantherExtras/trunk/ Installer packages for these three extensions are available at: http://pythonmac.org/packages/ Note that _bsddb and readline include their respective dependencies statically, where _tkinter requires TclTkAqua 8.4 from: http://tcltkaqua.sf.net/ -bob From Chris.Barker at noaa.gov Wed Mar 9 23:56:13 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Mar 9 23:56:11 2005 Subject: [Pythonmac-SIG] Missing extensions for Panther Python In-Reply-To: <775b72830a4187383aadd4adef1c5046@redivi.com> References: <775b72830a4187383aadd4adef1c5046@redivi.com> Message-ID: <422F7F0D.5010705@noaa.gov> Bob Ippolito wrote: > Note that _bsddb and readline include their respective dependencies > statically, where _tkinter requires TclTkAqua 8.4 from: > > http://tcltkaqua.sf.net/ not that this is all that big a deal, but how hard would it be to make a single installer for everything that Tkinter needs (and little else)? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Thu Mar 10 00:06:36 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 10 00:06:41 2005 Subject: [Pythonmac-SIG] Missing extensions for Panther Python In-Reply-To: <422F7F0D.5010705@noaa.gov> References: <775b72830a4187383aadd4adef1c5046@redivi.com> <422F7F0D.5010705@noaa.gov> Message-ID: On Mar 9, 2005, at 5:56 PM, Chris Barker wrote: > Bob Ippolito wrote: > >> Note that _bsddb and readline include their respective dependencies >> statically, where _tkinter requires TclTkAqua 8.4 from: >> http://tcltkaqua.sf.net/ > > not that this is all that big a deal, but how hard would it be to make > a single installer for everything that Tkinter needs (and little > else)? I don't use Tkinter enough to know precisely what Tkinter needs. I always just get the Batteries Included builds. If someone else wants to figure that out, I'm open to the idea. -bob From Henning.Ramm at mediapro-gmbh.de Thu Mar 10 09:17:07 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Thu Mar 10 09:17:11 2005 Subject: [Pythonmac-SIG] GUI design tools Message-ID: >I have experience with OOP, OOA&D and have about 16 years experience >writing various stand-alone, client/server and n-tier business >applications. I am getting a handle on Python, and I have written a >couple of "faceless" applications with it. As Bob wrote, wx seems to be the best cross-platform choice. Regarding 3-tier bussiness apps you should have a look at dabo (based on wx); it's not yet mature and esp. strange on OSX, but perhaps you can help them. Regarding client-server stuff I'd suggest twisted (huge framework of network stuff, event based). see http://www.wxpython.org/ http://www.dabodev.com/ http://twistedmatrix.com/ Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From troy.rollins at gmail.com Thu Mar 10 15:13:20 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Thu Mar 10 15:13:23 2005 Subject: [Pythonmac-SIG] Twisted package? Message-ID: <31ac537c05031006136d05759a@mail.gmail.com> I know Bob is creating and setting up a pyGame installer package to be housed at < http://pythonmac.org/packages/> can we assume that Twisted for OSX will make its way there as well? Thanks! -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From mark at mophilly.com Thu Mar 10 17:32:46 2005 From: mark at mophilly.com (Mark Phillips) Date: Thu Mar 10 17:32:50 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: References: Message-ID: Thanks to everyone who replied. The information is useful and I will investigate each option. - Mark On Mar 9, 2005, at 11:42 AM, Mark Phillips wrote: > This may be a perennial subject. If this is an oft-repeated request, I > sincerely apologize for wasting bandwidth. [snip] From bob at redivi.com Thu Mar 10 17:55:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 10 17:55:59 2005 Subject: [Pythonmac-SIG] Twisted package? In-Reply-To: <31ac537c05031006136d05759a@mail.gmail.com> References: <31ac537c05031006136d05759a@mail.gmail.com> Message-ID: On Mar 10, 2005, at 9:13, Troy Rollins wrote: > I know Bob is creating and setting up a pyGame installer package to be > housed at < http://pythonmac.org/packages/> can we assume that Twisted > for OSX will make its way there as well? You can't assume anything, but the chances are good that I'll do one for Twisted 2.0 when it's ready. -bob From Chris.Barker at noaa.gov Thu Mar 10 18:12:46 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Mar 10 18:12:41 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: References: Message-ID: <4230800E.3040300@noaa.gov> Mark Phillips wrote: > Thanks to everyone who replied. The information is useful and I will > investigate each option. One other note. Boa is worth checking out for an integrated GUI design tool and IDE, but I'm not sure it's ready to go on OS-X. Last I heard, it wasn't yet working with wxPython 2.5.*, which is really required for it to work well on OS-X. PythonCard has been actively targeting OS-X as well. For less integrated tools, there are a few GUI layout tools for wxPython: wxDesigner, Dialog Block, wxGlade, XrcEd, ??? The only one I've used is wxDesigner, and while I still prefer to do GUI layout with code (and Sizers, definitely take the time to wrap your brain around Sizers), other find these tools very helpful. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From troy.rollins at gmail.com Thu Mar 10 23:02:21 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Thu Mar 10 23:02:23 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: <4230800E.3040300@noaa.gov> References: <4230800E.3040300@noaa.gov> Message-ID: <31ac537c050310140276c60f76@mail.gmail.com> > The only one I've used is wxDesigner, and while I still prefer to do GUI > layout with code (and Sizers, definitely take the time to wrap your > brain around Sizers), other find these tools very helpful. > It really seems that on OSX, if you want to build x-plat native interfaces, you are pretty much going to do it with wx, and code. All of the graphical design tools for doing it are otherwise too buggy or unfinished to be productive. (pyObjC being the exception, but this isn't x-plat.) -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From charles.hartman at conncoll.edu Thu Mar 10 23:21:27 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Mar 10 23:22:00 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: <31ac537c050310140276c60f76@mail.gmail.com> References: <4230800E.3040300@noaa.gov> <31ac537c050310140276c60f76@mail.gmail.com> Message-ID: <2c193b7e88207d222ac83190b6c44463@conncoll.edu> On Mar 10, 2005, at 5:02 PM, Troy Rollins wrote: >> The only one I've used is wxDesigner, and while I still prefer to do >> GUI >> layout with code (and Sizers, definitely take the time to wrap your >> brain around Sizers), other find these tools very helpful. >> > > It really seems that on OSX, if you want to build x-plat native > interfaces, you are pretty much going to do it with wx, and code. All > of the graphical design tools for doing it are otherwise too buggy or > unfinished to be productive. (pyObjC being the exception, but this > isn't x-plat.) > > -- > Troy Rollins That is how I have found the situation. I use WingIDE for editing and debugging, but it doesn't include any graphic designer for wx. I wish something that did worked, or that I could get it to work. Several half-there solutions; but everything I've tried either isn't ready for OS X or isn't ready for prime time. Charles Hartman From Chris.Barker at noaa.gov Fri Mar 11 03:39:54 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Mar 10 23:45:10 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: <2c193b7e88207d222ac83190b6c44463@conncoll.edu> References: <4230800E.3040300@noaa.gov> <31ac537c050310140276c60f76@mail.gmail.com> <2c193b7e88207d222ac83190b6c44463@conncoll.edu> Message-ID: <423104FA.7090707@noaa.gov> Charles Hartman wrote: > That is how I have found the situation. I use WingIDE for editing and > debugging, but it doesn't include any graphic designer for wx. I wish > something that did worked, or that I could get it to work. Several > half-there solutions; but everything I've tried either isn't ready for > OS X or isn't ready for prime time. Have you tried wxDesigner? It's commercial, but quite reasonable. And I thought someone had built a wxGlade package for OS-X. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From sw at wordtech-software.com Fri Mar 11 00:17:08 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Fri Mar 11 00:17:13 2005 Subject: [Pythonmac-SIG] [Fwd: Re: [PyKDE] ANN: new eric3 snapshot] Message-ID: <4230D574.8040002@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can anyone who is using my distribution of PyQt download the new version of Eric3 (version 3.6.2) and give it a try? I'm getting weird errors from both 3.6.2 and the latest development snapshot, and I'm not sure how to address it. (This is in preparation for a new binary release of PyQt/Mac, updating all the bits to their latest versions). The attached correspondence with the Eric3 developer outlines some of the errors in more depth. He's not sure what's going on because stuff works fine on Linux, and also he has no access to the Mac. Thanks for any feedback. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMNVzJmdQs+6YVcoRAoOMAJ9BTWmWT1sHFlZf8Q7t6mxpcWzYdQCffU5Y 5sQRqspAGStoRGw0Y8Ugba4= =gCEN -----END PGP SIGNATURE----- -------------- next part -------------- An embedded message was scrubbed... From: Detlev Offenbach Subject: Re: [PyKDE] ANN: new eric3 snapshot Date: Thu, 10 Mar 2005 19:31:36 +0100 Size: 5220 Url: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050310/6a1195a0/neweric3snapshot.mht From Chris.Barker at noaa.gov Fri Mar 11 00:41:05 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Mar 11 00:40:59 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: <423104FA.7090707@noaa.gov> References: <4230800E.3040300@noaa.gov> <31ac537c050310140276c60f76@mail.gmail.com> <2c193b7e88207d222ac83190b6c44463@conncoll.edu> <423104FA.7090707@noaa.gov> Message-ID: <4230DB11.9@noaa.gov> Chris Barker wrote: > I > thought someone had built a wxGlade package for OS-X. and here it is: http://www.wordtech-software.com/wxglade.html -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From charles.hartman at conncoll.edu Fri Mar 11 01:07:59 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri Mar 11 01:08:07 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: <4230DB11.9@noaa.gov> References: <4230800E.3040300@noaa.gov> <31ac537c050310140276c60f76@mail.gmail.com> <2c193b7e88207d222ac83190b6c44463@conncoll.edu> <423104FA.7090707@noaa.gov> <4230DB11.9@noaa.gov> Message-ID: <3aeb0b30b59438243aeecd271c987371@conncoll.edu> It crashes for me all the time; I found it unusable at this stage. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Mar 10, 2005, at 6:41 PM, Chris Barker wrote: > Chris Barker wrote: >> I >> thought someone had built a wxGlade package for OS-X. > > and here it is: > > http://www.wordtech-software.com/wxglade.html > > -Chris > > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker@noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Fri Mar 11 09:31:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 11 09:32:01 2005 Subject: [Pythonmac-SIG] ANN: pygame 1.7.0 for Mac OS X 10.3 Message-ID: Although the official sdist tarball isn't cut yet, I've packaged what should be pygame 1.7.0 for Mac OS X 10.3 users. It is available from pythonmac.org packages at: http://pythonmac.org/packages/ This installer ships with: pygame: Installed to /Library/Python2.3/ pygame headers: Installed to /System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3/ pygame examples and documentation: Installed to /Developer/Python/pygame/ SDL with my AltiVec patches, SDL_mixer, SDL_ttf, SDL_image, smpeg: Installed to /Library/Frameworks/ To use pygame, you will need PyObjC 1.2 or later, and you will probably want Numeric and PyOpenGL installed. A PyOpenGL installer is not available from pythonmac.org packages at this time, but everything else listed is. The following improvements are especially relevant to Mac OS X: - Calls into nasty private Apple API to grab GUI access if it doesn't already have it (read: no pythonw required) - Can now read the default font and icon out of any "get_data" compliant loader (read: py2app 0.1.8 can put pygame entirely in the site-packages.zip, and it works!). - Includes newer versions of all dependencies (it sure has been a long time since 1.6.0!) - Most surface operations should be significantly faster on G4 and G5 computers due to my AltiVec patches to SDL As it has been quite a long time since the last release, there are pages full of bug fixes and feature enhancements. When the pygame.org site updates for the 1.7 release, check WhatsNew. Note that I will not be making a Mac OS X 10.2 compatible release for Python 2.3. When Python 2.4.1 is out (and probably not until there is an official distribution of it), I may build a pygame release for that. -bob From hengist.podd at virgin.net Fri Mar 11 12:21:03 2005 From: hengist.podd at virgin.net (has) Date: Fri Mar 11 12:21:08 2005 Subject: [Pythonmac-SIG] PyMac_Initialize()? Message-ID: Hi, Reading up on embedding the Python interpreter, and says to use PyMac_Initialize() instead of Py_Initialize() to initialise it on Mac; however it doesn't appear to be declared. Is this a typo in the Python docs? has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Fri Mar 11 12:43:14 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 11 12:43:19 2005 Subject: [Pythonmac-SIG] PyMac_Initialize()? In-Reply-To: References: Message-ID: <80abb33bc9411bede390bea4767104da@redivi.com> On Mar 11, 2005, at 6:21, has wrote: > Reading up on embedding the Python interpreter, and > says to use > PyMac_Initialize() instead of Py_Initialize() to initialise it on Mac; > however it doesn't appear to be declared. Is this a typo in the > Python docs? Yeah. It may have been necessary for Mac OS 9, but I'm pretty sure support for that doesn't exist in 2.4. FIle a bug. -bob From troy.rollins at gmail.com Fri Mar 11 15:04:28 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Fri Mar 11 15:04:35 2005 Subject: [Pythonmac-SIG] ANN: pygame 1.7.0 for Mac OS X 10.3 In-Reply-To: References: Message-ID: <31ac537c0503110604476958ee@mail.gmail.com> I've packaged what > should be pygame 1.7.0 for Mac OS X 10.3 users. > It is available from pythonmac.org packages at: > http://pythonmac.org/packages/ On my OSX.3.8, the installer starts with a dialog which says "The installationCheck tool was either not readable or not executable." And then it offers only to close, but will not complete running the installer. By the way, where then does one get the missing pyOpenGL? (I feel like Python could be the new Pokemon. Gotta collect all the right pieces!) -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From bob at redivi.com Fri Mar 11 19:03:11 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 11 19:03:27 2005 Subject: [Pythonmac-SIG] ANN: pygame 1.7.0 for Mac OS X 10.3 In-Reply-To: <31ac537c0503110604476958ee@mail.gmail.com> References: <31ac537c0503110604476958ee@mail.gmail.com> Message-ID: <407abe3c7789a9ac58cf6d64791ca250@redivi.com> On Mar 11, 2005, at 9:04, Troy Rollins wrote: > I've packaged what >> should be pygame 1.7.0 for Mac OS X 10.3 users. >> It is available from pythonmac.org packages at: >> http://pythonmac.org/packages/ > > On my OSX.3.8, the installer starts with a dialog which says "The > installationCheck tool was either not readable or not executable." And > then it offers only to close, but will not complete running the > installer. Works here, don't know what your problem is. > By the way, where then does one get the missing pyOpenGL? (I feel like > Python could be the new Pokemon. Gotta collect all the right pieces!) You build it yourself. -bob From kantel at mpiwg-berlin.mpg.de Fri Mar 11 19:17:30 2005 From: kantel at mpiwg-berlin.mpg.de (=?ISO-8859-1?Q?J=F6rg_Kantel?=) Date: Fri Mar 11 19:17:34 2005 Subject: [Pythonmac-SIG] ANN: pygame 1.7.0 for Mac OS X 10.3 In-Reply-To: References: Message-ID: Hi Bob, Am 11.03.2005 um 09:31 schrieb Bob Ippolito: > Although the official sdist tarball isn't cut yet, I've packaged what > should be pygame 1.7.0 for Mac OS X 10.3 users. > It is available from pythonmac.org packages at: > http://pythonmac.org/packages/ I gave it a try and it works fine. I've wrote a bit about my first impressions in my blog here and here (Sorry, in German). You've made my day. ;-) Many thanks J"org (aka Der Schockwellenreiter ) -- J"org Kantel Max-Planck-Institute for the History of Science Computer Department Wilhelmstr. 44 D-10117 Berlin fon: +4930-22667-220 fax: +4930-22667-299 From sw at wordtech-software.com Fri Mar 11 23:35:35 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Sat Mar 12 00:01:01 2005 Subject: [Pythonmac-SIG] Eric 3.6.2 Message-ID: <42321D37.1070603@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I got it to install, somehow (hosed my desktop in the process: NEVER run sudo python install.py on your desktop!!). So no need for anyone else to test it. Eric3 was the holdup on assembling a new installer of PyQt for Mac; the new PyQt does some things differently than the older version, and broke my older PyQt build of Eric. I'll get it wrapped up and uploaded to SourceForge in another week or so. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMh03JmdQs+6YVcoRArWbAJ9yo5gV1nX4cYeT0st40ghRaaTi8ACdFS4F Cb0zV307h4y6fZiCYJ/B2ao= =p5In -----END PGP SIGNATURE----- From bob at redivi.com Sat Mar 12 03:24:00 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 12 03:23:32 2005 Subject: [Pythonmac-SIG] Eric 3.6.2 In-Reply-To: <42321D37.1070603@wordtech-software.com> References: <42321D37.1070603@wordtech-software.com> Message-ID: <0c63a6fa07e747b0d9fc2f9fa3f45cc3@redivi.com> On Mar 11, 2005, at 5:35 PM, Kevin Walzer wrote: > I got it to install, somehow (hosed my desktop in the process: NEVER > run > sudo python install.py on your desktop!!). So no need for anyone else > to > test it. Really makes me trust that using Eric 3 is safe! hah :) -bob From jason at smileproject.com Sat Mar 12 14:18:36 2005 From: jason at smileproject.com (Jason Van Anden) Date: Sat Mar 12 14:18:41 2005 Subject: [Pythonmac-SIG] Trouble installing mxdatetime Message-ID: Hi, I was attempting to install mxdatetime on a mac mini - but it fails when I run setup. Repeated messages tell me it was unable to execute gcc. I unzipped the release in a temp folder and ran: sudo python setup.py install Advice appreciated. J From kid at kendermedia.com Sat Mar 12 15:18:18 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Sat Mar 12 15:18:21 2005 Subject: [Pythonmac-SIG] Trouble installing mxdatetime In-Reply-To: References: Message-ID: <4232FA2A.5030908@kendermedia.com> Sounds like you might not have Xcode/Developer Tools installed. They don't come installed by default. Kevin Jason Van Anden wrote: > Hi, > > I was attempting to install mxdatetime on a mac mini - but it fails > when I run setup. Repeated messages tell me it was unable to execute > gcc. I unzipped the release in a temp folder and ran: > > sudo python setup.py install > > Advice appreciated. > > J > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > From charles.hartman at conncoll.edu Sat Mar 12 17:30:02 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat Mar 12 17:30:09 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: <423104FA.7090707@noaa.gov> References: <4230800E.3040300@noaa.gov> <31ac537c050310140276c60f76@mail.gmail.com> <2c193b7e88207d222ac83190b6c44463@conncoll.edu> <423104FA.7090707@noaa.gov> Message-ID: "Quite reasonable" seems to mean $129. Too much for me, though I'm tempted to try it & talk myself into it. > On Mar 10, 2005, at 9:39 PM, Chris Barker wrote: > >> Have you tried wxDesigner? It's commercial, but quite reasonable. And >> I thought someone had built a wxGlade package for OS-X. (Yes, but I couldn't get it to wait to crash long enough to build a dialog box with it.) Charles Hartman From heiko_hartmann at arcor.de Sun Mar 13 01:06:55 2005 From: heiko_hartmann at arcor.de (Heiko Hartmann) Date: Sat Mar 12 21:51:44 2005 Subject: [Pythonmac-SIG] ANN: pygame 1.7.0 for Mac OS X 10.3 - Problem Message-ID: <13f4e05d75ee21ab535f18ca6f09de7c@arcor.de> Hello, I installed the pygame 1.7.0 distribution on my Mac (Mac OS X 10.3.8 with Python 2.3.5) and I get the following error when I initialize the display mode in a window (taken from the Apple Bug Report): Date/Time: 2005-03-12 16:00:34 -0800 OS Version: 10.3.8 (Build 7U16) Report Version: 2 Command: Python Path: /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ Python.app/Contents/MacOS/Python Version: 2.3 (2.3) PID: 367 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000008 Thread 0 Crashed: 0 org.python.Python.framework 0x9593d6dc PyFrame_New + 0x20 1 org.python.Python.framework 0x95987668 PyEval_EvalCodeEx + 0x88 2 org.python.Python.framework 0x9593f354 PyFunction_SetClosure + 0xd6c 3 org.python.Python.framework 0x9592a8d0 PyObject_Call + 0x30 4 org.python.Python.framework 0x959891ec PyEval_CallObjectWithKeywords + 0x100 5 _objc.so 0x00753c5c ObjC_UpdateConvenienceMethods + 0x188 (objc_util.m:343) 6 _objc.so 0x0075a98c PyObjCClass_CheckMethodList + 0xc4 (objc-class.m:490) 7 _objc.so 0x0075d140 PyObjCObject_New + 0xa4 (objc-object.m:694) 8 _objc.so 0x00754dd4 pythonify_c_value + 0x2e4 (objc_support.m:681) 9 _objc.so 0x007665a4 method_stub + 0x1c4 (libffi_support.m:390) 10 _objc.so 0x00767a24 ffi_closure_helper_DARWIN + 0x1e4 (ffi_darwin.c:700) 11 _objc.so 0x00767db4 ffi_closure_ASM + 0x74 12 com.apple.Foundation 0x909f7184 _nsnote_callback + 0xb0 13 com.apple.CoreFoundation 0x901aa5c0 __CFXNotificationPost + 0x1b4 14 com.apple.CoreFoundation 0x901aefd0 _CFXNotificationPostNotification + 0x340 15 com.apple.Foundation 0x909f4fd0 -[NSNotificationCenter postNotificationName:object:userInfo:] + 0x74 16 com.apple.AppKit 0x92e23024 -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 0x33c 17 com.apple.AppKit 0x92ecb684 -[NSWindow makeKeyAndOrderFront:] + 0xa0 18 SDL 0x30033334 QZ_SetVideoWindowed + 0x588 19 SDL 0x30031cf8 QZ_SetVideoMode + 0x4c 20 SDL 0x30025778 SDL_SetVideoMode + 0x1b0 21 display.so 0x002a611c set_mode + 0x1bc (display.c:628) 22 org.python.Python.framework 0x959894a8 PyEval_GetFuncDesc + 0x1dc 23 org.python.Python.framework 0x95986c64 PyEval_EvalCode + 0x2560 24 org.python.Python.framework 0x95987e30 PyEval_EvalCodeEx + 0x850 25 org.python.Python.framework 0x95984734 PyEval_EvalCode + 0x30 26 org.python.Python.framework 0x959a85f0 PyRun_FileExFlags + 0xe4 27 org.python.Python.framework 0x959a7668 PyRun_SimpleFileExFlags + 0x1bc 28 org.python.Python.framework 0x959b1ec0 Py_Main + 0x7cc 29 org.python.python 0x00003c78 0x1000 + 0x2c78 30 org.python.python 0x00003aec 0x1000 + 0x2aec Thread 1: 0 libSystem.B.dylib 0x9000b20c select + 0xc 1 SDL 0x30009ee8 SDL_Delay + 0x108 2 SDL 0x3000a070 RunTimer + 0x50 3 SDL 0x3002b444 SDL_RunThread + 0x48 4 SDL 0x3002d5ec RunThread + 0x10 5 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28 Thread 2: 0 libSystem.B.dylib 0x900074c8 mach_msg_trap + 0x8 1 libSystem.B.dylib 0x90007018 mach_msg + 0x38 2 com.apple.CoreFoundation 0x90191700 __CFRunLoopRun + 0x350 3 com.apple.CoreFoundation 0x90195e8c CFRunLoopRunSpecific + 0x148 4 com.apple.audio.CoreAudio 0x90732f80 HALRunLoop::OwnThread(void*) + 0x104 5 com.apple.audio.CoreAudio 0x907391e0 CAPThread::Entry(CAPThread*) + 0x30 6 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28 Thread 3: 0 libSystem.B.dylib 0x90018be8 semaphore_timedwait_signal_trap + 0x8 1 libSystem.B.dylib 0x9000e788 _pthread_cond_wait + 0x268 2 com.apple.audio.CoreAudio 0x907244fc CAGuard::WaitFor(unsigned long long) + 0xdc 3 com.apple.audio.CoreAudio 0x90724130 CAGuard::WaitUntil(unsigned long long) + 0x130 4 com.apple.audio.CoreAudio 0x90722b20 HPIOThread::WorkLoop() + 0x358 5 com.apple.audio.CoreAudio 0x9073919c HPIOThread::ThreadEntry(HPIOThread*) + 0x1c 6 com.apple.audio.CoreAudio 0x907391e0 CAPThread::Entry(CAPThread*) + 0x30 7 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28 PPC Thread State: srr0: 0x9593d6dc srr1: 0x0200f930 vrsave: 0x00000000 cr: 0x48424212 xer: 0x20000000 lr: 0x9593d6d4 ctr: 0x9593d6bc r0: 0x95987668 r1: 0xbfffea50 r2: 0x48424212 r3: 0x00000000 r4: 0x006a1960 r5: 0x006a7150 r6: 0x00000000 r7: 0x00000003 r8: 0x00000000 r9: 0x00000000 r10: 0x00000000 r11: 0xa5940ca8 r12: 0x9593d6bc r13: 0x00000000 r14: 0x00000000 r15: 0x0030c290 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x01378a80 r23: 0x00000003 r24: 0x00000000 r25: 0x006b0730 r26: 0x00000000 r27: 0x006a1960 r28: 0x01378a8c r29: 0x00000000 r30: 0x00000000 r31: 0x9593d6d4 Binary Images Description: 0x1000 - 0x4fff org.python.python 2.3 /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ Python.app/Contents/MacOS/Python 0xe3000 - 0xe4fff math.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/math.so 0xeb000 - 0xecfff _random.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/_random.so 0xf6000 - 0xf9fff strop.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/strop.so 0x227000 - 0x229fff base.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/base.so 0x238000 - 0x23afff constants.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/constants.so 0x251000 - 0x255fff rect.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/rect.so 0x26b000 - 0x26cfff rwobject.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/rwobject.so 0x273000 - 0x273fff surflock.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/surflock.so 0x289000 - 0x28bfff cdrom.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/cdrom.so 0x2a4000 - 0x2a7fff display.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/display.so 0x2ca000 - 0x2cffff surface.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/surface.so 0x405000 - 0x40efff draw.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/draw.so 0x42f000 - 0x432fff event.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/event.so 0x44c000 - 0x44ffff image.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/image.so 0x45f000 - 0x45ffff imageext.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/imageext.so 0x46e000 - 0x46ffff joystick.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/joystick.so 0x477000 - 0x477fff key.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/key.so 0x483000 - 0x484fff mouse.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/mouse.so 0x493000 - 0x494fff time.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/time.so 0x4ad000 - 0x4b1fff transform.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/transform.so 0x4ca000 - 0x4ccfff font.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/font.so 0x4e8000 - 0x4ebfff mixer.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/mixer.so 0x504000 - 0x505fff mixer_music.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/mixer_music.so 0x518000 - 0x519fff movie.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/movie.so 0x52f000 - 0x532fff surfarray.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/surfarray.so 0x57a000 - 0x58cfff _numpy.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/Numeric/_numpy.so 0x5cb000 - 0x5d0fff multiarray.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/Numeric/multiarray.so 0x616000 - 0x622fff umath.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/Numeric/umath.so 0x654000 - 0x657fff struct.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/struct.so 0x65f000 - 0x661fff binascii.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/binascii.so 0x668000 - 0x669fff cStringIO.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/cStringIO.so 0x675000 - 0x677fff _dotblas.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/Numeric/_dotblas.so 0x683000 - 0x683fff sndarray.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/sndarray.so 0x752000 - 0x76bfff _objc.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/PyObjC/objc/_objc.so 0x1008000 - 0x1011fff _FoundationMapping.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/PyObjC/objc/_FoundationMapping.so 0x1058000 - 0x1066fff _Foundation.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/PyObjC/Foundation/_Foundation.so 0x117e000 - 0x117ffff MacOS.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/MacOS.so 0x1185000 - 0x1185fff autoGIL.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/autoGIL.so 0x1338000 - 0x1349fff _AppKit.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/PyObjC/AppKit/_AppKit.so 0x13c1000 - 0x13c7fff _AppKitMapping.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/PyObjC/AppKit/_AppKitMapping.so 0x1526000 - 0x1529fff libMPAEncode0.1.dylib /Library/Application Support/DivXNetworks/libMPAEncode0.1.dylib 0x152d000 - 0x152efff com.apple.aoa.halplugin 2.5.0 /System/Library/Extensions/IOAudioFamily.kext/Contents/PlugIns/ AOAHALPlugin.bundle/Contents/MacOS/AOAHALPlugin 0x5294000 - 0x530afff ch.rafz.naegeli.christoph.xvid_codec 0.4.1 /Library/QuickTime/XviD_Codec v0.4.1.component/Contents/MacOS/XviD_Codec 0x5495000 - 0x555ffff com.divxnetworks.DivXCodec 5.2.1 /Library/QuickTime/DivX 5.component/Contents/MacOS/DivX 5 0x55e8000 - 0x5619fff liblame3.92.dylib /Library/Application Support/DivXNetworks/liblame3.92.dylib 0x5656000 - 0x5668fff libdpv10.dylib /Library/Application Support/DivXNetworks/libdpv10.dylib 0x56e1000 - 0x5741fff libdpus10.dylib /Library/Application Support/DivXNetworks/libdpus10.dylib 0x582e000 - 0x58d1fff com.apple.audio.units.Components 1.3.2 /System/Library/Components/CoreAudio.component/Contents/MacOS/ CoreAudio 0x58ef000 - 0x592bfff com.apple.iSightAudio 6.5.2 /Library/Audio/Plug-Ins/HAL/iSightAudio.plugin/Contents/MacOS/ iSightAudio 0x30000000 - 0x3004ffff SDL 1.2.8 /Library/Frameworks/SDL.framework/Versions/A/SDL 0x30f00000 - 0x30f64fff ??? ??? (0.0.1d1) /Library/Frameworks/smpeg.framework/Versions/A/smpeg 0x31000000 - 0x31078fff SDL_image 1.2.3 /Library/Frameworks/SDL_image.framework/Versions/A/SDL_image 0x32000000 - 0x32058fff SDL_mixer 1.2.5 /Library/Frameworks/SDL_mixer.framework/Versions/A/SDL_mixer 0x34000000 - 0x3402bfff SDL_ttf 2.0.6 /Library/Frameworks/SDL_ttf.framework/Versions/A/SDL_ttf 0x84610000 - 0x84619fff libz.1.1.3.dylib /usr/lib/libz.1.1.3.dylib 0x84630000 - 0x8465dfff libssl.0.9.dylib /usr/lib/libssl.0.9.dylib 0x8736f000 - 0x87a37fff com.apple.QuickTimeComponents.component 6.5.2 /System/Library/QuickTime/QuickTimeComponents.component/Contents/ MacOS/QuickTimeComponents 0x88d40000 - 0x88d4cfff com.apple.agl 2.5 (AGL-2.5) /System/Library/Frameworks/AGL.framework/Versions/A/AGL 0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld 0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90190000 - 0x9023dfff com.apple.CoreFoundation 6.3.6 (299.33) /System/Library/Frameworks/CoreFoundation.framework/Versions/ A/CoreFoundation 0x90280000 - 0x904f9fff com.apple.CoreServices.CarbonCore 10.3.6 (10.3.5) /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x90570000 - 0x905dffff com.apple.framework.IOKit 1.3.6 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x90610000 - 0x9069afff com.apple.CoreServices.OSServices 3.0.1 /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/OSServices.framework/Versions/A/OSServices 0x90700000 - 0x90700fff com.apple.CoreServices 10.3 (???) /System/Library/Frameworks/CoreServices.framework/Versions/A/ CoreServices 0x90720000 - 0x90787fff com.apple.audio.CoreAudio 2.1.2 /System/Library/Frameworks/CoreAudio.framework/Versions/A/ CoreAudio 0x907c7000 - 0x907d2fff libCSync.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x907f0000 - 0x907f9fff com.apple.DiskArbitration 2.0.4 /System/Library/PrivateFrameworks/DiskArbitration.framework/ Versions/A/DiskArbitration 0x90810000 - 0x90810fff com.apple.ApplicationServices 1.0 (???) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/ApplicationServices 0x90830000 - 0x9089ffff libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x908c5000 - 0x908d5fff com.apple.vecLib 3.0.3 (vecLib 3.0.3) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x90910000 - 0x90983fff com.apple.DesktopServices 1.2.2 /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/ Versions/A/DesktopServicesPriv 0x909f0000 - 0x90b4bfff com.apple.Foundation 6.3.5 (500.56) /System/Library/Frameworks/Foundation.framework/Versions/C/ Foundation 0x90c30000 - 0x90c4afff libGL.dylib /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib 0x90c60000 - 0x90cc2fff libGLU.dylib /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGLU.dylib 0x90d20000 - 0x90d3bfff com.apple.SystemConfiguration 1.7.1 (???) /System/Library/Frameworks/SystemConfiguration.framework/ Versions/A/SystemConfiguration 0x90d60000 - 0x90d6bfff com.apple.opengl 1.3.8 /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x90ec0000 - 0x90ec0fff com.apple.Cocoa 6.3 (???) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 0x910b0000 - 0x91101fff com.apple.bom 1.2.5 (63.2) /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom 0x912a0000 - 0x912bdfff com.apple.audio.SoundManager 3.8 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ CarbonSound.framework/Versions/A/CarbonSound 0x91320000 - 0x913dffff ColorSync /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ColorSync.framework/Versions/A/ColorSync 0x914a0000 - 0x914b3fff com.apple.speech.synthesis.framework 3.2 /System/Library/Frameworks/ApplicationServices.framework/Versions/ A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x914e0000 - 0x91549fff com.apple.htmlrendering 1.1.2 /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering 0x915a0000 - 0x91659fff com.apple.QD 3.4.65 (???) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/QD.framework/Versions/A/QD 0x916b0000 - 0x916e8fff com.apple.AE 1.4 /System/Library/Frameworks/ApplicationServices.framework/Versions/ A/Frameworks/AE.framework/Versions/A/AE 0x91720000 - 0x917b3fff com.apple.print.framework.PrintCore 3.3 /System/Library/Frameworks/ApplicationServices.framework/Versions/ A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x917f6000 - 0x9180dfff com.apple.LangAnalysis 1.5.4 /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x91820000 - 0x91830fff com.apple.speech.recognition.framework 3.3 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ SpeechRecognition.framework/Versions/A/SpeechRecognition 0x91850000 - 0x9186afff com.apple.openscripting 1.2.1 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x91890000 - 0x918a0fff com.apple.ImageCapture 2.1.5 /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x918d0000 - 0x918dcfff com.apple.help 1.0.1 /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/Help.framework/Versions/A/Help 0x91900000 - 0x9190dfff com.apple.CommonPanels 1.2.1 (1.0) /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x91930000 - 0x9197efff com.apple.print.framework.Print 3.3 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ Print.framework/Versions/A/Print 0x919a7000 - 0x919c1fff libresolv.9.dylib /usr/lib/libresolv.9.dylib 0x919d0000 - 0x919dbfff com.apple.securityhi 1.2 (90) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ SecurityHI.framework/Versions/A/SecurityHI 0x91a00000 - 0x91a73fff com.apple.NavigationServices 3.3.2 /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/NavigationServices.framework/Versions/A/NavigationServices 0x91af0000 - 0x91b04fff libCGATS.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib 0x91b10000 - 0x91b2afff libPDFRIP.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/Resources/ libPDFRIP.A.dylib 0x91b50000 - 0x91b5ffff libPSRIP.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/Resources/libPSRIP.A.dylib 0x91bc0000 - 0x91bd3fff libRIP.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x920f0000 - 0x92116fff com.apple.FindByContent 1.4 (1.2) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/FindByContent.framework/Versions/A/FindByContent 0x92140000 - 0x92327fff com.apple.security 2.4 (177) /System/Library/Frameworks/Security.framework/Versions/A/Security 0x924b0000 - 0x924e8fff com.apple.LaunchServices 10.3.5 (98.4) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/LaunchServices.framework/Versions/A/ LaunchServices 0x926d0000 - 0x92773fff libcrypto.0.9.dylib /usr/lib/libcrypto.0.9.dylib 0x927d0000 - 0x92b54fff com.apple.HIToolbox 1.3.5 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x92cca000 - 0x92d1afff com.apple.HIServices 1.4.1 (0.0.1d1) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x92dc0000 - 0x932bffff com.apple.AppKit 6.3.6 (743.33) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x935d0000 - 0x938a8fff com.apple.CoreGraphics 1.203.30 (???) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x9398f000 - 0x939fcfff libvDSP.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ vecLib.framework/Versions/A/libvDSP.dylib 0x93a20000 - 0x93a34fff libcups.2.dylib /usr/lib/libcups.2.dylib 0x93a50000 - 0x93a54fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x93bbc000 - 0x93c5ffff com.apple.audio.toolbox.AudioToolbox 1.3.2 /System/Library/Frameworks/AudioToolbox.framework/Versions/A/ AudioToolbox 0x940f0000 - 0x94108fff com.apple.WebServices 1.1.1 (1.1.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore 0x941ed000 - 0x941edfff com.apple.audio.units.AudioUnit 1.3.2 /System/Library/Frameworks/AudioUnit.framework/Versions/A/ AudioUnit 0x9422b000 - 0x942f0fff libxml2.2.dylib /usr/lib/libxml2.2.dylib 0x94640000 - 0x94649fff libz.1.dylib /usr/lib/libz.1.dylib 0x946e0000 - 0x9473ffff com.apple.SearchKit 1.0.2 /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/SearchKit.framework/Versions/A/SearchKit 0x948c0000 - 0x9494dfff com.apple.ink.framework 101.1.3 (55.10) /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/Ink.framework/Versions/A/Ink 0x94d39000 - 0x94d70fff com.apple.CFNetwork 1.2.1 (7) /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x94ea0000 - 0x954a6fff libBLAS.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ vecLib.framework/Versions/A/libBLAS.dylib 0x95500000 - 0x957d0fff libLAPACK.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ vecLib.framework/Versions/A/libLAPACK.dylib 0x958e0000 - 0x95900fff libvMisc.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ vecLib.framework/Versions/A/libvMisc.dylib 0x95920000 - 0x959e8fff org.python.Python.framework 2.2 /System/Library/Frameworks/Python.framework/Versions/2.3/Python 0x95b50000 - 0x95c32fff libicucore.A.dylib /usr/lib/libicucore.A.dylib 0x95ca0000 - 0x95d62fff libcrypto.0.9.7.dylib /usr/lib/libcrypto.0.9.7.dylib 0x95dc0000 - 0x95deefff libssl.0.9.7.dylib /usr/lib/libssl.0.9.7.dylib 0x95f30000 - 0x9601efff libiconv.2.dylib /usr/lib/libiconv.2.dylib 0x96bf0000 - 0x96c7ffff ATS /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ATS.framework/Versions/A/ATS 0x970f0000 - 0x970f8fff libbsm.dylib /usr/lib/libbsm.dylib 0x974da000 - 0x9766ffff com.apple.QuickTime 6.5.2 /System/Library/Frameworks/QuickTime.framework/Versions/A/ QuickTime 0x9770c000 - 0x9770cfff com.apple.Carbon 10.3 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0xefbef000 - 0xefcd1fff libPSIKey.dylib /Library/Application Support/DivXNetworks/libPSIKey.dylib This code did work with the pygame 1.6 distribution. When initialize the display mode in fullscreen everything works fine. Here are the calls I'm using: pygame.init() # Initialize the display mode surface = pygame.display.set_mode((800,600),0,16) #surface = pygame.display.set_mode((800,600),FULLSCREEN,16) Any ideas? Ciao, Heiko. Heiko Hartmann An der Betteleiche 18 70569 Stuttgart From troy.rollins at gmail.com Sat Mar 12 22:40:57 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Sat Mar 12 22:41:00 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: <3aeb0b30b59438243aeecd271c987371@conncoll.edu> References: <4230800E.3040300@noaa.gov> <31ac537c050310140276c60f76@mail.gmail.com> <2c193b7e88207d222ac83190b6c44463@conncoll.edu> <423104FA.7090707@noaa.gov> <4230DB11.9@noaa.gov> <3aeb0b30b59438243aeecd271c987371@conncoll.edu> Message-ID: <31ac537c0503121340621e6b3b@mail.gmail.com> > >> I > >> thought someone had built a wxGlade package for OS-X. > > wxDesigner is available, and the cost of its being commercial is not an issue. Its pretty limited functionality is more the issue. It does not seem capable of building complex windows, more aimed at dialog boxes, and even then the controls are not particularly... graceful. wxGlade is obviously available, and a few others, but they all are buggy, with interface glitches, and crashing being pretty common. That sort of tool does not make one more productive, nor does it have much of an educational benefit for new developers. In my tour of the available tools on OSX for developers wanting an IDE, I've found that only WingIDE is stable and fully featured, though it runs only in X11. There is no interface builder for X-Plat development on OSX which is ready for prime-time that I have seen. This leads me to believe that for general users, wanting to move to Python from other high-level scripting languages which DO include an IDE (Flash, Director, Revolution, RealBasic), OSX is NOT the platform to do it on. The tools landscape is much less refined, and the options far fewer, and a whole lot more buggy. Both Windows and Linux have many better options for designing GUIs, as well as scripting and debugging. My recommendation for developers who want to make the switch to Python, but need to be productive relatively quickly... stay away from OSX. Which is extremely difficult for me to say, since over the last few years I have converted my entire company to OSX. Time to make room for some Linux boxes, as Linux has commercial tools available. I think many of us want open-source, but commercial tool kits, with commercial refinements and support. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From brendansimons at yahoo.ca Sat Mar 12 23:55:17 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Sat Mar 12 23:55:25 2005 Subject: [Pythonmac-SIG] Matplotlib warning means what? In-Reply-To: <20050312205147.0220F1E400A@bag.python.org> References: <20050312205147.0220F1E400A@bag.python.org> Message-ID: I've been tooling around with matplotlib, as graciously packaged by Chris Barker, and hosted on Bob Ippolito's pythonmac.org/packages site. Everything seems to be working smoothly, but I've run into a couple of warnings I can't decrypt. 1) Executing the following code, #! /usr/bin/pythonw import pylab pylab.plot([1, 2, 3], [4, 5, 6]) pylab.show() displays a chart as expected (the toolbar icons are a little mucked, but that's minor). However, dismissing the chart window brings up this warning: 2005-03-12 17:26:52.075 Python[569] *** _NSAutoreleaseNoPool(): Object 0x66402d0 of class NSCFString autoreleased with no pool in place - just leaking *** malloc[569]: Deallocation of a pointer not malloced: 0x66c73d0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug Is this a bug with matplotlib, with my installation of matplotlib, or with my script? Can I ignore it, and if not, what can I do to address it? 2) a smaller issue: I tried to change matplotlib's array class by opening /system/library/frameworks/python.framework/version/2.3/share/ .matplotlibrc and changing "numerix : numeric" to "numerix: numarray" but I got the following error: The import of the numarray version of the _contour module, _na_contour, failed. This is is either because numarray was unavailable when matplotlib was compiled, because a dependency of _na_contour could not be satisfied, or because the build flag for this module was turned off in setup.py. If it appears that _na_contour was not built, make sure you have a working copy of numarray and then re-install matplotlib. Otherwise, the following traceback gives more details: File "/platlib/matplotlib/_contour.py", line 5, in ? ImportError: No module named _na_contour I know I had numarray installed before unpackaging matplotlib. Chris' notes say that he had numeric installed when he packaged matplotlib, but makes no mention of numarray. Perhaps the matplotlib.mpkg needs to be rebuilt on a machine that has numarray installed? It isn't a big deal, as the two types are -mostly- interchangeable, but it would be nice to have the choice. -Brendan ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From bob at redivi.com Sun Mar 13 00:06:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Mar 13 00:06:32 2005 Subject: [Pythonmac-SIG] Matplotlib warning means what? In-Reply-To: References: <20050312205147.0220F1E400A@bag.python.org> Message-ID: On Mar 12, 2005, at 17:55, Brendan Simons wrote: > I've been tooling around with matplotlib, as graciously packaged by > Chris Barker, and hosted on Bob Ippolito's pythonmac.org/packages > site. Everything seems to be working smoothly, but I've run into a > couple of warnings I can't decrypt. > > 1) Executing the following code, > #! /usr/bin/pythonw > import pylab > pylab.plot([1, 2, 3], [4, 5, 6]) > pylab.show() > > displays a chart as expected (the toolbar icons are a little mucked, > but that's minor). However, dismissing the chart window brings up > this warning: > > 2005-03-12 17:26:52.075 Python[569] *** _NSAutoreleaseNoPool(): Object > 0x66402d0 of class NSCFString autoreleased with no pool in place - > just leaking > *** malloc[569]: Deallocation of a pointer not malloced: 0x66c73d0; > This could be a double free(), or free() called with the middle of an > allocated block; Try setting environment variable MallocHelp to see > tools to help debug > > Is this a bug with matplotlib, with my installation of matplotlib, or > with my script? Can I ignore it, and if not, what can I do to address > it? This is a bug in matplotlib or something matplotlib depends on. It's using Foundation without setting up the proper NSAutoreleasePool context. If you have PyObjC, you could just throw an import objc at the top and it would get rid of the warning, but it would still be leaking memory because the context never gets popped. -bob From bob at redivi.com Sun Mar 13 00:08:52 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Mar 13 00:08:58 2005 Subject: [Pythonmac-SIG] ANN: pygame 1.7.0 for Mac OS X 10.3 - Problem In-Reply-To: <13f4e05d75ee21ab535f18ca6f09de7c@arcor.de> References: <13f4e05d75ee21ab535f18ca6f09de7c@arcor.de> Message-ID: <45285380dff51b58856fbcf2ebee5de6@redivi.com> On Mar 12, 2005, at 19:06, Heiko Hartmann wrote: > I installed the pygame 1.7.0 distribution on my Mac (Mac OS X 10.3.8 > with Python 2.3.5) and I get the following error when I initialize the > display mode in a window (taken from the Apple Bug Report): ... > This code did work with the pygame 1.6 distribution. > When initialize the display mode in fullscreen everything works fine. > Here are the calls I'm using: > > pygame.init() > > # Initialize the display mode > surface = pygame.display.set_mode((800,600),0,16) > #surface = pygame.display.set_mode((800,600),FULLSCREEN,16) I hope that you haven't replaced your /System Python with 2.3.5, because that would break more than just pygame. Are you sure that you have PyObjC 1.2? I can't reproduce this. -bob From jason at smileproject.com Sun Mar 13 14:58:37 2005 From: jason at smileproject.com (Jason Van Anden) Date: Sun Mar 13 14:58:47 2005 Subject: [Pythonmac-SIG] Trouble installing mxdatetime In-Reply-To: <4232FA2A.5030908@kendermedia.com> References: <4232FA2A.5030908@kendermedia.com> Message-ID: <108dfc5d6a784c90ef181bc2a6d749aa@smileproject.com> Thanks - that was it - everything works. I must say - installation has gotten a lot smoother since the last time I dealt with this. For the record, I am installing five mac minis with this stuff to run a video game art installation using python and java (could be me, but I doubt it). You can find version 1.0 of the game here: http://www.smileproject.com/farklempt/v/1 - version 2.0 is way cooler and uses touch screens - more detail at my website after its release on March 24th. Thanks to everyone - especially Bob Ippolito for this recent super helpful post: http://bob.pythonmac.org/archives/category/python/pygame/ Jason Van Anden On Mar 12, 2005, at 9:18 AM, Kevin Dangoor wrote: > Sounds like you might not have Xcode/Developer Tools installed. They > don't come installed by default. > > Kevin > > Jason Van Anden wrote: > >> Hi, >> >> I was attempting to install mxdatetime on a mac mini - but it fails >> when I run setup. Repeated messages tell me it was unable to execute >> gcc. I unzipped the release in a temp folder and ran: >> >> sudo python setup.py install >> >> Advice appreciated. >> >> J >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> >> > > From sw at wordtech-software.com Sun Mar 13 16:36:43 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Sun Mar 13 16:36:48 2005 Subject: [Pythonmac-SIG] GUI tools--for Troy In-Reply-To: <20050313110009.257BC1E400F@bag.python.org> References: <20050313110009.257BC1E400F@bag.python.org> Message-ID: <42345E0B.1040603@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Troy, I read your note about switching to Linux with interest. I was curious about a couple of things: 1. What xplat GUI building tools and IDE are available on Linux that are *not* available on OS X? I realize WingIDE may satisfy the IDE part of this, but what about the GUI part? The free/open-source tools that I package are also the main ones that are available on Linux. They may run more smoothly there, but they're pretty much the same. 2. Did you look at PyQt at all? I have trouble believing that Qt, and especially Qt Designer, would *not* satisfy your criteria for commercial-quality tools. Of course, Qt isn't cheap for commercial development, and perhaps that's an issue, but I think it should satisfy your critiera for high-quality, well-supported tools. Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCNF4LJmdQs+6YVcoRAm0RAJ0b/YNRyhxkqnIAyfayc4xukxrHlwCdHTSE b4FQNWNHDudToU7fG7RHkdI= =oyhm -----END PGP SIGNATURE----- From troy.rollins at gmail.com Sun Mar 13 20:35:37 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Sun Mar 13 20:35:40 2005 Subject: [Pythonmac-SIG] GUI tools--for Troy In-Reply-To: <42345E0B.1040603@wordtech-software.com> References: <20050313110009.257BC1E400F@bag.python.org> <42345E0B.1040603@wordtech-software.com> Message-ID: <31ac537c0503131135ab4b52@mail.gmail.com> > I read your note about switching to Linux with interest. I was curious > about a couple of things: > Thanks for the interest Kevin. > 1. What xplat GUI building tools and IDE are available on Linux that are > *not* available on OS X? I realize WingIDE may satisfy the IDE part of > this, but what about the GUI part? The free/open-source tools that I > package are also the main ones that are available on Linux. They may run > more smoothly there, but they're pretty much the same. ActiveState Komodo would be the key one. Commercial quality, reasonably priced, high-levels of support and learning resources. A GUI builder which is optional and based on TKinter. Coming from a background of using high quality, productive and efficient IDEs, Komodo makes the switch to Python very appealing. Boa Constructor looks like a decent option as well. Certainly better than anything available on Mac, but it doesn't hold a candle to Komodo. > > 2. Did you look at PyQt at all? I have trouble believing that Qt, and > especially Qt Designer, would *not* satisfy your criteria for > commercial-quality tools. Of course, Qt isn't cheap for commercial > development, and perhaps that's an issue, but I think it should satisfy > your critiera for high-quality, well-supported tools. That's true, but like everything else related to Python on OSX, it looks like a clumsy assembly process involving several separate programs and licenses, and is more difficult to maintain, in addition to being fairly (though not prohibitively) expensive. Not to mention the fact that QT carries with it a ton of baggage which is not required for Python development, and Black Adder (while attractive and appealing) is not available for OSX (but it is for Linux and Windows) nor can it build for OSX. OSX also carries the burden of having an Apple supplied version of Python in a non-standard location, the general inability to stay current and up-to-date, far fewer installable binaries, poorly maintained package libraries, less documentation on Mac specific issues, and little-to-no support avenues. For an approachable high-level language, MacPython manages to be a big PITA in comparison to both the other primary platforms. Linux looks FAR more appealing for Python work to me, as the tools are more refined, and the resources more available. I don't have the time or inclination to "hobby together" a working Python development kit, especially not while learning the language and applying that new knowledge to the needs of my projects. The amount of research required alone is a huge time sink, leading to too many dead-ends, and unmaintained repositories. I've taken to considering Python on Mac a "dot-seven" tool. In other words, the closest anything comes to actual release is a 0.7 alpha, where it stays eternally. I know, I know, welcome to open source. That's fair. In the past, I've snubbed any tool which did not allow me to work in OSX, but Python is important to my plans... enough so that I'll switch my development OS to have a decent, high-quality toolkit and IDE, preferably a commercial one, with help files, support, and yes, a GUI builder for those times when a native interface is required. If I've missed an OSX solution which is even a shadow of something like Komodo, I'd love to see it. Thanks again for listening in, offering suggestions, etc. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From sw at wordtech-software.com Sun Mar 13 21:40:59 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Sun Mar 13 21:41:03 2005 Subject: [Pythonmac-SIG] Re: GUI tools--for Troy Message-ID: <4234A55B.4030300@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Troy, Your comments are very insightful. Just a few observations: |ActiveState Komodo would be the key one. Commercial quality, |reasonably priced, high-levels of support and learning resources. A |GUI builder which is optional and based on TKinter. |Coming from a background of using high quality, productive and |efficient IDEs, Komodo makes the switch to Python very appealing. |Boa Constructor looks like a decent option as well. Certainly better |than anything available on Mac, but it doesn't hold a candle to |Komodo. I agree with you about Komodo. I wish it were available on OS X. The Mac is a big void for ActiveState. There have been periodic requests for a Mac port, but apparently they are concerned about a) the commercial viability of such an effort and b) some considerable technical hurdles surrounding their text component (Scintilla) which has not been fully ported to the Mac. Boa Contructor is not usable except with an obsolete version of wxPython (2.4.x), it has not been updated in two years, and so I have never been able to give it a real try. |That's true, but like everything else related to Python on OSX, it |looks like a clumsy assembly process involving several separate |programs and licenses, and is more difficult to maintain, in addition |to being fairly (though not prohibitively) expensive. Not to mention |the fact that QT carries with it a ton of baggage which is not |required for Python development, and Black Adder (while attractive and |appealing) is not available for OSX (but it is for Linux and Windows) |nor can it build for OSX. I maintain a binary installer of PyQt for the Mac, and I'm about to update it to the latest version of everything. However, it's GPL'ed, and would not be a viable tool for commercial development. Does TrollTech provide binary installers for commercial users? |In the past, I've snubbed any tool which did not allow me to work in |OSX, but Python is important to my plans... enough so that I'll switch |my development OS to have a decent, high-quality toolkit and IDE, |preferably a commercial one, with help files, support, and yes, a GUI |builder for those times when a native interface is required. One thing to keep in mind with Komodo is that while it has a GUI builder, I believe it only supports Tk/Tkinter. That's not surprising, given that ActiveState's bread and butter is Tcl. I myself like Tk, but I also develop in Tcl: I'm learning Python as a way into the more comprehensive GUI toolkits that it supports. (To me Tkinter just looks like a weird mangling of Tk code, and doesn't interest me.) In other words, if you want a commercial GUI builder for something other than Tk, you're back to wxDesigner or Black Adder/Qt. Or, coding the stuff by hand in Komodo. But if you're moving to Linux, Black Adder might be a good route. (Assuming theKompany doesn't go belly up in the interim...) Anyway, thanks for the discussion. I found it very intriguing. Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCNKVbJmdQs+6YVcoRAnWOAJ91qHV9qeR+ReYB4Jz30nKaFJ85ywCcD4sY cET36mlmWfcRseUWXuyZ+8A= =grfT -----END PGP SIGNATURE----- From keithn at 2xtreme.net Sun Mar 13 22:11:59 2005 From: keithn at 2xtreme.net (Keith Nemitz) Date: Sun Mar 13 22:13:01 2005 Subject: [Pythonmac-SIG] Re: [pygame] ANN: pygame 1.7.0 for Mac OS X 10.3 In-Reply-To: References: Message-ID: <89783E34-9404-11D9-963B-000393DB52E4@2xtreme.net> Bob, Got a bug for you. How do I access your bug reporting system? Briefly, I have art with black skip-color, and I use the alpha blending feature of pygame to fade the art in. Before 1.7 the art faded in beautifully. Now the art fades in without skipping color until the alpha reaches 255. So I get lots of black around the characters as they fade in. Also, I'm having trouble playing sound effects, but that seems to be an issue with py2app. Music (streamed sound) plays fine, but preloaded sound hangs the system while it plays and is silent. Music and SFX are all ogg. Worked fine with bundleBuilder. Maybe I'm using the wrong recipe with py2app, or I need to explicitly load a framework. hope you can help, Keith Nemitz Mousechief Co. On Mar 11, 2005, at 12:31 AM, Bob Ippolito wrote: > Although the official sdist tarball isn't cut yet, I've packaged what > should be pygame 1.7.0 for Mac OS X 10.3 users. > It is available from pythonmac.org packages at: > http://pythonmac.org/packages/ > > This installer ships with: > > pygame: > Installed to /Library/Python2.3/ > > pygame headers: > Installed to > /System/Library/Frameworks/Python.framework/Versions/2.3/include/ > python2.3/ > > pygame examples and documentation: > Installed to /Developer/Python/pygame/ > > SDL with my AltiVec patches, SDL_mixer, SDL_ttf, SDL_image, smpeg: > Installed to /Library/Frameworks/ > > To use pygame, you will need PyObjC 1.2 or later, and you will > probably want Numeric and PyOpenGL installed. A PyOpenGL installer is > not available from pythonmac.org packages at this time, but everything > else listed is. > > The following improvements are especially relevant to Mac OS X: > > - Calls into nasty private Apple API to grab GUI access if it doesn't > already have it (read: no pythonw required) > - Can now read the default font and icon out of any "get_data" > compliant loader (read: py2app 0.1.8 can put pygame entirely in the > site-packages.zip, and it works!). > - Includes newer versions of all dependencies (it sure has been a long > time since 1.6.0!) > - Most surface operations should be significantly faster on G4 and G5 > computers due to my AltiVec patches to SDL > > As it has been quite a long time since the last release, there are > pages full of bug fixes and feature enhancements. When the pygame.org > site updates for the 1.7 release, check WhatsNew. > > Note that I will not be making a Mac OS X 10.2 compatible release for > Python 2.3. When Python 2.4.1 is out (and probably not until there is > an official distribution of it), I may build a pygame release for > that. > > -bob > From bob at redivi.com Mon Mar 14 01:27:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 14 01:27:54 2005 Subject: [Pythonmac-SIG] Re: [pygame] ANN: pygame 1.7.0 for Mac OS X 10.3 In-Reply-To: <89783E34-9404-11D9-963B-000393DB52E4@2xtreme.net> References: <89783E34-9404-11D9-963B-000393DB52E4@2xtreme.net> Message-ID: <00119a84b91f0386a6914eae4c3d485f@redivi.com> Bug reporting system is email :) Send me some minimal example code that demonstrates this problem and I'll look at it. -bob On Mar 13, 2005, at 16:11, Keith Nemitz wrote: > Bob, > > Got a bug for you. How do I access your bug reporting system? > > Briefly, I have art with black skip-color, and I use the alpha > blending feature of pygame to fade the art in. Before 1.7 the art > faded in beautifully. Now the art fades in without skipping color > until the alpha reaches 255. So I get lots of black around the > characters as they fade in. > > Also, I'm having trouble playing sound effects, but that seems to be > an issue with py2app. Music (streamed sound) plays fine, but preloaded > sound hangs the system while it plays and is silent. Music and SFX are > all ogg. Worked fine with bundleBuilder. Maybe I'm using the wrong > recipe with py2app, or I need to explicitly load a framework. > > hope you can help, > Keith Nemitz > Mousechief Co. > > > > On Mar 11, 2005, at 12:31 AM, Bob Ippolito wrote: > >> Although the official sdist tarball isn't cut yet, I've packaged what >> should be pygame 1.7.0 for Mac OS X 10.3 users. >> It is available from pythonmac.org packages at: >> http://pythonmac.org/packages/ >> >> This installer ships with: >> >> pygame: >> Installed to /Library/Python2.3/ >> >> pygame headers: >> Installed to >> /System/Library/Frameworks/Python.framework/Versions/2.3/include/ >> python2.3/ >> >> pygame examples and documentation: >> Installed to /Developer/Python/pygame/ >> >> SDL with my AltiVec patches, SDL_mixer, SDL_ttf, SDL_image, smpeg: >> Installed to /Library/Frameworks/ >> >> To use pygame, you will need PyObjC 1.2 or later, and you will >> probably want Numeric and PyOpenGL installed. A PyOpenGL installer >> is not available from pythonmac.org packages at this time, but >> everything else listed is. >> >> The following improvements are especially relevant to Mac OS X: >> >> - Calls into nasty private Apple API to grab GUI access if it doesn't >> already have it (read: no pythonw required) >> - Can now read the default font and icon out of any "get_data" >> compliant loader (read: py2app 0.1.8 can put pygame entirely in the >> site-packages.zip, and it works!). >> - Includes newer versions of all dependencies (it sure has been a >> long time since 1.6.0!) >> - Most surface operations should be significantly faster on G4 and G5 >> computers due to my AltiVec patches to SDL >> >> As it has been quite a long time since the last release, there are >> pages full of bug fixes and feature enhancements. When the >> pygame.org site updates for the 1.7 release, check WhatsNew. >> >> Note that I will not be making a Mac OS X 10.2 compatible release for >> Python 2.3. When Python 2.4.1 is out (and probably not until there >> is an official distribution of it), I may build a pygame release for >> that. >> >> -bob >> > From troy.rollins at gmail.com Mon Mar 14 02:48:01 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Mon Mar 14 02:48:06 2005 Subject: [Pythonmac-SIG] Re: GUI tools--for Troy In-Reply-To: <4234A55B.4030300@wordtech-software.com> References: <4234A55B.4030300@wordtech-software.com> Message-ID: <31ac537c05031317487239aec8@mail.gmail.com> Kevin said : > I agree with you about Komodo. I wish it were available on OS X. The Mac > is a big void for ActiveState. There have been periodic requests for a > Mac port, but apparently they are concerned about a) the commercial > viability of such an effort and b) some considerable technical hurdles > surrounding their text component (Scintilla) which has not been fully > ported to the Mac. Komodo moving to Mac would be an extremely welcomed thing. Black adder as well. Either one was available, I probably wouldn't have had anything to say - I'd just be working. > > Boa Contructor is not usable except with an obsolete version of wxPython > (2.4.x), it has not been updated in two years, and so I have never been > able to give it a real try. Yes. Conceptually it looks pretty good, though I would imagine it to be pretty buggy. In fact, everything I have seen relating to tools for Python on the Mac are pretty buggy and incomplete. > > > One thing to keep in mind with Komodo is that while it has a GUI > builder, I believe it only supports Tk/Tkinter. That's not surprising, > given that ActiveState's bread and butter is Tcl. I myself like Tk, but > I also develop in Tcl: I'm learning Python as a way into the more > comprehensive GUI toolkits that it supports. (To me Tkinter just looks > like a weird mangling of Tk code, and doesn't interest me.) I like a GUI builder primarily for simple apps, and prototyping. Coming from the Director world, I'm also quite well-versed in building every individual GUI component myself from bitmaps and vectors. Coding the GUI doesn't scare me, I just don't want that to be the ONLY way to get a GUI with a couple of buttons and a text field, for instance. > > In other words, if you want a commercial GUI builder for something other > than Tk, you're back to wxDesigner or Black Adder/Qt. Or, coding the > stuff by hand in Komodo. But if you're moving to Linux, Black Adder > might be a good route. (Assuming theKompany doesn't go belly up in the > interim...) Black adder would be a great route. But it can't build for OSX. Am I wrong in thinking that the Tk GUIs created with Komodo on Linux shold be buildable for OSX delivery? Even still, I'll likely use hand-coded wx more often anyway... > -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From Henning.Ramm at mediapro-gmbh.de Mon Mar 14 10:28:48 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Mon Mar 14 10:28:51 2005 Subject: [Pythonmac-SIG] GUI design tools Message-ID: >Based on the statement above it looks as if wxWindows is the more >mature and stable GUI toolkit for cross-platform on OSX. Is it worth >learning WX? or will PyQt catch up? or does anyone even know the >answer to that? I guess you can use PyQt on OSX, I never tried it, but I need to develop also on WinXP, and Qt is commercial for Windows. >Second, are there tools to interface directly to Cocoa or Carbon Look after PyObjC. Looks like one can use Xcode Tools to build a GUI. Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From kerfue+pythonmac-sig at herocamp.org Mon Mar 14 11:21:01 2005 From: kerfue+pythonmac-sig at herocamp.org (Truls A. Tangstad) Date: Mon Mar 14 11:21:04 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: References: Message-ID: <20050314102100.GB525@sakura.chem.ntnu.no> On Mon, Mar 14, 2005 at 10:28:48AM +0100, Henning.Ramm@mediapro-gmbh.de wrote: > >Based on the statement above it looks as if wxWindows is the more > >mature and stable GUI toolkit for cross-platform on OSX. Is it worth > >learning WX? or will PyQt catch up? or does anyone even know the > >answer to that? > I guess you can use PyQt on OSX, I never tried it, but I need to > develop also on WinXP, and Qt is commercial for Windows. For those who want to develop non-commercial software, the next version of Qt will also be released under GPL also for windows second quarter 2005. PyQt bindings under GPL should follow. -- Truls A. Tangstad - From Jack.Jansen at cwi.nl Mon Mar 14 15:12:39 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Mar 14 15:12:22 2005 Subject: [Pythonmac-SIG] Compiling Python on Tiger Message-ID: <1f8a461f352a34f6c5868f2e506f109c@cwi.nl> If anyone has tried to build Python on Tiger: could you please contact me? I've received a bug report that I'd like some more data points on... -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From troy.rollins at gmail.com Tue Mar 15 06:14:48 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Tue Mar 15 06:14:54 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: <423647AD.8070807@noaa.gov> References: <4230800E.3040300@noaa.gov> <31ac537c050310140276c60f76@mail.gmail.com> <2c193b7e88207d222ac83190b6c44463@conncoll.edu> <423104FA.7090707@noaa.gov> <4230DB11.9@noaa.gov> <3aeb0b30b59438243aeecd271c987371@conncoll.edu> <31ac537c0503121340621e6b3b@mail.gmail.com> <423647AD.8070807@noaa.gov> Message-ID: <31ac537c050314211460543570@mail.gmail.com> > By the way, DialogBlocks is another option, also a commercial product > from one of the core (indeed, the founder) wx developers. > > http://www.anthemion.co.uk/dialogblocks/ > > I believe the OS-X version may still be listed as beta, but it hasn't > shown any problems for me with a quick check-out. At least runs long > enough for me to check it out quickly, and it seems solid and nice. You > can try it out (with restrictions) before buying. Interesting, that one hadn't shown up in any of my searches. > > That still doesn't give you an all-in-one IDE, but the pieces are there. Yes. I'm not debating that it is not possible to "get something working." I'm stating that OSX is behind the other two platforms in terms of polished tools for it. > > By the way, I'm curious: My impression is that all-in-one GUI > Point-and-click development environments are much easier on the newbie, > but I'm not the least bit convinced that they increase productivity for > folks that develop everyday. Has anyone seen any kind of study comparing > productivity between a GUI IDE and the old command-line + editor approach? I'm no newbie, other than to Python itself. I write a great deal of software, and earn a rather respectable income based on it. For me, productivity is partially measured by my enjoyment of the space my mind lives in roughly 16 hours a day. If I had a plain text editor or a buggy freeware thing for a workspace, I'd probably do a lot less coding. I'm not saying this is an issue for everyone, or even anyone else at all. It is an issue of enjoying what I do, and having tools that make my job easier, more fun, more visual, more playful, whatever... Not to mention that this group would be about the last to provide some unbiased polling on that particular topic. > > > Time to make room for some Linux boxes, as Linux has commercial tools > > available. > > Interestingly, I don't use commercial tools, and have also found Linux > to be a much easier environment. In contrast, I'd say the advantage of > Linux over OS-X is mostly in the non-commercial realm. For instance, I > don't think any of the mentioned tools (Flash, Director, Revolution, > RealBasic) are available on linux. Revolution is. The new RealBasic is. Flash has playback. I didn't mean to imply that I'm only interested in commercial products, or that Linux is the best place to find commercial products. I'm interested in the quality of commercial products, and (somewhat oddly) those currently exist on Linux rather than OSX. Windows as well, but I'm only willing to stoop so low. > > I do think it's odd that people are saying that only commercial tools > are robust and supported, and yet want to use Python. It isn't an issue of wanting everything to be "free". I'm not interested in Python because it is free as in beer, but because it is open. Open source has many benefits beyond saving a buck and sloppy tool sets. There are enough compelling reasons to use Python, even if a nice authoring tool costs a couple hundred bucks. > Personally, I'd > like us to focus on the quality of the tools (including installation, > support and documentation), rather than whether they are proprietary or > not. Personally, I've found both proprietary and open-source software to > be both excellent and crappy by all these measures. You seem to think I want to pay for something. I want the QUALITY of commercial software e.g. "commercial quality"... or something "people would be willing to pay for." If you can't see a difference between some of the dot-seven release tools on OSX, and something like Komodo... well, I don't expect to convince you. The point is, I'd be perfectly happy on OSX, so long as there are tools which meet my standards, payware or not. But there aren't currently. I have high hopes that someday there will be. > > By the way to second someone's comments about a TK- GUI-Builder: wx will > give you advantages over TK that no nifty GUI-builder will make up for > (unless you need the TK Canvas widget) Fair enough. I think I mentioned how I expected to use the TK tools for quick prototypes, and was willing to hand-code wx where needed. > > One last comment: while I agree that much of the MacPython experience > feels alpha or beta quality, I don't agree that it is fixed at that > level. It has gotten Much, Much better over the last few years, and I > expect to see it keep improving. Ooops. If I implied that it would never get better on OSX, I didn't mean to. I was refering to the landscape today, in comparison to the other platforms. > > Thanks Jack, Bob, Kevin O, etc, etc. for a job very well done! Indeed. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From lee_cullens at mac.com Tue Mar 15 07:38:57 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Mar 15 07:39:01 2005 Subject: [Pythonmac-SIG] Python Help Link in IDLE Message-ID: First, this question has most likely been asked before, but I can't get the hang of easily searching the archives so any pointers in that regard would be appreciated also (and limit my dumb questions :~). I'm new to Mac and the Python community, but I'm retired from a software engineering career. Dual 2.5 Power Mac G5 (OS X 10.3.8) Python 2.3 My limited experience so far with IDLE is positive, but Selecting Help>Python Docs (or F1) does nothing for me (nothing appears). I found what I think is the appropriate file on my system (/Library/Tci/docs/SWIG/Manual/Python.html) and using Options>Configure IDLE>General tab I added an additional help source browsing for the file noted. I also tried variations such as file:///Library....... but all to no avail. I can access the Python docs from PythonIDE and I can access IDLE Help in IDLE, but not Python Docs in IDLE. Might someone tell me how I should access Python Hepl docs from IDLE? Thank you, LeeC From bob at redivi.com Tue Mar 15 08:00:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 15 08:01:00 2005 Subject: [Pythonmac-SIG] Python Help Link in IDLE In-Reply-To: References: Message-ID: On Mar 15, 2005, at 1:38, Lee Cullens wrote: > First, this question has most likely been asked before, but I can't > get the hang of easily searching the archives so any pointers in that > regard would be appreciated also (and limit my dumb questions :~). > I'm new to Mac and the Python community, but I'm retired from a > software engineering career. Dual 2.5 Power Mac G5 (OS X 10.3.8) > Python 2.3 > > My limited experience so far with IDLE is positive, but Selecting > Help>Python Docs (or F1) does nothing for me (nothing appears). I > found what I think is the appropriate file on my system > (/Library/Tci/docs/SWIG/Manual/Python.html) and using > Options>Configure IDLE>General tab I added an additional help source > browsing for the file noted. I also tried variations such as > file:///Library....... but all to no avail. I can access the Python > docs from PythonIDE and I can access IDLE Help in IDLE, but not Python > Docs in IDLE. > > Might someone tell me how I should access Python Hepl docs from IDLE? When I booted up IDLE and went to Python Docs, it took me to the web docs: http://www.python.org/doc/current/ Generally, if I'm looking something up, I do it from the google box in Safari. Like this: webbrowser site:docs.python.org -bob From rswerdlow at goombah.com Tue Mar 15 21:36:44 2005 From: rswerdlow at goombah.com (Bob Swerdlow) Date: Tue Mar 15 21:37:19 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' Message-ID: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> I'm trying to move my application from bundlebuilder to py2app. I upgraded to PyObjC 1.2, which includes py2app 1.7. I get the following error when I include optimize=1 or optimize=2. Without optimize, it works fine. How do I get a good build with optimize on? Thanks, Bob Here's the error message: Traceback (most recent call last): File "/tmp/tmptCCn9S.py", line 218, in ? direct=1) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/py2app/py2app/util.py", line 208, in byte_compile if force or newer(mod.filename, cfile): File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/distutils/dep_util.py", line 22, in newer raise DistutilsFileError, "file '%s' does not exist" % source distutils.errors.DistutilsFileError: file 'boot_app.py' does not exist error: command '/usr/bin/python' failed with exit status 1 From bob at redivi.com Tue Mar 15 22:47:52 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 15 22:47:59 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' In-Reply-To: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> References: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> Message-ID: <45af680f78b35ab18f5cffa3270d4bf2@redivi.com> On Mar 15, 2005, at 15:36, Bob Swerdlow wrote: > I'm trying to move my application from bundlebuilder to py2app. I > upgraded to PyObjC 1.2, which includes py2app 1.7. I get the > following error when I include optimize=1 or optimize=2. Without > optimize, it works fine. > > How do I get a good build with optimize on? You don't, optimize is broken. It might work if you're using py2app from svn. -bob From troy.rollins at gmail.com Wed Mar 16 03:50:39 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Wed Mar 16 03:50:46 2005 Subject: [Pythonmac-SIG] GUI design tools In-Reply-To: <42377B7B.2030005@noaa.gov> References: <31ac537c050310140276c60f76@mail.gmail.com> <2c193b7e88207d222ac83190b6c44463@conncoll.edu> <423104FA.7090707@noaa.gov> <4230DB11.9@noaa.gov> <3aeb0b30b59438243aeecd271c987371@conncoll.edu> <31ac537c0503121340621e6b3b@mail.gmail.com> <423647AD.8070807@noaa.gov> <31ac537c050314211460543570@mail.gmail.com> <42377B7B.2030005@noaa.gov> Message-ID: <31ac537c0503151850b5032c9@mail.gmail.com> > I was refering to the landscape today, in comparison to the > > other platforms. > > Maybe it wasn't you, but someone in the thread said something about > Python on OS-X seeming to have been stuck at an 0.7 level for a long > time. I just wanted to point out that it was, in fact, moving forward a > lot, even if it's not where we want it to be. Ooops. That was me. My point aimed more at the sort of tools I'm looking for being stuck at 0.7, not Python itself. Though I'm really not sure how much the Apple installed version of Python is benefitting developers... especially new ones like me. The available resources on the web are not really aimed at explaining Apple's somewhat outside-the-norm installation. > > Anyway, I hope you don't give up, you might well be able to contribute > to the effort. Me too. Part of the issue is obviously based on my limited time to learn and "get up to speed." I have several ongoing projects in other languages and tools which want almost all of my time. An IDE, in the early stages at least, can provide a faster ramp-up and a gentler introduction. Later on, I find a powerful IDE makes me faster, and more willing to experiment... don't ask me why, I don't know the answer. The good news is that WingIDE came out with another update today. On the Mac, it is really quite good, even in X11. On a very fast machine, with a good display card, it works very nicely. On a slower machine, the interface gives the feel of an X11 (or "Javalike") app, for sure. Kinda slow redraws, scrolled text creates vertical streaking until a refresh ocurrs, stuff like that. Still, Wing is quite well thought out, and functions really nicely. They are bringing in some cool new features, including the ability to script the IDE, etc. One day, I do hope to contribute to the community. I've been keeping a journal of my progress and process, which may evolve to some web articles... > But if you go to Linux, that's cool, I'm more of a Linux than OS-X > advocate anyway. We'll see. I'm quite happy on OSX generally, but Linux has some appeal as well. At this point, Python is a given, the rest of it is up in the air. ;-) -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From bob at redivi.com Wed Mar 16 07:55:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 16 07:56:01 2005 Subject: [Pythonmac-SIG] Re: [pygame] ANN: pygame 1.7.0 for Mac OS X 10.3 In-Reply-To: <89783E34-9404-11D9-963B-000393DB52E4@2xtreme.net> References: <89783E34-9404-11D9-963B-000393DB52E4@2xtreme.net> Message-ID: <8a05168d676833f3753bea06543dd74c@redivi.com> On Mar 13, 2005, at 16:11, Keith Nemitz wrote: > Got a bug for you. How do I access your bug reporting system? > > Briefly, I have art with black skip-color, and I use the alpha > blending feature of pygame to fade the art in. Before 1.7 the art > faded in beautifully. Now the art fades in without skipping color > until the alpha reaches 255. So I get lots of black around the > characters as they fade in. > > Also, I'm having trouble playing sound effects, but that seems to be > an issue with py2app. Music (streamed sound) plays fine, but preloaded > sound hangs the system while it plays and is silent. Music and SFX are > all ogg. Worked fine with bundleBuilder. Maybe I'm using the wrong > recipe with py2app, or I need to explicitly load a framework. This was a bug in one of the AltiVec optimized blitters in the provided SDL framework. An updated version of the pygame package with this bug fixed has been placed on http://pythonmac.org/packages/ There *may* be bugs in other optimized but rarely used blits, they were tested mostly by example (I ran several games against them to verify correctness). If you see something that's blitting strangely, then set an environment variable SDL_DISABLE_CPUFEATURES sometime before "import pygame". If it goes away, boil it down to a simple example that demonstrates this blit, send it to me, and I'll fix it. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3590 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050316/082cca2a/smime.bin From rogerb at rogerbinns.com Wed Mar 16 08:26:09 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Mar 16 08:26:10 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' References: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> <45af680f78b35ab18f5cffa3270d4bf2@redivi.com> Message-ID: <017701c529f9$6ce01ef0$3501a8c0@rogersqyvr14d3> > You don't, optimize is broken. It might work if you're using py2app > from svn. Or you can use this few line workaround: http://article.gmane.org/gmane.comp.mobile.bitpim.devel/1779 The "bootstrap=" line should be indented inside the if (ie at the same level as 'import py2app'). Roger From bob at redivi.com Wed Mar 16 08:37:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 16 08:38:10 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' In-Reply-To: <017701c529f9$6ce01ef0$3501a8c0@rogersqyvr14d3> References: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> <45af680f78b35ab18f5cffa3270d4bf2@redivi.com> <017701c529f9$6ce01ef0$3501a8c0@rogersqyvr14d3> Message-ID: <47bff21674cef5a3ccbdde1e06b95f57@redivi.com> On Mar 16, 2005, at 2:26 AM, Roger Binns wrote: >> You don't, optimize is broken. It might work if you're using py2app >> from svn. > > Or you can use this few line workaround: > > http://article.gmane.org/gmane.comp.mobile.bitpim.devel/1779 > > The "bootstrap=" line should be indented inside the if (ie at > the same level as 'import py2app'). Updating to svn is the MUCH better option. There are other bug fixes and enhancements, and if you don't help me test svn then the next release might be broken for your purposes. -bob From rogerb at rogerbinns.com Wed Mar 16 08:44:56 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Mar 16 08:45:22 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' References: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> <45af680f78b35ab18f5cffa3270d4bf2@redivi.com> <017701c529f9$6ce01ef0$3501a8c0@rogersqyvr14d3> <47bff21674cef5a3ccbdde1e06b95f57@redivi.com> Message-ID: <000e01c529fc$14e645a0$3501a8c0@rogersqyvr14d3> > There are other bug fixes > and enhancements, and if you don't help me test svn then the next > release might be broken for your purposes. I am perfectly happy with the current release :-) Generally I don't run beta/test versions unless they are packaged up in such a way that they are trivial to (un)install, and trivial to get back to the old version. For example, Robin does that with wxPython release candidates. Roger From bob at redivi.com Wed Mar 16 09:03:59 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 16 09:04:15 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' In-Reply-To: <000e01c529fc$14e645a0$3501a8c0@rogersqyvr14d3> References: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> <45af680f78b35ab18f5cffa3270d4bf2@redivi.com> <017701c529f9$6ce01ef0$3501a8c0@rogersqyvr14d3> <47bff21674cef5a3ccbdde1e06b95f57@redivi.com> <000e01c529fc$14e645a0$3501a8c0@rogersqyvr14d3> Message-ID: On Mar 16, 2005, at 2:44 AM, Roger Binns wrote: >> There are other bug fixes and enhancements, and if you don't help me >> test svn then the next release might be broken for your purposes. > > I am perfectly happy with the current release :-) > > Generally I don't run beta/test versions unless they are packaged > up in such a way that they are trivial to (un)install, and trivial > to get back to the old version. For example, Robin does that > with wxPython release candidates. Since py2app requires no "installation" process, it's rather trivial. Install svn trunk (works whether or not py2app is already installed): # download/install subversion from if you don't already have it. You should, it rocks. mkdir ~/src mkdir -p ~/Library/Python/2.3/site-packages svn co http://svn.red-bean.com/bob/py2app/trunk ~/src/py2app echo "$HOME/src/py2app" > /Library/Python/2.3/py2app.pth # optionally add ~/src/py2app/scripts to your PATH Update to current release: svn up ~/src/py2app Uninstall (restores existing py2app): rm -rf ~/src/py2app # if not restoring existing py2app, rm this file instead echo py2app > /Library/Python/2.3/py2app.pth -bob From bob at redivi.com Wed Mar 16 09:14:57 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 16 09:15:21 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' In-Reply-To: References: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> <45af680f78b35ab18f5cffa3270d4bf2@redivi.com> <017701c529f9$6ce01ef0$3501a8c0@rogersqyvr14d3> <47bff21674cef5a3ccbdde1e06b95f57@redivi.com> <000e01c529fc$14e645a0$3501a8c0@rogersqyvr14d3> Message-ID: <37cc329127e245c5ed755d2ec5c3df18@redivi.com> On Mar 16, 2005, at 3:03 AM, Bob Ippolito wrote: > > On Mar 16, 2005, at 2:44 AM, Roger Binns wrote: > >>> There are other bug fixes and enhancements, and if you don't help me >>> test svn then the next release might be broken for your purposes. >> >> I am perfectly happy with the current release :-) >> >> Generally I don't run beta/test versions unless they are packaged >> up in such a way that they are trivial to (un)install, and trivial >> to get back to the old version. For example, Robin does that >> with wxPython release candidates. > > Since py2app requires no "installation" process, it's rather trivial. > > Install svn trunk (works whether or not py2app is already installed): > > # download/install subversion from > if you don't already have it. You should, it rocks. > mkdir ~/src > mkdir -p ~/Library/Python/2.3/site-packages > svn co http://svn.red-bean.com/bob/py2app/trunk ~/src/py2app > echo "$HOME/src/py2app" > /Library/Python/2.3/py2app.pth > # optionally add ~/src/py2app/scripts to your PATH > > Update to current release: > svn up ~/src/py2app > > Uninstall (restores existing py2app): > > rm -rf ~/src/py2app > # if not restoring existing py2app, rm this file instead > echo py2app > /Library/Python/2.3/py2app.pth The mkdir -p line in the installation instructions is superfluous. I was writing the directions to reflect how I have py2app installed at first, but then realized it wouldn't necessarily override an existing installation and changed it but forgot to remove that line. -bob From rogerb at rogerbinns.com Wed Mar 16 16:49:10 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Mar 16 16:49:16 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' References: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> <45af680f78b35ab18f5cffa3270d4bf2@redivi.com> <017701c529f9$6ce01ef0$3501a8c0@rogersqyvr14d3> <47bff21674cef5a3ccbdde1e06b95f57@redivi.com> <000e01c529fc$14e645a0$3501a8c0@rogersqyvr14d3> Message-ID: <002601c52a3f$b4258070$3501a8c0@rogersqyvr14d3> > Since py2app requires no "installation" process, it's rather trivial. Err, my definition of trivial is I point at something in my browser which downloads something I double click on. There also needs to be something to double click on to get rid of it. I don't care how it is done behind the scenes. This is open source and the version number is way less than 1.0. There isn't any harm in doing lots of little point releases, aka release early and release often. Roger From rogerb at rogerbinns.com Wed Mar 16 16:49:14 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Mar 16 16:49:17 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' References: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> <45af680f78b35ab18f5cffa3270d4bf2@redivi.com> <017701c529f9$6ce01ef0$3501a8c0@rogersqyvr14d3> <47bff21674cef5a3ccbdde1e06b95f57@redivi.com> <000e01c529fc$14e645a0$3501a8c0@rogersqyvr14d3> Message-ID: <002701c52a3f$b4316750$3501a8c0@rogersqyvr14d3> > Since py2app requires no "installation" process, it's rather trivial. Err, my definition of trivial is I point at something in my browser which downloads something I double click on. There also needs to be something to double click on to get rid of it. I don't care how it is done behind the scenes. This is open source and the version number is way less than 1.0. There isn't any harm in doing lots of little point releases, aka release early and release often. Roger From lee_cullens at mac.com Wed Mar 16 17:00:42 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Wed Mar 16 17:00:49 2005 Subject: [Pythonmac-SIG] Re: Getting acclimated In-Reply-To: <20050316110050.7AD4A1E4010@bag.python.org> References: <20050316110050.7AD4A1E4010@bag.python.org> Message-ID: <7746e980b0aa26e9df3a70d090d4fabb@mac.com> Mentioned this before, but just for context - new to Mac and Python but retired from a software engineering career. Dual 2.5 Power Mac G5; OS X 10.3.8; Python 2.3; PythonIDE, Package Manager, PythonLauncher, IDLE. Also have a PC on my LAN, but use it only as a test platform (dislike MS Windows environ). I do the odd project in the areas of multimedia presentations, graphical (charting) and DB front-end GUIs. Until recently I did such with Macromedia Director or more simply with Adobe Acrobat. Now, perhaps I'm getting ahead of myself as I'm not that far along in studying Python let alone producing an application, but I'm a little behind the curve regarding creating a "stand alone" application, especially X platform. There are two ways that come to mind that I might get up to speed. 1) links to relevant material (but what I've read so far is conflicting and confusing). 2) working with someone knowledgeable (doing the grunt work) to produce an instructional guide that would acclimate others (and myself in the process). Any thoughts and suggestions are appreciated :~) LeeC leeDOTklgcstudioATtdsDOTnet From Chris.Barker at noaa.gov Wed Mar 16 18:52:22 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Mar 16 18:51:56 2005 Subject: [Pythonmac-SIG] Another upgrade to the OS-X package for matplotlib 0.72.1 In-Reply-To: <422F6743.7000600@noaa.gov> References: <422F6743.7000600@noaa.gov> Message-ID: <42387256.30100@noaa.gov> Hi all, A user discovered that I had built only Numeric support, and not numarray support, into my OS-X matplotlib package. I've fixed that, and you can find the new version at: http://www.pythonmac.org/packages/matplotlib-0.72.1-py2.3-macosx10.3.zip It supports Numeric and/or numarray, and the Tk, Wx, and Agg back-ends. Note that TK and Wx are a bit weird, they both can crash python when you close the window. I'm only using the Agg back-end myself at the moment, so I'm not going to figure this out, but it would be great if someone did! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Wed Mar 16 23:31:51 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 16 23:31:59 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' In-Reply-To: <002701c52a3f$b4316750$3501a8c0@rogersqyvr14d3> References: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> <45af680f78b35ab18f5cffa3270d4bf2@redivi.com> <017701c529f9$6ce01ef0$3501a8c0@rogersqyvr14d3> <47bff21674cef5a3ccbdde1e06b95f57@redivi.com> <000e01c529fc$14e645a0$3501a8c0@rogersqyvr14d3> <002701c52a3f$b4316750$3501a8c0@rogersqyvr14d3> Message-ID: <19ec15920d529f76ce37f15b682c6252@redivi.com> On Mar 16, 2005, at 10:49 AM, Roger Binns wrote: >> Since py2app requires no "installation" process, it's rather trivial. > > Err, my definition of trivial is I point at something in my browser > which downloads something I double click on. There also needs to > be something to double click on to get rid of it. I don't care > how it is done behind the scenes. Perhaps I should make the official installer install whatever is in SVN at the time instead of having a release tarball at all :) > This is open source and the version number is way less than 1.0. > There isn't any harm in doing lots of little point releases, aka > release early and release often. Sure there is, it takes up time better spent on other things. -bob From kid at kendermedia.com Thu Mar 17 03:13:18 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Thu Mar 17 03:13:22 2005 Subject: [Pythonmac-SIG] py2app on Tiger Message-ID: <4238E7BE.1060606@kendermedia.com> Given the buzz that Tiger is coming in a month, I was curious about whether it's possible to create Python apps on Tiger and run them on Panther (assuming, of course, that I'm not using Tiger features). I'm already using my own Python build, if that makes any difference. I'd really like to upgrade to Tiger, but even more than that I'd really like for people running Panther to be able to buy my software :) Kevin From bob at redivi.com Thu Mar 17 03:39:47 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 17 03:39:56 2005 Subject: [Pythonmac-SIG] py2app on Tiger In-Reply-To: <4238E7BE.1060606@kendermedia.com> References: <4238E7BE.1060606@kendermedia.com> Message-ID: On Mar 16, 2005, at 9:13 PM, Kevin Dangoor wrote: > Given the buzz that Tiger is coming in a month, I was curious about > whether it's possible to create Python apps on Tiger and run them on > Panther (assuming, of course, that I'm not using Tiger features). I'm > already using my own Python build, if that makes any difference. > > I'd really like to upgrade to Tiger, but even more than that I'd > really like for people running Panther to be able to buy my software > :) You *may* need to compile the Python framework and all of the extensions that you use on Mac OS X 10.3 (Panther). If you *do* compile them on Mac OS X 10.3, then they will surely work on Mac OS X 10.3. If you compile them on Mac OS X 10.4 (Tiger), they *might* work on Mac OS X 10.3. It really depends on how they're written, what they link to, and how they link to it. Testing is necessary. In general, Python itself MUST be compiled on the minimum target platform, because its configure scripts and stuff will pick up features and use them regardless of how hard you try and prevent it from doing so with MACOSX_DEPLOYMENT_TARGET and usage of SDK paths. Extensions are usually less complicated and you may have more luck with that. PyObjC compiled on Mac OS X 10.4 probably won't work with Mac OS X 10.3, most other things *probably* will. Again, testing is necessary. All that said: Since you're going to have to test on the minimum target platform anyway, you might as well compile everything there. My recommendation is to: - Build your framework on the minimum target platform - Copy it over to your workstation - Use bdist_mpkg to build installer packages for the extensions you use from the minimum target platform - Install them on your workstation as needed py2app doesn't compile anything, so it doesn't care which OS it runs on. I have a Python framework plus extensions that were built on Mac OS X 10.2 (Jaguar) that I use to build a Mac OS X 10.2 compatible application with from Mac OS X 10.3. -bob From kid at kendermedia.com Thu Mar 17 03:52:49 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Thu Mar 17 03:52:58 2005 Subject: [Pythonmac-SIG] py2app on Tiger In-Reply-To: References: <4238E7BE.1060606@kendermedia.com> Message-ID: <4238F101.4050802@kendermedia.com> Bob Ippolito wrote: > > My recommendation is to: > > - Build your framework on the minimum target platform > - Copy it over to your workstation > - Use bdist_mpkg to build installer packages for the extensions you > use from the minimum target platform > - Install them on your workstation as needed So, I guess the next question is: is it possible to have two versions of Mac OS X on one machine? My primary development box is a PowerBook. Would it be possible to keep 10.3 on an external firewire drive and boot from that when I need to produce my builds? (Sorry for the fairly basic question there, but I haven't had to do that kind of thing on a Mac before...) > > py2app doesn't compile anything, so it doesn't care which OS it runs > on. I have a Python framework plus extensions that were built on Mac > OS X 10.2 (Jaguar) that I use to build a Mac OS X 10.2 compatible > application with from Mac OS X 10.3. Makes sense. I should've guessed that anything in C that links to OS libraries would not drop down to 10.3 easily. Kevin From bob at redivi.com Thu Mar 17 04:01:34 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 17 04:01:47 2005 Subject: [Pythonmac-SIG] py2app on Tiger In-Reply-To: <4238F101.4050802@kendermedia.com> References: <4238E7BE.1060606@kendermedia.com> <4238F101.4050802@kendermedia.com> Message-ID: <8a25ed58cce11712e23805f87976ccf4@redivi.com> On Mar 16, 2005, at 9:52 PM, Kevin Dangoor wrote: > Bob Ippolito wrote: > >> My recommendation is to: >> >> - Build your framework on the minimum target platform >> - Copy it over to your workstation >> - Use bdist_mpkg to build installer packages for the extensions you >> use from the minimum target platform >> - Install them on your workstation as needed > > So, I guess the next question is: is it possible to have two versions > of Mac OS X on one machine? My primary development box is a PowerBook. > Would it be possible to keep 10.3 on an external firewire drive and > boot from that when I need to produce my builds? > > (Sorry for the fairly basic question there, but I haven't had to do > that kind of thing on a Mac before...) Yes, external firewire drive or another partition on the same drive works fine. Another drive is your best option, because repartitioning would wipe your current drive. I have a G4 with 10.2, 10.3, and 10.4 installed on it (different partitions) that I use for compiling junk (basically only via ssh, ARD, or VNC). My powerbook also has 10.3 and 10.4 on it (different partitions). My G5 only has 10.3 on it right now, though (it has a whole bunch of drives, so it *could*, but I don't like rebooting it). Doing it with an iPod is also a possibility, though iPods aren't the fastest external firewire drives. >> py2app doesn't compile anything, so it doesn't care which OS it runs >> on. I have a Python framework plus extensions that were built on Mac >> OS X 10.2 (Jaguar) that I use to build a Mac OS X 10.2 compatible >> application with from Mac OS X 10.3. > > Makes sense. I should've guessed that anything in C that links to OS > libraries would not drop down to 10.3 easily. It does, for some definition of easily (weak linking, SDKs, etc.). However, autoconf based stuff has no idea how this works, and neither does distutils, so it's not really an option for Python. -bob From jdhunter at ace.bsd.uchicago.edu Thu Mar 17 13:26:32 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu Mar 17 14:07:38 2005 Subject: [Pythonmac-SIG] emergency python recovery Message-ID: I was in the process of getting ready for a talk this morning at 9AM, one that was largely a demo of python for scientific computing, when I inadvertently did > sudo rm -rf /System/Library/Frameworks/Python/.framework/Versions/2.3/lib/python2.3 Ouch! I had meant to just remove site-packages/matplotlib for a clean install, and just screwed up. Is there an easy way to get this directory back -- eg an installer or package? If not, could someone just tar up that directory and share it with me? I'm using OS X 10.3 on a 12 inch powerbook G4. Thanks! JDH From kid at kendermedia.com Thu Mar 17 14:26:17 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Thu Mar 17 14:26:25 2005 Subject: [Pythonmac-SIG] emergency python recovery In-Reply-To: References: Message-ID: <42398579.5030808@kendermedia.com> Just an FYI to anyone else who sees this... I've tarred up the files for John. Kevin John Hunter wrote: >I was in the process of getting ready for a talk this morning at 9AM, >one that was largely a demo of python for scientific computing, when I >inadvertently did > > > sudo rm -rf /System/Library/Frameworks/Python/.framework/Versions/2.3/lib/python2.3 > >Ouch! I had meant to just remove site-packages/matplotlib for a clean >install, and just screwed up. > >Is there an easy way to get this directory back -- eg an installer or >package? > >If not, could someone just tar up that directory and share it with me? >I'm using OS X 10.3 on a 12 inch powerbook G4. > >Thanks! >JDH >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > > From bob at redivi.com Thu Mar 17 16:36:21 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 17 16:36:31 2005 Subject: [Pythonmac-SIG] emergency python recovery In-Reply-To: <42398579.5030808@kendermedia.com> References: <42398579.5030808@kendermedia.com> Message-ID: It's also possible to unpax them BSD(somethingoranother).pkg somewhere on one of the Panther install CDs. -bob On Mar 17, 2005, at 8:26, Kevin Dangoor wrote: > Just an FYI to anyone else who sees this... I've tarred up the files > for John. > > Kevin > > John Hunter wrote: > >> I was in the process of getting ready for a talk this morning at 9AM, >> one that was largely a demo of python for scientific computing, when I >> inadvertently did >> >> > sudo rm -rf >> /System/Library/Frameworks/Python/.framework/Versions/2.3/lib/ >> python2.3 >> >> Ouch! I had meant to just remove site-packages/matplotlib for a clean >> install, and just screwed up. >> >> Is there an easy way to get this directory back -- eg an installer or >> package? >> >> If not, could someone just tar up that directory and share it with me? >> I'm using OS X 10.3 on a 12 inch powerbook G4. >> >> Thanks! >> JDH >> _______________________________________________ >> 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 From charles.hartman at conncoll.edu Thu Mar 17 16:37:11 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Mar 17 16:37:18 2005 Subject: [Pythonmac-SIG] py2app on Tiger In-Reply-To: References: <4238E7BE.1060606@kendermedia.com> Message-ID: <7f0c627e6d469ffc608fe043a9559cdc@conncoll.edu> On Mar 16, 2005, at 9:39 PM, Bob Ippolito wrote: > You *may* need to compile the Python framework and all of the > extensions that you use on Mac OS X 10.3 (Panther). If you *do* > compile them on Mac OS X 10.3, then they will surely work on Mac OS X > 10.3. If you compile them on Mac OS X 10.4 (Tiger), they *might* work > on Mac OS X 10.3. It really depends on how they're written, what they > link to, and how they link to it. Testing is necessary. Do I have this straight: 1. *Until* I upgrade to Tiger (proably a few months), I can keep working on 10.3, and what I build (using Apple-distributed framework 2.3 and wxPython 2.5.3.x or 2.5.4.x when I upgrade that) will work on *both* 10.3 and 10.4? 2. Once I upgrade, I will need to keep a 10.3 partition around until I decide to stop supporting 10.3, if ever? Not a cheery prospect, but I want to make sure I at least understand what it is. Charles Hartman From bob at redivi.com Thu Mar 17 16:48:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 17 16:48:50 2005 Subject: [Pythonmac-SIG] py2app on Tiger In-Reply-To: <7f0c627e6d469ffc608fe043a9559cdc@conncoll.edu> References: <4238E7BE.1060606@kendermedia.com> <7f0c627e6d469ffc608fe043a9559cdc@conncoll.edu> Message-ID: On Mar 17, 2005, at 10:37, Charles Hartman wrote: > On Mar 16, 2005, at 9:39 PM, Bob Ippolito wrote: > >> You *may* need to compile the Python framework and all of the >> extensions that you use on Mac OS X 10.3 (Panther). If you *do* >> compile them on Mac OS X 10.3, then they will surely work on Mac OS X >> 10.3. If you compile them on Mac OS X 10.4 (Tiger), they *might* >> work on Mac OS X 10.3. It really depends on how they're written, >> what they link to, and how they link to it. Testing is necessary. > > Do I have this straight: > > 1. *Until* I upgrade to Tiger (proably a few months), I can keep > working on 10.3, and what I build (using Apple-distributed framework > 2.3 and wxPython 2.5.3.x or 2.5.4.x when I upgrade that) will work on > *both* 10.3 and 10.4? I didn't say that. I said it would work if you compiled a Python framework. I said nothing of whether using the Apple-distributed framework would be compatible. Applications using the stock Python 2.3.x might (let's upgrade that to "will probably") work on both 10.3 or 10.4, but there is no guarantee, and it's unlikely to work after that. > 2. Once I upgrade, I will need to keep a 10.3 partition around until I > decide to stop supporting 10.3, if ever? Not a cheery prospect, but I > want to make sure I at least understand what it is. Compiling extensions on 10.3 is the only way to guarantee they will work on 10.3. Testing on 10.3 is the only way to know if your app works on 10.3. The degree to which you need 10.3 depends on how often you need to compile extensions, and how actively you're going to support it by testing. -bob From charles.hartman at conncoll.edu Thu Mar 17 16:58:58 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Mar 17 17:09:45 2005 Subject: [Pythonmac-SIG] py2app on Tiger In-Reply-To: References: <4238E7BE.1060606@kendermedia.com> <7f0c627e6d469ffc608fe043a9559cdc@conncoll.edu> Message-ID: Thanks, that clarifies it. Since I'm not -- at least in my main current project -- compiling any extensions, just using off-the-shelf Python 2.3 and wxPython, it sounds as though my life shouldn't get *too* much more compicated too soon. I'm pretty sure my fairly straightforward code isn't using anything in 2.3 that will turn out not to work in 2.4. (Famous last words?) Probably like a lot of people, I don't care much about supporting versions of the OS that "nobody" (???) is using. Not only don't I have an OS9 version of my application, I don't worry about the absence of a 10.2 version, because "people" -- which means everyone I know in the audience for my weird app -- will have upgraded to 10.3 by now. That implies that, from now on, I'll need to keep one (1) bootable partition around with the previous x in 10.x, but no more. I'm counting on the herd instinct, here. Charles Hartman On Mar 17, 2005, at 10:48 AM, Bob Ippolito wrote: > > On Mar 17, 2005, at 10:37, Charles Hartman wrote: > >> On Mar 16, 2005, at 9:39 PM, Bob Ippolito wrote: >> >>> You *may* need to compile the Python framework and all of the >>> extensions that you use on Mac OS X 10.3 (Panther). If you *do* >>> compile them on Mac OS X 10.3, then they will surely work on Mac OS >>> X 10.3. If you compile them on Mac OS X 10.4 (Tiger), they *might* >>> work on Mac OS X 10.3. It really depends on how they're written, >>> what they link to, and how they link to it. Testing is necessary. >> >> Do I have this straight: >> >> 1. *Until* I upgrade to Tiger (proably a few months), I can keep >> working on 10.3, and what I build (using Apple-distributed framework >> 2.3 and wxPython 2.5.3.x or 2.5.4.x when I upgrade that) will work on >> *both* 10.3 and 10.4? > > I didn't say that. I said it would work if you compiled a Python > framework. I said nothing of whether using the Apple-distributed > framework would be compatible. Applications using the stock Python > 2.3.x might (let's upgrade that to "will probably") work on both 10.3 > or 10.4, but there is no guarantee, and it's unlikely to work after > that. > >> 2. Once I upgrade, I will need to keep a 10.3 partition around until >> I decide to stop supporting 10.3, if ever? Not a cheery prospect, but >> I want to make sure I at least understand what it is. > > Compiling extensions on 10.3 is the only way to guarantee they will > work on 10.3. Testing on 10.3 is the only way to know if your app > works on 10.3. The degree to which you need 10.3 depends on how often > you need to compile extensions, and how actively you're going to > support it by testing. > > -bob > From rogerb at rogerbinns.com Thu Mar 17 18:17:13 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Mar 17 18:17:11 2005 Subject: [Pythonmac-SIG] py2app fails with 'optimize' References: <01ba01c5299e$bf3a5590$066fa8c0@RSWERDLOW800> <45af680f78b35ab18f5cffa3270d4bf2@redivi.com> <017701c529f9$6ce01ef0$3501a8c0@rogersqyvr14d3> <47bff21674cef5a3ccbdde1e06b95f57@redivi.com> <000e01c529fc$14e645a0$3501a8c0@rogersqyvr14d3> <002701c52a3f$b4316750$3501a8c0@rogersqyvr14d3> <19ec15920d529f76ce37f15b682c6252@redivi.com> Message-ID: <00c801c52b15$296eec10$3501a8c0@rogersqyvr14d3> > Perhaps I should make the official installer install whatever is in SVN > at the time instead of having a release tarball at all :) Ximian used to start the install process for Gnome by doing something like: wget -dump http://...../install.sh | sh Note that I don't care how you do thinks behind the scenes only that it is one step to install and one to uninstall and the likely hood of hosing anything else is zero. >> This is open source and the version number is way less than 1.0. >> There isn't any harm in doing lots of little point releases, aka >> release early and release often. > > Sure there is, it takes up time better spent on other things. It depends on whose time you want to spend. There is your time once, vs the time of all the individual people you asked to test things. Since the existing release already works for me (with my small change to get optimize to work), there is little motivation to test things under development that require more work to get going and back out of. The lack of a point release also makes it harder to reproduce things on multiple machines. Roger From apt.shansen at gmail.com Thu Mar 17 22:49:16 2005 From: apt.shansen at gmail.com (Stephen Hansen) Date: Thu Mar 17 22:50:38 2005 Subject: [Pythonmac-SIG] "Launching" a file on a mounted server. Message-ID: <7a9c25c205031713497968a4a5@mail.gmail.com> Hello all :) I'm in the progress of porting our Python program over to the Mac, and I've run into a snag or two. We're running Python2.3 on MacOSX 10.3 I have two files: /Volumes/server/file1.jpg and: /Volumes/server/element/file2.jpg If I do: fs1 = Carbon.File.FSRef('/Volumes/server/file1.jpg') and: fs2 = Carbon.File.FSRef('/Volumes/server/element/file2.jpg') then if I use findertools.launch(fs1) it works, but findertools.launch(fs2) does not. It throws the following traceback: Traceback (most recent call last): File "/falcon/apt/system/editorial/library/ResourceGrid.py", line 162, in OnLeftDoubleClick cb(self, row, rec, line) File "/falcon/apt/system/editorial/application/client/Client.py", line 558, in OnQueue_DoubleClick findertools.launch(Carbon.File.FSRef(path)) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/findertools.py", line 45, in launch return finder.open(fss) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/lib-scriptpackages/Finder/Standard_Suite.py", line 250, in open raise aetools.Error, aetools.decodeerror(_arguments) aetools.Error: (-10000, 'errAEEventFailed', None) Now, i can browse into that directory (QA_Edit40->element) and run that file fine, and if i copy that file onto the roof of the share (so it becomes /Volumes/server/file2.jpg) it runs fine.. Just not in the subdirectory... -- Stephen Hansen Development Advanced Publishing Technology shansen@advpubtech.com (818) 557-3035 x330 From bob at redivi.com Thu Mar 17 22:59:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 17 22:59:11 2005 Subject: [Pythonmac-SIG] "Launching" a file on a mounted server. In-Reply-To: <7a9c25c205031713497968a4a5@mail.gmail.com> References: <7a9c25c205031713497968a4a5@mail.gmail.com> Message-ID: On Mar 17, 2005, at 16:49, Stephen Hansen wrote: > Hello all :) I'm in the progress of porting our Python program over to > the Mac, and I've run into a snag or two. > > We're running Python2.3 on MacOSX 10.3 > > I have two files: /Volumes/server/file1.jpg > and: /Volumes/server/element/file2.jpg > > If I do: fs1 = Carbon.File.FSRef('/Volumes/server/file1.jpg') > and: fs2 = Carbon.File.FSRef('/Volumes/server/element/file2.jpg') > > then if I use findertools.launch(fs1) it works, but > findertools.launch(fs2) does not. It throws the following traceback: I would suggest not using those functions at all. Either use the LaunchServices module from Python23Compat (backported from Python 2.4), or use the NSWorkspace methods in PyObjC (easier). The findertools stuff is *ancient* API. God knows why it doesn't work, but I'm not surprised in the least. -bob From bob at redivi.com Fri Mar 18 03:55:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 18 03:55:44 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 Message-ID: (see also: ) `py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.8 will be included in the installer for `PyObjC`_ 1.3. If you have installed `PyObjC`_ 1.3, then you already have `py2app`_ 0.1.8 installed. Download and related links are here: http://undefined.org/python/#py2app py2app 0.1.8 is a major enhancements release: Bugs fixed: - Symlinks in included frameworks should be preserved correctly (fixes Tcl/Tk) - Fixes some minor issues with alias bundles - Removed implicit SpiderImagePlugin -> ImageTk reference in PIL recipe - The ``--optimize`` option should work now - ``weakref`` is now included by default - ``anydbm``'s dynamic dependencies are now in the standard implies list - Errors on app launch are brought to the front so the user does not miss them - bdist_mpkg now compatible with pychecker (data_files had issues) Options changed: - deprecated ``--strip``, it is now on by default - new ``--no-strip`` option to turn off stripping of executables New features: - Looks for a hacked version of the PyOpenGL __init__.py so that it doesn't have to include the whole package in order to get at the stupid version file. - New ``loader_files`` key that a recipe can return in order to ensure that non-code ends up in the .zip (the pygame recipe uses this) - Now scans all files in the bundle and normalizes Mach-O load commands, not just extensions. This helps out when using the ``--package`` option, when including frameworks that have plugins, etc. - An embedded Python interpreter is now included in the executable bundle (``sys.executable`` points to it), this currently only works for framework builds of Python - New ``macho_standalone`` tool - New ``macho_find`` tool - Major enhancements to the way plugins are built - bdist_mpkg now has a ``--zipdist`` option to build zip files from the built package - The bdist_mpkg "Installed to:" description is now based on the package install root, rather than the build root .. _`py2app`: http://undefined.org/python/#py2app .. _`pyobjc`: http://pyobjc.sourceforge.net/ .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/ From bob at redivi.com Fri Mar 18 04:35:19 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 18 04:35:26 2005 Subject: [Pythonmac-SIG] ANN: PyObjC 1.3b1 Message-ID: <3e24953b100f0b68fcefedcd235b943e@redivi.com> NOTE: This is an announcement for a BETA release of `PyObjC`_. Though we know it to be quite stable, and have been using it on a daily basis for quite some time, use it at your own risk. 1.3.0 will be out in a matter of days, but it is essential that we get some eyes on this! .. _`PyObjC`: http://pyobjc.sourceforge.net/ Installer package available from: http://pythonmac.org/packages/ (note that the installer also contains `py2app`_ 0.1.8) .. _`py2app`: http://undefined.org/python/#py2app Source: http://svn.red-bean.com/pyobjc/tags/pyobjc-1.3b1/ Version 1.3 (2005-03-??) ------------------------ - The bridge now maintains object identity across the bridge in both directions. Previous versions of the bridge only did this when bridging from Objective-C to Python. Exceptions: NSString and NSNumber do not have unique proxies. NSString never will have. Python numbers and strings are converted, not proxied and therefore also don't get unique proxies. And finally, any python object that is proxied using the ``__pyobjc_object__`` interface will only get a unique proxy if the ``__pyobjc_object__`` method implements that feature. - New ``objc.protocolsForClass`` function that returns a list of protocols that the class directly claims to conform to. - PyObjC classes can now declare that they implement formal protocols, for example:: class MyLockingClass(NSObject, objc.protocolNamed('NSLocking')): # implementation pass It is also possible to define new protocols:: MyProtocol = objc.formal_protocol("MyProtocol", None, [ selector(None, selector='mymethod', signature='v@:'), ]) All formal protocols are instances of ``objc.formal_protocol``. - PyObjCTools.KeyValueCoding has a new ``kvc`` class that allows Pythonic Key-Value Coding. - ``__getitem__`` is mapped to ``valueForKeyPath:`` - ``__setitem__`` is mapped to ``setValue:forKeyPath:`` - ``__getattr__`` is mapped to ``valueForKey:`` - ``__setattr__`` is mapped to ``setValue:forKey:`` The ``kvc`` class uses ``__pyobjc_object__``, so it may cross the bridge as the wrapped object. - ``NSNumber`` instances are bridged to a ``float``, ``long``, or ``int`` subclass that uses ``__pyobjc_object__``. ``NSDecimal`` is converted to ``NSDecimalNumber`` when used as an object, ``NSDecimalNumber`` is not bridged to ``NSDecimal`` because the latter is a mutable type. - The Python to Objective-C bridge now looks for a ``__pyobjc_object__`` attribute to get a PyObjC object from a Python object. - New IDNSnitch example in Inject that demonstrates how to write an monitor for the launch of another application, use ``objc.inject`` to load code into a target process, and override the implementation of an existing method but still call back into the original implementation (method swizzling). - ``objc.IMP`` should do the right thing now. This type is returned by ``+[NSObject methodForSelector:]`` and ``+[NSObject instanceMethodForSelector:]`` - New ToDos example in CocoaBindings that demonstrates how to use two array controllers for the same data, and how to use value transformers to alter the color of text. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler. - New Bookmarks example in CocoaBindings that demonstrates how to subclass ``NSArrayController`` to implement the ``NSTableView`` delegate drag and drop protocol, including copying of objects between documents and accepting URL drops from other applications. Also demonstrates re-ordering of the content array. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler. - New FilteringController example in CocoaBindings that demonstrates how to subclass ``NSArrayController`` to implement filtering of a ``NSTableView``. Also demonstrates the use of indexed accessors. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler. - New ControlledPreferences example in CocoaBindings that demonstrates how to use Cocoa Bindings to simplify storing and retrieving user preferences. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler. - New TemperatureTransformer example in CocoaBindings that demonstrates how to use NSValueTransfomers with PyObjC. Based on Apple's "Cocoa: Value Transformers" documentation, converted to PyObjC by u.fiedler. - New CurrencyConvBindings example in CocoaBindings that demonstrates a Cocoa Bindings enabled version of the CurrencyConverter example. Converted to PyObjC by u.fiedler from the example in Apple's "Introduction to Developing Cocoa Applications Using Bindings". - New ManualBindings example in CocoaBindings that demonstrates how to develop programmatic bindings from a PyObjC application. Converted to PyObjC by u.fiedler from the "Cocoa Bindings and Hints" example of the same name. - New HotKeyPython example in AppKit that demonstrates how to use Carbon global hot keys from a PyObjC application. Also demonstrates how to use a NSApplication subclass. - Key-Value Observing support is now automatic in Python classes that descend from ``NSObject``, unless they implement a custom ``willChangeValueForKey:``, ``didChangeValueForKey:``, or ``__useKVO__`` is not True. This allows ``self.foo = 1`` to automatically trigger notifications. This works in all cases, whether ``foo`` is a ``property``, ``ivar``, or just in the ``__dict__``. - New Inject folder in Examples, with an InjectInterpreter example that will inject a GUI Python interpreter into any process. - New ``objc.inject()`` function for Mac OS X 10.3 and later, allows an arbitrary bundle to be loaded into another process using mach_inject. - ``objc.classAddMethods`` now recognizes and supports classmethods. - GC is now correctly implemented for struct wrappers. - The ``NSNumber`` bridge has been removed, now you will get ``NSNumber`` instances across the bridge instead of a Python representation. - ``PyObjCTools.AppHelper.runEventLoop()`` will now bring your application to the front at startup when using pdb mode for convenience. - ``objc.loadBundle()`` no longer filters the class list. This solves a few potential issues and shaves off about 1/3rd of the overhead of ``python -c "import AppKit"``. - ``PyObjCTools.AppHelper.runEventLoop()`` no longer breaks on pure Objective-C exceptions. Most exceptions of this variety are more like warnings, and there is nothing that can be done them anyway. - ``PyObjCTools.AppHelper.runEventLoop()`` now installs the interrupt handler and verbose exception logging when using pdb, either explicitly or by the USE_PDB environment variable. - There is now a fast path for the ``NSString``/``unicode`` bridge when ``Py_UNICODE_SIZE`` is 2. This is the default setting for Python. - The default selector signature will have a void return value unless a "return" statement with an argument is used in the bytecode. In that case, it will default to an object return value. - ``__bundle_hack__`` is no longer necessary, py2app now sets a different environment variable to the current plugin during execution, and a hack is installed to ``NSBundle`` so that classes may respond to requests for their bundle with the ``+bundleForClass`` method. The class builder adds a default implementation of this to Python classes if this environment variable is set. - Added ``objc.currentBundle()``, which is equivalent to ``NSBundle.mainBundle()`` except after loading a plug-in. Makes it easier to load nib files. - ``PyObjCTools.NibClassBuilder.extractClasses()`` now uses ``objc.currentBundle()`` instead of ``NSBundle.mainBundle()``. This makes plugins less of a hassle to develop and allows identical code to be used for application or plugin development. - ``objc.registerPlugin()`` and ``objc.pluginBundle()`` are now deprecated as they are no longer useful. - It is now possible to subclass a class that implements ``copyWithZone:`` without setting ``__slots__`` to ``()``. From bob at mastersofbranding.com Fri Mar 18 04:33:09 2005 From: bob at mastersofbranding.com (Bob Ippolito) Date: Fri Mar 18 10:45:13 2005 Subject: [Pythonmac-SIG] ANN: PyObjC 1.3b1 Message-ID: <42c6879889426568ad1307449b82cab2@mastersofbranding.com> NOTE: This is an announcement for a BETA release of `PyObjC`_. Though we know it to be quite stable, and have been using it on a daily basis for quite some time, use it at your own risk. 1.3.0 will be out in a matter of days, but it is essential that we get some eyes on this! .. _`PyObjC`: http://pyobjc.sourceforge.net/ Installer package available from: http://pythonmac.org/packages/ (note that the installer also contains `py2app`_ 0.1.8) .. _`py2app`: http://undefined.org/python/#py2app Source: http://svn.red-bean.com/pyobjc/tags/pyobjc-1.3b1/ Version 1.3 (2005-03-??) ------------------------ - The bridge now maintains object identity across the bridge in both directions. Previous versions of the bridge only did this when bridging from Objective-C to Python. Exceptions: NSString and NSNumber do not have unique proxies. NSString never will have. Python numbers and strings are converted, not proxied and therefore also don't get unique proxies. And finally, any python object that is proxied using the ``__pyobjc_object__`` interface will only get a unique proxy if the ``__pyobjc_object__`` method implements that feature. - New ``objc.protocolsForClass`` function that returns a list of protocols that the class directly claims to conform to. - PyObjC classes can now declare that they implement formal protocols, for example:: class MyLockingClass(NSObject, objc.protocolNamed('NSLocking')): # implementation pass It is also possible to define new protocols:: MyProtocol = objc.formal_protocol("MyProtocol", None, [ selector(None, selector='mymethod', signature='v@:'), ]) All formal protocols are instances of ``objc.formal_protocol``. - PyObjCTools.KeyValueCoding has a new ``kvc`` class that allows Pythonic Key-Value Coding. - ``__getitem__`` is mapped to ``valueForKeyPath:`` - ``__setitem__`` is mapped to ``setValue:forKeyPath:`` - ``__getattr__`` is mapped to ``valueForKey:`` - ``__setattr__`` is mapped to ``setValue:forKey:`` The ``kvc`` class uses ``__pyobjc_object__``, so it may cross the bridge as the wrapped object. - ``NSNumber`` instances are bridged to a ``float``, ``long``, or ``int`` subclass that uses ``__pyobjc_object__``. ``NSDecimal`` is converted to ``NSDecimalNumber`` when used as an object, ``NSDecimalNumber`` is not bridged to ``NSDecimal`` because the latter is a mutable type. - The Python to Objective-C bridge now looks for a ``__pyobjc_object__`` attribute to get a PyObjC object from a Python object. - New IDNSnitch example in Inject that demonstrates how to write an monitor for the launch of another application, use ``objc.inject`` to load code into a target process, and override the implementation of an existing method but still call back into the original implementation (method swizzling). - ``objc.IMP`` should do the right thing now. This type is returned by ``+[NSObject methodForSelector:]`` and ``+[NSObject instanceMethodForSelector:]`` - New ToDos example in CocoaBindings that demonstrates how to use two array controllers for the same data, and how to use value transformers to alter the color of text. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler. - New Bookmarks example in CocoaBindings that demonstrates how to subclass ``NSArrayController`` to implement the ``NSTableView`` delegate drag and drop protocol, including copying of objects between documents and accepting URL drops from other applications. Also demonstrates re-ordering of the content array. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler. - New FilteringController example in CocoaBindings that demonstrates how to subclass ``NSArrayController`` to implement filtering of a ``NSTableView``. Also demonstrates the use of indexed accessors. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler. - New ControlledPreferences example in CocoaBindings that demonstrates how to use Cocoa Bindings to simplify storing and retrieving user preferences. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler. - New TemperatureTransformer example in CocoaBindings that demonstrates how to use NSValueTransfomers with PyObjC. Based on Apple's "Cocoa: Value Transformers" documentation, converted to PyObjC by u.fiedler. - New CurrencyConvBindings example in CocoaBindings that demonstrates a Cocoa Bindings enabled version of the CurrencyConverter example. Converted to PyObjC by u.fiedler from the example in Apple's "Introduction to Developing Cocoa Applications Using Bindings". - New ManualBindings example in CocoaBindings that demonstrates how to develop programmatic bindings from a PyObjC application. Converted to PyObjC by u.fiedler from the "Cocoa Bindings and Hints" example of the same name. - New HotKeyPython example in AppKit that demonstrates how to use Carbon global hot keys from a PyObjC application. Also demonstrates how to use a NSApplication subclass. - Key-Value Observing support is now automatic in Python classes that descend from ``NSObject``, unless they implement a custom ``willChangeValueForKey:``, ``didChangeValueForKey:``, or ``__useKVO__`` is not True. This allows ``self.foo = 1`` to automatically trigger notifications. This works in all cases, whether ``foo`` is a ``property``, ``ivar``, or just in the ``__dict__``. - New Inject folder in Examples, with an InjectInterpreter example that will inject a GUI Python interpreter into any process. - New ``objc.inject()`` function for Mac OS X 10.3 and later, allows an arbitrary bundle to be loaded into another process using mach_inject. - ``objc.classAddMethods`` now recognizes and supports classmethods. - GC is now correctly implemented for struct wrappers. - The ``NSNumber`` bridge has been removed, now you will get ``NSNumber`` instances across the bridge instead of a Python representation. - ``PyObjCTools.AppHelper.runEventLoop()`` will now bring your application to the front at startup when using pdb mode for convenience. - ``objc.loadBundle()`` no longer filters the class list. This solves a few potential issues and shaves off about 1/3rd of the overhead of ``python -c "import AppKit"``. - ``PyObjCTools.AppHelper.runEventLoop()`` no longer breaks on pure Objective-C exceptions. Most exceptions of this variety are more like warnings, and there is nothing that can be done them anyway. - ``PyObjCTools.AppHelper.runEventLoop()`` now installs the interrupt handler and verbose exception logging when using pdb, either explicitly or by the USE_PDB environment variable. - There is now a fast path for the ``NSString``/``unicode`` bridge when ``Py_UNICODE_SIZE`` is 2. This is the default setting for Python. - The default selector signature will have a void return value unless a "return" statement with an argument is used in the bytecode. In that case, it will default to an object return value. - ``__bundle_hack__`` is no longer necessary, py2app now sets a different environment variable to the current plugin during execution, and a hack is installed to ``NSBundle`` so that classes may respond to requests for their bundle with the ``+bundleForClass`` method. The class builder adds a default implementation of this to Python classes if this environment variable is set. - Added ``objc.currentBundle()``, which is equivalent to ``NSBundle.mainBundle()`` except after loading a plug-in. Makes it easier to load nib files. - ``PyObjCTools.NibClassBuilder.extractClasses()`` now uses ``objc.currentBundle()`` instead of ``NSBundle.mainBundle()``. This makes plugins less of a hassle to develop and allows identical code to be used for application or plugin development. - ``objc.registerPlugin()`` and ``objc.pluginBundle()`` are now deprecated as they are no longer useful. - It is now possible to subclass a class that implements ``copyWithZone:`` without setting ``__slots__`` to ``()``. From dave.opstad at monotypeimaging.com Fri Mar 18 21:59:44 2005 From: dave.opstad at monotypeimaging.com (Dave Opstad) Date: Fri Mar 18 21:59:49 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: Message-ID: Well, the good news is that I was able to build and launch my app with 0.1.8 where I wasn't with 0.1.7 (see my posting to this list on March 7). On my development system I double-click the app and it launches and runs fine. The bad news, though, is that the app doesn't launch on a system that doesn't have Tcl already installed, even though the Tcl framework got correctly bundled in the app itself. The same error ("Can't find a usable init.tcl") is happening as I described back on the 7th. I checked, and the init.tcl is indeed in the Tcl.framework within the app's Contents directory. Any ideas what could be causing it to not find the init.tcl bundled in the app? Thanks! Dave Opstad From bob at redivi.com Fri Mar 18 22:21:47 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 18 22:22:16 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: References: Message-ID: On Mar 18, 2005, at 3:59 PM, Dave Opstad wrote: > Well, the good news is that I was able to build and launch my app with > 0.1.8 > where I wasn't with 0.1.7 (see my posting to this list on March 7). On > my > development system I double-click the app and it launches and runs > fine. > > The bad news, though, is that the app doesn't launch on a system that > doesn't have Tcl already installed, even though the Tcl framework got > correctly bundled in the app itself. The same error ("Can't find a > usable > init.tcl") is happening as I described back on the 7th. I checked, and > the > init.tcl is indeed in the Tcl.framework within the app's Contents > directory. > > Any ideas what could be causing it to not find the init.tcl bundled in > the > app? You'll have to ask the Tcl people.. it really has nothing to do with Python, and I don't know how Tcl bootstraps itself. -bob From dave.opstad at monotypeimaging.com Fri Mar 18 22:26:02 2005 From: dave.opstad at monotypeimaging.com (Dave Opstad) Date: Fri Mar 18 22:26:05 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: Message-ID: > You'll have to ask the Tcl people.. it really has nothing to do with > Python, and I don't know how Tcl bootstraps itself. This might be my misunderstanding; if so, I'm sorry. I thought that py2app was intended (among many other things) to make Python/Tkinter apps that could work on OS X systems where neither Python nor Tcl/Tk/Tkinter were installed. If that's not the case, I'll take a different approach. Dave From rkern at ucsd.edu Fri Mar 18 22:26:37 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri Mar 18 22:26:44 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: References: Message-ID: <423B478D.20703@ucsd.edu> Dave Opstad wrote: > Well, the good news is that I was able to build and launch my app with 0.1.8 > where I wasn't with 0.1.7 (see my posting to this list on March 7). On my > development system I double-click the app and it launches and runs fine. > > The bad news, though, is that the app doesn't launch on a system that > doesn't have Tcl already installed, even though the Tcl framework got > correctly bundled in the app itself. The same error ("Can't find a usable > init.tcl") is happening as I described back on the 7th. I checked, and the > init.tcl is indeed in the Tcl.framework within the app's Contents directory. > > Any ideas what could be causing it to not find the init.tcl bundled in the > app? I have occasionally run into a similar problem with py2app'd Tkinter programs. Unfortunately I haven't had the time to track it down and submit a bug report. I believe the culprit is a missing symlink in the included Tcl.framework. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Fri Mar 18 22:33:09 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 18 22:33:15 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: References: Message-ID: <6a05e6ea4745980cdd0be50cd77feacd@redivi.com> On Mar 18, 2005, at 4:26 PM, Dave Opstad wrote: >> You'll have to ask the Tcl people.. it really has nothing to do with >> Python, and I don't know how Tcl bootstraps itself. > > This might be my misunderstanding; if so, I'm sorry. I thought that > py2app > was intended (among many other things) to make Python/Tkinter apps that > could work on OS X systems where neither Python nor Tcl/Tk/Tkinter were > installed. If that's not the case, I'll take a different approach. Yes, that is one of its goals, but honestly, I don't care enough to research it myself. I don't write Tkinter applications. It's up to the community to figure out what's wrong with Tcl and tell me how to fix it. Either that, or find a way to make me care (i.e. monetary bribe). -bob From rkern at ucsd.edu Fri Mar 18 22:45:26 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri Mar 18 22:45:38 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: <423B478D.20703@ucsd.edu> References: <423B478D.20703@ucsd.edu> Message-ID: <423B4BF6.901@ucsd.edu> Robert Kern wrote: > Dave Opstad wrote: >> Any ideas what could be causing it to not find the init.tcl bundled in >> the >> app? > > > I have occasionally run into a similar problem with py2app'd Tkinter > programs. Unfortunately I haven't had the time to track it down and > submit a bug report. I believe the culprit is a missing symlink in the > included Tcl.framework. And I can't reproduce said condition with 0.1.8. Do check the included framework for missing symlinks, though. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Fri Mar 18 22:50:24 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 18 22:50:31 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: <423B4BF6.901@ucsd.edu> References: <423B478D.20703@ucsd.edu> <423B4BF6.901@ucsd.edu> Message-ID: On Mar 18, 2005, at 4:45 PM, Robert Kern wrote: > Robert Kern wrote: >> Dave Opstad wrote: > >>> Any ideas what could be causing it to not find the init.tcl bundled >>> in the >>> app? >> I have occasionally run into a similar problem with py2app'd Tkinter >> programs. Unfortunately I haven't had the time to track it down and >> submit a bug report. I believe the culprit is a missing symlink in >> the included Tcl.framework. > > And I can't reproduce said condition with 0.1.8. Do check the included > framework for missing symlinks, though. ktrace/kdump is probably a good way to figure out what it wants. In fact, it's how I solved a problem very similar to this, and I distilled the experience into a blog entry: http://bob.pythonmac.org/archives/2005/02/04/advanced-debugging- techniques-ktrace/ -bob From dave.opstad at monotypeimaging.com Fri Mar 18 23:37:30 2005 From: dave.opstad at monotypeimaging.com (Dave Opstad) Date: Fri Mar 18 23:37:36 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: Message-ID: > ktrace/kdump is probably a good way to figure out what it wants. Yes, it was quite helpful -- I found the problem. TThe symbolic links within the framework (things like Resources -> Versions/Current/Resources) were all gone when I copied the application to another machine. The problem was I used a non-Unix-aware server as an intermediary for the copy, which means all the symbolic links just vanished. Arrgggghh. Anyway, when I did a direct Mac-to-Mac transfer, the app worked fine. Thanks for the help! Dave From bob at redivi.com Fri Mar 18 23:46:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 18 23:46:48 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: References: Message-ID: <4936cf197b80cf925bc7905f97862ca2@redivi.com> On Mar 18, 2005, at 17:37, Dave Opstad wrote: >> ktrace/kdump is probably a good way to figure out what it wants. > > Yes, it was quite helpful -- I found the problem. TThe symbolic links > within > the framework (things like Resources -> Versions/Current/Resources) > were all > gone when I copied the application to another machine. The problem was > I > used a non-Unix-aware server as an intermediary for the copy, which > means > all the symbolic links just vanished. Arrgggghh. > > Anyway, when I did a direct Mac-to-Mac transfer, the app worked fine. And this is why Mac applications are distributed in disk images, sit files, tarballs, or 10.3+-Finder-created-zip files... Actually, I'm not totally sure I trust the 10.3+ zip files for symlinks. Disk images are the popular solution. Some later version of py2app will probably have an option for creating a dmg out of your application. -bob From charles.hartman at conncoll.edu Sat Mar 19 00:17:46 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat Mar 19 00:25:44 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: <4936cf197b80cf925bc7905f97862ca2@redivi.com> References: <4936cf197b80cf925bc7905f97862ca2@redivi.com> Message-ID: <82f763e951aea29634b38ac475d7fe44@conncoll.edu> On Mar 18, 2005, at 5:46 PM, Bob Ippolito wrote: > Actually, I'm not totally sure I trust the 10.3+ zip files for > symlinks. Disk images are the popular solution. Some later version > of py2app will probably have an option for creating a dmg out of your > application. Yes please! Charles Hartman From OpenMacNews at speakeasy.net Sat Mar 19 20:42:08 2005 From: OpenMacNews at speakeasy.net (OpenMacNews) Date: Sat Mar 19 20:42:15 2005 Subject: [Pythonmac-SIG] python make failing: "ImportError: No module named MacOS" Message-ID: <2ABF10D7BBA08ECBBFD5D3D7@tiedgar.internal.presence-group.net> Hi all, i'm building a local instance of Python v2.4.1c2 on a 'virgin install' of fully-updated OSX 10.3.8. w/ XCode 1.5 'configure' is successful w/ ./configure \ --with-prefix=/usr/local/pythontest \ --enable-framework=/usr/local/pythonframe \ --with-threads \ --with-cxx=g++ \ --enable-ipv6 \ --enable-toolbox-glue but a subsequent make frameworkinstall FAILS at: /usr/bin/install -c -m 644 ./Mac/Tools/IDE/Wtraceback.py /usr/local/pythonframe/Python.framework/Versions/2.4/Mac/Tools/IDE /usr/bin/install -c -m 644 ./Mac/Tools/IDE/Wwindows.py /usr/local/pythonframe/Python.framework/Versions/2.4/Mac/Tools/IDE ./python.exe ./Mac/scripts/cachersrc.py -v /usr/local/pythonframe/Python.framework/Versions/2.4/lib/python2.4/plat-mac /usr/local/pythonframe/Python.framework/Versions/2.4/Mac/Tools Traceback (most recent call last): File "./Mac/scripts/cachersrc.py", line 7, in ? import macresource File "/Volumes/g4_PORTS/usr/ports/Python-2.4.1c2/Lib/plat-mac/macresource.py", line 6, in ? import MacOS ImportError: No module named MacOS make[1]: *** [installmacsubtree] Error 1 make: *** [frameworkinstallmaclib] Error 2 I've found limited prior reference to this "ImportError: No module named MacOS "), @: http://mail.python.org/pipermail/pythonmac-sig/2004-March/010709.html but, afaik, there was no resolution ... any suggestions as to what's broken here? thx! richard From bob at redivi.com Sat Mar 19 22:51:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 19 22:51:46 2005 Subject: [Pythonmac-SIG] python make failing: "ImportError: No module named MacOS" In-Reply-To: <2ABF10D7BBA08ECBBFD5D3D7@tiedgar.internal.presence-group.net> References: <2ABF10D7BBA08ECBBFD5D3D7@tiedgar.internal.presence-group.net> Message-ID: On Mar 19, 2005, at 2:42 PM, OpenMacNews wrote: > Hi all, > > i'm building a local instance of Python v2.4.1c2 on a 'virgin install' > of fully-updated OSX 10.3.8. w/ XCode 1.5 > > 'configure' is successful w/ > > > ./configure \ > --with-prefix=/usr/local/pythontest \ > --enable-framework=/usr/local/pythonframe \ > --with-threads \ > --with-cxx=g++ \ > --enable-ipv6 \ > --enable-toolbox-glue > > but a subsequent > > make frameworkinstall > > FAILS at: > > /usr/bin/install -c -m 644 ./Mac/Tools/IDE/Wtraceback.py > /usr/local/pythonframe/Python.framework/Versions/2.4/Mac/Tools/IDE > /usr/bin/install -c -m 644 ./Mac/Tools/IDE/Wwindows.py > /usr/local/pythonframe/Python.framework/Versions/2.4/Mac/Tools/IDE > ./python.exe ./Mac/scripts/cachersrc.py -v > /usr/local/pythonframe/Python.framework/Versions/2.4/lib/python2.4/ > plat-mac > /usr/local/pythonframe/Python.framework/Versions/2.4/Mac/Tools > Traceback (most recent call last): > File "./Mac/scripts/cachersrc.py", line 7, in ? > import macresource > File > "/Volumes/g4_PORTS/usr/ports/Python-2.4.1c2/Lib/plat-mac/ > macresource.py", line 6, in ? > import MacOS > ImportError: No module named MacOS > make[1]: *** [installmacsubtree] Error 1 > make: *** [frameworkinstallmaclib] Error 2 > > I've found limited prior reference to this "ImportError: No module > named MacOS > "), @: > > http://mail.python.org/pipermail/pythonmac-sig/2004-March/010709.html > > but, afaik, there was no resolution ... > > any suggestions as to what's broken here? Works here, with 2.4.1c1 anyway.. but there have been no relevant changes that I know of. Most of the arguments you specify to configure are already on by default or have no effect. The --prefix argument has no effect, the symlinks are hardcoded to be installed to /usr/local/bin, and the framework contains everything else. I'm not totally sure that enable-toolbox-glue is on by default, but I think it is. I used it anyway: % mkdir -p ~/src/Python-2.4.1c1/_panther % cd ~/src/Python-2.4.1c1/_panther % ../configure \ --enable-toolbox-glue \ --enable-framework=/Users/bob/python-2.4.1c1/Frameworks % make % sudo make frameworkinstall worked fine for me. -bob From OpenMacNews at speakeasy.net Sat Mar 19 23:34:19 2005 From: OpenMacNews at speakeasy.net (OpenMacNews) Date: Sat Mar 19 23:34:26 2005 Subject: [Pythonmac-SIG] python make failing: "ImportError: No module named MacOS" In-Reply-To: References: <2ABF10D7BBA08ECBBFD5D3D7@tiedgar.internal.presence-group.net> Message-ID: <580BA579A1985E21E21D2974@tiedgar.internal.presence-group.net> hi bob, >> any suggestions as to what's broken here? > > Works here, with 2.4.1c1 anyway. > but there have been no relevant changes that I know of. i dropeed back and tried it with c1 as well ... same prob 4 me. argh > Most of the arguments you specify to configure are already > on by default or have no effect. The --prefix argument has no effect, the > symlinks are hardcoded to be installed to /usr/local/bin, and the framework > contains everything else. well, that's particularly annoying ... then why offer the --prefix arg in the first place? just for NON-framework installs? > I'm not totally sure that enable-toolbox-glue is > on by default, but I think it is. I used it anyway: > > % mkdir -p ~/src/Python-2.4.1c1/_panther > % cd ~/src/Python-2.4.1c1/_panther > % ../configure \ > --enable-toolbox-glue \ > --enable-framework=/Users/bob/python-2.4.1c1/Frameworks > % make > % sudo make frameworkinstall > > worked fine for me. ok, so something's missing on my system ... which is particularly odd since its a clean/complete install. hmmmm .... anyone else, perhaps with ideas? or should i take this over the the dev list? cheers, richard From bob at redivi.com Sat Mar 19 23:52:43 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 19 23:52:50 2005 Subject: [Pythonmac-SIG] python make failing: "ImportError: No module named MacOS" In-Reply-To: <580BA579A1985E21E21D2974@tiedgar.internal.presence-group.net> References: <2ABF10D7BBA08ECBBFD5D3D7@tiedgar.internal.presence-group.net> <580BA579A1985E21E21D2974@tiedgar.internal.presence-group.net> Message-ID: On Mar 19, 2005, at 5:34 PM, OpenMacNews wrote: >> Most of the arguments you specify to configure are already >> on by default or have no effect. The --prefix argument has no >> effect, the >> symlinks are hardcoded to be installed to /usr/local/bin, and the >> framework >> contains everything else. > > well, that's particularly annoying ... > > then why offer the --prefix arg in the first place? just for > NON-framework installs? Yes, --prefix is for non-framework installs. If you read the docs for frameworks, you'll see that it's only "lightly tested" with an alternate path. You may have more luck if you just use the defaults. The docs also say that you can move the framework later. >> I'm not totally sure that enable-toolbox-glue is >> on by default, but I think it is. I used it anyway: >> >> % mkdir -p ~/src/Python-2.4.1c1/_panther >> % cd ~/src/Python-2.4.1c1/_panther >> % ../configure \ >> --enable-toolbox-glue \ >> --enable-framework=/Users/bob/python-2.4.1c1/Frameworks >> % make >> % sudo make frameworkinstall >> >> worked fine for me. > > ok, so something's missing on my system ... which is particularly odd > since its a clean/complete install. > > hmmmm .... > > anyone else, perhaps with ideas? or should i take this over the the > dev list? I doubt there's anyone on dev that would be able to help you that isn't also subscribed here. You'll probably just have to wait, or dig deeper into the output of make to find out why MacOS isn't building, or isn't loading properly. I suspect that you may have some weird environment variables set, maybe PYTHONPATH, maybe DYLD_*, etc. You may also want to make sure that the MACOSX_DEPLOYMENT_TARGET environment variable is set to 10.3. The only thing I left out is that I have MACOSX_DEPLOYMENT_TARGET set to 10.3 in my rc. -bob From bob at redivi.com Sat Mar 19 23:58:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 19 23:58:28 2005 Subject: [Pythonmac-SIG] python make failing: "ImportError: No module named MacOS" In-Reply-To: References: <2ABF10D7BBA08ECBBFD5D3D7@tiedgar.internal.presence-group.net> <580BA579A1985E21E21D2974@tiedgar.internal.presence-group.net> Message-ID: <478f1c6231217ba6159a65e312597cdd@redivi.com> On Mar 19, 2005, at 5:52 PM, Bob Ippolito wrote: > On Mar 19, 2005, at 5:34 PM, OpenMacNews wrote: > >>> Most of the arguments you specify to configure are already >>> on by default or have no effect. The --prefix argument has no >>> effect, the >>> symlinks are hardcoded to be installed to /usr/local/bin, and the >>> framework >>> contains everything else. >> >> well, that's particularly annoying ... >> >> then why offer the --prefix arg in the first place? just for >> NON-framework installs? > > Yes, --prefix is for non-framework installs. If you read the docs for > frameworks, you'll see that it's only "lightly tested" with an > alternate path. You may have more luck if you just use the defaults. > The docs also say that you can move the framework later. Oh, and note that if you DO move the framework, you will need to run install_name_tool over it, the python executable, and possibly ALL of the extensions if MACOSX_DEPLOYMENT_TARGET was set to 10.2 (or maybe if not set at all, I haven't confirmed the default behavior when not set). -bob From OpenMacNews at speakeasy.net Sun Mar 20 00:22:48 2005 From: OpenMacNews at speakeasy.net (OpenMacNews) Date: Sun Mar 20 00:22:55 2005 Subject: [Pythonmac-SIG] python make failing: "ImportError: No module named MacOS" In-Reply-To: References: <2ABF10D7BBA08ECBBFD5D3D7@tiedgar.internal.presence-group.net> <580BA579A1985E21E21D2974@tiedgar.internal.presence-group.net> Message-ID: <0A577602DD2604264DA59D95@tiedgar.internal.presence-group.net> hi bob, >> then why offer the --prefix arg in the first place? just for >> NON-framework installs? > > Yes, --prefix is for non-framework installs. If you read the docs for > frameworks, you'll see that it's only "lightly tested" with an alternate > path. You may have more luck if you just use the defaults. The docs also > say that you can move the framework later. ah ... >> anyone else, perhaps with ideas? or should i take this over the the dev list? > > I doubt there's anyone on dev that would be able to help you that isn't also > subscribed here. fair nuf. always best to ask, i find ... cuz 'they' all get pretty ornery if ya don' belong ;-D > You'll probably just have to wait, beer has been opened ... > or dig deeper into the output of make to find out why MacOS isn't building, > or isn't loading properly. yup. 1st gotta figure out 'what' MacOS 'is' ... > I suspect that you may have some weird environment variables set, maybe > PYTHONPATH empty > maybe DYLD_*, etc. changes, but at the moment, % echo $DYLD_LIBRARY_PATH /usr/local/berkeley-db/lib: /usr/local/cyrus-sasl/lib: /usr/local/ssl/lib: /usr/local/lib: /System/Library/Frameworks: /usr/lib: /usr/X11R6/lib tried moving/removing the '/System/Library/Frameworks', to no avail ... > You may also want to make sure that the > MACOSX_DEPLOYMENT_TARGET environment variable is set to 10.3. The only thing > I left out is that I have MACOSX_DEPLOYMENT_TARGET set to 10.3 in my rc. % echo $MACOSX_DEPLOYMENT_TARGET 10.3 > Oh, and note that if you DO move the framework, you will need to run > install_name_tool over it, the python executable, and possibly ALL of the > extensions if MACOSX_DEPLOYMENT_TARGET was set to 10.2 (or maybe if not set > at all, I haven't confirmed the default behavior when not set). this i need to remember ... thanks again. now to dig & wait =) richard From bob at redivi.com Sun Mar 20 00:39:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Mar 20 00:39:29 2005 Subject: [Pythonmac-SIG] python make failing: "ImportError: No module named MacOS" In-Reply-To: <0A577602DD2604264DA59D95@tiedgar.internal.presence-group.net> References: <2ABF10D7BBA08ECBBFD5D3D7@tiedgar.internal.presence-group.net> <580BA579A1985E21E21D2974@tiedgar.internal.presence-group.net> <0A577602DD2604264DA59D95@tiedgar.internal.presence-group.net> Message-ID: On Mar 19, 2005, at 6:22 PM, OpenMacNews wrote: >> or dig deeper into the output of make to find out why MacOS isn't >> building, >> or isn't loading properly. > > yup. 1st gotta figure out 'what' MacOS 'is' ... It's part of the toolbox glue. >> maybe DYLD_*, etc. > > changes, but at the moment, > > % echo $DYLD_LIBRARY_PATH > /usr/local/berkeley-db/lib: /usr/local/cyrus-sasl/lib: > /usr/local/ssl/lib: /usr/local/lib: /System/Library/Frameworks: > /usr/lib: /usr/X11R6/lib > > tried moving/removing the '/System/Library/Frameworks', to no avail ... Setting DYLD_* like this is really horribly BAD. You should ONLY set DYLD variables in very specific circumstances when doing development (i.e. when testing the a framework in the build dir). Doing anything to /System/* is BAD. -bob From rkern at ucsd.edu Sun Mar 20 05:32:16 2005 From: rkern at ucsd.edu (Robert Kern) Date: Sun Mar 20 05:32:25 2005 Subject: [Pythonmac-SIG] ANN: pygame 1.7.0 for Mac OS X 10.3 In-Reply-To: <407abe3c7789a9ac58cf6d64791ca250@redivi.com> References: <31ac537c0503110604476958ee@mail.gmail.com> <407abe3c7789a9ac58cf6d64791ca250@redivi.com> Message-ID: <423CFCD0.3060805@ucsd.edu> Bob Ippolito wrote: > > On Mar 11, 2005, at 9:04, Troy Rollins wrote: > >> I've packaged what >> >>> should be pygame 1.7.0 for Mac OS X 10.3 users. >>> It is available from pythonmac.org packages at: >>> http://pythonmac.org/packages/ >> >> >> On my OSX.3.8, the installer starts with a dialog which says "The >> installationCheck tool was either not readable or not executable." And >> then it offers only to close, but will not complete running the >> installer. > > > Works here, don't know what your problem is. Using /usr/bin/unzip to unzip the package seems to strip the executable flags from these files. Stuffit Expander seems to work fine. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From daniel.keep at gmail.com Sun Mar 20 06:59:35 2005 From: daniel.keep at gmail.com (Daniel Keep) Date: Sun Mar 20 06:59:47 2005 Subject: [Pythonmac-SIG] ETA on MacPython 2.4? Message-ID: <423D1147.1030403@gmail.com> Hi all. Please be gentle--I use a PC. I'm doing my third-year computer science project at university, and we're in the early stages of requirements testing. That said, I'm also trying to extol the virtues of Python upon the group, as I honestly believe it will be the best language for our project. But there's always a fly in the ointment: most of us are using PCs (I run Windows+coLinux, and another member has Windows+BSD), but one member uses Mac OSX. As a result, cross-platform compatibility is a big issue for our program. Obviously, Python is great in this respect, but we wanted to use Python 2.4. This is mainly because I happen to really like generator expressions and decorators . Anyway, I was wondering if anyone knew in even a vague sense when MacPython 2.4.1 will be released. I understand that Jack is waiting on the PythonLabs 2.4.1 release, but even having a reasonably stable preview release to work with in the meantime would be good. Will 2.4.1 be out within the next few months, or should we start looking at 2.3 instead? Thanks for your time and patience with a heathen PC user. -- Daniel -- v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/ From mdunn at cantares.on.ca Sun Mar 20 21:36:40 2005 From: mdunn at cantares.on.ca (Michael Dunn) Date: Sun Mar 20 21:36:52 2005 Subject: [Pythonmac-SIG] OS9/2.1 IDE problem In-Reply-To: References: <20030324170003.11302.66298.Mailman@mail.python.org> Message-ID: Yeah, I'm using old stuff, I know. Having a weird problem. I've defined a few functions for a program and put them in a separate file. In my main program I write "from filename import *". When I run as an applet, everything seems to work. When I run from the IDE, it appears that ONLY THE FIRST function is imported. And guess what? I just solved the problem. I ran the function defs from the IDE, then my main program. It worked. Still seems a bit odd... Michael From bob at redivi.com Sun Mar 20 21:58:49 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Mar 20 22:00:24 2005 Subject: [Pythonmac-SIG] ETA on MacPython 2.4? In-Reply-To: <423D1147.1030403@gmail.com> References: <423D1147.1030403@gmail.com> Message-ID: On Mar 20, 2005, at 12:59 AM, Daniel Keep wrote: > Hi all. Please be gentle--I use a PC. > > I'm doing my third-year computer science project at university, and > we're in the early stages of requirements testing. That said, I'm > also trying to extol the virtues of Python upon the group, as I > honestly believe it will be the best language for our project. > > But there's always a fly in the ointment: most of us are using PCs (I > run Windows+coLinux, and another member has Windows+BSD), but one > member uses Mac OSX. As a result, cross-platform compatibility is a > big issue for our program. Obviously, Python is great in this > respect, but we wanted to use Python 2.4. This is mainly because I > happen to really like generator expressions and decorators . > > Anyway, I was wondering if anyone knew in even a vague sense when > MacPython 2.4.1 will be released. I understand that Jack is waiting > on the PythonLabs 2.4.1 release, but even having a reasonably stable > preview release to work with in the meantime would be good. Will > 2.4.1 be out within the next few months, or should we start looking at > 2.3 instead? > > Thanks for your time and patience with a heathen PC user. I can't speak for when Jack is going to distribute a Python 2.4.1 binary release, but it compiles fine, and the Xcode developers tools are free, so there isn't much in your way of building your own Python 2.4.1. -bob From jim at monkeybiz.stanford.edu Sun Mar 20 22:26:24 2005 From: jim at monkeybiz.stanford.edu (Jim Muller) Date: Sun Mar 20 22:26:30 2005 Subject: [Pythonmac-SIG] mod_python / lib compatibility question Message-ID: Hi, A question from a new mod_python user: When I run within an otherwise working apache2/mod_python, if my script imports MySQLdb I get a dyld compability version error: File "/Users/jim/Sites/WatchEvents.py", line 97, in ? import MySQLdb, pickle File "/opt/local/lib/python2.4/site-packages/MySQLdb/__init__.py", line 27, in ? import _mysql ImportError: Failure linking new module: /opt/local/lib/libssl.0.9.7.dylib: dyld: /opt/local/apache2/bin/httpd version mismatch for library: /opt/local/lib/libssl.0.9.7.dylib (compatibility version of user: 0.9.7 greater than library's version: 0.9.0) Now, /opt/local/lib/libssl.0.9.7, like /opt/local/apache2/bin/httpd, and the installed copy of _mysql.so report having "(compatibility version 0.9.0, current version 0.9.7)". [Perhaps it matters that /usr/local/lib/libssl.0.9.7 has "(compatibility version 0.9.7, current version 0.9.7)", but I don't see where it's used] As I understand it [from man ld] this sort of dyld error should only occur when the program compatibility version is > the lib version -- yet the lib is version 0.9.7, >= all the compatibility versions in play. Can anyone see what I'm missing? I should point out that MySQLdb was installed in the usual way using setup.py, and I did redo this after fully updating the darwinports tree and rebuilding apache2. Apache2, mod_python, and python24 all come from darwinports. MySQLdb is of course installed, as is MySQL from Server Logistics. [Perhaps the MySQL version is the problem? Because the MySQL is not from darwinports, I had to hack the MySQLdb setup.py file to get it to use the darwinports version of libssl and thus have exactly the same compatibility version. Should I have hacked something more?] This is on lhe latest MacOS X 10.3.8. All these components work fine if I don't import MySQLdb, and MySQLdb works fine in the python interpreter. If anyone has any suggestions I'd greatly appreciate them. And BTW I'd be happy to link statically if that's doable/better/easier. Jim PS: according to locate (after running locate.update) the only libssl are: /Applications/Firefox.app/Contents/MacOS/libssl3.dylib /Applications/Navigator.app/Contents/MacOS/libssl3.dylib /opt/local/lib/libssl.0.9.7.dylib /opt/local/lib/libssl.0.dylib /opt/local/lib/libssl.a /opt/local/lib/libssl.dylib /opt/local/var/db/dports/software/openssl/0.9.7e_0/opt/local/lib/ libssl.0.9.7.dylib /opt/local/var/db/dports/software/openssl/0.9.7e_0/opt/local/lib/ libssl.0.dylib /opt/local/var/db/dports/software/openssl/0.9.7e_0/opt/local/lib/ libssl.a /opt/local/var/db/dports/software/openssl/0.9.7e_0/opt/local/lib/ libssl.dylib /usr/lib/libssl.0.9.7.dylib /usr/lib/libssl.0.9.dylib /usr/lib/libssl.dylib /usr/libexec/gdb/symfiles/libssl.0.9.7.dylib.syms /usr/libexec/gdb/symfiles/libssl.0.9.dylib.syms /usr/libexec/httpd/libssl.so -- Jim From just at letterror.com Sun Mar 20 23:04:26 2005 From: just at letterror.com (Just van Rossum) Date: Sun Mar 20 23:04:31 2005 Subject: [Pythonmac-SIG] OS9/2.1 IDE problem In-Reply-To: Message-ID: Michael Dunn wrote: > Yeah, I'm using old stuff, I know. > > Having a weird problem. I've defined a few functions for a > program and put them in a separate file. In my main program I write > "from filename import *". > > When I run as an applet, everything seems to work. When I run > from the IDE, it appears that ONLY THE FIRST function is imported. > > And guess what? I just solved the problem. I ran the function > defs from the IDE, then my main program. It worked. Still seems a > bit odd... Sounds like you have a circular import? Module A importing module B importing module A? Just From mdunn at cantares.on.ca Sun Mar 20 23:09:41 2005 From: mdunn at cantares.on.ca (Michael Dunn) Date: Sun Mar 20 23:09:55 2005 Subject: [Pythonmac-SIG] Another odd question re breaks/returns Message-ID: I have a double-nested 'for' loop in a function. I can't use 'break' to get out of BOTH loops from the inner loop. Can I simply put a 'return' statement in the inner loop, or will this completely mess up the stack or something? thanks! Michael From mdunn at cantares.on.ca Mon Mar 21 00:00:02 2005 From: mdunn at cantares.on.ca (Michael Dunn) Date: Mon Mar 21 00:00:31 2005 Subject: [Pythonmac-SIG] OS9/2.1 IDE problem In-Reply-To: References: Message-ID: At 11:04 PM +0100 2005/3/20, Just van Rossum wrote: >Michael Dunn wrote: > >> Yeah, I'm using old stuff, I know. >> >> Having a weird problem. I've defined a few functions for a >> program and put them in a separate file. In my main program I write >> "from filename import *". >> >> When I run as an applet, everything seems to work. When I run >> from the IDE, it appears that ONLY THE FIRST function is imported. >> >> And guess what? I just solved the problem. I ran the function >> defs from the IDE, then my main program. It worked. Still seems a >> bit odd... > >Sounds like you have a circular import? Module A importing module B >importing module A? > >Just Nope. It's quite simple at the moment... Could it be something to do with an old pyo or pyc file being used in one instance but not the other? Michael From bob at redivi.com Mon Mar 21 00:02:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 21 00:02:45 2005 Subject: [Pythonmac-SIG] Another odd question re breaks/returns In-Reply-To: References: Message-ID: <61f6e96a74d8141d2681ec82867bc8e6@redivi.com> On Mar 20, 2005, at 5:09 PM, Michael Dunn wrote: > I have a double-nested 'for' loop in a function. I can't use > 'break' to get out of BOTH loops from the inner loop. Can I simply > put a 'return' statement in the inner loop, or will this completely > mess up the stack or something? return will work fine, assuming that's actually what you want to do... -bob From bob at redivi.com Mon Mar 21 00:01:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 21 00:02:47 2005 Subject: [Pythonmac-SIG] mod_python / lib compatibility question In-Reply-To: References: Message-ID: On Mar 20, 2005, at 4:26 PM, Jim Muller wrote: > A question from a new mod_python user: > > When I run within an otherwise working apache2/mod_python, if my > script imports MySQLdb I get a dyld compability version error: > > File "/Users/jim/Sites/WatchEvents.py", line 97, in ? > import MySQLdb, pickle > > File "/opt/local/lib/python2.4/site-packages/MySQLdb/__init__.py", > line 27, in ? > import _mysql > > ImportError: Failure linking new module: > /opt/local/lib/libssl.0.9.7.dylib: dyld: /opt/local/apache2/bin/httpd > version mismatch for library: /opt/local/lib/libssl.0.9.7.dylib > (compatibility version of user: 0.9.7 greater than library's version: > 0.9.0) This is a darwinports problem. If you ask over there, you'll get a good response as to what needs to be rebuilt in order to fix this. -bob From daniel.keep at gmail.com Mon Mar 21 02:47:48 2005 From: daniel.keep at gmail.com (Daniel Keep) Date: Mon Mar 21 02:47:47 2005 Subject: [Pythonmac-SIG] ETA on MacPython 2.4? In-Reply-To: References: <423D1147.1030403@gmail.com> Message-ID: <423E27C4.60502@gmail.com> Bob Ippolito wrote: > > On Mar 20, 2005, at 12:59 AM, Daniel Keep wrote: > >> Hi all. Please be gentle--I use a PC. >> >> I'm doing my third-year computer science project at university, and >> we're in the early stages of requirements testing. That said, I'm >> also trying to extol the virtues of Python upon the group, as I >> honestly believe it will be the best language for our project. >> >> But there's always a fly in the ointment: most of us are using PCs (I >> run Windows+coLinux, and another member has Windows+BSD), but one >> member uses Mac OSX. As a result, cross-platform compatibility is a >> big issue for our program. Obviously, Python is great in this >> respect, but we wanted to use Python 2.4. This is mainly because I >> happen to really like generator expressions and decorators . >> >> Anyway, I was wondering if anyone knew in even a vague sense when >> MacPython 2.4.1 will be released. I understand that Jack is waiting >> on the PythonLabs 2.4.1 release, but even having a reasonably stable >> preview release to work with in the meantime would be good. Will >> 2.4.1 be out within the next few months, or should we start looking >> at 2.3 instead? >> >> Thanks for your time and patience with a heathen PC user. > > > I can't speak for when Jack is going to distribute a Python 2.4.1 > binary release, but it compiles fine, and the Xcode developers tools > are free, so there isn't much in your way of building your own Python > 2.4.1. > > -bob > > Nothing except that I don't have a Mac :P I only ask because the guy with the Mac tried compiling it, but got a slew of compile errors. Not too sure why, but I'll tell him at least one person has gotten it to work. Thanks for the response. -- Daniel -- v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/ From rkern at ucsd.edu Mon Mar 21 04:02:44 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Mar 21 04:02:52 2005 Subject: [Pythonmac-SIG] bdist_mpkg zipdist and unzip(1) (was ANN: pygame 1.7.0 for Mac OS X 10.3) In-Reply-To: <423CFCD0.3060805@ucsd.edu> References: <31ac537c0503110604476958ee@mail.gmail.com> <407abe3c7789a9ac58cf6d64791ca250@redivi.com> <423CFCD0.3060805@ucsd.edu> Message-ID: <423E3954.8060801@ucsd.edu> Robert Kern wrote: > Using /usr/bin/unzip to unzip the package seems to strip the executable > flags from these files. Stuffit Expander seems to work fine. I've traced the problem to a deficiency in Python's zipfile (well, one could equally say that there is a deficiency in Info-Zip's code, but Python is still wrong regardless). I have attached a workaround patch to py2app. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter -------------- next part -------------- Index: src/bdist_mpkg/cmd_bdist_mpkg.py =================================================================== --- src/bdist_mpkg/cmd_bdist_mpkg.py (revision 426) +++ src/bdist_mpkg/cmd_bdist_mpkg.py (working copy) @@ -434,6 +434,15 @@ if os.path.splitext(fn)[1] == '.gz': compression= zipfile.ZIP_STORED z.write(fn, arcfn, compression) + + # ZipFile always marks the files' attributes to be interpreted as if + # they came from a Windows host. This interferes with some software + # (namely unzip(1) from Info-Zip) from extracting executables with the + # proper file attributes. So manually fix the appropriate attributes on + # each of the ZipInfo's to specify the host system as a UNIX. + for zinfo in z.filelist: + zinfo.create_system = 3 # UNIX + z.close() def copy_tree(self, infile, outfile, From dave.opstad at monotypeimaging.com Mon Mar 21 16:01:31 2005 From: dave.opstad at monotypeimaging.com (Dave Opstad) Date: Mon Mar 21 16:01:35 2005 Subject: [Pythonmac-SIG] Python at WWDC Message-ID: There's going to be a presentation at this year's WWDC on Python! The session topics were just released, and I noticed this one on Python: ----------------------------------------------------------------------- PyObjC is a bridge between Python and Objective-C. It allows you to write Python scripts that use and extend existing Objective-C class libraries, and most importantly, Cocoa libraries. Specific topics from the 1.2 release covered in this session are: py2app, macho_standalone, NSBundle features, KVO/KVC support, the new scanframework script, objc.inject(), and runtime editing. ----------------------------------------------------------------------- Just FYI... Dave From bob at redivi.com Mon Mar 21 16:16:09 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 21 16:16:23 2005 Subject: [Pythonmac-SIG] bdist_mpkg zipdist and unzip(1) (was ANN: pygame 1.7.0 for Mac OS X 10.3) In-Reply-To: <423E3954.8060801@ucsd.edu> References: <31ac537c0503110604476958ee@mail.gmail.com> <407abe3c7789a9ac58cf6d64791ca250@redivi.com> <423CFCD0.3060805@ucsd.edu> <423E3954.8060801@ucsd.edu> Message-ID: On Mar 20, 2005, at 10:02 PM, Robert Kern wrote: > Robert Kern wrote: > >> Using /usr/bin/unzip to unzip the package seems to strip the >> executable flags from these files. Stuffit Expander seems to work >> fine. > > I've traced the problem to a deficiency in Python's zipfile (well, > one could equally say that there is a deficiency in Info-Zip's > code, but Python is still wrong regardless). I have attached a > workaround patch to py2app. Thanks! Fixed in r427. -bob From Chris.Barker at noaa.gov Tue Mar 22 18:17:13 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Mar 22 18:16:24 2005 Subject: [Pythonmac-SIG] OT cvs version with OS-X 10.3? Message-ID: <42405319.4000600@noaa.gov> Hi all, Sorry for the OT question, but this is the only list I'm on with knowledgeable (about OS-X) and helpful folks. I just noticed that the cvs client I have on my box (which came with Apple's XCode tools) is version 1.10, which is pretty old, and lacks at least one feature I want (update -C). Has Apple provided and updated version? if so, how do I get it. If not, should I build from source, or use darwinports or something? thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Tue Mar 22 19:27:51 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 22 19:27:56 2005 Subject: [Pythonmac-SIG] OT cvs version with OS-X 10.3? In-Reply-To: <42405319.4000600@noaa.gov> References: <42405319.4000600@noaa.gov> Message-ID: On Mar 22, 2005, at 12:17 PM, Chris Barker wrote: > Sorry for the OT question, but this is the only list I'm on with > knowledgeable (about OS-X) and helpful folks. > > I just noticed that the cvs client I have on my box (which came with > Apple's XCode tools) is version 1.10, which is pretty old, and lacks > at least one feature I want (update -C). Has Apple provided and > updated version? if so, how do I get it. If not, should I build from > source, or use darwinports or something? Apple has not provided an updated CVS. Last I remember, building from source using the typical "./configure && make && sudo make install" dance works without a hitch. DarwinPorts has: cvs 1.11.19, devel/cvs-port (Variants: gssapi, proxy) -bob From jeremyconlin at mail.weber.edu Tue Mar 22 21:30:38 2005 From: jeremyconlin at mail.weber.edu (Jeremy Conlin) Date: Tue Mar 22 21:30:49 2005 Subject: [Pythonmac-SIG] Copying to clipboard (pasteboard) Message-ID: <5fbd027b4d27fb4c33b8a28c4fd0ffee@mail.weber.edu> I have a little python script that reads a text file and prints what it finds to the screen. Not everything it finds, of course, just the important stuff. Instead of printing to the screen, or in addition to printing to the screen, I would also like to copy the text to the clipboard so I can paste it in another application. Does anyone know how to do this? In my searching, I have found things like Carbon.Scrap, but it has very little documentation and so is of no help to me. Thanks, Jeremy From bob at redivi.com Tue Mar 22 21:59:42 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 22 21:59:47 2005 Subject: [Pythonmac-SIG] Copying to clipboard (pasteboard) In-Reply-To: <5fbd027b4d27fb4c33b8a28c4fd0ffee@mail.weber.edu> References: <5fbd027b4d27fb4c33b8a28c4fd0ffee@mail.weber.edu> Message-ID: <98dbf58badcba7d2d97bd61cc7a7cae9@redivi.com> On Mar 22, 2005, at 3:30 PM, Jeremy Conlin wrote: > I have a little python script that reads a text file and prints what > it finds to the screen. Not everything it finds, of course, just the > important stuff. Instead of printing to the screen, or in addition to > printing to the screen, I would also like to copy the text to the > clipboard so I can paste it in another application. Does anyone know > how to do this? > > In my searching, I have found things like Carbon.Scrap, but it has > very little documentation and so is of no help to me. One easy way is to just use the pbcopy command line tool: #!/usr/bin/env python import os out = os.popen('/usr/bin/pbcopy', 'w') out.write('my text to put on clipboard') out.close() Another way would be to use PyObjC, NSPasteboard, etc. /usr/bin/pbcopy and pbpaste are written in Objective-C using this class. Using that method, you could do things other than ascii, rtf, or postscript. -bob From Martina at Oefelein.de Tue Mar 22 22:01:48 2005 From: Martina at Oefelein.de (Martina Oefelein) Date: Tue Mar 22 22:01:51 2005 Subject: [Pythonmac-SIG] Copying to clipboard (pasteboard) In-Reply-To: <5fbd027b4d27fb4c33b8a28c4fd0ffee@mail.weber.edu> References: <5fbd027b4d27fb4c33b8a28c4fd0ffee@mail.weber.edu> Message-ID: <7c04aa702645d5dcfd74fe4c269c12dc@Oefelein.de> Hi Jeremy: > I have a little python script that reads a text file and prints what > it finds to the screen. Not everything it finds, of course, just the > important stuff. Instead of printing to the screen, or in addition to > printing to the screen, I would also like to copy the text to the > clipboard so I can paste it in another application. Does anyone know > how to do this? just pipe the output of your script into pbcopy, for example: $ python myscript.py | pbcopy ciao Martina From redhatdude at gmail.com Tue Mar 22 22:09:40 2005 From: redhatdude at gmail.com (Caleb Land) Date: Tue Mar 22 22:09:44 2005 Subject: [Pythonmac-SIG] Reading Finder Labels on Folders Message-ID: Hello, I'm writing a backup rsync script in python (who hasn't?), but I want to be able to specify directories and files to exclude in the backup based on the file/folder's label color in the finder. I don't know anything about Carbon but I managed to scrape together code to read the label color of files: def getFileLabel(path): filespec = Carbon.File.FSSpec(path) if not os.path.isdir(path): finfo = filespec.FSpGetFInfo() else: finfo = filespec.FSpGetFInfo() return labels[getLabelNumber(finfo.Flags)] The problem is that this doesn't work on directories. Is there a way I can read the label on folders from python? Thanks. By the way, if anybody wants my script when I'm done with it just mail me and I'll send you a copy. -- Caleb Land (RedHatDude@gmail.com) From dmschwarz at urgrad.rochester.edu Wed Mar 23 00:29:35 2005 From: dmschwarz at urgrad.rochester.edu (Doug Schwarz) Date: Wed Mar 23 00:29:40 2005 Subject: [Pythonmac-SIG] Copying to clipboard (pasteboard) In-Reply-To: <5fbd027b4d27fb4c33b8a28c4fd0ffee@mail.weber.edu> References: <5fbd027b4d27fb4c33b8a28c4fd0ffee@mail.weber.edu> Message-ID: <4536266a28b8fd843de89b6b13ac0ee7@urgrad.rochester.edu> On Mar 22, 2005, at 3:30 PM, Jeremy Conlin wrote: > I have a little python script that reads a text file and prints what > it finds to the screen. Not everything it finds, of course, just the > important stuff. Instead of printing to the screen, or in addition to > printing to the screen, I would also like to copy the text to the > clipboard so I can paste it in another application. Does anyone know > how to do this? > > In my searching, I have found things like Carbon.Scrap, but it has > very little documentation and so is of no help to me. > > Thanks, > Jeremy I figured out how to do this with a lot of trial and error. You can use Carbon or AppKit/Foundation. ------------------------------------------------- import Carbon.Scrap, AppKit, Foundation def clipcopy(arg): Carbon.Scrap.ClearCurrentScrap() scrap = Carbon.Scrap.GetCurrentScrap() scrap.PutScrapFlavor('TEXT', 0, arg) def clippaste(): scrap = Carbon.Scrap.GetCurrentScrap() try: return scrap.GetScrapFlavorData('TEXT') except: return '' def clipcopy1(arg): board = AppKit.NSPasteboard.generalPasteboard() board.declareTypes_owner_([AppKit.NSStringPboardType], None) newStr = Foundation.NSString.stringWithString_(arg) newData = newStr.nsstring().dataUsingEncoding_(Foundation.NSASCIIStringEncoding) board.setData_forType_(newData, AppKit.NSStringPboardType) def clippaste1(): board = AppKit.NSPasteboard.generalPasteboard() content = board.stringForType_(AppKit.NSStringPboardType) return content ------------------------------------------------- Doug From bob at redivi.com Wed Mar 23 00:53:15 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 23 00:53:20 2005 Subject: [Pythonmac-SIG] Copying to clipboard (pasteboard) In-Reply-To: <4536266a28b8fd843de89b6b13ac0ee7@urgrad.rochester.edu> References: <5fbd027b4d27fb4c33b8a28c4fd0ffee@mail.weber.edu> <4536266a28b8fd843de89b6b13ac0ee7@urgrad.rochester.edu> Message-ID: On Mar 22, 2005, at 6:29 PM, Doug Schwarz wrote: > import Carbon.Scrap, AppKit, Foundation > > def clipcopy1(arg): > board = AppKit.NSPasteboard.generalPasteboard() > board.declareTypes_owner_([AppKit.NSStringPboardType], None) > newStr = Foundation.NSString.stringWithString_(arg) > newData = > newStr.nsstring().dataUsingEncoding_(Foundation.NSASCIIStringEncoding) > board.setData_forType_(newData, AppKit.NSStringPboardType) This should probably be written as: from AppKit import * from Foundation import * def clipcopy1(arg): # assume that arg is ASCII board = NSPasteboard.generalPasteboard() board.declareTypes_owner_([NSStringPboardType], None) board.setString_forType_(unicode(arg), NSStringPboardType) -bob From Chris.Barker at noaa.gov Wed Mar 23 01:46:31 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Mar 23 01:45:41 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: <4936cf197b80cf925bc7905f97862ca2@redivi.com> References: <4936cf197b80cf925bc7905f97862ca2@redivi.com> Message-ID: <4240BC67.1040403@noaa.gov> Bob Ippolito wrote: > Actually, I'm not totally sure I trust the 10.3+ zip files for > symlinks. Disk images are the popular solution. Thanks for the tip, I have had problems moving .app bundles around through a Windows-based server. > Some later version of > py2app will probably have an option for creating a dmg out of your > application. great idea. In the meantime, does anyone know of a command-line tool for making Disk Images? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From cookedm at physics.mcmaster.ca Wed Mar 23 01:52:30 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Wed Mar 23 01:52:33 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: <4240BC67.1040403@noaa.gov> (Chris Barker's message of "Tue, 22 Mar 2005 16:46:31 -0800") References: <4936cf197b80cf925bc7905f97862ca2@redivi.com> <4240BC67.1040403@noaa.gov> Message-ID: "Chris Barker" writes: > Bob Ippolito wrote: > >> Actually, I'm not totally sure I trust the 10.3+ zip files for >> symlinks. Disk images are the popular solution. > > Thanks for the tip, I have had problems moving .app bundles around > through a Windows-based server. > > > Some later version of > > py2app will probably have an option for creating a dmg out of your > > application. > > great idea. In the meantime, does anyone know of a command-line tool > for making Disk Images? hdiutil is the one included with OS X. More information than you could shake a stick at in the man page for that, too. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca From mday at mac.com Wed Mar 23 02:55:10 2005 From: mday at mac.com (Mark Day) Date: Wed Mar 23 02:55:15 2005 Subject: [Pythonmac-SIG] python make failing: "ImportError: No module named MacOS" In-Reply-To: <580BA579A1985E21E21D2974@tiedgar.internal.presence-group.net> References: <2ABF10D7BBA08ECBBFD5D3D7@tiedgar.internal.presence-group.net> <580BA579A1985E21E21D2974@tiedgar.internal.presence-group.net> Message-ID: <5935D7A1-C885-485F-BBA2-834560D0DC77@mac.com> On Mar 19, 2005, at 2:34 PM, OpenMacNews wrote: >> I'm not totally sure that enable-toolbox-glue is >> on by default, but I think it is. I used it anyway: >> >> % mkdir -p ~/src/Python-2.4.1c1/_panther >> % cd ~/src/Python-2.4.1c1/_panther >> % ../configure \ >> --enable-toolbox-glue \ >> --enable-framework=/Users/bob/python-2.4.1c1/Frameworks >> % make >> % sudo make frameworkinstall >> >> worked fine for me. >> > > ok, so something's missing on my system ... which is particularly > odd since its a clean/complete install. > > hmmmm .... > > anyone else, perhaps with ideas? or should i take this over the > the dev list? Did you include the "sudo" before the "make frameworkinstall"? If not, did you make sure you really have write access to the path given in the --enable-framework option? If you don't have write access, you will have a whole slew of errors attempting to install the framework. Those errors don't stop the build, and you may not notice them until something tries to actually use the files that were supposed to be installed. It might be prudent to look earlier in the build output to see if there were other errors or failures. -Mark From janssen at parc.com Wed Mar 23 05:09:41 2005 From: janssen at parc.com (Bill Janssen) Date: Wed Mar 23 05:10:17 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.8 In-Reply-To: Your message of "Tue, 22 Mar 2005 16:46:31 PST." <4240BC67.1040403@noaa.gov> Message-ID: <05Mar22.200944pst."58617"@synergy1.parc.xerox.com> Here's the line I use to create new disk image copies of my package: /usr/bin/hdiutil create -srcfolder /tmp/my.pkg -volname "My Package version x.x" -ov /tmp/my-pkg-x.x.dmg Bill From sw at wordtech-software.com Wed Mar 23 06:25:42 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Mar 23 06:25:47 2005 Subject: [Pythonmac-SIG] ANN: New PyQt-Mac-03-2005 binary installer available Message-ID: <4240FDD6.1030608@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have released a new binary installer of PyQt-Mac, PyQt-Mac-03-2005, which packages PyQt for Mac OS X. This installer updates all components of PyQt to the latest versions: PyQt 3.14.1, Sip 4.2.1, QScintilla 1.5.1, Qt 3.3.4, and Eric 3 (PyQt IDE) 3.6.2 This version differs from previous releases of PyQt-Mac by handling all installation details, no longer requiring the user to run additional installer scripts. The result is a significantly smaller installer package (60 MB) and final installation (250 MB). Based on user requests, we have also added instructions on how to build PyQt on Mac OS X to the "ReadMe" documentation; this material is also included on the web page for PyQt-Mac. For more information and download links, see this page: http://www.wordtech-software.com/pyqt-mac.html - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCQP3VJmdQs+6YVcoRAiGnAJ92qRb2kUMYEt/Dn+UEjN/yFqvJEwCgg6dv A8cmnXjO+Rxf45FKHLAlzTw= =L37d -----END PGP SIGNATURE----- From meesters at uni-mainz.de Wed Mar 23 10:33:35 2005 From: meesters at uni-mainz.de (Christian Meesters) Date: Wed Mar 23 10:33:36 2005 Subject: [Pythonmac-SIG] installing MySQL for Python Message-ID: <6ae66231192598020b996c7747c7a23d@uni-mainz.de> Hi Has anybody experience installing MySQL-Python (v1.2)? In this case I'd like to install it for the standard 2.3 (for the record: I'm using 10.3.8 with Python Panther Fix). Simply starting 'python setup.py build' results in a bunch of errors and compiler warning and eventually fails: #just the last few errors and warnings for brevity: _mysql.c: In function `_mysql_ResultObject_setattr': _mysql.c:2360: error: `v' undeclared (first use in this function) _mysql.c:2371: error: `name' undeclared (first use in this function) _mysql.c:2372: error: `self' undeclared (first use in this function) _mysql.c: At top level: _mysql.c:172: warning: `_mysql_server_init__doc__' defined but not used _mysql.c:183: warning: `_mysql_server_init' defined but not used _mysql.c:267: warning: `_mysql_server_end__doc__' defined but not used _mysql.c:273: warning: `_mysql_server_end' defined but not used error: command '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/config/PantherPythonFix/run-gcc' failed with exit status 1 Any idea how I could solve my problem? It's not the first time problems with MySQL for Python are discussed on this list, but I can't see how much my problem is related to what we have had before. So, I hope you forgive me asking this if this question was raised in some other way before. Thanks a lot in advance. Cheers Christian From meesters at uni-mainz.de Wed Mar 23 15:57:34 2005 From: meesters at uni-mainz.de (Christian Meesters) Date: Wed Mar 23 15:57:34 2005 Subject: [Pythonmac-SIG] installing MySQL for Python In-Reply-To: References: <6ae66231192598020b996c7747c7a23d@uni-mainz.de> Message-ID: Hi Jim, On 23 Mar 2005, at 15:07, Jim Muller wrote: > Well, the last few errors are probably caused by the first few -- what > are they? > Sorry, didn't thought that it could be all too important - but thinking about it, my excuse sounds a bit silly. Well here they are: $ python setup.py build sh: line 1: mysql_config: command not found sh: line 1: mysql_config: command not found sh: line 1: mysql_config: command not found running build running build_py running build_ext building '_mysql' extension /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ config/PantherPythonFix/run-gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c _mysql.c -o build/temp.darwin-7.8.0-Power_Macintosh-2.3/_mysql.o _mysql.c:41:19: mysql.h: No such file or directory _mysql.c:42:26: mysqld_error.h: No such file or directory _mysql.c:43:20: errmsg.h: No such file or directory _mysql.c:73: error: parse error before "MYSQL" _mysql.c:73: warning: no semicolon at end of struct or union _mysql.c:76: error: parse error before '}' token _mysql.c:76: warning: type defaults to `int' in declaration of `_mysql_ConnectionObject' _mysql.c:76: warning: data definition has no type or storage class _mysql.c:87: error: parse error before "MYSQL_RES" _mysql.c:87: warning: no semicolon at end of struct or union _mysql.c:91: error: parse error before '}' token and so on. Yet, I'm still hesitant to send the entire list of errors. Anyway: Looking on the first few lines let me search for mysql_config. All I found was a binary in my PHP folder - but this has got nothing to do with MySQL for Python. There is no other mysql_config file on the system. setup.py tries to use 'popen' on 'mysql_config'. Well, from this point on I still have no idea how to proceed and want to raise the very same question: Any hints? Thanks, Christian From bob at redivi.com Wed Mar 23 17:00:49 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 23 17:01:06 2005 Subject: [Pythonmac-SIG] installing MySQL for Python In-Reply-To: References: <6ae66231192598020b996c7747c7a23d@uni-mainz.de> Message-ID: On Mar 23, 2005, at 9:57 AM, Christian Meesters wrote: > On 23 Mar 2005, at 15:07, Jim Muller wrote: > >> Well, the last few errors are probably caused by the first few -- >> what are they? >> > > Sorry, didn't thought that it could be all too important - but > thinking about it, my excuse sounds a bit silly. Well here they are: > > $ python setup.py build > sh: line 1: mysql_config: command not found --- > Anyway: Looking on the first few lines let me search for mysql_config. > All I found was a binary in my PHP folder - but this has got nothing > to do with MySQL for Python. There is no other mysql_config file on > the system. > setup.py tries to use 'popen' on 'mysql_config'. Well, from this > point on I still have no idea how to proceed and want to raise the > very same question: Any hints? I think what's most important here is how you installed MySQL. Apparently the MySQL extension is looking for components of MySQL that you do not have installed, or that you have installed in a location other than where the extension knows to look. Unfortunately for you, I don't use MySQL, so I can't really give you any specific advice. Last I remember, the PostgreSQL extensions build fine, and I have binaries for two different SQLite extensions (one DB-API compliant, and one not) available from http://pythonmac.org/packages/ -bob From meesters at uni-mainz.de Wed Mar 23 18:55:28 2005 From: meesters at uni-mainz.de (Christian Meesters) Date: Wed Mar 23 18:55:28 2005 Subject: [Pythonmac-SIG] installing MySQL for Python In-Reply-To: References: <6ae66231192598020b996c7747c7a23d@uni-mainz.de> Message-ID: On 23 Mar 2005, at 17:00, Bob Ippolito wrote: > > I think what's most important here is how you installed MySQL. > Apparently the MySQL extension is looking for components of MySQL that > you do not have installed, or that you have installed in a location > other than where the extension knows to look. Right. I installed MySQL from a darwinport ('mysql-standard-4.1.10-apple-darwin6.8-powerpc') and don't have this mysql_config file - for whatever reason. Seems like I have to de-install MySQL and re-install it from scratch. But this will have to wait until tomorrow ... Anyway, thanks for all your help! Cheers Christian From Larry.A.Meyn at nasa.gov Wed Mar 23 19:05:34 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Wed Mar 23 19:05:40 2005 Subject: [Pythonmac-SIG] installing MySQL for Python In-Reply-To: References: <6ae66231192598020b996c7747c7a23d@uni-mainz.de> Message-ID: I would suggest getting the package installer from MySQL at http://dev.mysql.com/downloads/mysql/4.1.html. I've had no problems with the installer packages they've provided. --Larry On Mar 23, 2005, at 9:55 AM, Christian Meesters wrote: > > On 23 Mar 2005, at 17:00, Bob Ippolito wrote: >> >> I think what's most important here is how you installed MySQL. >> Apparently the MySQL extension is looking for components of MySQL >> that you do not have installed, or that you have installed in a >> location other than where the extension knows to look. > > Right. I installed MySQL from a darwinport > ('mysql-standard-4.1.10-apple-darwin6.8-powerpc') and don't have this > mysql_config file - for whatever reason. > Seems like I have to de-install MySQL and re-install it from scratch. > But this will have to wait until tomorrow ... > > Anyway, thanks for all your help! > Cheers > Christian > > From dreedmac at columbus.rr.com Wed Mar 23 22:40:57 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Wed Mar 23 22:41:18 2005 Subject: [Pythonmac-SIG] problem creating first pyobjc file Message-ID: <3b3c0b023eaabae15e224cf48eaaefbf@columbus.rr.com> I'm a Linux refugee familiar used to programming pygtk apps with glade and decided to see how to make Cocoa apps. I downloaded the pybobc 1.3b1 and py2app that Bob announced about a week ago. I'm following the tutorial and go to the step where I'm supposed to run: /usr/bin/python setup.py py2app -A and I get: Traceback (most recent call last): File "setup.py", line 2, in ? import py2app File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/py2app/__init__.py", line 43, in ? import distutils.dist, distutils.core, distutils.command, build_app, sys File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/py2app/build_app.py", line 24, in ? from py2app.find_modules import find_modules, parse_mf_results File "/Library/Python/2.3/py2app/py2app/__init__.py", line 33, in ? import py2app.install ImportError: No module named install Here is what I think is the relevant directory listing: 516 mac:/Library/Python/2.3/py2app/py2app $ ls -l total 464 -rw-rw-r-- 1 dreed admin 1185 30 Dec 21:18 __init__.py -rw-rw-r-- 1 dreed admin 1382 17 Mar 21:34 __init__.pyc -rw-rw-r-- 1 dreed admin 227 17 Mar 21:34 __init__.pyo drwxrwxr-x 14 dreed admin 476 23 Mar 16:32 apptemplate/ drwxrwxr-x 35 dreed admin 1190 23 Mar 16:32 bootstrap/ -rw-rw-r-- 1 dreed admin 37063 12 Mar 23:58 build_app.py -rw-rw-r-- 1 dreed admin 42985 17 Mar 21:34 build_app.pyc -rw-rw-r-- 1 dreed admin 42603 17 Mar 21:34 build_app.pyo drwxrwxr-x 14 dreed admin 476 23 Mar 16:32 bundletemplate/ drwxrwxr-x 5 dreed admin 170 23 Mar 16:32 command/ -rw-rw-r-- 1 dreed admin 1320 3 Dec 02:43 create_appbundle.py -rw-rw-r-- 1 dreed admin 1976 17 Mar 21:34 create_appbundle.pyc -rw-rw-r-- 1 dreed admin 1976 17 Mar 21:34 create_appbundle.pyo -rw-rw-r-- 1 dreed admin 1312 3 Dec 02:07 create_pluginbundle.py -rw-rw-r-- 1 dreed admin 2006 17 Mar 21:34 create_pluginbundle.pyc -rw-rw-r-- 1 dreed admin 2006 17 Mar 21:34 create_pluginbundle.pyo -rw-rw-r-- 1 dreed admin 993 9 Feb 18:24 filters.py -rw-rw-r-- 1 dreed admin 1809 17 Mar 21:34 filters.pyc -rw-rw-r-- 1 dreed admin 1537 17 Mar 21:34 filters.pyo -rw-rw-r-- 1 dreed admin 812 9 Dec 13:12 install.py -rw-rw-r-- 1 dreed admin 1402 17 Mar 21:34 install.pyc -rw-rw-r-- 1 dreed admin 1106 17 Mar 21:34 install.pyo drwxrwxr-x 27 dreed admin 918 23 Mar 16:32 recipes/ drwxrwxr-x 8 dreed admin 272 23 Mar 16:32 scripts/ -rw-rw-r-- 1 dreed admin 12264 12 Feb 02:56 util.py -rw-rw-r-- 1 dreed admin 16365 17 Mar 21:34 util.pyc -rw-rw-r-- 1 dreed admin 15028 17 Mar 21:34 util.pyo I see the install.py file. Any ideas what is wrong here? Thanks, Dave From bob at redivi.com Wed Mar 23 22:53:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 23 22:53:55 2005 Subject: [Pythonmac-SIG] problem creating first pyobjc file In-Reply-To: <3b3c0b023eaabae15e224cf48eaaefbf@columbus.rr.com> References: <3b3c0b023eaabae15e224cf48eaaefbf@columbus.rr.com> Message-ID: On Mar 23, 2005, at 4:40 PM, David Reed wrote: > > I'm a Linux refugee familiar used to programming pygtk apps with glade > and decided to see how to make Cocoa apps. I downloaded the pybobc > 1.3b1 and py2app that Bob announced about a week ago. I'm following > the tutorial and go to the step where I'm supposed to run: > > /usr/bin/python setup.py py2app -A > > and I get: > > Traceback (most recent call last): > File "setup.py", line 2, in ? > import py2app > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/py2app/__init__.py", line 43, in ? > import distutils.dist, distutils.core, distutils.command, > build_app, sys > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/py2app/build_app.py", line 24, in ? > from py2app.find_modules import find_modules, parse_mf_results > File "/Library/Python/2.3/py2app/py2app/__init__.py", line 33, in ? > import py2app.install > ImportError: No module named install You have two copies of py2app installed, one of which is older than 0.1.6. From : As of version 0.1.6, py2app uses the extra_path feature of distutils, which changes the installation layout. If you have py2app 0.1.5 or earlier installed, you must manually remove the following directories from your site-packages directory (probably /Library/Python/2.3 ) if they exist before upgrading: ? py2app ? macholib ? bdist_mpkg ? modulegraph ? altgraph so.. clobber those directories and reinstall the mpkg. -bob From dreedmac at columbus.rr.com Thu Mar 24 00:43:48 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Thu Mar 24 00:43:54 2005 Subject: [Pythonmac-SIG] problem creating first pyobjc file In-Reply-To: References: <3b3c0b023eaabae15e224cf48eaaefbf@columbus.rr.com> Message-ID: <87546b1a48621dfbd4d86fee8fbf5bab@columbus.rr.com> On Mar 23, 2005, at 4:53 PM, Bob Ippolito wrote: > > On Mar 23, 2005, at 4:40 PM, David Reed wrote: > >> >> I'm a Linux refugee familiar used to programming pygtk apps with >> glade and decided to see how to make Cocoa apps. I downloaded the >> pybobc 1.3b1 and py2app that Bob announced about a week ago. I'm >> following the tutorial and go to the step where I'm supposed to run: >> >> /usr/bin/python setup.py py2app -A >> >> and I get: >> >> Traceback (most recent call last): >> File "setup.py", line 2, in ? >> import py2app >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/py2app/__init__.py", line 43, in ? >> import distutils.dist, distutils.core, distutils.command, >> build_app, sys >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/py2app/build_app.py", line 24, in ? >> from py2app.find_modules import find_modules, parse_mf_results >> File "/Library/Python/2.3/py2app/py2app/__init__.py", line 33, in ? >> import py2app.install >> ImportError: No module named install > > You have two copies of py2app installed, one of which is older than > 0.1.6. > > From : > > As of version 0.1.6, py2app uses the extra_path feature of distutils, > which changes the installation layout. If you have py2app 0.1.5 or > earlier installed, you must manually remove the following directories > from your site-packages directory (probably /Library/Python/2.3 ) if > they exist before upgrading: > ? py2app > ? macholib > ? bdist_mpkg > ? modulegraph > ? altgraph > > so.. clobber those directories and reinstall the mpkg. > Thanks Bob. A few of those didn't exist (modulegraph and altgraph I think), but I deleted the ones that did and got it to work. Now I need to look at the Cocoa books I borrowed from the library and try to understand a little bit more about Cocoa and Objective-C. Thanks, Dave From nmadnani at mac.com Thu Mar 24 03:18:32 2005 From: nmadnani at mac.com (nmadnani@mac.com) Date: Thu Mar 24 03:18:40 2005 Subject: [Pythonmac-SIG] Having trouble installing Panther python packages Message-ID: <8c65ac2b6d39c740a8b3656992241d71@mac.com> Hi Guys I am having trouble installing the python packages at http://pythonmac.org/packages/ Everytime I unzip the file and install the .mpkg file, I get the following error: "The InstallationCheck tool is either not exectutable or not readable." 1) I chmod'ed +x the "InstallationCheck" script in the Resouces folder. Didn't help 2) I did a google search and found someone else having the same problem, but they said that it was fixed if they used StuffIt Expander to unzip the file and not 'unzip'. I used both and I am having the same problems in both cases. 3) I looked at what the file 'InstallationCheck' contained in the pkg and it was just this: #!/bin/sh exit 112 So I thought I would just delete it and that should be ok. Nope, same problems. 4) I contacted Bob Ippolito and he was kind enought to provide some suggestions but could not help much because he could not reproduce the problems on any of his macs. So, if anyone else is having the same problems and has managed to fix it, I would really appreciate any advice ! Thanks in advance ! Nitin From detlev at die-offenbachs.de Wed Mar 23 19:10:58 2005 From: detlev at die-offenbachs.de (Detlev Offenbach) Date: Thu Mar 24 03:43:00 2005 Subject: [Pythonmac-SIG] Re: [PyKDE] ANN: New PyQt-Mac-03-2005 binary installer available In-Reply-To: <4240FDD6.1030608@wordtech-software.com> References: <4240FDD6.1030608@wordtech-software.com> Message-ID: <200503231910.58568.detlev@die-offenbachs.de> Am Mittwoch, 23. M?rz 2005 06:25 schrieb Kevin Walzer: > We have released a new binary installer of PyQt-Mac, PyQt-Mac-03-2005, > which packages PyQt for Mac OS X. This installer updates all components > of PyQt to the latest versions: > > PyQt 3.14.1, Sip 4.2.1, QScintilla 1.5.1, Qt 3.3.4, and Eric 3 (PyQt > IDE) 3.6.2 > > This version differs from previous releases of PyQt-Mac by handling all > installation details, no longer requiring the user to run additional > installer scripts. The result is a significantly smaller installer > package (60 MB) and final installation (250 MB). > > Based on user requests, we have also added instructions on how to build > PyQt on Mac OS X to the "ReadMe" documentation; this material is also > included on the web page for PyQt-Mac. > > For more information and download links, see this page: > > http://www.wordtech-software.com/pyqt-mac.html I have added this link to the eric3 site (links page). Detlev -- Detlev Offenbach detlev@die-offenbachs.de From Henning.Ramm at mediapro-gmbh.de Thu Mar 24 12:10:54 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Thu Mar 24 12:10:57 2005 Subject: [Pythonmac-SIG] XML handler design Message-ID: Hi there! I just wrote a SAX handler for XML files that describe a newspaper issue (list of pages etc.); I'd like to know if I could do it better. def startElement(self, name, attrs): """call an own handler method named _start_Something for a Something element if it exists, to avoid a long list of 'if name== ...'""" self._queue.append(name) # keep the order of processed tags handler = str('_start_'+name) if hasattr(self, handler): self.__class__.__dict__[handler](self, attrs) # is there a better syntax for this? The different element handlers fill an array of custom Page objects (self.pages). One gets this array either directly as MyHandler.pages or via def getPages(self): return self.pages.getSortedArray() # no, it's not a plain array ;-) def getPage(self, no): return self.pages[no] Is that the right way to get data from a handler? Like in: parser = xml.sax.make_parser() parser.setFeature(xml.sax.handler.feature_namespaces, 0) pxh = MyHandler() parser.setContentHandler(pxh) parser.parse(dateiname) for p in pxh.getPages(): ... I guess it would be better (more logical) to get the data from the parser? Further, if I'd like to use it in a twisted driven asynchronous app, would I let the parser run in a thread? (Or how can I make the parser non-blocking?) Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From steve at spvi.com Thu Mar 24 14:28:15 2005 From: steve at spvi.com (Steve Spicklemire) Date: Thu Mar 24 14:28:52 2005 Subject: [Pythonmac-SIG] Embedding with CW6 Message-ID: <20732218f235a554e4964c428f32fac6@spvi.com> Hi Folks, Back in the pretty old days (python 1.5 or so I think) I developed a Macromedia Director (MMD) scripting Xtra that allowed Lingo scripts to use python as an embedded language. It worked great... but I moved on and haven't done anything Carbon in years. Now I find myself in a situation where I need to get that Xtra working with the latest MMD. The Macromedia XDK seems to only support Codewarrior on the Mac. I have only CW6 at this point (I have an email sent off to Metrowerks asking how I might get CW7) so I guess I can't build the latest sources (as they seem to want CW7). So.. the question is: What's the latest set of sources that will likely work on CW6? (in case I can't get CW7). thanks for any help! -steve From Henning.Ramm at mediapro-gmbh.de Thu Mar 24 14:35:33 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Thu Mar 24 14:35:41 2005 Subject: [Pythonmac-SIG] XML handler design Message-ID: David Reed wrote: >There's probably a better mailing list with XML parsing experts. I'm >certainly not an expert but have done a little XML parsing. >I've always >followed the pattern of using startElement, characters and endElement >to grab all the data. In the startElement method you set a instance >variable to keep track of the current tag you are processing. You use >the characters method to build up the values and then in the >endElement >method you store the data in your data structure. See the pyxml HOWTO >for an example - specifically this section: >http://pyxml.sourceforge.net/topics/howto/node14.html Yes, sure. Thanks, but that's not what I wanted to know. Perhaps I wasn't clear enough. It's not really so much XML related... >> def startElement(self, name, attrs): >> self._queue.append(name) # keep the order of processed tags >> handler = str('_start_'+name) >> if hasattr(self, handler): >> self.__class__.__dict__[handler](self, attrs) Is there a better syntax for self.__class__.__dict__[handler]? And where should the "output" go to? All examples use print statements in the element handlers. I wrote those get... methods - but I guess they don't belong in the XML handler, but perhaps in the parser or somewhere else. It works, but I don't think it's good design. >> def getPages(self): >> return self.pages.getSortedArray() >> >> def getPage(self, no): >> return self.pages[no] >> parser = xml.sax.make_parser() >> parser.setFeature(xml.sax.handler.feature_namespaces, 0) >> pxh = MyHandler() >> parser.setContentHandler(pxh) >> parser.parse(dateiname) >> for p in pxh.getPages(): ... I should ask the last question on the twisted ML, I guess: >> Further, if I'd like to use it in a twisted driven asynchronous app, >> would I let the parser run in a thread? (Or how can I make >> the parser non-blocking?) Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From steve at spvi.com Thu Mar 24 15:10:04 2005 From: steve at spvi.com (Steve Spicklemire) Date: Thu Mar 24 15:10:46 2005 Subject: [Pythonmac-SIG] XML handler design In-Reply-To: References: Message-ID: Hi Henning, > >>> def startElement(self, name, attrs): >>> self._queue.append(name) # keep the order of processed tags >>> handler = str('_start_'+name) >>> if hasattr(self, handler): >>> self.__class__.__dict__[handler](self, attrs) > > Is there a better syntax for self.__class__.__dict__[handler]? how about: handler = getattr(self, str('_start_'+name),None) # fetch the actual bound method if handler is not None: handler( attrs ) or something like that? I'm not sure why you're using the __class__.__dict__ attributes in the first place, so maybe what I suggest can't work. > > And where should the "output" go to? > All examples use print statements in the element handlers. > I wrote those get... methods - but I guess they don't belong in the > XML handler, but perhaps in the parser or somewhere else. > It works, but I don't think it's good design. I've not uesd the sax stuff myself.. but I'd say you can either save it in the handler, as you're doing, or pass some kind structure/object to the handler's constructor that it will use to save away the content it finds. good luck! -steve > >>> def getPages(self): >>> return self.pages.getSortedArray() >>> >>> def getPage(self, no): >>> return self.pages[no] > >>> parser = xml.sax.make_parser() >>> parser.setFeature(xml.sax.handler.feature_namespaces, 0) >>> pxh = MyHandler() >>> parser.setContentHandler(pxh) >>> parser.parse(dateiname) >>> for p in pxh.getPages(): ... > > I should ask the last question on the twisted ML, I guess: > >>> Further, if I'd like to use it in a twisted driven asynchronous app, >>> would I let the parser run in a thread? (Or how can I make >>> the parser non-blocking?) > > Best regards, > Henning Hraban Ramm > S?dkurier Medienhaus / MediaPro > Support/Admin/Development Dept. > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From dreedmac at columbus.rr.com Thu Mar 24 15:13:16 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Thu Mar 24 15:13:24 2005 Subject: [Pythonmac-SIG] XML handler design In-Reply-To: References: Message-ID: <685f02aad0b7e2b480f3c2fbe270adc3@columbus.rr.com> On Mar 24, 2005, at 8:35 AM, Henning.Ramm@mediapro-gmbh.de wrote: > David Reed wrote: > >> There's probably a better mailing list with XML parsing experts. I'm >> certainly not an expert but have done a little XML parsing. >> I've always >> followed the pattern of using startElement, characters and endElement >> to grab all the data. In the startElement method you set a instance >> variable to keep track of the current tag you are processing. You use >> the characters method to build up the values and then in the >> endElement >> method you store the data in your data structure. See the pyxml HOWTO >> for an example - specifically this section: >> http://pyxml.sourceforge.net/topics/howto/node14.html > > Yes, sure. Thanks, but > that's not what I wanted to know. > Perhaps I wasn't clear enough. > It's not really so much XML related... > >>> def startElement(self, name, attrs): >>> self._queue.append(name) # keep the order of processed tags >>> handler = str('_start_'+name) >>> if hasattr(self, handler): >>> self.__class__.__dict__[handler](self, attrs) > > Is there a better syntax for self.__class__.__dict__[handler]? You should be able to use getattr to get the method and then call it. That's a little cleaner IMO. > And where should the "output" go to? > All examples use print statements in the element handlers. I'm not certain we are clear. Instead of output statements you set store the data in some instance variable - in your case it appears self.pages is your instance variable containing the data. So your endElement method would set something in self.pages based on the tag indicated and the data built up from the characters method and any of the attrs from the start tag. If all your data is in the attrs that you get in the startElement tag then there's no need to do anything in the characters or endElement methods. If you want to use the startElement/characters/endElement approach, I can try to find a small example I've written and send it to you off-list. > I wrote those get... methods - but I guess they don't belong in the > XML handler, but perhaps in the parser or somewhere else. > It works, but I don't think it's good design. > >>> def getPages(self): >>> return self.pages.getSortedArray() >>> >>> def getPage(self, no): >>> return self.pages[no] > >>> parser = xml.sax.make_parser() >>> parser.setFeature(xml.sax.handler.feature_namespaces, 0) >>> pxh = MyHandler() >>> parser.setContentHandler(pxh) >>> parser.parse(dateiname) >>> for p in pxh.getPages(): ... > > I should ask the last question on the twisted ML, I guess: > >>> Further, if I'd like to use it in a twisted driven asynchronous app, >>> would I let the parser run in a thread? (Or how can I make >>> the parser non-blocking?) >>> I've never looked into twister so I can't answer this. Dave From Henning.Ramm at mediapro-gmbh.de Thu Mar 24 15:14:04 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Thu Mar 24 15:14:06 2005 Subject: [Pythonmac-SIG] XML handler design Message-ID: >> Is there a better syntax for self.__class__.__dict__[handler]? >how about: > handler = getattr(self, str('_start_'+name),None) ># fetch the actual bound method > if handler is not None: > handler( attrs ) That's good, I think. Thank you. >or something like that? I'm not sure why you're using the >__class__.__dict__ attributes in the first place, so maybe what I >suggest can't work. I'm using it because I didn't knew better and it works. ;-) Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From eric.nieuwland at xs4all.nl Thu Mar 24 15:20:11 2005 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Thu Mar 24 15:20:16 2005 Subject: [Pythonmac-SIG] XML handler design In-Reply-To: References: Message-ID: <20d61d693e0eedf2400c506391d2dce5@xs4all.nl> wrote: >>> def startElement(self, name, attrs): >>> self._queue.append(name) # keep the order of processed tags >>> handler = str('_start_'+name) >>> if hasattr(self, handler): >>> self.__class__.__dict__[handler](self, attrs) > > Is there a better syntax for self.__class__.__dict__[handler]? > > And where should the "output" go to? > All examples use print statements in the element handlers. > I wrote those get... methods - but I guess they don't belong in the > XML handler, but perhaps in the parser or somewhere else. > It works, but I don't think it's good design. > >>> def getPages(self): >>> return self.pages.getSortedArray() >>> >>> def getPage(self, no): >>> return self.pages[no] > >>> parser = xml.sax.make_parser() >>> parser.setFeature(xml.sax.handler.feature_namespaces, 0) >>> pxh = MyHandler() >>> parser.setContentHandler(pxh) >>> parser.parse(dateiname) >>> for p in pxh.getPages(): ... My style is to create/build a data structure in the parser and have a single get... method that will give me the result. Your getPage/getPages would be part of the objects in the data structure. So: class MyDoc(...): ... def getPage(self): ... def getPages(self,no): ... ... class MyXmlParser(...): ... def reset(self): super(MyXmlParser,self).reset() self._myresult = MyDoc(...) ... def startElement(self, name, attrs): ... add to self._result ... def getResult(self): # usually something more advanced than this return self._result > I should ask the last question on the twisted ML, I guess: > >>> Further, if I'd like to use it in a twisted driven asynchronous app, >>> would I let the parser run in a thread? (Or how can I make >>> the parser non-blocking?) Sorry, dunnoh! --eric From Henning.Ramm at mediapro-gmbh.de Thu Mar 24 15:22:15 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Thu Mar 24 15:22:18 2005 Subject: [Pythonmac-SIG] XML handler design Message-ID: >> And where should the "output" go to? >> All examples use print statements in the element handlers. >I'm not certain we are clear. Instead of output statements you >store the data in some instance variable - in your case it appears >self.pages is your instance variable containing the data. Right. >So your >endElement method would set something in self.pages based on the tag >indicated and the data built up from the characters method and any of >the attrs from the start tag. If all your data is in the attrs >that you >get in the startElement tag then there's no need to do anything in the >characters or endElement methods. If you want to use the >startElement/characters/endElement approach, I can try to find a small >example I've written and send it to you off-list. I need the different element handlers (start, end and characters) to collect lots of small data parts that are spread all over the file and make a series of objects from it (stored in self.pages). My first attempt used DOM, but I get a cleaner, more readable, better extendable code with SAX. And I guess it's easier to make a SAX parser asynchronous. I'd be interested in your code, if you were so kind. (I'm on going in holidays now, so I guess you'll get an out of office reply, but I'll read my mail sometimes.) Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From Henning.Ramm at mediapro-gmbh.de Thu Mar 24 15:25:17 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Thu Mar 24 15:25:20 2005 Subject: [Pythonmac-SIG] XML handler design Message-ID: >>>> def getPages(self): >>>> return self.pages.getSortedArray() >>>> >>>> def getPage(self, no): >>>> return self.pages[no] >My style is to create/build a data structure in the parser and have a >single get... method that will give me the result. >Your getPage/getPages would be part of the objects in the data >structure. As you see my get methods aren't much more than redirections to the object's own methods - one could access them directly via MyHandler.pages[12] or MyHandler.pages,getSortedArray() Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From eric.nieuwland at xs4all.nl Thu Mar 24 15:36:53 2005 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Thu Mar 24 15:36:57 2005 Subject: [Pythonmac-SIG] XML handler design In-Reply-To: References: Message-ID: <41da9816ed75bbf7edce071212c00c2e@xs4all.nl> wrote: > As you see my get methods aren't much more than redirections to the > object's own methods - one could access them directly via > MyHandler.pages[12] or MyHandler.pages,getSortedArray() Yes, I see it. What I tried to explain is that I use the factory pattern (well, sort of) for the XML handler. --eric From jeremyconlin at mail.weber.edu Thu Mar 24 15:57:54 2005 From: jeremyconlin at mail.weber.edu (Jeremy Conlin) Date: Thu Mar 24 15:58:05 2005 Subject: [Pythonmac-SIG] Copying to clipboard (pasteboard) In-Reply-To: <4536266a28b8fd843de89b6b13ac0ee7@urgrad.rochester.edu> References: <5fbd027b4d27fb4c33b8a28c4fd0ffee@mail.weber.edu> <4536266a28b8fd843de89b6b13ac0ee7@urgrad.rochester.edu> Message-ID: <749627d9bc04434ea7242fc582d3da1d@mail.weber.edu> > I figured out how to do this with a lot of trial and error. You can > use Carbon or AppKit/Foundation. > > ------------------------------------------------- > import Carbon.Scrap, AppKit, Foundation > > def clipcopy(arg): > Carbon.Scrap.ClearCurrentScrap() > scrap = Carbon.Scrap.GetCurrentScrap() > scrap.PutScrapFlavor('TEXT', 0, arg) > > That worked! Thanks a bunch. (Now I get to show what kind of a newbie I am.) Why should I put this into a class? Is it just better programming practice? I suppose the answer may depend on what the script does and how complicated it is. Also, where can I find documentation on this? I tried Python's help, but it offered very little. Thanks, Jeremy From Benjamin.Schollnick at xerox.com Thu Mar 24 16:19:14 2005 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Thu Mar 24 16:20:07 2005 Subject: [Pythonmac-SIG] Copying to clipboard (pasteboard) Message-ID: <266589E1B9392B4C9195CC25A07C73B9AA4F55@usa0300ms04.na.xerox.net> > > import Carbon.Scrap, AppKit, Foundation > > > > def clipcopy(arg): > > Carbon.Scrap.ClearCurrentScrap() > > scrap = Carbon.Scrap.GetCurrentScrap() > > scrap.PutScrapFlavor('TEXT', 0, arg) > That worked! Thanks a bunch. > (Now I get to show what kind of a newbie I am.) Why should I > put this into a class? Is it just better programming practice? Well, making this into a class could allow you to simply extend the functionality.... For example, you could store the changes in a LIST/queue and use the class to store multiple clipboard entries.... >I suppose the > answer may depend on what the script does and how complicated it is. Exactly... It depends on how and what you are trying to do.... - Ben From bob at redivi.com Thu Mar 24 16:24:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 24 16:24:35 2005 Subject: [Pythonmac-SIG] Copying to clipboard (pasteboard) In-Reply-To: <749627d9bc04434ea7242fc582d3da1d@mail.weber.edu> References: <5fbd027b4d27fb4c33b8a28c4fd0ffee@mail.weber.edu> <4536266a28b8fd843de89b6b13ac0ee7@urgrad.rochester.edu> <749627d9bc04434ea7242fc582d3da1d@mail.weber.edu> Message-ID: On Mar 24, 2005, at 9:57 AM, Jeremy Conlin wrote: >> I figured out how to do this with a lot of trial and error. You can >> use Carbon or AppKit/Foundation. >> >> ------------------------------------------------- >> import Carbon.Scrap, AppKit, Foundation >> >> def clipcopy(arg): >> Carbon.Scrap.ClearCurrentScrap() >> scrap = Carbon.Scrap.GetCurrentScrap() >> scrap.PutScrapFlavor('TEXT', 0, arg) >> >> > > That worked! Thanks a bunch. > (Now I get to show what kind of a newbie I am.) Why should I put this > into a class? Is it just better programming practice? I suppose the > answer may depend on what the script does and how complicated it is. > > Also, where can I find documentation on this? I tried Python's help, > but it offered very little. For any of the Carbon.* functions you need to look in Apple's documentation or the headers for the C version, and then more or less just guess how it would work from Python. Those wrappers are automatically generated and nobody has documented them. I'd recommend avoiding the Carbon stuff whenever possible and using PyObjC and Cocoa instead. The translation from Objective-C to Python is straightforward and maintained, the documentation (both Apple's and PyObjC's) is better, the APIs are generally cleaner and more obvious to begin with, amongst other things. -bob From Martina at Oefelein.de Fri Mar 25 00:14:22 2005 From: Martina at Oefelein.de (Martina Oefelein) Date: Fri Mar 25 00:14:27 2005 Subject: [Pythonmac-SIG] Having trouble installing Panther python packages In-Reply-To: <8c65ac2b6d39c740a8b3656992241d71@mac.com> References: <8c65ac2b6d39c740a8b3656992241d71@mac.com> Message-ID: <29e137cb3b947a1ab39fe01afedbbfa3@Oefelein.de> Hi Nitin! > Everytime I unzip the file and install the .mpkg file, I get the > following error: > "The InstallationCheck tool is either not exectutable or not readable." did you use unzip to decompress the archive? Apparently unzip doesn't preserve "execute" rights. Try another decompressor. Stuffit Expander seems to work fine. ciao Martina From Martina at Oefelein.de Fri Mar 25 00:21:44 2005 From: Martina at Oefelein.de (Martina Oefelein) Date: Fri Mar 25 00:21:48 2005 Subject: [Pythonmac-SIG] XML handler design In-Reply-To: References: Message-ID: <20670fb19abe0b92b1f4206279f6bac1@Oefelein.de> Hi Henning, > My first attempt used DOM, but I get a cleaner, more readable, better > extendable code with SAX. If you want a cleaner coder, you give might one of the more "pythonic" XML APIs, like ElementTree or XIST a try. ElementTree: http://effbot.org/zone/element-index.htm XIST: http://www.livinglogic.de/Python/xist/ ciao Martina From bob at redivi.com Fri Mar 25 02:12:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 25 02:12:11 2005 Subject: [Pythonmac-SIG] Having trouble installing Panther python packages In-Reply-To: <29e137cb3b947a1ab39fe01afedbbfa3@Oefelein.de> References: <8c65ac2b6d39c740a8b3656992241d71@mac.com> <29e137cb3b947a1ab39fe01afedbbfa3@Oefelein.de> Message-ID: <35bc2da2f5fe8705a4a75616eb392d40@redivi.com> On Mar 24, 2005, at 6:14 PM, Martina Oefelein wrote: >> Everytime I unzip the file and install the .mpkg file, I get the >> following error: >> "The InstallationCheck tool is either not exectutable or not >> readable." > > did you use unzip to decompress the archive? Apparently unzip doesn't > preserve "execute" rights. Try another decompressor. Stuffit Expander > seems to work fine. That was stated in the question. What *particularly* bothers me is that he said it STILL COMPLAINS after he *removed InstallationCheck* (I suggested this -- it is perfectly valid to do, as it is only there to disallow <= 10.2 users from attempting an install). That is bizarre. I think that one or more of the following is true, the latter being more likely: (a) Installer is completely insane (b) Installer is doing the check with a receipt (which I definitely don't think it's supposed to do) (c) He didn't actually perform the manipulation he said he performed on the mpkg AND all of the contained pkgs (I came to this conclusion just now, after thinking harder) Since the case is probably (c), this is how you would solve it from the shell: % find somepackage-version.mpkg -name InstallationCheck -exec chmod +x {} \; or alternatively, if you really like Python: #!/usr/bin/env python import os for root, dirs, files in os.walk('somepackage-version.mpg'): for fn in files: if fn != 'InstallationCheck': continue fn = os.path.join(root, fn) mode = os.stat(fn).st_mode os.chmod(fn, mode | 0111) Obviously, the shell version is a little shorter -- both were composed in Mail and neither were tested, so.. good luck. -bob From rkern at ucsd.edu Fri Mar 25 02:33:18 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri Mar 25 02:33:26 2005 Subject: [Pythonmac-SIG] Having trouble installing Panther python packages In-Reply-To: <35bc2da2f5fe8705a4a75616eb392d40@redivi.com> References: <8c65ac2b6d39c740a8b3656992241d71@mac.com> <29e137cb3b947a1ab39fe01afedbbfa3@Oefelein.de> <35bc2da2f5fe8705a4a75616eb392d40@redivi.com> Message-ID: <42436A5E.8070202@ucsd.edu> Bob Ippolito wrote: > > On Mar 24, 2005, at 6:14 PM, Martina Oefelein wrote: > >>> Everytime I unzip the file and install the .mpkg file, I get the >>> following error: >>> "The InstallationCheck tool is either not exectutable or not readable." >> >> >> did you use unzip to decompress the archive? Apparently unzip doesn't >> preserve "execute" rights. Try another decompressor. Stuffit Expander >> seems to work fine. > > > That was stated in the question. > > What *particularly* bothers me is that he said it STILL COMPLAINS after > he *removed InstallationCheck* (I suggested this -- it is perfectly > valid to do, as it is only there to disallow <= 10.2 users from > attempting an install). That is bizarre. I talked with him offlist. He didn't do the chmod on *all* of the InstallationCheck's in each of the sub-packages. Doing that fixed the problem. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From nmadnani at mac.com Fri Mar 25 02:34:44 2005 From: nmadnani at mac.com (nmadnani@mac.com) Date: Fri Mar 25 02:34:50 2005 Subject: [Pythonmac-SIG] Having trouble installing Panther python packages In-Reply-To: <42436A5E.8070202@ucsd.edu> References: <8c65ac2b6d39c740a8b3656992241d71@mac.com> <29e137cb3b947a1ab39fe01afedbbfa3@Oefelein.de> <35bc2da2f5fe8705a4a75616eb392d40@redivi.com> <42436A5E.8070202@ucsd.edu> Message-ID: Hi Everyone I was able to fix the problem as Robert said. Thanks so much for all your suggestions !! Nitin On Mar 24, 2005, at 8:33 PM, Robert Kern wrote: > Bob Ippolito wrote: >> On Mar 24, 2005, at 6:14 PM, Martina Oefelein wrote: >>>> Everytime I unzip the file and install the .mpkg file, I get the >>>> following error: >>>> "The InstallationCheck tool is either not exectutable or not >>>> readable." >>> >>> >>> did you use unzip to decompress the archive? Apparently unzip >>> doesn't preserve "execute" rights. Try another decompressor. Stuffit >>> Expander seems to work fine. >> That was stated in the question. >> What *particularly* bothers me is that he said it STILL COMPLAINS >> after he *removed InstallationCheck* (I suggested this -- it is >> perfectly valid to do, as it is only there to disallow <= 10.2 users >> from attempting an install). That is bizarre. > > I talked with him offlist. He didn't do the chmod on *all* of the > InstallationCheck's in each of the sub-packages. Doing that fixed the > problem. > > -- > Robert Kern > rkern@ucsd.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From rkern at ucsd.edu Fri Mar 25 19:45:11 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri Mar 25 19:45:18 2005 Subject: [Pythonmac-SIG] MacEnthon ... Message-ID: <42445C37.8030703@ucsd.edu> ... is not here, yet! But it will be! I have one more issue to work out before cutting a pre-release. Sadly, I must get some science done today. So I issue a challenge to the PythonMac masses: Write me an uninstaller. Standalone GUI is a plus, although I can live with a CLI script. For now, it only needs to be run by the intrepid testers. One ought to be able to uninstall indivdual packages. Almost all of the packages are built using bdist_mpkg. A few are made by PackageMaker.app. Another few (MacPython extras and wxPython, notably) come from their original, non-bdist_mpkg packagers. Assume that you can have a list of packages to check for hard-coded. Everything gets installed somewhere under - /Developer/Documentation/Enthon - /Developer/Python - /Library/Python/2.3 - /usr/local - /Applications/MacPython-2.3 In return for your generosity, you get my eternal gratitude[1], the beverage of your choice should we happen to be in the same city somewhen, and a brand spankin' new MacEnthon by Monday. wxPython has a CLI uninstaller for itself that you can steal from. Attached is the current MacEnthon ReadMe thingy. Yell at me if there's something obviously bogus in it (but no package requests, please. We'll talk about adding to this 157Mib behemoth later). [1] Which I imagine will be somewhat tricky to fulfill once I die, but that just makes it *so* much more valuable. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050325/6bc24406/ReadMe.html From bob at redivi.com Fri Mar 25 23:44:28 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 25 23:44:36 2005 Subject: [Pythonmac-SIG] MacEnthon ... In-Reply-To: <42445C37.8030703@ucsd.edu> References: <42445C37.8030703@ucsd.edu> Message-ID: <292876ae828f8ce4c5cfcd39d29651a2@redivi.com> On Mar 25, 2005, at 1:45 PM, Robert Kern wrote: > So I issue a challenge to the PythonMac masses: Write me an > uninstaller. Standalone GUI is a plus, although I can live with a CLI > script. For now, it only needs to be run by the intrepid testers. One > ought to be able to uninstall indivdual packages. Is this usable? -bob From rkern at ucsd.edu Fri Mar 25 23:57:02 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri Mar 25 23:57:01 2005 Subject: [Pythonmac-SIG] MacEnthon ... In-Reply-To: <292876ae828f8ce4c5cfcd39d29651a2@redivi.com> References: <42445C37.8030703@ucsd.edu> <292876ae828f8ce4c5cfcd39d29651a2@redivi.com> Message-ID: <4244973E.7070204@ucsd.edu> Bob Ippolito wrote: > > On Mar 25, 2005, at 1:45 PM, Robert Kern wrote: > >> So I issue a challenge to the PythonMac masses: Write me an >> uninstaller. Standalone GUI is a plus, although I can live with a CLI >> script. For now, it only needs to be run by the intrepid testers. One >> ought to be able to uninstall indivdual packages. > > > Is this usable? No, it assumes things about the naming conventions of the BOM file. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Sat Mar 26 01:42:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 26 01:42:25 2005 Subject: [Pythonmac-SIG] MacEnthon ... In-Reply-To: <4244973E.7070204@ucsd.edu> References: <42445C37.8030703@ucsd.edu> <292876ae828f8ce4c5cfcd39d29651a2@redivi.com> <4244973E.7070204@ucsd.edu> Message-ID: <6240002be42b6fcddb6f0e824a1193e4@redivi.com> On Mar 25, 2005, at 5:57 PM, Robert Kern wrote: > Bob Ippolito wrote: >> On Mar 25, 2005, at 1:45 PM, Robert Kern wrote: >>> So I issue a challenge to the PythonMac masses: Write me an >>> uninstaller. Standalone GUI is a plus, although I can live with a >>> CLI script. For now, it only needs to be run by the intrepid >>> testers. One ought to be able to uninstall indivdual packages. >> Is this usable? > > No, it assumes things about the naming conventions of the BOM file. It looked kinda crappy anyway, I was just wondering if you had tried it. I'm not volunteering to do this, as I don't need it and I have plenty of other things to work on.. but here is a brain dump of the procedure for uninstalling a package generated by bdist_mpkg (or most anything else): (1) Somehow know the name of all the .pkgs inside, the .mpkg does not create a receipt of its own (2) Pick up the value of the "IFPkgReceiptLocation" key in the ./Contents/Info.plist of the .pkg (3) Grab the output of "/usr/bin/lsbom -p f ./Contents/Archive.bom" (obviously using the full path to the bom) (4) shutil.rmtree(os.path.join(IFPkgReceiptLocation, line.rstrip()), ignore_errors=True) for every line in the output gathered from (3) This, of course, basically needs to happen with euid 0. So, you could: (a) make it only usable from the shell via sudo (b) write an AppleScript stub that does the root stuff (c) use Authorization wrappers .. amongst other possibilities -bob From janssen at parc.com Sat Mar 26 01:55:03 2005 From: janssen at parc.com (Bill Janssen) Date: Sat Mar 26 01:55:31 2005 Subject: [Pythonmac-SIG] MacEnthon ... In-Reply-To: Your message of "Fri, 25 Mar 2005 10:45:11 PST." <42445C37.8030703@ucsd.edu> Message-ID: <05Mar25.165512pst."58617"@synergy1.parc.xerox.com> What the heck *is* MacEnthon? The README didn't give me a clue. Bill From bob at redivi.com Sat Mar 26 02:04:32 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 26 02:04:32 2005 Subject: [Pythonmac-SIG] MacEnthon ... In-Reply-To: <05Mar25.165512pst."58617"@synergy1.parc.xerox.com> References: <05Mar25.165512pst."58617"@synergy1.parc.xerox.com> Message-ID: On Mar 25, 2005, at 7:55 PM, Bill Janssen wrote: > What the heck *is* MacEnthon? The README didn't give me a clue. It's an distribution of Python[1] that comes with all the useful stuff that was listed, quite similar to the "Enthought Edition" of Python for Windows (but seems to contain far more batteries). [1] currently implemented such that it augments the stock Mac OS X 10.3 installation, rather than being a completely independent distribution. -bob From rkern at ucsd.edu Sat Mar 26 02:08:20 2005 From: rkern at ucsd.edu (Robert Kern) Date: Sat Mar 26 02:08:22 2005 Subject: [Pythonmac-SIG] MacEnthon ... In-Reply-To: <05Mar25.165512pst."58617"@synergy1.parc.xerox.com> References: <05Mar25.165512pst."58617"@synergy1.parc.xerox.com> Message-ID: <4244B604.8040501@ucsd.edu> Bill Janssen wrote: > What the heck *is* MacEnthon? The README didn't give me a clue. Oh, sorry! I've mostly talked about it on the Scipy lists. Enthought, Inc. has been distributing a "sumo" distribution of the Python interpreter for the Windows platform with many third-party packages (particularly those geared towards scientific development) built, tested and ready to go all in one installer. It has been nick-named "Enthon". Enthought will be rolling out a Windows Enthon in the next week or so with a Linux release to follow. MacEnthon is the same thing, more or less, for OS X. Right now, I just target the stock 2.3.0 interpreter. When Python 2.4.1 gets released, I might target that as well. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From jschull at digitalgoods.com Sun Mar 27 04:55:46 2005 From: jschull at digitalgoods.com (Jon Schull) Date: Sun Mar 27 04:55:51 2005 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 23, Issue 42 In-Reply-To: <20050326010826.8C7811E400A@bag.python.org> References: <20050326010826.8C7811E400A@bag.python.org> Message-ID: <31d1ad927c937c844c708e0927513230@digitalgoods.com> > MacEnthon 0.0 Prerelease > This looks great. Have you considered adding vpython to this package? It uses numarray, plays well with ipython, and is of unsurpassed simplicity and elegance. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 325 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050326/4e6c38a6/attachment.bin From sarwat at sarwat.net Sun Mar 27 05:48:32 2005 From: sarwat at sarwat.net (Sarwat Khan) Date: Sun Mar 27 05:48:35 2005 Subject: [Pythonmac-SIG] plistservices 3 is available Message-ID: I've released plistservices v3 at http://sarwat.net/opensource/ The main feature it adds is that it indents the XML output as CoreFoundation does. I think the only difference in the output is that CF will put newlines at well-placed spots in the CFData objects, and I didn't want to bother. => This point is the end of the useful part of this message. The reason why it took so long to do indenting was a matter of principle. I was sick of the thought of doing yet another XML/HTML-output chunk of code that passes a stupid indent param along the recursion. At this point, it's been 2+ years since I've had to do that, so it doesn't have the same sting anymore (I am noticing however, that the more I think about the fact that I did it, the more it bugs me). Also, I found myself not wanting to use plistservices for some things because of the fugly XML it produced. This is actually version 4. Version 3 has been sitting on my computers since 2003, and apparently I forgot to release it. Back then I modified it so it was a nice replacement for mx.DateTime in MySQLdb's times.py. That was back when MySQLdb was at version 0.94; MySQLdb was then assuming Python 2.2, which doesn't have the datetime module. The fact that I didn't put newlines in CFData XML is starting to gnaw at my brain. We'll see what happens. Anyway, enjoy. Sarwat. {sarwat khan : http://sarwat.net} From bob at redivi.com Sun Mar 27 05:57:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Mar 27 05:58:03 2005 Subject: [Pythonmac-SIG] plistservices 3 is available In-Reply-To: References: Message-ID: On Mar 26, 2005, at 10:48 PM, Sarwat Khan wrote: > I've released plistservices v3 at http://sarwat.net/opensource/ > > The main feature it adds is that it indents the XML output as > CoreFoundation does. I think the only difference in the output is > that CF will put newlines at well-placed spots in the CFData > objects, and I didn't want to bother. Since we fixed the bugs in plistlib w.r.t. date/time stuff before the release of Python 2.4, is there any particularly good reason to use plistservices instead of the updated plistlib? -bob From sarwat at sarwat.net Sun Mar 27 06:33:16 2005 From: sarwat at sarwat.net (Sarwat Khan) Date: Sun Mar 27 06:33:20 2005 Subject: [Pythonmac-SIG] plistservices 3 is available In-Reply-To: References: Message-ID: <0fd606ccbbae59632d09fb6429d16026@sarwat.net> > Since we fixed the bugs in plistlib w.r.t. date/time stuff before the > release of Python 2.4, is there any particularly good reason to use > plistservices instead of the updated plistlib? Well, there is the fact that you have to go to http://sarwat.net/opensource/ to get it. Is that a good reason? :) The most useful part is the classes it contains and the programming interface that mimics Cocoa. When I'm using plists I often want to manipulate dates the same way I do in Cocoa/CF (datetime et al can be annoying). plistservices has the following classes with the following methods, class Data: dataWithContentsOfFile dataWithOpenFile dataWithString writeToFile description - CF style description bytes - raw str class Date (datetime.datetime): timeIntervalSince1970 -- and vica versa timeIntervalSinceReferenceDate -- and vv dateFromStandard8601String - gives you a datetime from an 8601 string; useful with MySQL and the like. class EasternTimeZone (datetime.tzinfo): Fixed offset in minutes east of UTC class TimeInterval (datetime.timedelta): duration - in seconds, same as NSTimeInterval durationForTimeDelta, a class method for getting the seconds of any timedelta object. timeIntervalFromStandard8601TimeString(self, string) from __builtin__.type | mx.DateTime compatibility method. | | Given an iso 8601 time string (HH:MM:SS.FF), returns a timeInterval | compatible with mx.DateTime.ISO.ParseTimeDelta. This means that | you can also add a - in front of the value to create a negative | time delta. (hey, copy & paste is a good idea) timeIntervalWithTimeDelta, a TimeInterval from a timedelta. And then there's two module functions, dataFromPropertyList and propertyListFromData, which do what NSPropertyListSerialization does. {sarwat khan : http://sarwat.net} From bob at redivi.com Sun Mar 27 06:43:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Mar 27 06:43:50 2005 Subject: [Pythonmac-SIG] plistservices 3 is available In-Reply-To: <0fd606ccbbae59632d09fb6429d16026@sarwat.net> References: <0fd606ccbbae59632d09fb6429d16026@sarwat.net> Message-ID: On Mar 26, 2005, at 11:33 PM, Sarwat Khan wrote: >> Since we fixed the bugs in plistlib w.r.t. date/time stuff before >> the release of Python 2.4, is there any particularly good reason >> to use plistservices instead of the updated plistlib? >> >> > > Well, there is the fact that you have to go to http://sarwat.net/ > opensource/ to get it. Is that a good reason? :) > Unfortunately most people would rather pick something up from the standard library if it works :) > The most useful part is the classes it contains and the programming > interface that mimics Cocoa. When I'm using plists I often want to > manipulate dates the same way I do in Cocoa/CF (datetime et al can > be annoying). plistservices has the following classes with the > following methods, > > class Data: > dataWithContentsOfFile > dataWithOpenFile > dataWithString > Which are inconsistent with PyObjC, because the number of arguments does not equal the number of underscores! So now there are three ways to do it: 1) Use plistlib, which comes with Python anyway, and has a pythonic API (at the expense of having to download it if you're not on a Mac) 2) Use PyObjC, and get the real APIs (at the expense of losing cross- plat support and requiring an extension, but guaranteed compatibility and speed) 3) Use plistservices, and get something that is similar to the real APIs, but mapped in a somewhat ambiguous way, that is different from the PyObjC mapping. -bob From sarwat at sarwat.net Sun Mar 27 07:02:46 2005 From: sarwat at sarwat.net (Sarwat Khan) Date: Sun Mar 27 07:02:49 2005 Subject: [Pythonmac-SIG] plistservices 3 is available In-Reply-To: References: <0fd606ccbbae59632d09fb6429d16026@sarwat.net> Message-ID: On 26-Mar-05, at 8:43 PM, Bob Ippolito wrote: > Which are inconsistent with PyObjC, because the number of arguments > does not equal the number of underscores! Who wants to write code like that :P You're either using PyObjC or not. > So now there are three ways to do it: > 1) Use plistlib, which comes with Python anyway, and has a pythonic > API (at the expense of having to download it if you're not on a Mac) > 2) Use PyObjC, and get the real APIs (at the expense of losing > cross-plat support and requiring an extension, but guaranteed > compatibility and speed) > 3) Use plistservices, and get something that is similar to the real > APIs, but mapped in a somewhat ambiguous way, that is different from > the PyObjC mapping. My use of plists are either on a Mac or on a web server. In the second case, #1 and #2 are out (at any rate, it's easier to download plistservices than it is to get the Python's source and extract plistlib). plistlib doesn't make available its ISO 8601 parsing available either. The mapping isn't ambiguous, it's the same as the Java bridge. {sarwat khan : http://sarwat.net} From bob at redivi.com Sun Mar 27 07:14:56 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Mar 27 07:15:04 2005 Subject: [Pythonmac-SIG] plistservices 3 is available In-Reply-To: References: <0fd606ccbbae59632d09fb6429d16026@sarwat.net> Message-ID: <06E18DCB-C7C7-40AD-841E-5C8126FB98E9@redivi.com> On Mar 27, 2005, at 12:02 AM, Sarwat Khan wrote: > On 26-Mar-05, at 8:43 PM, Bob Ippolito wrote: > > >> Which are inconsistent with PyObjC, because the number of >> arguments does not equal the number of underscores! >> > > Who wants to write code like that :P You're either using PyObjC or > not. It would be more useful if it had the same API as the actual classes as you would use them from PyObjC. Then you could just drop it in when you need cross-platform code. >> So now there are three ways to do it: >> 1) Use plistlib, which comes with Python anyway, and has a >> pythonic API (at the expense of having to download it if you're >> not on a Mac) >> 2) Use PyObjC, and get the real APIs (at the expense of losing >> cross-plat support and requiring an extension, but guaranteed >> compatibility and speed) >> 3) Use plistservices, and get something that is similar to the >> real APIs, but mapped in a somewhat ambiguous way, that is >> different from the PyObjC mapping. >> > > My use of plists are either on a Mac or on a web server. In the > second case, #1 and #2 are out (at any rate, it's easier to > download plistservices than it is to get the Python's source and > extract plistlib). plistlib doesn't make available its ISO 8601 > parsing available either. The mapping isn't ambiguous, it's the > same as the Java bridge. It's not that hard to get the plistlib from Python's source. "doesn't make available its ISO 8601" parsing doesn't really sound like a feature to me. It doesn't make its base64 decoding either :) If the feature was compelling enough to make available, it should be in a "date/time parsing" module, not in a mostly unrelated module that just so happens to need it. You mean, the same as the Java bridge, where every selector is mapped by a human manually, and is probably *already* unmaintained and dying? -bob From rkern at ucsd.edu Sun Mar 27 12:23:15 2005 From: rkern at ucsd.edu (Robert Kern) Date: Sun Mar 27 12:23:19 2005 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 23, Issue 42 In-Reply-To: <31d1ad927c937c844c708e0927513230@digitalgoods.com> References: <20050326010826.8C7811E400A@bag.python.org> <31d1ad927c937c844c708e0927513230@digitalgoods.com> Message-ID: <42468993.1010607@ucsd.edu> Jon Schull wrote: > *MacEnthon 0.0 Prerelease* > > This looks great. > Have you considered adding vpython to this package? It uses numarray, > plays well with ipython, and is of unsurpassed simplicity and elegance. I am not taking package requests at this time. I did consider vpython at one time, but it has a strong presumption against it because of the X11 requirement. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From mark at mophilly.com Tue Mar 29 20:05:03 2005 From: mark at mophilly.com (Mark Phillips) Date: Tue Mar 29 20:05:10 2005 Subject: [Pythonmac-SIG] Dabo and mysqldb Message-ID: <8490c54ff7b8bbbcf3f3d054117bda50@mophilly.com> I am trying to get Dabo up and running on MacOS 10.3.8. I have installed dabo and wxPython. I am tripping over mysqldb, being mysql-python-1.2.0. MySQL 4.x is installed and running. When I execute "setup.py build", I am getting a long series of errors that begin with sh: line 1: mysql_config: command not found and continue with more shell and gcc errors. I ran setup.py as "su" and not; no joy. The Dabo readme states: "The setup.py script uses mysql_config to find all compiler and linker options, and should work as is on any POSIX-like platform, so long as mysql_config is in your path." I cannot find a file named "mysql_config". Any links, comments and suggestions are greatly appreciated. - Mark "I'd rather be a failure at something I enjoy than a success at something I hate." -?George Burns From lee_cullens at mac.com Tue Mar 29 23:10:42 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Mar 29 23:10:51 2005 Subject: [Pythonmac-SIG] RE: SPE-OSX IDE with Python on Mac or others? Message-ID: Greetings, Dual 2.5 Power Mac G5; OS X 10.3.8 (retired software engineer in the process of learning Python and new to Mac) I wanted to kill two birds at once in using an IDE that "supposedly" integrates with Blender3D and can be used otherwise. So I downloaded SPE-OSX which came as a zip folder with both binary and source (after downloading and installing wxPython - already had MacPython add-ons and Blender). I moved the SPE-OSX folder that was downloaded to /Applications/MacPython-2.3, and the Kiki, wxGladeOSX and XRCed executables all bring up a window, but the SPE-OSX executable doesn't make it that far (flash on double click, and HD activity, but nothing more). I am wondering if anyone knows what is missing (path definition/whatever) to bring up the SPE IDE, or if I'm wasting my time? I notice their hasn't been much activity with SPE since late 2003 / early 2004 and no mail list on the site to search - has the author moved on to bigger and better things? Currently I'm using PythonIDE - have to manually type the URL for the PackageManager when I occasionally look at it, but the docs are an easy click away (which I access more often). I also have IDLE but with 10.3.8 the help docs are screwed up so I went back to PythonIDE. I would like a better sandbox and thus was trying to use SPE, but would really appreciate and recommendations/comments/ref links/whatever :~) Thank you, Lee C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1472 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050329/f348db7b/attachment.bin From bob at redivi.com Tue Mar 29 23:48:00 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 29 23:48:05 2005 Subject: [Pythonmac-SIG] RE: SPE-OSX IDE with Python on Mac or others? In-Reply-To: References: Message-ID: On Mar 29, 2005, at 4:10 PM, Lee Cullens wrote: > Currently I'm using PythonIDE - have to manually type the URL for the > PackageManager when I occasionally look at it, but the docs are an > easy click away (which I access more often). I also have IDLE but > with 10.3.8 the help docs are screwed up so I went back to PythonIDE. I can't answer your questions about SPE, but you shouldn't bother with PackageManager. Everything in there is old, and the UI is no fun. For newer packages that do not depend on the packman infrastructure, go to: http://pythonmac.org/packages/ -bob From lee_cullens at mac.com Wed Mar 30 00:56:24 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Wed Mar 30 00:56:30 2005 Subject: [Pythonmac-SIG] RE: IDE recommendation Message-ID: <3a8cdf266d7b704af8837e3d8829356d@mac.com> Relative to my previous post : RE: SPE-OSX IDE with Python on Mac or others? I'm leery of SPE, so maybe a more general recommendation - an IDE I can "grow with" that has a significant user base, is still reasonably maintained (maybe even evolving). I'll work out how to integrate Python scripts in Blender when I get to that point, but for now I need to create modules (duh - text edit), debug, package and deliver on an OS X platform. It seems there should be a viable sandbox to work within. I'm aware of the Wing IDE but have not purchased it yet - I don't know enough yet to know if is really worth it. Thanks, Lee C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 643 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050329/48dea759/attachment.bin From Chris.Barker at noaa.gov Wed Mar 30 07:37:57 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Mar 30 07:38:07 2005 Subject: [Pythonmac-SIG] RE: IDE recommendation In-Reply-To: <3a8cdf266d7b704af8837e3d8829356d@mac.com> References: <3a8cdf266d7b704af8837e3d8829356d@mac.com> Message-ID: <424A3B35.6080802@noaa.gov> Lee Cullens wrote: > I'm leery of SPE, SPE has only recently worked at all on the Mac, and has a pretty Windows-centric design. > so maybe a more general recommendation - an IDE I can "grow with" that > has a significant user base, is still reasonably maintained (maybe > even evolving). check the archives of this list. There are a number of options, but all the open-source ones seem to be beta (at best, maybe alpha) quality on OS-X. Some folks like Wing, which may be the only commercial option on OS-X at this point. You can go a long way with a good editor and the command line, however. -CHB From lee_cullens at mac.com Wed Mar 30 09:42:04 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Wed Mar 30 09:42:10 2005 Subject: [Pythonmac-SIG] RE: IDE recommendation Message-ID: <2816dcd4f64a158066c376ffda0e562a@mac.com> Wanted to say thank you to Bob, Chris and Mark. I'll let IDLE and SPE just sit there for the time being. Maybe I' get back to SPE after Tiger and see if I can work with them to get it to play well with Mac - we'll see where I'm at. I've got Leo up and running. It isn't everything I would like in a sandbox but it does have an intriguing organizational approach that I'll either learn to love or hate :~). Would like to first figure out how to keep it from opening up two terminal windows when it starts though - maybe a good learning exercise. Beginning my software engineering career in the 60's with computer sciences curriculum of mostly "brand new" IBM 360 assembler and ending such with distributed HP3000 systems (Unix and C) I have fell in love with my new Mac (I passed over the 1990s Apple). I think the elegance of the high level GUI combined with an intuitive underbelly is a combination neither of the other two platforms approach. Anyway since I'm now retired, I'm going to do the development I want to on the platform I like (to keep my mind active and happy) even if such generates more "keep busy" work. Best to all and thanks again, Lee C > Relative to my previous post : RE: SPE-OSX IDE with Python on Mac or > others? > > I'm leery of SPE, so maybe a more general recommendation - an IDE I > can "grow with" that has a significant user base, is still reasonably > maintained (maybe even evolving). I'll work out how to integrate > Python scripts in Blender when I get to that point, but for now I need > to create modules (duh - text edit), debug, package and deliver on an > OS X platform. It seems there should be a viable sandbox to work > within. I'm aware of the Wing IDE but have not purchased it yet - I > don't know enough yet to know if is really worth it. > > Thanks, > Lee C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1841 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050330/f92d800f/attachment.bin From thestation at swfla.rr.com Wed Mar 30 06:31:24 2005 From: thestation at swfla.rr.com (me) Date: Wed Mar 30 10:55:57 2005 Subject: [Pythonmac-SIG] appscript and XXXX - what is my app instance returning? Message-ID: <1fcf8da9e4eb199f5185057d83abaff6@swfla.rr.com> I am having much fun with appscript and QuarkXpress6.x The appscript module is such a fantastic piece of code. It lets novices wander right into the thick of AppleScript without requiring intimate knowledge of AppleScript's eccentricities. Unfortunately, when you do get lost like I am. You're completely lost. """ Would someone please share their method for figuring out what my app instance is returning, and how I can coerce that into a form I can utilize? """ In case you are not familiar with QuarkXpress, it is a Professional Desktop Publishing App with a completely object oriented element model. Virtually every nuance of every element of every document of every window is exposed to AppleScript. Hence appscript has a very rich playground to wrap. I've tried using dir() and end up in endless loops of auto-created stem code, with methods and classes pointing everywhere. Wow, there is a LOT of it available in layers like an onion. Too bad I am such a NOOB other things I've tried. . . Quark = appscript.app('QuarkXpress') pw = Quark.documents[1].page_width #This is what I want >>> type(pw) >>> pw.get() <_AE.AEDesc object at 0x1181c38> >>> type(pw.get()) >>> pw.help() =================================================================== Appscript Help (-t) Reference: app(u'/Applications/QuarkXPress 6.1/QuarkXPress').documents[1].page_width ------------------------------------------------------------------------ -------- Description of reference Property: page_width : k.horizontal_measurement (r/o) -- the width of a page in this document Terminology for horizontal_measurement class Class: horizontal_measurement -- =================================================================== OK, I think pw.get() returns an instance of a horizontal_measurement. Where do I go from here? Much Thanks From sw at wordtech-software.com Wed Mar 30 16:05:27 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Mar 30 16:05:33 2005 Subject: [Pythonmac-SIG] SPE-OSX Message-ID: <424AB227.2020600@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Lee, I'm the maintainer of SPE-OSX. You can e-mail me with questions at the address above, although I'm also subscribed to the PythonMac list. What version of wxPython are you using? I have not updated my build of SPE to work with the latest version: mine still runs against 2.5.3.1. I believe the developer has just released an updated version: I'll track that down in the next couple of days and try to get a new build posted to my website. SPE is very actively developed, and there is a mailing list. The main SPE site is http://spe.pycs.net. Hope this helps. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCSrInJmdQs+6YVcoRAsrTAJ4l3Vrlc9ElugQDa0eMbMUAP+pAjACfV0PY dYXYkeYlUTgJXtpsV35QRTI= =uD68 -----END PGP SIGNATURE----- From hengist.podd at virgin.net Wed Mar 30 16:06:45 2005 From: hengist.podd at virgin.net (has) Date: Wed Mar 30 16:07:01 2005 Subject: [Pythonmac-SIG] appscript and XXXX - what is my app instance returning? In-Reply-To: <1fcf8da9e4eb199f5185057d83abaff6@swfla.rr.com> References: <1fcf8da9e4eb199f5185057d83abaff6@swfla.rr.com> Message-ID: 'me' wrote: >I am having much fun with appscript and QuarkXpress6.x [...] >Unfortunately, when you do get lost like I am. You're completely >lost. While appscript saves you from the vagaries of the AppleScript language, it can't do anything about bugs and quirks in individual applications' scripting interfaces. >Would someone please share their method for >figuring out what my app instance is returning, >and how I can coerce that into a form I can utilize? >[...] >Quark = appscript.app('QuarkXpress') >pw = Quark.documents[1].page_width #This is what I want Remember that while appscript uses an OO-like syntax for convenience it's not OO. It's a simple relational query builder plus RPC wrapper. Ditto AppleScript, except it has an even thicker layer of syntactic and semantic sugar on top. The downside of this is that it causes quite a bit of confusion amongst users who assume that because it looks like OO it will behave like it too. (I've considered changing the syntax to avoid this problem, but that'd impact badly on its ease of use. I'd rather keep the syntax but make sure users know it's really just smoke and mirrors. Expect a bigger health warning in the docs for the next release.) > >>> type(pw) > The line: pw = Quark.documents[1].page_width simply constructs a query (represented as an appscript Specifier object) identifying the page_width property of the first document element of the QXP application. To actually retrieve the value of that property from the application, you have to send the application an explicit 'get' command: pw = Quark.documents[1].page_width.get() > >>> pw.get() > <_AE.AEDesc object at 0x1181c38> This is a typical Quarkism: returning an opaque value that only it understands instead of using a standard AE type. AEDesc is the MacPython type used to hold raw Apple event data (in AS it'd appear as <>), and is returned here as appscript doesn't have a suitable converter for it. If you're sending this value back to QXP, no problem. If you want to manipulate it in your script, you'll need to ask QXP to coerce it to a standard datatype (integer, float, string, etc.) before returning it, e.g.: pw.get(astype=k.Char) Not sure which coercions are supported here, so you may need to fiddle with it a bit. Good place to ask for QXP-specific advice would be [e.g.] the MacScrpt mailing list . HTH has -- http://freespace.virgin.net/hamish.sanderson/ From mark at mophilly.com Wed Mar 30 16:49:41 2005 From: mark at mophilly.com (Mark Phillips) Date: Wed Mar 30 16:49:48 2005 Subject: [Pythonmac-SIG] RE: IDE recommendation In-Reply-To: <3a8cdf266d7b704af8837e3d8829356d@mac.com> References: <3a8cdf266d7b704af8837e3d8829356d@mac.com> Message-ID: <85716deb7936e412ac6c930056dcb821@mophilly.com> On Mar 29, 2005, at 2:56 PM, Lee Cullens wrote: > Relative to my previous post : RE: SPE-OSX IDE with Python on Mac or > others? > > I'm leery of SPE, so maybe a more general recommendation - an IDE I > can "grow with" that has a significant user base, is still reasonably > maintained (maybe even evolving). I'll work out how to integrate > Python scripts in Blender when I get to that point, but for now I need > to create modules (duh - text edit), debug, package and deliver on an > OS X platform. It seems there should be a viable sandbox to work > within. I'm aware of the Wing IDE but have not purchased it yet - I > don't know enough yet to know if is really worth it. I recently asked a similar question. This seems to be a sticking point in the Python/Mac community. That is, several project were begun but appear to be stuck in the time/space continuum. The state of the art for Python developers on Mac is the old tool box, with few exceptions. I have be playing with SPE. Nice concept but it does not quit cleanly and has other issues. xCode tools are pretty neat and tidy but I haven't tried to build anything not related to Cocoa with it. wxDesigner looks pretty cool but is neither free nor an "IDE". Wing also looks pretty good but it is also a commercial endeavor. Generally I don't ming paying for tools but I don't like paying to find out whether a tool is worth the money. Toward that end I haven't heard much from developers about these. In the case of Wing, I haven't pursued it... if you form an opinion I would love to hear it. Today I have been working with Dabo and wxGlade. Not to bad, after some personal growth regarding mysqldb. hth, Mark Phillips Mophilly & Associates On the web at http://www.mophilly.com On the phone at 619 444-9210 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1804 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050330/9299bb03/attachment.bin From mark at mophilly.com Wed Mar 30 17:44:28 2005 From: mark at mophilly.com (Mark Phillips) Date: Wed Mar 30 17:44:34 2005 Subject: [Pythonmac-SIG] SPE-OSX In-Reply-To: <424AB227.2020600@wordtech-software.com> References: <424AB227.2020600@wordtech-software.com> Message-ID: On Mar 30, 2005, at 6:05 AM, Kevin Walzer wrote: > -I'm the maintainer of SPE-OSX. You can e-mail me with questions at the > address above, although I'm also subscribed to the PythonMac list. Hello, Kevin, Thanks for responding to Lee and for maintaining the SPE OSX site. It is nice to know you are interested and in action. I have encountered a couple of issues you may be able to help with. I have other questions, but it is too early in the morning for me to think of them. I have been exercising SPE-OSX version 0.7.2c with python 2.3 on MacOS 10.3.8. wxPython version 2.5.2.8 is installed. I like the concept very much. The UML generation is a great feature. The code block control is very nice. This product may give BBedit a run for my choice for python work. I have had a couple of problems. Perhaps you can get me going in the right direction. Getting started: I downloaded the archive, unpacked it and ran the setup.py but it complained of finding another copy of SPE. So I just ran the product using the bundle. Seems to work but... 1. Invoking wxGlade or XRC from the Tools menu does not work. Simply nothing happens. 2. If I close all the open SPE windows, I cannot quit SPE. Please refer to Example 1 below for the traceback displayed in the python window. While SPE is still "responding" according to MacOS X, it does not react to menu selections and I must force quit. Thanks, in advance, Mark Phillips Mophilly & Associates On the web at http://www.mophilly.com On the phone at 619 444-9210 Example 1 Traceback (most recent call last): File "/Users/markphillips/Documents/Software Biz/Development Tools/Python/IDE's/WordTech stuff/SPE-OSX/SPE-OSX.app/Contents/Resources/_spe/Menu.py", line 445, in menu_exit File "//Library/Python/2.3/wx/_core.py", line 10548, in __getattr__ raise PyDeadObjectError(self.attrStr % self._name) wx._core.PyDeadObjectError: The C++ part of the Bar object has been deleted, attribute access no longer allowed. From sw at wordtech-software.com Wed Mar 30 17:59:41 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Mar 30 17:59:46 2005 Subject: [Pythonmac-SIG] SPE-OSX In-Reply-To: References: <424AB227.2020600@wordtech-software.com> Message-ID: <424ACCED.30704@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark, | | 1. Invoking wxGlade or XRC from the Tools menu does not work. Simply | nothing happens. ~From the traceback, it doesn't look like you have SPE installed in the right place. The SPE-OSX folder needs to go in /Applications. There are paths to wxGlade and XRCed that are hard-coded. I know that's not the most elegant way to do things, but it was the simplest approach to getting every tool installed in its own app bundle. (SPE does this differently on other platforms, but I wanted a more Mac-like approach.) | | 2. If I close all the open SPE windows, I cannot quit SPE. Please refer | to Example 1 below for the traceback displayed in the python window. | While SPE is still "responding" according to MacOS X, it does not react | to menu selections and I must force quit. I've noticed that SPE sometimes hangs in this fashion. I don't have a solution for it, unfortunately. I generally save files then simply quit--that seems to shut it down more gracefully. Hope this helps, Kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCSszsJmdQs+6YVcoRAlg+AJ9DP0rG87pi6IaNO769680KrkRrGwCgipig ewak4kEDfHT0ZvA4CpGQF44= =AgJg -----END PGP SIGNATURE----- From berkowit at silcom.com Wed Mar 30 18:04:29 2005 From: berkowit at silcom.com (Paul Berkowitz) Date: Wed Mar 30 18:04:42 2005 Subject: [Pythonmac-SIG] appscript and XXXX - what is my app instance returning? In-Reply-To: Message-ID: On 3/30/05 6:06 AM, "has" wrote: > While appscript saves you from the vagaries of the AppleScript > language, it can't do anything about bugs and quirks in individual > applications' scripting interfaces. > > Remember that while appscript uses an OO-like syntax for convenience > it's not OO. It's a simple relational query builder plus RPC wrapper. > Ditto AppleScript, except it has an even thicker layer of syntactic > and semantic sugar on top. The downside of this is that it causes > quite a bit of confusion amongst users who assume that because it > looks like OO it will behave like it too. > > (I've considered changing the syntax to avoid this problem, but > that'd impact badly on its ease of use. I'd rather keep the syntax > but make sure users know it's really just smoke and mirrors. Expect a > bigger health warning in the docs for the next release.) So there's a bit of a problem then in that you'd pretty well have to know some AppleScript to be able to deal with quirky applications? (Quark is quite possibly the quirkiest, but it's by no means alone.) Many applications have strange and unfortunate implementations of AppleScript, which must reflect the same quirks in their underlying AppleEvent implementations. While there are years of "accumulated wisdom" available on the AppleScript mailing lists (yes, I know MacScrpt is meant to be for all scripting on Macs but for years has been effectively 100% AppleScript-oriented), and in a few cases there is even AppleScript support of various descriptions from the applications' creators, with appscript you'd be on your own, or dependent on has to explain things to you. Someone with years of AppleScript experience in the relevant apps, or apps with similar quirks, can probably figure it out. But this has got to present some hurdles to the very people at whom appscript is aimed - people not conversant in AppleScript - no? If appscript is meant to replace the vagaries of AppleScript with the sanity of Python, there's no getting around the fact that its whole raison d'?tre - healthy application scripting - can founder on poorly implemented application AppleEvent syntax, with no one around to explain it, let alone fix it. -- Paul Berkowitz From ml at fgranger.com Wed Mar 30 20:42:57 2005 From: ml at fgranger.com (Fran=?ISO-8859-1?B?5w==?=ois Granger) Date: Wed Mar 30 20:42:51 2005 Subject: [Pythonmac-SIG] RE: IDE recommendation In-Reply-To: <2816dcd4f64a158066c376ffda0e562a@mac.com> Message-ID: Le 30/03/05 9:42, ??Lee Cullens?? a ?crit?: > I'll let IDLE and SPE just sit there for the time being. Maybe I' get > back to SPE after Tiger and see if I can work with them to get it to > play well with Mac - we'll see where I'm at. I have been using Eclipse with Pydev plugin. This is still beta. This is too heavy for my Mac (iBook 1,2). But it may be ok for your config. http://www.eclipse.org/ http://pydev.sourceforge.net/ > I've got Leo up and running. For a simple good text editor, SubEthaEdit is a must. I use it with PythonIDE for most things. http://www.codingmonkeys.de/subethaedit/ -- Convert from markup to markup: http://fgranger.net1.nerim.net/mtom/ From lee_cullens at mac.com Wed Mar 30 22:27:16 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Wed Mar 30 22:27:21 2005 Subject: [Pythonmac-SIG] RE: IDE recommendation In-Reply-To: References: Message-ID: <70e164530f6f81abaa27f37fd8780c21@mac.com> Thanks Fran?ois Not sure I want to get into eclipse just now but I referenced it for further study. I seem to remember blowing by SubEthaEdit already, but I went back and checked it out with Python IDE and it is indeed a must have basic text editor. I was running into some problems between IDLE and PythonIDE and text editors with end-of-line conventions and I don't see that here. Seems like I was mistaken about SPE's maintenance state also and will be following up further with that. Thanks again, LeeC On Mar 30, 2005, at 1:42 PM, Fran?ois Granger wrote: > Le 30/03/05 9:42, ??Lee Cullens?? a ?crit?: > >> I'll let IDLE and SPE just sit there for the time being. Maybe I' get >> back to SPE after Tiger and see if I can work with them to get it to >> play well with Mac - we'll see where I'm at. > > I have been using Eclipse with Pydev plugin. This is still beta. This > is too > heavy for my Mac (iBook 1,2). But it may be ok for your config. > > http://www.eclipse.org/ > http://pydev.sourceforge.net/ > >> I've got Leo up and running. > > For a simple good text editor, SubEthaEdit is a must. I use it with > PythonIDE for most things. > > http://www.codingmonkeys.de/subethaedit/ > > -- > Convert from markup to markup: > http://fgranger.net1.nerim.net/mtom/ > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From sw at wordtech-software.com Wed Mar 30 22:38:21 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Mar 30 22:38:29 2005 Subject: [Pythonmac-SIG] Re: SPE-OSX In-Reply-To: <0a4dcf7a5b9cbaec68ec2f14dacc4a8e@mac.com> References: <424AB227.2020600@wordtech-software.com> <0a4dcf7a5b9cbaec68ec2f14dacc4a8e@mac.com> Message-ID: <424B0E3D.7030405@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lee Cullens wrote: | Kevin, | | Thank you - I really wanted to try to work with SPE because it seems to | have more of what I want in a sandbox than the other packages I'm | playing with. | | From the SPE page - I already had MacPython Add-Ons and Blender so I | followed the wxPython link to wxpython.org/download.php#prerequisites | and downloaded and installed | wxPython2.5-osx-unicode-2.5.4.1-panther-py2.3dmg. I could have also | downloaded the osx-ansi binary but did not as yet? | Lee, My build of SPE doesn't work with wxPy 2.5.4.1--it's fine with the older version, 2.5.3.x. I believe a new version of SPE has just been released that fixes this. I'm going to check it out and see if everything's OK, but it will be a few days before I can get to it. I'll post when I've verified that everything's OK. Kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCSw49JmdQs+6YVcoRAvI+AJ9gGTp8IfHPSlqTVPPhf4JzBm+tPgCfVKIg g5dDgiOTyb1RzjyhRHq1a9g= =nnm4 -----END PGP SIGNATURE----- From rowen at cesmail.net Wed Mar 30 23:42:34 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Wed Mar 30 23:44:23 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation References: <70e164530f6f81abaa27f37fd8780c21@mac.com> Message-ID: In article <70e164530f6f81abaa27f37fd8780c21@mac.com>, Lee Cullens wrote: > Thanks François > > Not sure I want to get into eclipse just now but I referenced it for > further study. > > I seem to remember blowing by SubEthaEdit already, but I went back and > checked it out with Python IDE and it is indeed a must have basic text > editor. I was running into some problems between IDLE and PythonIDE > and text editors with end-of-line conventions and I don't see that > here. Warning: SubEthaEdit does not enforce a line ending convention. That's probably OK for Python source code, but can be a headache in other contexts. Example: set SubEthaEdit to enter \n when you type (the unix line ending convention). Then paste in text from any standard Mac app and notice that the pasted text uses \r as a line ending. SubEthaEdit is the only text editor I've seen that has this bizarre behavior and I stopped using it because of that (it was causing mysterious failures when checking in svn comments, which is how I stumbled across the problem). I recommend TextWrangler as a "must-have" free editor, though I hate the find/replace dialog box enough to not use it for coding. TextMate looks promising but is not yet polished. Pepper is superb but no longer supported. XCode takes forever to launch. -- Russell From lee_cullens at mac.com Thu Mar 31 00:27:03 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Thu Mar 31 00:27:11 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation In-Reply-To: References: <70e164530f6f81abaa27f37fd8780c21@mac.com> Message-ID: <6db80a3b8bfb75b03ddda6caba4cfbba@mac.com> On Mar 30, 2005, at 4:42 PM, Russell E. Owen wrote: > In article <70e164530f6f81abaa27f37fd8780c21@mac.com>, > Lee Cullens wrote: > >> Thanks Fran?ois >> >> Not sure I want to get into eclipse just now but I referenced it for >> further study. >> >> I seem to remember blowing by SubEthaEdit already, but I went back and >> checked it out with Python IDE and it is indeed a must have basic text >> editor. I was running into some problems between IDLE and PythonIDE >> and text editors with end-of-line conventions and I don't see that >> here. > > Warning: SubEthaEdit does not enforce a line ending convention. That's > probably OK for Python source code, but can be a headache in other > contexts. > Well I only checked it out with a py script for PythonIDE where it left a usable script, but now I also checked it with IDLE and there is the line ending problem. The same problem I was having between PythonIDE and IDLE with other text editors so I guess (relative to Python scripts) the real stumbling block is between PythonTDE and IDLE - i.e. don't use both. I think I'll opt for using neither IDE and concentrate on SPE (as soon as it's checked out for the new wxPython). Where I'll end up eventually ???, maybe just the terminal like Bob and keep things organized with Leo (I usually start planning with a pseudo code framework anyway). Thanks for the heads-up on SubEthaEdit - I don't like hidden source problems :~) > Example: set SubEthaEdit to enter \n when you type (the unix > line ending convention). Then paste in text from any standard Mac app > and notice that the pasted text uses \r as a line ending. > > SubEthaEdit is the only text editor I've seen that has this bizarre > behavior and I stopped using it because of that (it was causing > mysterious failures when checking in svn comments, which is how I > stumbled across the problem). > > I recommend TextWrangler as a "must-have" free editor, though I hate > the > find/replace dialog box enough to not use it for coding. TextMate looks > promising but is not yet polished. Pepper is superb but no longer > supported. XCode takes forever to launch. > I'll revisit TextWrangler. I had looked at XCode and (probably because of my Mac & Python inexperience) didn't see it as the sandbox I was looking for. XCode does launch instantly on my Mac though - but then everything does except the Adobe apps than scan all the fonts at startup. > -- Russell > Thanks again, LeeC > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From berkowit at silcom.com Thu Mar 31 01:45:53 2005 From: berkowit at silcom.com (Paul Berkowitz) Date: Thu Mar 31 01:45:34 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation In-Reply-To: Message-ID: On 3/30/05 1:42 PM, "Russell E. Owen" wrote: > XCode takes forever to launch. It does? Takes about 1 second here. -- Paul Berkowitz From Chris.Barker at noaa.gov Thu Mar 31 06:34:11 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Mar 31 06:34:26 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation In-Reply-To: <6db80a3b8bfb75b03ddda6caba4cfbba@mac.com> References: <70e164530f6f81abaa27f37fd8780c21@mac.com> <6db80a3b8bfb75b03ddda6caba4cfbba@mac.com> Message-ID: <424B7DC3.1030504@noaa.gov> > I had looked at XCode So what is the story with XCode? Has Apple made it extensible and customizable enough that it could be made into a good general purpose IDE/editor? One thing that has always bugged me about all the IDEs I've even seen is that they are designed for a couple languages/compilers,a nd are lousy for other things. That's why I use Xemacs for everything on Linux: It has an excellent mode for every kind of text file I've ever needed to edit. I still haven't found an editor on the Mac I like much. I use BBedit, but it doesn't handle indentation very well with Python, and there are a number of things I don't like about the interface. I think what I like least is that Bare Bones decides how it will work, and if you don't like that: too bad. Is XCode better? I had high hopes for Pepper, but it has been in limbo for a long time now. Maybe Eclipse will be my savior...we'll see. -Chris From bob at redivi.com Thu Mar 31 06:42:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 31 06:42:32 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation In-Reply-To: <424B7DC3.1030504@noaa.gov> References: <70e164530f6f81abaa27f37fd8780c21@mac.com> <6db80a3b8bfb75b03ddda6caba4cfbba@mac.com> <424B7DC3.1030504@noaa.gov> Message-ID: <5d42ed47850f3b9ea9e3ba5835407e3a@redivi.com> On Mar 30, 2005, at 11:34 PM, Chris Barker wrote: > >> I had looked at XCode > > So what is the story with XCode? Has Apple made it extensible and > customizable enough that it could be made into a good general purpose > IDE/editor? One thing that has always bugged me about all the IDEs > I've even seen is that they are designed for a couple > languages/compilers,a nd are lousy for other things. That's why I use > Xemacs for everything on Linux: It has an excellent mode for every > kind of text file I've ever needed to edit. I still haven't found an > editor on the Mac I like much. I use BBedit, but it doesn't handle > indentation very well with Python, and there are a number of things I > don't like about the interface. I think what I like least is that Bare > Bones decides how it will work, and if you don't like that: too bad. > Is XCode better? > > I had high hopes for Pepper, but it has been in limbo for a long time > now. Maybe Eclipse will be my savior...we'll see. Xcode isn't terribly extensible via public API, but it has a very modular design if you prod at it, so there's a possibility that they'll open the flood gates in the future. It will let you plug in arbitrary code (but you have no documented APIs to do much with, beyond AppKit), and add stuff to the scripts menu. How come you're not using XEmacs, Terminal+Emacs, or Carbon Emacs on Mac OS X? Personally I use Vim in a terminal. I plan to switch to Xcode for Python development when it's sufficiently documented and extensible, though. -bob From lee_cullens at mac.com Thu Mar 31 08:52:47 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Thu Mar 31 08:52:56 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation In-Reply-To: References: <70e164530f6f81abaa27f37fd8780c21@mac.com> Message-ID: Just an update Russel, I was getting bored going through the TextWrangler docs, and remembering that I had not even looked at the SubEthaEdit docs when I used it went back to check out what you said further. First, of course, such is something that can be set in the perfs and per document. I found that the only case (that I tried) where I could get into trouble with line endings was as per your note of pasting in text that contained CR line endings and that is an issue that might be troublesome (depending on one's intentions) with many text editors. I'm sure you already know that showing "hidden" characters is prudent in such copying. I also noted in my tests that such is the difference between PythonIDE (uses LF) and IDLE (uses CR), and why only a new-be dummy like me would mix them. TextWrangler is (to me) too much like its big brother - a do-all "develop it yourself" sandbox. Great if that's what your into, but a sidetrack to me. For the moment I'll stick with the simpler SubEthaEdit which I can even use in Terminal (instead of Pico). Besides I liked "The Hitchhikers Guide To The Galaxy" (origin of Sub Etha) - was it the late 70's or the 80's they serialized it on PBS (I'm forgetting too much)? Cheers, Lee C On Mar 30, 2005, at 4:42 PM, Russell E. Owen wrote: > > Warning: SubEthaEdit does not enforce a line ending convention. That's > probably OK for Python source code, but can be a headache in other > contexts. > > Example: set SubEthaEdit to enter \n when you type (the unix > line ending convention). Then paste in text from any standard Mac app > and notice that the pasted text uses \r as a line ending. > > SubEthaEdit is the only text editor I've seen that has this bizarre > behavior and I stopped using it because of that (it was causing > mysterious failures when checking in svn comments, which is how I > stumbled across the problem). > > I recommend TextWrangler as a "must-have" free editor, though I hate > the > find/replace dialog box enough to not use it for coding. TextMate looks > promising but is not yet polished. Pepper is superb but no longer > supported. XCode takes forever to launch. > > -- Russell > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From konrad.hinsen at laposte.net Thu Mar 31 14:02:40 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Thu Mar 31 14:02:44 2005 Subject: [Pythonmac-SIG] RE: IDE recommendation In-Reply-To: <2816dcd4f64a158066c376ffda0e562a@mac.com> References: <2816dcd4f64a158066c376ffda0e562a@mac.com> Message-ID: <481a17eabedf1caa3b658366e039f973@laposte.net> On 30.03.2005, at 09:42, Lee Cullens wrote: > I've got Leo up and running. It isn't everything I would like in a > sandbox but it does have an intriguing organizational approach that > I'll either learn to love or hate :~). Would like to first figure out > how to keep it from opening up Leo is interesting, and useful, but not a good testing environment in my experience. Using pdb in Leo is a pain, for example. I still use Emacs as my main Python developement environment, and I have yet to see any IDE that is more convenient (though for newcomers, the Emacs learning curve may be a bit steep). For editing, I also use jEdit, which is also a nice IDE if you can live with Jython, but I can't. However, the Jython module makes jEdit scriptable in Python, which is a very nice feature. It should be possible to add a Python IDE in principle, but that would be more work than I can invest at the moment. Konrad. From bob at redivi.com Thu Mar 31 17:12:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 31 17:12:19 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer Message-ID: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> I've put together an "official unofficial" framework build distribution of Python 2.4.1 for Mac OS X 10.3 (and later, but that is not tested yet). It is built using the same tools that Jack builds the official MacPython distribution with. Unlike typical builds, this one has all the stock goodies: - readline 5.0.005 (static) - BerkeleyDB 4.3.27 (static) - waste (static) - Tcl/Tk Aqua 8.4.9 (dynamic - needs TclTkAqua ) Note that this WILL NOT work with Mac OS X 10.2 (Jaguar) or earlier. It is ONLY for Mac OS X 10.3 (Panther) and later. That means, it should work on Mac OS X 10.4 (Tiger) . Also note that it expects you to install to the root drive only, despite the fact that the installer doesn't force you to do this. If you are using Mac OS X 10.3, it is recommended that you also get the PantherPythonFix [1] if you have not already, to prevent conflicts with the stock Python when you build new extensions. Packages for this Python will start popping up at pythonmac.org packages in the coming weeks. And now what you're all waiting for, the download link. It's here: http://undefined.org/python/#python Several packages for MacPython 2.4.1 are already available from: http://pythonmac.org/packages/ [1] You can get PantherPythonFix from http://pythonmac.org/packages/ in the Mac OS X 10.3 (Python 2.3.0) section. -bob From bob at redivi.com Thu Mar 31 18:02:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 31 18:02:32 2005 Subject: [Pythonmac-SIG] ANN: py2app 0.1.9 Message-ID: <7d074a36c208bc55f96eba9ed5369003@redivi.com> (see also: ) `py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.9 is included in the installer for `PyObjC`_ 1.3. If you have installed `PyObjC`_ 1.3, then you already have `py2app`_ 0.1.9 installed. Download and related links are here: http://undefined.org/python/#py2app py2app 0.1.9 is a minor bug fix release: Bugs fixed: - bdist_mpkg now builds zip files that are correctly unzipped by all known tools. - The behavior of the bootstrap has changed slightly such that ``__file__`` should now point to your main script, rather than the bootstrap. The main script has also moved to ``Resources``, from ``Resources/Python``, so that ``__file__`` relative resource paths should still work. .. _`py2app`: http://undefined.org/python/#py2app .. _`pyobjc`: http://pyobjc.sourceforge.net/ .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/ From bob at redivi.com Thu Mar 31 18:10:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 31 18:10:35 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> Message-ID: <2f4f83fe12fb301cac600685df80421b@redivi.com> On Mar 31, 2005, at 10:59 AM, Charles Hartman wrote: > I apologize for being newbiely (nubilely? newbly??) dense, but I want > to make sure I have this straight. I'm running 10.3.8 with the stock > 2.3 framework Python; for Mac I use py2app to make standalone > distributables (though I know that's partly silly since I'm > distributing some stuff that I also can and must assume is on any > target machine, since I'm targeting only 10.3.) Is it true > > 1. that I can download & install this 2.4.1 and it will sit there > politely beside, not interfering with, the stock 2.3 framework? Yes, *if* you have installed PantherPythonFix, it will sit politely beside. If you DO NOT install PantherPythonFix, the stock 2.3 framework will not longer be able to build extensions correctly. > 2. (Then I need to set a path variable to say which one will be used > in various contexts, such as debugging, building with py2app, etc.?) When typing "python": - If /usr/bin comes before /usr/local/bin in your PATH then Python 2.3.0 will be used, if /usr/local/bin comes first, then Python 2.4.1 will be used (of course, with sufficient other crap installed, this may not be true). When typing "python2.3" - Will always choose 2.3.0 (unless you have other crap installed) When typing "python2.4" - Will always choose 2.4.1 (unless you have other crap installed, or /usr/local/bin is not in the path) When running scripts installed by Python packages, their "#!" lines are rewritten to point to a *specific* Python. In those cases, it's whichever you installed most recently. For example, the bdist_mpkg script that comes with py2app. > 3. that the standalone builds I do that way, when distributed to other > users with 10.3+, will work, no matter what they've got on their > machines? Yes, in theory, packages build using 2.4.1 will work on 10.3, 10.4, and later. Packages build using the standard 2.3.0 will work on 10.3 and probably 10.4, but it is unlikely that they will work in 10.5+. The price you pay is a meg or two. > 4. that this will keep being true (probably!) when Tiger is released & > some of my users get ahead of me that way? That's what the 10.3+ means... -bob From lee_cullens at mac.com Thu Mar 31 18:55:15 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Thu Mar 31 18:55:25 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> Message-ID: Bravo Bob :~) already have TclTkAqua (why SPE broke) so I'll give it a whirl Lee C On Mar 31, 2005, at 10:12 AM, Bob Ippolito wrote: > I've put together an "official unofficial" framework build > distribution of Python 2.4.1 for Mac OS X 10.3 (and later, but that is > not tested yet). It is built using the same tools that Jack builds the > official MacPython distribution with. > > Unlike typical builds, this one has all the stock goodies: > - readline 5.0.005 (static) > - BerkeleyDB 4.3.27 (static) > - waste (static) > - Tcl/Tk Aqua 8.4.9 (dynamic - needs TclTkAqua > ) From bob at redivi.com Thu Mar 31 19:02:00 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 31 19:02:05 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> Message-ID: <1947f3e6e78476c270a3649cc696b653@redivi.com> On Mar 31, 2005, at 11:55 AM, Lee Cullens wrote: > On Mar 31, 2005, at 10:12 AM, Bob Ippolito wrote: > >> I've put together an "official unofficial" framework build >> distribution of Python 2.4.1 for Mac OS X 10.3 (and later, but that >> is not tested yet). It is built using the same tools that Jack builds >> the official MacPython distribution with. >> >> Unlike typical builds, this one has all the stock goodies: >> - readline 5.0.005 (static) >> - BerkeleyDB 4.3.27 (static) >> - waste (static) >> - Tcl/Tk Aqua 8.4.9 (dynamic - needs TclTkAqua >> ) > > already have TclTkAqua (why SPE broke) so I'll give it a whirl You only need TclTkAqua *if* you use Tkinter. It's not a requirement of Python 2.4.1. -bob From lee_cullens at mac.com Thu Mar 31 19:11:15 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Thu Mar 31 19:11:33 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> Message-ID: <9b9aa2bcdb495bcbda3c071d6b5d5e76@mac.com> strike "(why SPE broke)" - a confused old man (TclTkAqua is not wxPython) > Bravo Bob :~) > > already have TclTkAqua (why SPE broke) so I'll give it a whirl > > Lee C > > > On Mar 31, 2005, at 10:12 AM, Bob Ippolito wrote: > >> I've put together an "official unofficial" framework build >> distribution of Python 2.4.1 for Mac OS X 10.3 (and later, but that >> is not tested yet). It is built using the same tools that Jack builds >> the official MacPython distribution with. >> >> Unlike typical builds, this one has all the stock goodies: >> - readline 5.0.005 (static) >> - BerkeleyDB 4.3.27 (static) >> - waste (static) >> - Tcl/Tk Aqua 8.4.9 (dynamic - needs TclTkAqua >> ) From hengist.podd at virgin.net Thu Mar 31 20:50:17 2005 From: hengist.podd at virgin.net (has) Date: Thu Mar 31 20:50:26 2005 Subject: [Pythonmac-SIG] appscript and XXXX - what is my app instance returning? Message-ID: Paul Berkowitz wrote: >If appscript >is meant to replace the vagaries of AppleScript with the sanity of Python, >there's no getting around the fact that its whole raison d'?tre - healthy >application scripting - can founder on poorly implemented application >AppleEvent syntax, with no one around to explain it, let alone fix it. The 'syntax problem' I mention is common to both AppleScript and appscript and has _nothing_ to do with individual applications' Apple event support. The problem is that both wrap Apple events in a very OO-like syntax which is easy to use and perfectly sound in itself, but tends to mislead unwary users who assume that because it looks like OO it *is* OO. Which it's not: it's an RPC interface plus simple relational query builder. While I could change appscript's syntax to make it look less OO-like, it would also make it less easy to use. The solution is better education (starting with better documentation, obviously) so that appscript users aren't labouring under any false assumptions when they start to use it. BTW, the last place to learn this stuff is from AppleScript, which plays even more syntactic and semantic tricks and is even worse about informing its users of this. It's something we Python folks will have to provide for ourselves, and I'm sure we will. All of which is a completely separate issue to learning how to effectively script individual applications, which is the problem the OP's having. That has nothing to do with the language/bridge used, and everything to do with learning how an application's Apple Event Object Model works, what it can and can't do, where all the quirks and bugs lie, etc. Information that should be supplied by application developers, of course, but they often don't so users often have to rely on experimentation and shared knowledge to fill in the blanks. Personally I don't think the language difference should be too much of an issue when asking application-related questions, though we'll only find out for sure when appscripters start asking these questions on traditionally AppleScript-oriented lists such as MacScrpt. (As opposed to Python/appscript-related questions, which are still best asked here.) has -- http://freespace.virgin.net/hamish.sanderson/ From ml at fgranger.com Thu Mar 31 21:10:30 2005 From: ml at fgranger.com (Fran=?ISO-8859-1?B?5w==?=ois Granger) Date: Thu Mar 31 21:10:23 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation In-Reply-To: Message-ID: Le 30/03/05 23:42, ??Russell E. Owen?? a ?crit?: > Example: set SubEthaEdit to enter \n when you type (the unix > line ending convention). Then paste in text from any standard Mac app > and notice that the pasted text uses \r as a line ending. You are right. I always have a \r -> \n replace handy (see below why). (as well as a 4 space -> one tab but that is another story). > I recommend TextWrangler as a "must-have" free editor I use Bbedit (it older brother) less and less because it ruin any proper UTF-8 document. SubEthaEdit allow to recover from this. >, though I hate the > find/replace dialog box enough to not use it for coding. (the Bbedit version) It get some time to get to it, but it does really good search, regex, multifile ... -- Convert from markup to markup: http://fgranger.net1.nerim.net/mtom/ From rowen at cesmail.net Thu Mar 31 21:39:51 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Thu Mar 31 21:41:04 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation References: Message-ID: In article , François Granger wrote: > Le 30/03/05 23:42, « Russell E. Owen » a écrit : > >, though I hate ...(BBEdit's) > > find/replace dialog box enough to not use it for coding. > > (the Bbedit version) It get some time to get to it, but it does really good > search, regex, multifile ... I agree that BBEdit does a very good job with regular expressions and multi-file searching (especially the older BBEdit, see below). My main objection is that it is really clumsy and dangerous for doing a one-off "in selection" search and replace (far more so than ANY other editor I've seen). Also, the dialog box is modal, which I loathe (why they can't make that an option is beyond me). Also, if you do decide to upgrade, TextWrangler and the latest BBEdit seem to have much more dangerous multi-file search and replace than the older BBEdit. It is a bit more flexible, but far too easy to search files you had no intention of searching. -- Russell From rowen at cesmail.net Thu Mar 31 21:45:18 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Thu Mar 31 21:46:34 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation References: <70e164530f6f81abaa27f37fd8780c21@mac.com> Message-ID: In article , Lee Cullens wrote: > Just an update Russel, > > I was getting bored going through the TextWrangler docs, and > remembering that I had not even looked at the SubEthaEdit docs when I > used it went back to check out what you said further. First, of > course, such is something that can be set in the perfs and per > document. I found that the only case (that I tried) where I could get > into trouble with line endings was as per your note of pasting in text > that contained CR line endings and that is an issue that might be > troublesome (depending on one's intentions) with many text editors. > I'm sure you already know that showing "hidden" characters is prudent > in such copying. I also noted in my tests that such is the difference > between PythonIDE (uses LF) and IDLE (uses CR), and why only a new-be > dummy like me would mix them. That SubEtha preference only controls what happens when you type . It has no affect on pasted text, as you found. I personally consider this unacceptable for a text editor, and it is certainly not a "feature" of any other text editor I've ever tried. Some programs don't mind the mixed line endings, but others have a horrible time with it. For example svn can't handle commit comments with mixed line endings. > TextWrangler is (to me) too much like its big brother - a do-all > "develop it yourself" sandbox. Great if that's what your into, but a > sidetrack to me. For the moment I'll stick with the simpler > SubEthaEdit which I can even use in Terminal (instead of Pico). Most good text editors allow you to use them as a command-line editor. It is a very handy feature. -- Russell From berkowit at silcom.com Thu Mar 31 22:00:22 2005 From: berkowit at silcom.com (Paul Berkowitz) Date: Thu Mar 31 22:00:26 2005 Subject: [Pythonmac-SIG] appscript and XXXX - what is my app instance returning? In-Reply-To: Message-ID: On 3/31/05 10:50 AM, "has" wrote: > All of which is a completely separate issue to learning how to > effectively script individual applications, which is the problem the > OP's having. That's precisely the problem I was discussing, has. Sorry if that was not clear. > That has nothing to do with the language/bridge used, > and everything to do with learning how an application's Apple Event > Object Model works, what it can and can't do, where all the quirks > and bugs lie, etc. Information that should be supplied by application > developers, of course, but they often don't so users often have to > rely on experimentation and shared knowledge to fill in the blanks. > > Personally I don't think the language difference should be too much > of an issue when asking application-related questions, though we'll > only find out for sure when appscripters start asking these questions > on traditionally AppleScript-oriented lists such as MacScrpt. (As > opposed to Python/appscript-related questions, which are still best > asked here.) I think it might be an issue. Python users who know appscript but not AppleScript will tend to ask questions about application scripting in a way that AppleScripters who don't know Python won't understand. So you personally will probably end up having to check out every application's AppleScript dictionary (which may not always be feasible for expensive commercial apps, although some have demo periods and macscripter.net keeps a collection of dictionaries) and maybe even check out sample AppleScripts. (Somehow I don't see Shane Stanley answering too many appscript questions about Quark.) That will keep you quite busy. If I, or other AppleScripters, ever manage to get around to learning Python properly and then appscript, we might be able to pitch in. But even the very limited documentation that application creators provide for their AppleScript implementations will not be extended to appscript, or even to raw AppleEvent documentation (I think FMP may provide a bit of that.) It will mostly be up to you. Then you'll know how Bob I. must feel on this list...;-) -- Paul Berkowitz