From kenneth.m.mcdonald at sbcglobal.net Tue Jun 1 21:27:35 2004 From: kenneth.m.mcdonald at sbcglobal.net (Kenneth McDonald) Date: Tue Jun 1 21:27:42 2004 Subject: [Pythonmac-SIG] Any way to use Python scripts (instead of Applescript) for folder actions? Message-ID: <06CC467C-B434-11D8-9590-000A956870AC@sbcglobal.net> Or, I guess more accurately, is there any _easy_ way to do this. I'm sure that if I know Applescript I could come up with an Applescript that would run a Python script but, I don't want to learn AppleScript--my brain is already full of languages! More generally, is there any way to hook Python into the system as one can do with AppleScript, _without_ need to venture (far) outside of Python? Thanks, Ken McDonald From bob at redivi.com Tue Jun 1 21:37:40 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jun 1 21:37:52 2004 Subject: [Pythonmac-SIG] Any way to use Python scripts (instead of Applescript) for folder actions? In-Reply-To: <06CC467C-B434-11D8-9590-000A956870AC@sbcglobal.net> References: <06CC467C-B434-11D8-9590-000A956870AC@sbcglobal.net> Message-ID: <6F856BD4-B435-11D8-9B3A-000A95686CD8@redivi.com> On Jun 1, 2004, at 9:27 PM, Kenneth McDonald wrote: > Or, I guess more accurately, is there any _easy_ way to do this. I'm > sure that > if I know Applescript I could come up with an Applescript that would > run a > Python script but, I don't want to learn AppleScript--my brain is > already full > of languages! More generally, is there any way to hook Python into the > system > as one can do with AppleScript, _without_ need to venture (far) > outside of > Python? What do you mean, more specificially? What do you want Python to do? -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040601/de933306/smime.bin From ghoover19 at cox.net Wed Jun 2 03:57:05 2004 From: ghoover19 at cox.net (Greg Hoover) Date: Wed Jun 2 03:57:19 2004 Subject: [Pythonmac-SIG] Bus Error: wxPython Message-ID: <70472CD4-B46A-11D8-B95F-003065A6DED8@cox.net> I've got a strange situation when using wxPython (version 2.4.2.4 btw). The main class creates two frames, one of which functions correctly. The second has a bizarre behavior. When running the code below, the application quits due to a Bus Error, more specifically a EXC_BAD_ACCESS exception. If I comment out the EVT_BUTTON event handler lines, the code runs fine. The panel below is added to a wxNotebook inside of a wxFrame. Any ideas? Or advice for tracking this down further? Here is the offending code: #/usr/bin/pythonw from wxPython.wx import * # # ADC FILE PANEL # class adcFilePanel(wxPanel): def __init__(self, parent, size, id, pos = wxDefaultPosition, style = wxNO_BORDER): wxPanel.__init__(self, parent, id, pos, size) self.parent = parent self.uploadFile = wxTextCtrl(self, -1, 'ADC Upload File', pos = wxPoint(20, 20), size = wxSize(250, 24)) self.downloadFile = wxTextCtrl(self, -1, 'ADC Download File', pos = wxPoint(20, 55), size = wxSize(250, 24)) self.uploadButton = wxButton(self, 1030, label = 'Upload', pos = wxPoint(280, 20)) EVT_BUTTON(self, 1030, self.uploadFile) self.downloadButton = wxButton(self, 1031, label = 'Download', pos = wxPoint(280, 55)) EVT_BUTTON(self, 1031, self.downloadFile) self.Show(true) def dispose(self, event): self.Show(False) del self def uploadFile(self, event): pass def downloadFile(self, event): pass Here is the resulting crash log: ********** Host Name: xserver Date/Time: 2004-06-02 00:52:06 -0700 OS Version: 10.3.4 (Build 7H63) 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: 7360 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000028 Thread 0 Crashed: 0 <<00000000>> 0x95fb8d08 0 + 0x95fb8d08 1 <<00000000>> 0x95f4e4ec 0 + 0x95f4e4ec 2 <<00000000>> 0x95f737dc 0 + 0x95f737dc 3 <<00000000>> 0x95f74618 0 + 0x95f74618 4 wxc.so 0x0101bab8 _wrap_wxEvtHandler_Connect + 0x118 5 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 6 <<00000000>> 0x95fa9df0 0 + 0x95fa9df0 7 <<00000000>> 0x95fa6d44 0 + 0x95fa6d44 8 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 9 <<00000000>> 0x95fa97dc 0 + 0x95fa97dc 10 <<00000000>> 0x95fa9580 0 + 0x95fa9580 11 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 12 <<00000000>> 0x95fa9728 0 + 0x95fa9728 13 <<00000000>> 0x95fa9580 0 + 0x95fa9580 14 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 15 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 16 <<00000000>> 0x95f5f354 0 + 0x95f5f354 17 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 18 <<00000000>> 0x95f529e8 0 + 0x95f529e8 19 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 20 <<00000000>> 0x95fa91ec 0 + 0x95fa91ec 21 <<00000000>> 0x95f4de40 0 + 0x95f4de40 22 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 23 <<00000000>> 0x95fa9ba8 0 + 0x95fa9ba8 24 <<00000000>> 0x95fa9598 0 + 0x95fa9598 25 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 26 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 27 <<00000000>> 0x95f5f354 0 + 0x95f5f354 28 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 29 <<00000000>> 0x95f529e8 0 + 0x95f529e8 30 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 31 <<00000000>> 0x95fa91ec 0 + 0x95fa91ec 32 <<00000000>> 0x95f4de40 0 + 0x95f4de40 33 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 34 <<00000000>> 0x95fa9ba8 0 + 0x95fa9ba8 35 <<00000000>> 0x95fa9598 0 + 0x95fa9598 36 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 37 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 38 <<00000000>> 0x95fa4734 0 + 0x95fa4734 39 <<00000000>> 0x95fc85f0 0 + 0x95fc85f0 40 <<00000000>> 0x95fc7668 0 + 0x95fc7668 41 <<00000000>> 0x95fd1ec0 0 + 0x95fd1ec0 42 org.python.python 0x00003c78 0x1000 + 0x2c78 43 org.python.python 0x00003aec 0x1000 + 0x2aec Thread 1: 0 libSystem.B.dylib 0x900074c8 mach_msg_trap + 0x8 1 libSystem.B.dylib 0x90007018 mach_msg + 0x38 2 com.unsanity.ape 0xc000a954 __ape_internal + 0x90b8 3 com.unsanity.ape 0xc0001328 __ape_agent + 0x40 4 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 ...lagutin.audio_hijack.server 0x00798770 ah_serv_loop + 0x58 3 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28 PPC Thread State: srr0: 0x95fb8d08 srr1: 0x0000f030 vrsave: 0x00000000 cr: 0x24224222 xer: 0x00000004 lr: 0x95f4e3a8 ctr: 0x95fb8cec r0: 0x95f4e3a8 r1: 0xbfffe100 r2: 0x00000000 r3: 0x00000000 r4: 0xa5f47cd0 r5: 0x4221c438 r6: 0x00000000 r7: 0x00000061 r8: 0x0000006c r9: 0x00000018 r10: 0x95fb8cf4 r11: 0xa5f607b8 r12: 0x95fb8cec r13: 0x015cbbe0 r14: 0x00000000 r15: 0x015cec38 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000003 r20: 0x003ab61c r21: 0x003054c0 r22: 0x00000000 r23: 0x0114cfe4 r24: 0x003054c0 r25: 0x00002713 r26: 0xffffffff r27: 0x00019520 r28: 0x00000000 r29: 0x017ea648 r30: 0x00019534 r31: 0x95f4e2bc Binary Images Description: 0x1000 - 0x4fff org.python.python 2.3 /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ Python.app/Contents/MacOS/Python 0x795000 - 0x79afff alex_lagutin.audio_hijack.server 1.2 /Library/Application Enhancers/Audio Hijack Server.ape/Contents/MacOS/Audio Hijack Server 0x1008000 - 0x11f2fff wxc.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/wxPython/wxc.so 0x17f6000 - 0x17fafff array.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/array.so 0x2008000 - 0x2009fff time.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/time.so 0x2014000 - 0x2017fff strop.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/strop.so 0x201f000 - 0x2020fff fcntl.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/fcntl.so 0x2027000 - 0x2028fff termios.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/termios.so 0x2031000 - 0x2034fff struct.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/struct.so 0x203b000 - 0x203cfff select.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/select.so 0x204f000 - 0x205afff _curses.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/_curses.so 0x20a2000 - 0x20a3fff macSerialLocator.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/macSerialLocator.so 0x20ab000 - 0x20acfff MacOS.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/MacOS.so 0x25b8000 - 0x28bbfff libwx_mac-2.4.0.dylib /usr/local/lib/libwx_mac-2.4.0.dylib 0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld 0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90190000 - 0x9023dfff com.apple.CoreFoundation 6.3.4 (299.31) /System/Library/Frameworks/CoreFoundation.framework/Versions/ A/CoreFoundation 0x90280000 - 0x904f9fff com.apple.CoreServices.CarbonCore 10.3.4 /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x90570000 - 0x905defff com.apple.framework.IOKit 1.3.2 (???) /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 0xc0000000 - 0xc000efff com.unsanity.ape 1.4.1 /Library/Frameworks/ApplicationEnhancer.framework/Versions/A/ ApplicationEnhancer Thanks in advance. --Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 8685 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040602/2bb62875/attachment.bin From ghoover19 at cox.net Wed Jun 2 04:06:22 2004 From: ghoover19 at cox.net (Greg Hoover) Date: Wed Jun 2 04:06:42 2004 Subject: [Pythonmac-SIG] Bus Error: wxPython In-Reply-To: <70472CD4-B46A-11D8-B95F-003065A6DED8@cox.net> References: <70472CD4-B46A-11D8-B95F-003065A6DED8@cox.net> Message-ID: Nevermind...found the problem. There must be a name conflict in some library, because when I changed the names of the event handler functions the application doesn't crash. --Greg On Jun 2, 2004, at 12:57 AM, Greg Hoover wrote: > I've got a strange situation when using wxPython (version 2.4.2.4 > btw). The main class creates two frames, one of which functions > correctly. The second has a bizarre behavior. When running the code > below, the application quits due to a Bus Error, more specifically a > EXC_BAD_ACCESS exception. If I comment out the EVT_BUTTON event > handler lines, the code runs fine. The panel below is added to a > wxNotebook inside of a wxFrame. Any ideas? Or advice for tracking > this down further? > > Here is the offending code: > > #/usr/bin/pythonw > > from wxPython.wx import * > > # > # ADC FILE PANEL > # > class adcFilePanel(wxPanel): > def __init__(self, parent, size, id, pos = wxDefaultPosition, style = > wxNO_BORDER): > wxPanel.__init__(self, parent, id, pos, size) > > self.parent = parent > > self.uploadFile = wxTextCtrl(self, -1, 'ADC Upload File', > pos = wxPoint(20, 20), > size = wxSize(250, 24)) > > self.downloadFile = wxTextCtrl(self, -1, 'ADC Download File', > pos = wxPoint(20, 55), > size = wxSize(250, 24)) > > self.uploadButton = wxButton(self, 1030, > label = 'Upload', > pos = wxPoint(280, 20)) > > EVT_BUTTON(self, 1030, self.uploadFile) > > > self.downloadButton = wxButton(self, 1031, > label = 'Download', > pos = wxPoint(280, 55)) > > EVT_BUTTON(self, 1031, self.downloadFile) > > self.Show(true) > > > > def dispose(self, event): > > self.Show(False) > > del self > > > def uploadFile(self, event): > > pass > > > def downloadFile(self, event): > > pass > > > > Here is the resulting crash log: > > ********** > > Host Name: xserver > Date/Time: 2004-06-02 00:52:06 -0700 > OS Version: 10.3.4 (Build 7H63) > 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: 7360 > Thread: 0 > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000028 > > Thread 0 Crashed: > 0 <<00000000>> 0x95fb8d08 0 + 0x95fb8d08 > 1 <<00000000>> 0x95f4e4ec 0 + 0x95f4e4ec > 2 <<00000000>> 0x95f737dc 0 + 0x95f737dc > 3 <<00000000>> 0x95f74618 0 + 0x95f74618 > 4 wxc.so 0x0101bab8 > _wrap_wxEvtHandler_Connect + 0x118 > 5 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 > 6 <<00000000>> 0x95fa9df0 0 + 0x95fa9df0 > 7 <<00000000>> 0x95fa6d44 0 + 0x95fa6d44 > 8 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 > 9 <<00000000>> 0x95fa97dc 0 + 0x95fa97dc > 10 <<00000000>> 0x95fa9580 0 + 0x95fa9580 > 11 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 > 12 <<00000000>> 0x95fa9728 0 + 0x95fa9728 > 13 <<00000000>> 0x95fa9580 0 + 0x95fa9580 > 14 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 > 15 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 > 16 <<00000000>> 0x95f5f354 0 + 0x95f5f354 > 17 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 > 18 <<00000000>> 0x95f529e8 0 + 0x95f529e8 > 19 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 > 20 <<00000000>> 0x95fa91ec 0 + 0x95fa91ec > 21 <<00000000>> 0x95f4de40 0 + 0x95f4de40 > 22 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 > 23 <<00000000>> 0x95fa9ba8 0 + 0x95fa9ba8 > 24 <<00000000>> 0x95fa9598 0 + 0x95fa9598 > 25 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 > 26 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 > 27 <<00000000>> 0x95f5f354 0 + 0x95f5f354 > 28 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 > 29 <<00000000>> 0x95f529e8 0 + 0x95f529e8 > 30 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 > 31 <<00000000>> 0x95fa91ec 0 + 0x95fa91ec > 32 <<00000000>> 0x95f4de40 0 + 0x95f4de40 > 33 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 > 34 <<00000000>> 0x95fa9ba8 0 + 0x95fa9ba8 > 35 <<00000000>> 0x95fa9598 0 + 0x95fa9598 > 36 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 > 37 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 > 38 <<00000000>> 0x95fa4734 0 + 0x95fa4734 > 39 <<00000000>> 0x95fc85f0 0 + 0x95fc85f0 > 40 <<00000000>> 0x95fc7668 0 + 0x95fc7668 > 41 <<00000000>> 0x95fd1ec0 0 + 0x95fd1ec0 > 42 org.python.python 0x00003c78 0x1000 + 0x2c78 > 43 org.python.python 0x00003aec 0x1000 + 0x2aec > > Thread 1: > 0 libSystem.B.dylib 0x900074c8 mach_msg_trap + 0x8 > 1 libSystem.B.dylib 0x90007018 mach_msg + 0x38 > 2 com.unsanity.ape 0xc000a954 __ape_internal + 0x90b8 > 3 com.unsanity.ape 0xc0001328 __ape_agent + 0x40 > 4 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 ...lagutin.audio_hijack.server 0x00798770 ah_serv_loop + 0x58 > 3 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28 > > PPC Thread State: > srr0: 0x95fb8d08 srr1: 0x0000f030 vrsave: 0x00000000 > cr: 0x24224222 xer: 0x00000004 lr: 0x95f4e3a8 ctr: 0x95fb8cec > r0: 0x95f4e3a8 r1: 0xbfffe100 r2: 0x00000000 r3: 0x00000000 > r4: 0xa5f47cd0 r5: 0x4221c438 r6: 0x00000000 r7: 0x00000061 > r8: 0x0000006c r9: 0x00000018 r10: 0x95fb8cf4 r11: 0xa5f607b8 > r12: 0x95fb8cec r13: 0x015cbbe0 r14: 0x00000000 r15: 0x015cec38 > r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000003 > r20: 0x003ab61c r21: 0x003054c0 r22: 0x00000000 r23: 0x0114cfe4 > r24: 0x003054c0 r25: 0x00002713 r26: 0xffffffff r27: 0x00019520 > r28: 0x00000000 r29: 0x017ea648 r30: 0x00019534 r31: 0x95f4e2bc > > Binary Images Description: > 0x1000 - 0x4fff org.python.python > 2.3 /System/Library/Frameworks/Python.framework/Versions/2.3/ > Resources/Python.app/Contents/MacOS/Python > 0x795000 - 0x79afff alex_lagutin.audio_hijack.server > 1.2 /Library/Application Enhancers/Audio Hijack > Server.ape/Contents/MacOS/Audio Hijack Server > 0x1008000 - 0x11f2fff wxc.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/wxPython/wxc.so > 0x17f6000 - 0x17fafff array.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload/array.so > 0x2008000 - 0x2009fff time.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload/time.so > 0x2014000 - 0x2017fff strop.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload/strop.so > 0x201f000 - 0x2020fff fcntl.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload/fcntl.so > 0x2027000 - 0x2028fff termios.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload/termios.so > 0x2031000 - 0x2034fff struct.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload/struct.so > 0x203b000 - 0x203cfff select.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload/select.so > 0x204f000 - 0x205afff _curses.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload/_curses.so > 0x20a2000 - 0x20a3fff macSerialLocator.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/macSerialLocator.so > 0x20ab000 - 0x20acfff MacOS.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload/MacOS.so > 0x25b8000 - 0x28bbfff libwx_mac-2.4.0.dylib > /usr/local/lib/libwx_mac-2.4.0.dylib > 0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld > 0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/libSystem.B.dylib > 0x90190000 - 0x9023dfff com.apple.CoreFoundation 6.3.4 > (299.31) /System/Library/Frameworks/CoreFoundation.framework/Versions/ > A/CoreFoundation > 0x90280000 - 0x904f9fff com.apple.CoreServices.CarbonCore > 10.3.4 /System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/CarbonCore.framework/Versions/A/CarbonCore > 0x90570000 - 0x905defff com.apple.framework.IOKit 1.3.2 > (???) /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 > 0xc0000000 - 0xc000efff com.unsanity.ape > 1.4.1 /Library/Frameworks/ApplicationEnhancer.framework/Versions/A/ > ApplicationEnhancer > > > Thanks in advance. > > --Greg_______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 9096 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040602/91b90325/attachment-0001.bin From hengist.podd at virgin.net Wed Jun 2 09:46:08 2004 From: hengist.podd at virgin.net (has) Date: Wed Jun 2 10:10:39 2004 Subject: [Pythonmac-SIG] Any way to use Python scripts (instead of Applescript) for folder actions? Message-ID: Kenneth McDonald wrote: >Or, I guess more accurately, is there any _easy_ way to do this. Not really. It requires two things we don't currently have: OSA support in MacPython, and better OSA support in Cocoa[1]. >I'm sure that if I know Applescript I could come up with an >Applescript that would run a Python script but, I don't want to >learn AppleScript--my brain is already full of languages! It's a PITA to learn anyway; slow, bug-laden, and riddled with design flaws. (Some core aspects are quite nice; e.g. Smalltalk-style messaging and built-in object persistence, and a very neat, if underpowered, prototype-based object system that I much prefer over Python's class-based bottomless pit. But mostly it's a mess.) Best thing is to write an AppleScript wrapper that runs a shell script upon receiving folder events. Here's one I knocked together: ---------------------------------------------------------------------- -- PROPERTIES property shellScriptPath : "/path/to/shell/script" -- YOUR PATH HERE -- SUPPORT on _doScript(folderAction, folderAlias, args) try do shell script ? (quoted form of my shellScriptPath) & space & ? quoted form of folderAction & space & ? quoted form of POSIX path of folderAlias & space & ? args on error eMsg number eNum beep 2 tell application "Finder" activate display dialog eMsg & return & eNum with icon stop end tell end try end _doScript on _escAliasList(lst) set str to "" repeat with aliasRef in lst set str to str & quoted form of POSIX path of aliasRef & space end repeat return str end _escAliasList -- EVENT HANDLERS on opening folder folderAlias _doScript("opening folder", folderAlias, "") end opening folder on closing folder window for folderAlias _doScript("closing folder window", folderAlias, "") end closing folder window for on moving folder window for folderAlias from boundingRect set AppleScript's text item delimiters to space _doScript("moving folder window", folderAlias, boundingRect as string) end moving folder window for on adding folder items to folderAlias after receiving aliasList _doScript("adding folder items", folderAlias, _escAliasList(aliasList)) end adding folder items to on removing folder items from folderAlias after losing aliasList _doScript("removing folder items", folderAlias, _escAliasList(aliasList)) end removing folder items from ---------------------------------------------------------------------- >More generally, is there any way to hook Python into the system as >one can do with AppleScript, _without_ need to venture (far) outside >of Python? AppleScripts don't directly hook into the system; they're attached to apps like System Events that translate application/system-level events into Apple events that they fire at those attached scripts to trigger their handlers. Like I say, the only reason Perl, Python, etc. can't be used in place of AppleScript here is that folk [on both sides] haven't yet done the OSA support needed. MacPython's application scripting support is a bit further on [though I really need help to complete it in time for the MacPython 2.4 release; hint-hint]; see: HTH has [1] Its current offering, NSAppleScript, only supports AppleScripts, which is no good if you want to attach scripts written in other OSA languages to Cocoa apps, of which System Events is one. -- http://freespace.virgin.net/hamish.sanderson/ From kevino at tulane.edu Wed Jun 2 10:53:34 2004 From: kevino at tulane.edu (Kevin Ollivier) Date: Wed Jun 2 10:53:44 2004 Subject: [Pythonmac-SIG] Bus Error: wxPython In-Reply-To: References: <70472CD4-B46A-11D8-B95F-003065A6DED8@cox.net> Message-ID: <9EDFF904-B4A4-11D8-BB1D-000393CB1C86@tulane.edu> Hi Greg, Take a close look at your original code. self.uploadFile is used *both* as the name of a wxTextCtrl, and the name of the button's event handler, which obviously is a problem. There isn't any library conflict, but there is a naming conflict in your own code. Thanks, Kevin On Jun 2, 2004, at 1:06 AM, Greg Hoover wrote: > Nevermind...found the problem. There must be a name conflict in some > library, because when I changed the names of the event handler > functions the application doesn't crash. > > --Greg > > On Jun 2, 2004, at 12:57 AM, Greg Hoover wrote: > >> I've got a strange situation when using wxPython (version 2.4.2.4 >> btw). The main class creates two frames, one of which functions >> correctly. The second has a bizarre behavior. When running the code >> below, the application quits due to a Bus Error, more specifically a >> EXC_BAD_ACCESS exception. If I comment out the EVT_BUTTON event >> handler lines, the code runs fine. The panel below is added to a >> wxNotebook inside of a wxFrame. Any ideas? Or advice for tracking >> this down further? >> >> Here is the offending code: >> >> #/usr/bin/pythonw >> >> from wxPython.wx import * >> >> # >> # ADC FILE PANEL >> # >> class adcFilePanel(wxPanel): >> def __init__(self, parent, size, id, pos = wxDefaultPosition, style >> = wxNO_BORDER): >> wxPanel.__init__(self, parent, id, pos, size) >> >> self.parent = parent >> >> self.uploadFile = wxTextCtrl(self, -1, 'ADC Upload File', >> pos = wxPoint(20, 20), >> size = wxSize(250, 24)) >> >> self.downloadFile = wxTextCtrl(self, -1, 'ADC Download File', >> pos = wxPoint(20, 55), >> size = wxSize(250, 24)) >> >> self.uploadButton = wxButton(self, 1030, >> label = 'Upload', >> pos = wxPoint(280, 20)) >> >> EVT_BUTTON(self, 1030, self.uploadFile) >> >> >> self.downloadButton = wxButton(self, 1031, >> label = 'Download', >> pos = wxPoint(280, 55)) >> >> EVT_BUTTON(self, 1031, self.downloadFile) >> >> self.Show(true) >> >> >> >> def dispose(self, event): >> >> self.Show(False) >> >> del self >> >> >> def uploadFile(self, event): >> >> pass >> >> >> def downloadFile(self, event): >> >> pass >> >> >> >> Here is the resulting crash log: >> >> ********** >> >> Host Name: xserver >> Date/Time: 2004-06-02 00:52:06 -0700 >> OS Version: 10.3.4 (Build 7H63) >> 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: 7360 >> Thread: 0 >> >> Exception: EXC_BAD_ACCESS (0x0001) >> Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000028 >> >> Thread 0 Crashed: >> 0 <<00000000>> 0x95fb8d08 0 + 0x95fb8d08 >> 1 <<00000000>> 0x95f4e4ec 0 + 0x95f4e4ec >> 2 <<00000000>> 0x95f737dc 0 + 0x95f737dc >> 3 <<00000000>> 0x95f74618 0 + 0x95f74618 >> 4 wxc.so 0x0101bab8 >> _wrap_wxEvtHandler_Connect + 0x118 >> 5 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 >> 6 <<00000000>> 0x95fa9df0 0 + 0x95fa9df0 >> 7 <<00000000>> 0x95fa6d44 0 + 0x95fa6d44 >> 8 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 >> 9 <<00000000>> 0x95fa97dc 0 + 0x95fa97dc >> 10 <<00000000>> 0x95fa9580 0 + 0x95fa9580 >> 11 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 >> 12 <<00000000>> 0x95fa9728 0 + 0x95fa9728 >> 13 <<00000000>> 0x95fa9580 0 + 0x95fa9580 >> 14 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 >> 15 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 >> 16 <<00000000>> 0x95f5f354 0 + 0x95f5f354 >> 17 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 >> 18 <<00000000>> 0x95f529e8 0 + 0x95f529e8 >> 19 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 >> 20 <<00000000>> 0x95fa91ec 0 + 0x95fa91ec >> 21 <<00000000>> 0x95f4de40 0 + 0x95f4de40 >> 22 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 >> 23 <<00000000>> 0x95fa9ba8 0 + 0x95fa9ba8 >> 24 <<00000000>> 0x95fa9598 0 + 0x95fa9598 >> 25 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 >> 26 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 >> 27 <<00000000>> 0x95f5f354 0 + 0x95f5f354 >> 28 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 >> 29 <<00000000>> 0x95f529e8 0 + 0x95f529e8 >> 30 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 >> 31 <<00000000>> 0x95fa91ec 0 + 0x95fa91ec >> 32 <<00000000>> 0x95f4de40 0 + 0x95f4de40 >> 33 <<00000000>> 0x95f4a8d0 0 + 0x95f4a8d0 >> 34 <<00000000>> 0x95fa9ba8 0 + 0x95fa9ba8 >> 35 <<00000000>> 0x95fa9598 0 + 0x95fa9598 >> 36 <<00000000>> 0x95fa6c64 0 + 0x95fa6c64 >> 37 <<00000000>> 0x95fa7e30 0 + 0x95fa7e30 >> 38 <<00000000>> 0x95fa4734 0 + 0x95fa4734 >> 39 <<00000000>> 0x95fc85f0 0 + 0x95fc85f0 >> 40 <<00000000>> 0x95fc7668 0 + 0x95fc7668 >> 41 <<00000000>> 0x95fd1ec0 0 + 0x95fd1ec0 >> 42 org.python.python 0x00003c78 0x1000 + 0x2c78 >> 43 org.python.python 0x00003aec 0x1000 + 0x2aec >> >> Thread 1: >> 0 libSystem.B.dylib 0x900074c8 mach_msg_trap + 0x8 >> 1 libSystem.B.dylib 0x90007018 mach_msg + 0x38 >> 2 com.unsanity.ape 0xc000a954 __ape_internal + 0x90b8 >> 3 com.unsanity.ape 0xc0001328 __ape_agent + 0x40 >> 4 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 ...lagutin.audio_hijack.server 0x00798770 ah_serv_loop + 0x58 >> 3 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28 >> >> PPC Thread State: >> srr0: 0x95fb8d08 srr1: 0x0000f030 vrsave: 0x00000000 >> cr: 0x24224222 xer: 0x00000004 lr: 0x95f4e3a8 ctr: 0x95fb8cec >> r0: 0x95f4e3a8 r1: 0xbfffe100 r2: 0x00000000 r3: 0x00000000 >> r4: 0xa5f47cd0 r5: 0x4221c438 r6: 0x00000000 r7: 0x00000061 >> r8: 0x0000006c r9: 0x00000018 r10: 0x95fb8cf4 r11: 0xa5f607b8 >> r12: 0x95fb8cec r13: 0x015cbbe0 r14: 0x00000000 r15: 0x015cec38 >> r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000003 >> r20: 0x003ab61c r21: 0x003054c0 r22: 0x00000000 r23: 0x0114cfe4 >> r24: 0x003054c0 r25: 0x00002713 r26: 0xffffffff r27: 0x00019520 >> r28: 0x00000000 r29: 0x017ea648 r30: 0x00019534 r31: 0x95f4e2bc >> >> Binary Images Description: >> 0x1000 - 0x4fff org.python.python >> 2.3 /System/Library/Frameworks/Python.framework/Versions/2.3/ >> Resources/Python.app/Contents/MacOS/Python >> 0x795000 - 0x79afff alex_lagutin.audio_hijack.server >> 1.2 /Library/Application Enhancers/Audio Hijack >> Server.ape/Contents/MacOS/Audio Hijack Server >> 0x1008000 - 0x11f2fff wxc.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/wxPython/wxc.so >> 0x17f6000 - 0x17fafff array.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-dynload/array.so >> 0x2008000 - 0x2009fff time.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-dynload/time.so >> 0x2014000 - 0x2017fff strop.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-dynload/strop.so >> 0x201f000 - 0x2020fff fcntl.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-dynload/fcntl.so >> 0x2027000 - 0x2028fff termios.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-dynload/termios.so >> 0x2031000 - 0x2034fff struct.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-dynload/struct.so >> 0x203b000 - 0x203cfff select.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-dynload/select.so >> 0x204f000 - 0x205afff _curses.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-dynload/_curses.so >> 0x20a2000 - 0x20a3fff macSerialLocator.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/macSerialLocator.so >> 0x20ab000 - 0x20acfff MacOS.so >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-dynload/MacOS.so >> 0x25b8000 - 0x28bbfff libwx_mac-2.4.0.dylib >> /usr/local/lib/libwx_mac-2.4.0.dylib >> 0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld >> 0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/libSystem.B.dylib >> 0x90190000 - 0x9023dfff com.apple.CoreFoundation 6.3.4 >> (299.31) /System/Library/Frameworks/CoreFoundation.framework/ >> Versions/A/CoreFoundation >> 0x90280000 - 0x904f9fff com.apple.CoreServices.CarbonCore >> 10.3.4 /System/Library/Frameworks/CoreServices.framework/Versions/A/ >> Frameworks/CarbonCore.framework/Versions/A/CarbonCore >> 0x90570000 - 0x905defff com.apple.framework.IOKit 1.3.2 >> (???) /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 >> 0xc0000000 - 0xc000efff com.unsanity.ape >> 1.4.1 /Library/Frameworks/ApplicationEnhancer.framework/Versions/A/ >> ApplicationEnhancer >> >> >> Thanks in advance. >> >> --Greg_______________________________________________ >> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 9610 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040602/95f7615c/attachment.bin From Jonathan.Peirce at nottingham.ac.uk Wed Jun 2 10:54:46 2004 From: Jonathan.Peirce at nottingham.ac.uk (Jon Peirce) Date: Wed Jun 2 10:54:51 2004 Subject: [Pythonmac-SIG] package manager parsing error In-Reply-To: <40BDE432.7060608@psychology.nottingham.ac.uk> References: <40BDE432.7060608@psychology.nottingham.ac.uk> Message-ID: <40BDEA36.2010401@psychology.nottingham.ac.uk> I've just installed the python panther addons to a completely fresh, new machine (10.3.3) but can't get going with pacakge manager. It finds the database (so not a firewall error) but gives me 'unspecified error parsing database:....' and tells me that the it probably isn't formatted properly. I;ve tried several different ones from the list of databases (Jack's and Bob's) as well as the default one, with the same error each time. Has anyone else seen this? Is it a 10.3.3 issue? Jon This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From Jonathan.Peirce at nottingham.ac.uk Thu Jun 3 06:11:21 2004 From: Jonathan.Peirce at nottingham.ac.uk (Jon Peirce) Date: Thu Jun 3 06:11:29 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 14, Issue 2 In-Reply-To: References: Message-ID: <40BEF949.5060201@psychology.nottingham.ac.uk> So I now realise that there was a previous report of this last year (so probably nothing to do with this OSX version). The diagnosis then was to do with the firewall. In my case, I did have a firewall problem initially, which was causing the databases not to be found. So I set the appropriate http proxy in my environment.plist as instructed and it was then that the databases were found but caused the 'unspecified error while parsing'. If I download the database files and point to them locally rather than pointing to their URLs I get the same problem. Which leaves me at a bit of a loss. Any other things I should try? Jon > I've just installed the python panther addons to a completely fresh, > new machine (10.3.3) but can't get going with pacakge manager. It > finds the database (so not a firewall error) but gives me 'unspecified > error parsing database:....' and tells me that the it probably isn't > formatted properly. I;ve tried several different ones from the list of > databases (Jack's and Bob's) as well as the default one, with the same > error each time. > > Has anyone else seen this? Is it a 10.3.3 issue? > > Jon This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From pharr at nemetschek.net Thu Jun 3 13:56:17 2004 From: pharr at nemetschek.net (Paul C. Pharr) Date: Thu Jun 3 13:56:25 2004 Subject: [Pythonmac-SIG] macostools.copy failing after volumes are mounted or unmounted during script execution Message-ID: Hi everyeone, I have attempted to use the macostools.copy call under python 2.3 (stock install under Panther) to copy a large quantity of files to a file server from a python script which runs continuously as a server process. After recently changing the script to dynamically mount the server volumes as necessary using the command line "mount" command, I started getting seemingly random, but frequent failures referencing a -120 Directory Not Found error. After investigation, it turned out that this failure always happened on the third copy operation to a new directory. Thinking I had found a subtle MacOS X bug, I submitted a request to Apple's Developer Technical Support, and after a few days got a long and informative response which said essentially that: The Carbon File Manager, opon which macostools is based, depends on being notified within the process's runloop when volumes are mounted or unmounted within the file system. When I make a system call from my script to mount or unmount a volume, my script and its instance of the Carbon File Manager is not notified because it does not have a runloop. My question to you Mac Python experts out there is this: I have seen some references to Mac python scripts implementing a runloop to respond to system needs. Is there a standard, simple (hopefully trivial) way to do this which would allow Carbon File Manager to get the notification it needs? Is there a complicated way to accomplish this? Alternately, does anyone know of smething I can do within my script after mounting or unmounting a volume from within my script which will give CFM a kick so it will requery the state of all mounted volumes and eliminate the need to respond to these notifications? Many thanks in advance, Paul Pharr From hengist.podd at virgin.net Thu Jun 3 19:09:01 2004 From: hengist.podd at virgin.net (has) Date: Thu Jun 3 19:09:20 2004 Subject: [Pythonmac-SIG] [FWD] OSABase Message-ID: One for Jack, Bob, Donovan, Ronald, et-al (or anyone else really with an interest in this stuff;)... Philip Aker - a hoopy frood who definitely knows where his towel is - recently posted OSABase, a funky wrapper for bringing OSA goodness to the many fine languages whose names do not currently begin in 'Apple' and end in 'Script'. :) While I'm personally much to thick to really understand this stuff myself, and suspect it may require a spot of negotiation vis-a-vis licences to ensure pure plain sailing, I really think it worth one of MacPython's Primary Brains at least investigating it to see if it's a viable option for providing MacPython OSA support. Full OSA component support in MacPython 2.4 would be great to see - especially if 2.4 will be finding its way into Tiger [do you know if it will?]. Just imagine having every AppleScripter see MacPython's name popping up in Script Editor's language menu - instant increase in exposure and brandname awareness boost. It might also help guilt Apple into brushing up their Cocoa framework's own OSA support if they haven't already done so by then; give us decent attachability support for stuff like Folder Actions, Mail rules, InDesign (publishing workflow automation could be a great new market for MacPython once its IAC support is up to snuff), and the rest - even nicer. Anyway, here's the link: http://homepage.mac.com/philip_aker/osa/osa.html Fingers crossed, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Thu Jun 3 19:39:06 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Jun 3 19:39:16 2004 Subject: [Pythonmac-SIG] [FWD] OSABase In-Reply-To: References: Message-ID: <346FBE4C-B5B7-11D8-B453-000A95686CD8@redivi.com> On Jun 3, 2004, at 7:09 PM, has wrote: > One for Jack, Bob, Donovan, Ronald, et-al (or anyone else really with > an interest in this stuff;)... > > Philip Aker - a hoopy frood who definitely knows where his towel is - > recently posted OSABase, a funky wrapper for bringing OSA goodness to > the many fine languages whose names do not currently begin in 'Apple' > and end in 'Script'. :) > > While I'm personally much to thick to really understand this stuff > myself, and suspect it may require a spot of negotiation vis-a-vis > licences to ensure pure plain sailing, I really think it worth one of > MacPython's Primary Brains at least investigating it to see if it's a > viable option for providing MacPython OSA support. The license scenario looks bad. You can't even download it without emailing him and saying "yes I comply with this license". We'd probably be better off starting from scratch unless you can convince him to make his stuff open source under a PSF compatible license. > Full OSA component support in MacPython 2.4 would be great to see - > especially if 2.4 will be finding its way into Tiger [do you know if > it will?]. Just imagine having every AppleScripter see MacPython's > name popping up in Script Editor's language menu - instant increase in > exposure and brandname awareness boost. It might also help guilt Apple > into brushing up their Cocoa framework's own OSA support if they > haven't already done so by then; give us decent attachability support > for stuff like Folder Actions, Mail rules, InDesign (publishing > workflow automation could be a great new market for MacPython once its > IAC support is up to snuff), and the rest - even nicer. > > Anyway, here's the link: > http://homepage.mac.com/philip_aker/osa/osa.html There is approximately no chance whatsoever of OSA component support making it into Python 2.4. The first alpha is almost out the door, and there isn't even a prototype or PEP that detains the whys and hows. It would be great if we had it, but it won't be a standard feature until Python 2.5 at the earliest. Not sure about Tiger and Python 2.4, I'm guessing they will probably take Python 2.3.x for the largest number x that is a stable Python at the time Tiger freezes. Though, there is some chance that 2.4 will be ready soon enough for inclusion into Tiger.. so it could happen. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040603/fc9ad26c/smime.bin From gherman at darwin.in-berlin.de Fri Jun 4 03:38:30 2004 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Fri Jun 4 03:36:04 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 Message-ID: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> Hi all, while having some software and hardware upgrading fest I thought I'd give Pack Man another try. Here are some comments. First, I'm on OS X 10.3.4, giving a chance to Apple's Python 2.3.0 in /usr/bin, and I have downloaded and installed "MacPython addons for 10.3" as explained on Jack's site: http://homepages.cwi.nl/~jack/macpython/download.html Then I've started PackageManager.app in /Applications/MacPython-2.3. While Pack Man tries loading the "standard database" I'm getting immediately a warning panel, saying "Cannot open http://www.python.org/packman/version-0.3/\ darwin-7.4.0-Power_macintosh.plist: HTTP Error 404: Not Found See MacPython Package Manager help page." Unfortunately, this panel isn't very useful, since: 1) it has no title, 2) the warning text is not selectable (to copy and paste into emails, say), and 3) the reference to the "MacPython Package Manager help page" is misleading because, although there is such a menu entry, the page itself simply does not exist. Looking on python.org/packman the latest database file I found is version-0.3/darwin-7.3.0-Power_Macintosh.plist. Sadly, it's unclear what version-0.3 means as Pack Man's "About" panel says nothing about its version number. Nor does the finder say anything about that. I believe Pack Man derives the URL for the so-called "standard data- base" from the version of the running Darwin OS, in my case apparent- ly darwin-7.4.0, for which there is no Pack Man database file on python.org. This raises the question of how these files are created? Then, I've loaded the file darwin-7.3.0-Power_Macintosh.plist which unfortunately contains entries only to PyObjC v. 1.0, but not the recently released 1.1. This raises questions about how these database files are updated and if this could be automated/included in the re- lease process of PyObjC somehow, perhaps? In addition to all these, I see the following other issues with Pack Man. 1) I'd like to read some advice about how to upgrade Apple's Python inplace or what else to do with it while keeping the other installed packages, 2) I'd like Pack Man to tell me where exactly it's going to install something, and 3) I'd like to see either Pack Man or Package Manager being used as a name allover the place. Also, I'd like to be able to move Mac-Python-2.3 from /Applications to some arbitrary directory, if that isn't possible, yet (not sure). And, finally, Pack Man should really really be rewritten in Cocoa, but everbody knows that, I guess. BTW, I cannot see any "full" MacPython 2.3.3 (or even 2.3.4) for OS X 10.3 on Jack's page. Some comments on what to expect here might be of interest as well. Thanks for reading down to here! Regards, Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... Get your Bushy protest panties now! - http://www.axisofeve.org From Jack.Jansen at cwi.nl Fri Jun 4 08:09:15 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jun 4 08:11:09 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 14, Issue 2 In-Reply-To: <40BEF949.5060201@psychology.nottingham.ac.uk> References: <40BEF949.5060201@psychology.nottingham.ac.uk> Message-ID: On 3-jun-04, at 12:11, Jon Peirce wrote: > So I now realise that there was a previous report of this last year > (so probably nothing to do with this OSX version). The diagnosis then > was to do with the firewall. > > In my case, I did have a firewall problem initially, which was causing > the databases not to be found. So I set the appropriate http proxy in > my environment.plist as instructed and it was then that the databases > were found but caused the 'unspecified error while parsing'. > > If I download the database files and point to them locally rather than > pointing to their URLs I get the same problem. > > Which leaves me at a bit of a loss. Any other things I should try? Try and run pimp (the engine underlying Package Manager) from the command line, and see whether that gives more information. Pimp is in /System/Library/Frameworks/Python.framework/Versions/Current/Lib/plat- mac/pimp.py. Running it without any arguments will print the help message. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2086 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040604/b1609cfe/smime.bin From hengist.podd at virgin.net Fri Jun 4 14:38:43 2004 From: hengist.podd at virgin.net (has) Date: Fri Jun 4 14:39:08 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> Message-ID: Dinu Gherman wrote: >And, finally, Pack Man should really really be rewritten in Cocoa, but >everbody knows that, I guess. This gives an idea: would DarwinPackages or Fink be viable alternatives for MacPython package management? This would certainly save the time and hassle of rewriting and maintaining PackMan if a standard existing system could be leveraged immediately more or less for free. Anyone familiar with OS X-compatible package managers have any thoughts on this? ... Also, this reminds me: I never did get around to filing a feature request re. PyMod , which provides a simple GUI frontend for building, installing and registering distutils-based packages. I've added a comment to '[ 779160 ] Enhance PackageManager functionality' feature request on sourceforge indicating it is available for inclusion in MacPython 2.4 (which, given PM's shortcomings in this area, I'd recommend). If I should submit a separate feature request as well, can somebody please let me know. Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Fri Jun 4 14:46:23 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jun 4 14:46:31 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> Message-ID: <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> On Jun 4, 2004, at 2:38 PM, has wrote: > Dinu Gherman wrote: > >> And, finally, Pack Man should really really be rewritten in Cocoa, but >> everbody knows that, I guess. > > This gives an idea: would DarwinPackages or Fink be viable > alternatives for MacPython package management? This would certainly > save the time and hassle of rewriting and maintaining PackMan if a > standard existing system could be leveraged immediately more or less > for free. > > Anyone familiar with OS X-compatible package managers have any > thoughts on this? Not possible, Fink and DarwinPorts both use their own version of Python. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040604/52c06b92/smime.bin From hengist.podd at virgin.net Fri Jun 4 15:30:02 2004 From: hengist.podd at virgin.net (has) Date: Fri Jun 4 15:30:24 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> Message-ID: Bob Ippolito wrote: >>This gives an idea: would DarwinPackages or Fink be viable >>alternatives for MacPython package management? This would certainly >>save the time and hassle of rewriting and maintaining PackMan if a >>standard existing system could be leveraged immediately more or >>less for free. >> >>Anyone familiar with OS X-compatible package managers have any >>thoughts on this? > >Not possible, Fink and DarwinPorts both use their own version of Python. I don't mean you should install and use their version of Python (which seems a bit of a stupid reinventing-the-wheel exercise), just use them to manage third-party packages for MacPython where a straight distutils-only approach isn't adequate for the task (which is the justification for creating PackMan in the first place, if I understand correctly). Can that be done (or made to work for minimal effort), or are they really dumb enough that they can't play properly with anyone else? has -- http://freespace.virgin.net/hamish.sanderson/ From Jack.Jansen at cwi.nl Fri Jun 4 16:04:04 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jun 4 16:04:11 2004 Subject: [Pythonmac-SIG] [FWD] OSABase In-Reply-To: <346FBE4C-B5B7-11D8-B453-000A95686CD8@redivi.com> References: <346FBE4C-B5B7-11D8-B453-000A95686CD8@redivi.com> Message-ID: <541009EE-B662-11D8-BCCF-000D934FF6B4@cwi.nl> On 4 Jun 2004, at 01:39, Bob Ippolito wrote: > The license scenario looks bad. You can't even download it without > emailing him and saying "yes I comply with this license". We'd > probably be better off starting from scratch unless you can convince > him to make his stuff open source under a PSF compatible license. Yes, very bad. Weird, too: this reference to " Because of issues pertaining to registering OSA components with the MacOS, you may not redistribute products derived from the personal edition of TextOSA. " has me a bit worried. Would there really be something behind this, or would it just be a smokescreen? > There is approximately no chance whatsoever of OSA component support > making it into Python 2.4. The first alpha is almost out the door, > and there isn't even a prototype or PEP that detains the whys and > hows. It would be great if we had it, but it won't be a standard > feature until Python 2.5 at the earliest. I beg to differ. As far as I can see, the component is completely separate from the distribution. It would use the framework from the distribution, but that's about it. There's no reason it couldn't be grafted onto the current 2.3 distribution on Panther. The only problem is: someone has to do the work:-) -- 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 bob at redivi.com Fri Jun 4 16:04:33 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jun 4 16:04:40 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> Message-ID: <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> On Jun 4, 2004, at 3:30 PM, has wrote: > Bob Ippolito wrote: > >>> This gives an idea: would DarwinPackages or Fink be viable >>> alternatives for MacPython package management? This would certainly >>> save the time and hassle of rewriting and maintaining PackMan if a >>> standard existing system could be leveraged immediately more or less >>> for free. >>> >>> Anyone familiar with OS X-compatible package managers have any >>> thoughts on this? >> >> Not possible, Fink and DarwinPorts both use their own version of >> Python. > > I don't mean you should install and use their version of Python (which > seems a bit of a stupid reinventing-the-wheel exercise), just use them > to manage third-party packages for MacPython where a straight > distutils-only approach isn't adequate for the task (which is the > justification for creating PackMan in the first place, if I understand > correctly). > > Can that be done (or made to work for minimal effort), or are they > really dumb enough that they can't play properly with anyone else? It's probably much less work to fix our own stuff than it is to fork someone else's package management system. I'm pretty sure that the software Fink uses isn't license compatible with Python, since it comes from Debian, so that's a big minus. If you really think DarwinPorts would be a good idea, then feel free to do the research... but I don't think it's "smart" enough to be ripped into pieces and used by us. Besides, it's written in TCL. I think your effort would be better spent filing bugs, feature requests, and PEPs for what we have. It's definitely not as fundamentally flawed as you make it out to be. If you really do believe it's broken beyond repair, then feel free to start developing an alternative. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040604/94e630b4/smime.bin From bob at redivi.com Fri Jun 4 16:08:37 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jun 4 16:08:42 2004 Subject: [Pythonmac-SIG] [FWD] OSABase In-Reply-To: <541009EE-B662-11D8-BCCF-000D934FF6B4@cwi.nl> References: <346FBE4C-B5B7-11D8-B453-000A95686CD8@redivi.com> <541009EE-B662-11D8-BCCF-000D934FF6B4@cwi.nl> Message-ID: On Jun 4, 2004, at 4:04 PM, Jack Jansen wrote: > > On 4 Jun 2004, at 01:39, Bob Ippolito wrote: >> There is approximately no chance whatsoever of OSA component support >> making it into Python 2.4. The first alpha is almost out the door, >> and there isn't even a prototype or PEP that detains the whys and >> hows. It would be great if we had it, but it won't be a standard >> feature until Python 2.5 at the earliest. > > I beg to differ. As far as I can see, the component is completely > separate from the distribution. It would use the framework from the > distribution, but that's about it. There's no reason it couldn't be > grafted onto the current 2.3 distribution on Panther. The only problem > is: someone has to do the work:-) Yes, of course. I'm pretty sure he was suggestion that OSA component support should be bundled with the mainline distribution of 2.4.0, which isn't going to happen. OSA Component support could of course be made available for any reasonable version of Python, but since no implementation exists yet, it won't ship with the next major release of Python :) -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040604/41bea0f0/smime.bin From jwblist at olympus.net Fri Jun 4 17:20:10 2004 From: jwblist at olympus.net (John W. Baxter) Date: Fri Jun 4 17:20:18 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: Message-ID: On 6/4/2004 11:38, "has" wrote: > This gives an idea: would DarwinPackages or Fink be viable > alternatives for MacPython package management? This machine is a Fink-free zone, and is likely to remain that way. I have no valid reason for that attitude (other than the fact that my paycheck depends on the machine working). And I don't have a sandbox machine. I'm not familiar with DarwinPackages. --John From bob at redivi.com Fri Jun 4 17:36:34 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jun 4 17:36:43 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: References: Message-ID: <4083BAAA-B66F-11D8-B453-000A95686CD8@redivi.com> On Jun 4, 2004, at 5:20 PM, John W. Baxter wrote: > On 6/4/2004 11:38, "has" wrote: > >> This gives an idea: would DarwinPackages or Fink be viable >> alternatives for MacPython package management? > > This machine is a Fink-free zone, and is likely to remain that way. I > have > no valid reason for that attitude (other than the fact that my paycheck > depends on the machine working). And I don't have a sandbox machine. > > I'm not familiar with DarwinPackages. DarwinPackages doesn't exist. There is something called Darwinports, which is part of the Opendarwin project. I guess it's similar in concept to Fink, it just has a very different implementation. It's very BSD-like instead of Debian-like. Whenever I end up using one or the other I feel like I'm installing a separate operating system, that just happens to be hosted on the Darwin kernel. I find that the easiest thing to do when dealing in X11 apps is to just run them over SSH from a real Linux box :) When there is a port of MacOnLinux to OS X, I would probably run NetBSD or some distribution of Linux PPC when I really wanted to do the X11 thing and didn't have a dedicated Linux/BSD box available... -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040604/4397f5ef/smime.bin From mww at opendarwin.org Fri Jun 4 16:40:56 2004 From: mww at opendarwin.org (Markus W. Weissmann) Date: Fri Jun 4 17:58:24 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> Message-ID: <7A7F221C-B667-11D8-A2FE-000D93AE2252@opendarwin.org> On Jun 04, 2004, at 22:04, Bob Ippolito wrote: > On Jun 4, 2004, at 3:30 PM, has wrote: > >> Bob Ippolito wrote: >> >>>> This gives an idea: would DarwinPackages or Fink be viable >>>> alternatives for MacPython package management? This would certainly >>>> save the time and hassle of rewriting and maintaining PackMan if a >>>> standard existing system could be leveraged immediately more or >>>> less for free. >>>> >>>> Anyone familiar with OS X-compatible package managers have any >>>> thoughts on this? >>> >>> Not possible, Fink and DarwinPorts both use their own version of >>> Python. yep, we actually use our own python, but the DarwinPorts tools dont force you to. This is just the default we make our stuff work for. >> I don't mean you should install and use their version of Python >> (which seems a bit of a stupid reinventing-the-wheel exercise), just >> use them to manage third-party packages for MacPython where a >> straight distutils-only approach isn't adequate for the task (which >> is the justification for creating PackMan in the first place, if I >> understand correctly). >> >> Can that be done (or made to work for minimal effort), or are they >> really dumb enough that they can't play properly with anyone else? > > It's probably much less work to fix our own stuff than it is to fork > someone else's package management system. I'm pretty sure that the > software Fink uses isn't license compatible with Python, since it > comes from Debian, so that's a big minus. If you really think > DarwinPorts would be a good idea, then feel free to do the research... > but I don't think it's "smart" enough to be ripped into pieces and > used by us. Besides, it's written in TCL. > > I think your effort would be better spent filing bugs, feature > requests, and PEPs for what we have. It's definitely not as > fundamentally flawed as you make it out to be. If you really do > believe it's broken beyond repair, then feel free to start developing > an alternative. I dont know exactly how Pack Man works or what packages it makes available, but using darwinports python ports for you should be rather easy: -Install DarwinPorts -hack the python group code and replace the calls to /opt/local/bin/python by those to /usr/bin/python [/opt/local/share/darwinports/resources/port1.0/group/python-1.0.tcl - edit two lines] -install packages -make packages from the stuff installed (e. g. 'port contents py-snmp' -> list of files) I dont know what you do about non-python packages that are required for python modules but are not supplied by OS-X, those of course will not work this (very easy) way. cheers, Markus --- Markus W. Weissmann http://www.mweissmann.de/ http://www.opendarwin.org/~mww/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040604/7227e471/PGP.bin From mww at opendarwin.org Fri Jun 4 19:14:10 2004 From: mww at opendarwin.org (Markus W. Weissmann) Date: Fri Jun 4 19:15:40 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: <4083BAAA-B66F-11D8-B453-000A95686CD8@redivi.com> References: <4083BAAA-B66F-11D8-B453-000A95686CD8@redivi.com> Message-ID: On Jun 04, 2004, at 23:36, Bob Ippolito wrote: > On Jun 4, 2004, at 5:20 PM, John W. Baxter wrote: > >> On 6/4/2004 11:38, "has" wrote: >> >>> This gives an idea: would DarwinPackages or Fink be viable >>> alternatives for MacPython package management? >> >> This machine is a Fink-free zone, and is likely to remain that way. >> I have >> no valid reason for that attitude (other than the fact that my >> paycheck >> depends on the machine working). And I don't have a sandbox machine. >> >> I'm not familiar with DarwinPackages. > > DarwinPackages doesn't exist. There is something called Darwinports, > which is part of the Opendarwin project. I guess it's similar in > concept to Fink, it just has a very different implementation. It's > very BSD-like instead of Debian-like. In fact its very similar to the other BSD ports collections. > Whenever I end up using one or the other I feel like I'm installing a > separate operating system, that just happens to be hosted on the > Darwin kernel. I find that the easiest thing to do when dealing in > X11 apps is to just run them over SSH from a real Linux box :) When > there is a port of MacOnLinux to OS X, I would probably run NetBSD or > some distribution of Linux PPC when I really wanted to do the X11 > thing and didn't have a dedicated Linux/BSD box available... hmm... did you ever use BSD? If their ports collections feel like different operating systems to you, then probably DarwinPorts will also do so. They also have stuff in base that is also in their ports collections. I really dont think you need to have a second computer running for X11, just to play xbill or whatever. Also if you're on the road the Linux fallback is no solution. In fact everyone I talked to about DarwinPorts said "oh, its that easy? thats even easier then FreeBSD ports". I dont get how setting up a 2nd computer is easier compared to installing Fink or DarwinPorts on your "real Unix" Mac. cheers, Markus --- Markus W. Weissmann http://www.mweissmann.de/ http://www.opendarwin.org/~mww/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040605/07420088/PGP.bin From bob at redivi.com Fri Jun 4 19:44:27 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jun 4 19:44:36 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: References: <4083BAAA-B66F-11D8-B453-000A95686CD8@redivi.com> Message-ID: <1DE22445-B681-11D8-BBA0-000A95686CD8@redivi.com> On Jun 4, 2004, at 7:14 PM, Markus W. Weissmann wrote: > On Jun 04, 2004, at 23:36, Bob Ippolito wrote: >> Whenever I end up using one or the other I feel like I'm installing a >> separate operating system, that just happens to be hosted on the >> Darwin kernel. I find that the easiest thing to do when dealing in >> X11 apps is to just run them over SSH from a real Linux box :) When >> there is a port of MacOnLinux to OS X, I would probably run NetBSD or >> some distribution of Linux PPC when I really wanted to do the X11 >> thing and didn't have a dedicated Linux/BSD box available... > > hmm... did you ever use BSD? If their ports collections feel like > different operating systems to you, then probably > DarwinPorts will also do so. They also have stuff in base that is also > in their ports collections. Mostly speaking from Fink experience, it feels like a different operating system than Darwin because it has a lot of overlap with the base system. I don't typically want to install a marginally newer version of something like libxml2 if I don't have to. It also requires a bootstrap script to be used.. so you essentially have two modes of operation at the shell, depending on whether or not you want to run Fink apps and/or link to Fink libraries. I like DarwinPorts a lot better, in theory anyway, but I really haven't needed any ports from it... so I don't have real experience using it. I do have experience with other BSD ports collections (mostly OpenBSD). > I really dont think you need to have a second computer running for > X11, just to play xbill or whatever. Also if you're > on the road the Linux fallback is no solution. In fact everyone I > talked to about DarwinPorts said "oh, its that easy? > thats even easier then FreeBSD ports". > I dont get how setting up a 2nd computer is easier compared to > installing Fink or DarwinPorts on your "real Unix" Mac. Well, I don't use X11 apps on a day to day basis. I fall back to an existing X11 system because I don't generally want to spend hours installing gtk, gnome, kde, etc. on my OS X machines just to screw around with some non-essential application for a few minutes. Installing DP or Fink would probably be easier than setting up another machine, but I already had the other machine setup :) I do have the X11 server installed on my OS X machines though, mostly because it comes with Panther, not because I use it often. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040604/18f6730e/smime.bin From hengist.podd at virgin.net Fri Jun 4 20:25:53 2004 From: hengist.podd at virgin.net (has) Date: Fri Jun 4 20:29:47 2004 Subject: [Pythonmac-SIG] [FWD] OSABase In-Reply-To: <541009EE-B662-11D8-BCCF-000D934FF6B4@cwi.nl> References: <346FBE4C-B5B7-11D8-B453-000A95686CD8@redivi.com> <541009EE-B662-11D8-BCCF-000D934FF6B4@cwi.nl> Message-ID: Jack Jansen wrote: >>The license scenario looks bad. You can't even download it without >>emailing him and saying "yes I comply with this license". We'd >>probably be better off starting from scratch unless you can >>convince him to make his stuff open source under a PSF compatible >>license. > >Yes, very bad. Weird, too: this reference to " Because of issues >pertaining to registering OSA components with the MacOS, you may not >redistribute products derived from the personal edition of TextOSA. >" has me a bit worried. Would there really be something behind this, >or would it just be a smokescreen? I've no idea myself, I'm afraid, though I've appended his response on the MacScrpt mailing list to the end of this mail FWIW. I know you guys have more than enough on your own plate, but I think it's something that really has to fall in your court rather than mine. Like I've said before, I have neither the C knowledge and familiarity with MacPython's guts nor the authority and political clout to make any kind of call on this subject. That's why I'm tossing it in you guys' direction, because you're the ones that can. Anyway, best thing would be to go talk to Philip; he's a nice guy and I'm sure he won't bite if you explain to him your needs and what your concerns are, and ask what the chances are he could/might adjust his position to something more statisfactory. >>There is approximately no chance whatsoever of OSA component >>support making it into Python 2.4. The first alpha is almost out >>the door, and there isn't even a prototype or PEP that detains the >>whys and hows. It would be great if we had it, but it won't be a >>standard feature until Python 2.5 at the earliest. > >I beg to differ. As far as I can see, the component is completely >separate from the distribution. It would use the framework from the >distribution, but that's about it. There's no reason it couldn't be >grafted onto the current 2.3 distribution on Panther. The only >problem is: someone has to do the work:-) I think you're right on this. Please don't quote me on this, but I think how it works is that you create a scripting component, /Library/Components/Python.component, and this component would link (presumably dynamically) to whatever MacPython.framework you've got installed on your system. Philip's wrapper should make this hook-up easier than if you do it yourself through Apple's original OSA API, though _how_much_ easier I couldn't say myself, obviously. But maybe it'll turn out to be really trivial for somebody with a bit of C and MacPython API experience - only one way to find out, of course. ;) As for who gets to do the work... um, Very busy. Very, very busy. Maybe in another five to ten years, once I've finally bought myself a clue as to what I'm doing. Meantime, feel free to donate dollars any time you like, yes? Cheers, has ------- Date: Mon, 31 May 2004 13:49:17 -0700 From: Philip Aker Subject: Re. OSABase Hi Hamish, >> You, or more likely Hamish, can implement Python as an OSA language >> using OSABase. Then it can be available to you in any OS X >> application supporting scripting calls. > Heh, not me squire; have you seen any of my attempts at C? ;p I did pick up the latest and greatest and noticed a few C modules. So that's a big step up from the previous zero quantity. With people like c.nebel contributing, I'd guess that such attempts would be quite good. > Anyway, Jack Jansen and/or Donovan Preston were/are the ones > supposedly(?) working on OSA support for Python. (I rather regret not > trying harder to get you folks together at the time, but don't have > very much traction in the MacPython community unfortunately.) I had this stuff 99.99% completed last January but had some gigs to take care of plus I squished a disk in my lower back and kinda forgot about everything else for nearly two months. > Took a quick squizz at your page, though wondering what are the > licensing conditions/restrictions you mention? (Python uses a very > liberal open-source license.) Almost none. Components must have a couple of four char codes registered with Apple. This prevent idiots from re-distributing TextOSA with a customized driver file. For Python, since I'm not really a member of that community, I'd suggest a real Pythonite select and register the four char codes and fill in the other details. I get the impression that you may wish to have separate info for both python and pythonw. Also, you'll probably want to work with the C/C++ interfaces to grab every last bit of speed but that is not necessary for an implementation. It's perfectly feasible to do them with 'do shell script' AppleScript for the nonce and upgrade to C/C++/Objective-C later. The C interfaces are easy to grok for someone vaguely familiar with AEDescs and a really simple callback notion (to initialize the component). Also, I test for NULL procs so only handling 'execute' is still make for a legit component. -- http://freespace.virgin.net/hamish.sanderson/ From jwight_lists at spamcop.net Fri Jun 4 22:13:19 2004 From: jwight_lists at spamcop.net (Jonathan Wight) Date: Fri Jun 4 22:13:26 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: <887C9628-B695-11D8-9EF6-000D93AD320E@mac.com> References: <4083BAAA-B66F-11D8-B453-000A95686CD8@redivi.com> <1DE22445-B681-11D8-BBA0-000A95686CD8@redivi.com> <887C9628-B695-11D8-9EF6-000D93AD320E@mac.com> Message-ID: On Jun 04, 2004, at 19:44, Bob Ippolito wrote: > On Jun 4, 2004, at 7:14 PM, Markus W. Weissmann wrote: > > Mostly speaking from Fink experience, it feels like a different > operating system than Darwin because it has a lot of overlap with the > base system. I don't typically want to install a marginally newer > version of something like libxml2 if I don't have to. It also > requires a bootstrap script to be used.. so you essentially have two > modes of operation at the shell, depending on whether or not you want > to run Fink apps and/or link to Fink libraries. > > I like DarwinPorts a lot better, in theory anyway, but I really > haven't needed any ports from it... so I don't have real experience > using it. I do have experience with other BSD ports collections > (mostly OpenBSD). I've been using DarwinPorts a lot recently. Mainly as a quick way to install and upgrade Subversion and a handful of libraries (libxml2, sqlite) that I need during my day job developing (Cocoa) software. I switched to DarwinPorts from Fink a year ago mainly because Fink just grated on me and because Jordan Hubbard is one of the leaders on the DarwinPorts project - I was hoping DarwinPorts would be more 'mac-like' than Fink. On the whole it is a nice system, you certainly can't beat "port install svn". It seems to have a broad selection of packages available and configuration of new packages is straight-forward (unfortunately it is tightly bound to TCL). I have a couple of problems with DarwinPorts though. The first is that the tools seem quite immature, the programs seem missing quite a few useful options and the built-in help is limited. to top it off you have to manually update your port files by updating them from cvs yourself. My second main problem is that, like Bob points out with Fink, it seems like a second operating system. Again it will install its own version of tools and libraries you already have installed, for example if you install sqlite with python bindings DarwinPorts will install its own version of Python 2.3! Needless to say this is a pain in the butt. This might be fine on a pure Darwin system but with Mac OS X this is just plain crazy. I think maybe this will get fixed in the future (there was a thread on the DarwinPorts mailing list discussing this a while ago) but right now the immaturity of DarwinPorts stands out. I'm sticking with DarwinPorts because I really hope it gets better. But as to the original question about using DarwinPorts (or Fink) as Python's package management system it seems to me that Python & PackMan are doing the right thing already and just need to be fixed. Jon. From bob at redivi.com Fri Jun 4 22:22:52 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jun 4 22:23:00 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: References: <4083BAAA-B66F-11D8-B453-000A95686CD8@redivi.com> <1DE22445-B681-11D8-BBA0-000A95686CD8@redivi.com> <887C9628-B695-11D8-9EF6-000D93AD320E@mac.com> Message-ID: <3F70A0A2-B697-11D8-BBA0-000A95686CD8@redivi.com> On Jun 4, 2004, at 10:13 PM, Jonathan Wight wrote: > On Jun 04, 2004, at 19:44, Bob Ippolito wrote: > >> On Jun 4, 2004, at 7:14 PM, Markus W. Weissmann wrote: >> >> Mostly speaking from Fink experience, it feels like a different >> operating system than Darwin because it has a lot of overlap with the >> base system. I don't typically want to install a marginally newer >> version of something like libxml2 if I don't have to. It also >> requires a bootstrap script to be used.. so you essentially have two >> modes of operation at the shell, depending on whether or not you want >> to run Fink apps and/or link to Fink libraries. >> >> I like DarwinPorts a lot better, in theory anyway, but I really >> haven't needed any ports from it... so I don't have real experience >> using it. I do have experience with other BSD ports collections >> (mostly OpenBSD). > > I've been using DarwinPorts a lot recently. Mainly as a quick way to > install and upgrade Subversion and a handful of libraries (libxml2, > sqlite) that I need during my day job developing (Cocoa) software. I > switched to DarwinPorts from Fink a year ago mainly because Fink just > grated on me and because Jordan Hubbard is one of the leaders on the > DarwinPorts project - I was hoping DarwinPorts would be more > 'mac-like' than Fink. > > On the whole it is a nice system, you certainly can't beat "port > install svn". It seems to have a broad selection of packages available > and configuration of new packages is straight-forward (unfortunately > it is tightly bound to TCL). For a while, I would compile+install my own svn.. but ever since Martin Ott started releasing nice statically compiled binaries, I've been using those since: http://codingmonkeys.de/mbo/ It doesn't get you the svn Apache module, but then again, you don't have Apache 2 by default anyway. He also seems to be within a day or two of subversion releases, which is more than good enough for me. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040604/5be6d070/smime.bin From gherman at darwin.in-berlin.de Sat Jun 5 05:11:46 2004 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Sat Jun 5 05:09:23 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: <1DE22445-B681-11D8-BBA0-000A95686CD8@redivi.com> Message-ID: <5EC4763A-B6D0-11D8-AFF7-00039345C610@darwin.in-berlin.de> Bob Ippolito: > Mostly speaking from Fink experience, it feels like a different > operating system than Darwin because it has a lot of overlap with > the base system. Very true, but one reason for the current mess is that OS X itself doesn't provide any *real* packaging/versioning mechanism like those by RedHat, Debian, etc. It might be able to do so on the Darwin level, but it doesn look like it wants to, does it? Well, I wouldn't really expect anything like this from Apple soon, especially on the higher application level, or not before OS X 11, or so... Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... Get your Bushy protest panties now! - http://www.axisofeve.org From bob at redivi.com Sat Jun 5 10:30:34 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jun 5 10:30:50 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: <5EC4763A-B6D0-11D8-AFF7-00039345C610@darwin.in-berlin.de> References: <5EC4763A-B6D0-11D8-AFF7-00039345C610@darwin.in-berlin.de> Message-ID: On Jun 5, 2004, at 5:11 AM, Dinu Gherman wrote: > Bob Ippolito: > >> Mostly speaking from Fink experience, it feels like a different >> operating system than Darwin because it has a lot of overlap with >> the base system. > > Very true, but one reason for the current mess is that OS X itself > doesn't provide any *real* packaging/versioning mechanism like those > by RedHat, Debian, etc. It might be able to do so on the Darwin level, > but it doesn look like it wants to, does it? Well, I wouldn't really > expect anything like this from Apple soon, especially on the higher > application level, or not before OS X 11, or so... I had heard that they looked at apt early on, but chose not to pursue anything with it because it's GPL. I actually expect them to do something by 10.5, at least in OS X Server, even if it's just Darwinports. I don't expect to see anything in 10.4, though there is a lot of room for enhancing Installer and they may have started to do that. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040605/ee22059e/smime.bin From hengist.podd at virgin.net Sun Jun 6 17:16:27 2004 From: hengist.podd at virgin.net (has) Date: Sun Jun 6 17:20:22 2004 Subject: [Pythonmac-SIG] [FWD] OSABase In-Reply-To: References: <346FBE4C-B5B7-11D8-B453-000A95686CD8@redivi.com> <541009EE-B662-11D8-BCCF-000D934FF6B4@cwi.nl> Message-ID: Bob Ippolito wrote: >If you can convince him to change the license to something >compatible with the PSF (MIT or BSD are good candidates), I'll look >at it. Otherwise, I'm not interested enough to talk to him. Okay, and while I think it might've been better coming from the Big Chiefs than minor Indian, I've passed on your request and will let you know what comes back. I would imagine there's nothing in OSABase and its licences that would prevent it and Python from technically operating together, I quite understand (and agree with) the want/need for it to be completely open and on the level with Python if it's to become part of the official Python package itself. Regards, has -- http://freespace.virgin.net/hamish.sanderson/ From Jack.Jansen at cwi.nl Mon Jun 7 07:47:03 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jun 7 07:48:40 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> Message-ID: <64C0E803-B878-11D8-A777-000A958D1666@cwi.nl> >> And, finally, Pack Man should really really be rewritten in Cocoa, but >> everbody knows that, I guess. This is going to happen real soon. Or actually, it has happened already: Ronald did a PyObjC-based frontend to pimp that is included in the PyObjC distribution. I'm going to switch to that as the "official" Package Manager real soon now. > This gives an idea: would DarwinPackages or Fink be viable > alternatives for MacPython package management? Not really, because I want Package Manager to be cross-platform. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2086 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040607/05212264/smime.bin From hengist.podd at virgin.net Mon Jun 7 08:38:51 2004 From: hengist.podd at virgin.net (has) Date: Mon Jun 7 08:39:55 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> Message-ID: Bob Ippolito [snip 'Bill Cosby' moment] >PackageManager was designed to have as simple of an *implementation* >as possible, and it pretty much does. You do a lot of hand-waving >about how awful it is, but the reality is that it is VERY simple and >works pretty well. The GUI application is horrible and has lots of >bugs, but that is easy to fix. The underlying system doesn't have >very many real problems. My problem isn't that it's inherently awful, it's that it's inherently pointless. 1. Expending 100% of labour creating a solution that caters to <1% of module installations if not an efficient use of extremely scarce, and therefore extremely valuable, manpower and brainpower resources (i.e. yours, Jack's and the other core MacPython developers). 2. Its administration model is inherently non-scalable, being utterly dependent on the good will and hard work of a few elite MacPython gurus to maintain its custom databases. I've stated several times that I couldn't care less about the state of its GUI. PackMan's major problem _isn't_ its technical glitches (which can be easily resolved with a bit of elbow grease as we're both happy to acknowledge). It's a complete failure to perform a proper cost-vs-benefit analysis of its basic concept/design, which would quickly show it to be a classic white elephant, impossible to support at the kind of level that would make it genuinely useful due to the high ongoing support costs that will spiral out of control long before you ever reach that point. And _that_ is the foundation of my argument for abandoning PackMan and starting over again. (So please don't haul out the old "minor technical glitches" canard again, because it'll only annoying me... and Hulk Smash when he get angry, which won't do any of us any favours.) So if you want to refute my argument as an unmigitated load of old codswallop then you're going to have to explain how the logistics of creating, expanding and maintaining a centrally managed package database can be justified, and how they're not going to cause the entire system to slowly suffocate under its own weight. (Because, you know, that whole central planning and control thing really didn't pan out too well for the old USSR or People's Republic of China.) And how it's going to be more cost-effective than cutting a deal with something like PyPI that already has a robust and sustainable - not to mention well established and quite successful - model for doing this sort of thing. (Decentralisation rocks. Cooperation rocks.) Because as the whole history of software development shows, a 50%-good practical solution that addresses 90% of the common need will beat out a 100%-perfect ivory tower one that obsesses over a few % of corner cases to the neglect of everything else. I realise a lot of programmers get a bit funny about throwing out "working" software, but that's just something y'all need to get over. e.g. See the arts and sciences which, being rather older and wiser than software dev, have no such hangups about letting go and moving on. Time to cast aside your inner albatrosses, yes? >>>I think your effort would be better spent filing bugs, feature >>>requests, and PEPs for what we have. It's definitely not as >>>fundamentally flawed as you make it out to be. If you really do >>>believe it's broken beyond repair, then feel free to start >>>developing an alternative. >> >>You've told me this already, and I've done exactly that. And I've >>asked for feedback on what I've done and whether it would be >>suitable for inclusion in the standard distribution, and I'm >>_still_ waiting for a response. > >Ok, here's some feedback. Thank you. And I say that with 100% absolute sincerity. Just what the doctor ordered. >I downloaded PyMod and the following things happen: >- It launches with a window that says "Path" and has some buttons. >If it worked, I wouldn't really know what to do with it. Path to >what? Path to the setup.py script of the distutils package to build or install. Or to a .zip or .tar.gz archive assumed to be a compressed package. (Note: I suspect I should cater to other compressed forms too, e.g. .tar.bz2 or whatever it's called. Any easy way of doing this, other than writing a different archive-decompression shell script each time?) FWIW, the tool tip and built-in help do explain what this field is for. But you're quite right that the visible label is poor, so I'm wide open to suggestions for a better name. >- I can't focus the application because it's busy doing something. >There is no indication of what this something is. There's a few seconds' delay upon startup as it initialises itself. I suspect the bottleneck is the following shell script: find /usr -name python; find /usr -name pythonw To use PyMod, the user must first specify the Python executable with which to run distutils via the combo text field in the Preferences dialog. For their convenience, a list of known python executables is provided under the combo box's drop-down menu, so folks can usually just pick the one they want without having to type the path from scratch (though they can do that too if. Given the length of the delay, the application should really do something to indicate it's working rather than just frozen, e.g. drop down a sheet with a barber-pole and "Looking for installed python executables..." message. Though see the next point for why this may cease to be an issue anyway... >- Eventually it comes up with an error dialog that says "find: >/usr/local/pgsql/data: Permission denied" twice, with a Quit button. Looks like my genius shell script just blew up. I'm open to suggestions: - Could a better 'python exe locator' be written? - Or should I bundle one in the app, or just link dynamically to the MacPython framework? Though if I did that, how then would users indicate which Python installation they wanted to install into? - Or I could hardcode a few 'reasonable guess' paths like /usr/bin/python, /usr/local/bin/python, /usr/local/bin/pythonw (whose presence I can easily check for at startup and eliminate invalid paths from the list before showing it to the user). That'd be easy enough to do, and might be an adequate compromise. (It'd also eliminate the slow startup.) - Or I could just leave it entirely to the user to key in the path(s) they want. (Not very friendly, but about as simple and reliable as it could get.) >- After clicking Quit, which is the only thing I am allowed to do, >it pops up another dialog titled "AppleScript Error" that says >"NSReceiverEvaluationScriptError: 4(1)" with an Ok button. Yeah, welcome to Cocoa Scripting. Worst. Error. Messages. EVER. Scripters have been bollocking Apple over its cruddy incomprehensible error messages since year dot, and they still haven't sorted it yet. (This is one of the reasons I've been making appscript so anal about checking event params, specifiers, etc. before dispatching them, btw; better the premature faked-up error message you can grok than the real one you can't.) Anyway, it's noted now. Though I'll not worry too much about this one right now, as it's probably just a knock-on effect from the other bugs, so let's see if it clears up when those are fixed. >- I cilck Ok, and it quits. Yayy! SOMETHING worked! ("But it works just fine OMM!") Anyway, this is what [third-party user] testing is for. Much appreciated, and in return I've posted a modified version with the funky 'python mis-finder' script disabled so you can [hopefully] try the rest of it out: http://freespace.virgin.net/hamish.sanderson/PyMod_for_Bob.sit Let me know what other horrors you find. ;) (BTW, delete any PyMod.plist preferences file before running, just to get a clean shot at it.) >So much for simple, general-purpose, reusable software eh? When your v0.3 releases are all the very shining models of perfection, I'll happily concede you that jibe... but NOT before. :p Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From mlpollard at earthlink.net Mon Jun 7 09:54:15 2004 From: mlpollard at earthlink.net (Tom Pollard) Date: Mon Jun 7 09:52:11 2004 Subject: [Pythonmac-SIG] Package Manager questions Message-ID: <29C5BD2A-B88A-11D8-868A-000A959B24A6@earthlink.net> Hi, Three questions: (1) I went to try to use the MacPython 2.3 PackageManager on my fully upgraded MacOSX 10.3 system today and got the error message that Cannot open http://www.python.org/packman/version-0.3/darwin-7.4.0- Power_Macintosh.plist: HTTP Error 404: Not Found Other people have reported this problem, I believe, so why can't we put in a symlink on the server so that "darwin-7.4.0" maps to the appropriate address? (2) The MacPython PackageManager page doesn't make it clear which URLs are appropriate for MacOSX 10.3 users and which (if any) aren't. (3) Are there any packages up at the undefined.org URL that can't be built from source (that is, that required some unchecked-in changes for MacOS X)? Thanks, Tom From rowen at cesmail.net Mon Jun 7 14:49:28 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Mon Jun 7 14:49:34 2004 Subject: [Pythonmac-SIG] Re: Pack Man issues on OS X 10.3.4 References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> Message-ID: In article , has wrote: > Looks like my genius shell script just blew up. I'm open to suggestions: > > - Could a better 'python exe locator' be written? Certainly. Perhaps you could base it on locate: % locate python (huge list of stuff that you'd have to grep through, unless you can figure out how to locate ^python$) Another, probably better, option is to only search the path (e.g. sys.path) for things called "python". -- Russell From Chris.Barker at noaa.gov Mon Jun 7 15:05:45 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Jun 7 15:06:55 2004 Subject: [Pythonmac-SIG] Re: Pack Man issues on OS X 10.3.4 In-Reply-To: References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> Message-ID: <40C4BC89.7080002@noaa.gov> Russell E. Owen wrote: > Perhaps you could base it on locate: > % locate python > (huge list of stuff that you'd have to grep through, unless you can > figure out how to locate ^python$) locate "*bin*python" better, but it won't pick up: /usr/bin/python2.3, for instance, which it should: locate "*bin*python?.?" will catch that, but not the former. I think locate follows glob rules, so there may be better ways. You do have to make sure that the locate DB is up to date, I'm not sure when it gets updated by the system. -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 Mon Jun 7 15:12:58 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jun 7 15:13:09 2004 Subject: [Pythonmac-SIG] Re: Pack Man issues on OS X 10.3.4 In-Reply-To: References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> Message-ID: On Jun 7, 2004, at 2:49 PM, Russell E. Owen wrote: > In article , > has wrote: > >> Looks like my genius shell script just blew up. I'm open to >> suggestions: >> >> - Could a better 'python exe locator' be written? > > Certainly. > > Perhaps you could base it on locate: > % locate python > (huge list of stuff that you'd have to grep through, unless you can > figure out how to locate ^python$) > > Another, probably better, option is to only search the path (e.g. > sys.path) for things called "python". find is definitely way too slow to use for this. locate can easily get out of date.. especially considering if you just install a new python, the first thing you're going to do is install modules for it. I would just take the system /usr/bin/python. If the user wants something else, make them (go somewhat out of their way to) configure it. Anything else can get confusing really fast. When you present a dialog to the user allowing them to configure the location, populate it with a few sane choices (/usr/local/bin [self install], /opt/local/bin [darwinports], and /sw/bin [fink]) if they exist, but give them the option to type in another path if they want to. Searching the path is unpredictable at best because chances are the user isn't going to put their path of choice into the environment.plist so that GUI apps would pick up on it (I don't do this, for example.. I just use .tcshrc). -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040607/3862ec8d/smime.bin From bob at redivi.com Mon Jun 7 15:28:53 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jun 7 15:29:02 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> Message-ID: On Jun 7, 2004, at 8:38 AM, has wrote: > Bob Ippolito > >> I downloaded PyMod and the following things happen: >> - It launches with a window that says "Path" and has some buttons. If >> it worked, I wouldn't really know what to do with it. Path to what? > > Path to the setup.py script of the distutils package to build or > install. Or to a .zip or .tar.gz archive assumed to be a compressed > package. (Note: I suspect I should cater to other compressed forms > too, e.g. .tar.bz2 or whatever it's called. Any easy way of doing > this, other than writing a different archive-decompression shell > script each time?) > > FWIW, the tool tip and built-in help do explain what this field is > for. But you're quite right that the visible label is poor, so I'm > wide open to suggestions for a better name. I would've probably seen the tool top or built-in help if the application correctly launched at all. Since you are so gung-ho about simple solutions, how come your application tries to unpack archives at all? The user should already have software that does that, and since they have to download packages themselves, there's a non-zero chance that Safari and/or StuffIt already unpacked it for them. >> - I can't focus the application because it's busy doing something. >> There is no indication of what this something is. > > There's a few seconds' delay upon startup as it initialises itself. I > suspect the bottleneck is the following shell script: > > find /usr -name python; find /usr -name pythonw --- >> - Eventually it comes up with an error dialog that says "find: >> /usr/local/pgsql/data: Permission denied" twice, with a Quit button. > > Looks like my genius shell script just blew up. I'm open to > suggestions: I posted a reasonable alternative in another message. >> - I cilck Ok, and it quits. > > Yayy! SOMETHING worked! ("But it works just fine OMM!") > > Anyway, this is what [third-party user] testing is for. Much > appreciated, and in return I've posted a modified version with the > funky 'python mis-finder' script disabled so you can [hopefully] try > the rest of it out: > > http://freespace.virgin.net/hamish.sanderson/PyMod_for_Bob.sit > > Let me know what other horrors you find. ;) > > (BTW, delete any PyMod.plist preferences file before running, just to > get a clean shot at it.) It didn't get far enough to even make one the first run. - This time it gets far enough to let me interact with the application, but it does NOT present me any choices for python locations. - It lets me type in my own location, but it doesn't have a button that says "ok" nor does it dismiss the input dialog when I press return. - The file chooser shows dot files.. why? Nowhere else does.. - It lets me choose any file I want, but doesn't let me do anything with it (even if it is a setup.py or legitimate archive containing one) - The dock icon accepts file drops, but does not do anything with them At this point, even if it did work, I'm not really interested enough in it continue testing it.. You should find someone in the target audience (presumably those who are not comfortable in a shell) to bang on this thing for you... -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040607/78479bc9/smime.bin From mww at opendarwin.org Mon Jun 7 19:28:19 2004 From: mww at opendarwin.org (Markus W. Weissmann) Date: Mon Jun 7 19:29:34 2004 Subject: [Pythonmac-SIG] Re: Pack Man issues on OS X 10.3.4 In-Reply-To: References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> Message-ID: <5BEFD03E-B8DA-11D8-A7D6-000D93AE2252@opendarwin.org> On Jun 07, 2004, at 21:12, Bob Ippolito wrote: > On Jun 7, 2004, at 2:49 PM, Russell E. Owen wrote: > >> In article , >> has wrote: >> >>> Looks like my genius shell script just blew up. I'm open to >>> suggestions: >>> >>> - Could a better 'python exe locator' be written? >> >> Certainly. >> >> Perhaps you could base it on locate: >> % locate python >> (huge list of stuff that you'd have to grep through, unless you can >> figure out how to locate ^python$) >> >> Another, probably better, option is to only search the path (e.g. >> sys.path) for things called "python". > > find is definitely way too slow to use for this. > what about just "which python"? This will most probably hit the python that the user wants. At least its the python he/she uses. > locate can easily get out of date.. especially considering if you just > install a new python, the first thing you're going to do is install > modules for it. > > I would just take the system /usr/bin/python. If the user wants > something else, make them (go somewhat out of their way to) configure > it. Anything else can get confusing really fast. When you present a > dialog to the user allowing them to configure the location, populate > it with a few sane choices (/usr/local/bin [self install], > /opt/local/bin [darwinports], and /sw/bin [fink]) if they exist, but > give them the option to type in another path if they want to. > Searching the path is unpredictable at best because chances are the > user isn't going to put their path of choice into the > environment.plist so that GUI apps would pick up on it (I don't do > this, for example.. I just use .tcshrc). > > -bob Markus --- Markus W. Weissmann http://www.mweissmann.de/ http://www.opendarwin.org/~mww/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040608/abd788e5/PGP.bin From bob at redivi.com Mon Jun 7 20:01:08 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jun 7 20:01:18 2004 Subject: [Pythonmac-SIG] Re: Pack Man issues on OS X 10.3.4 In-Reply-To: <5BEFD03E-B8DA-11D8-A7D6-000D93AE2252@opendarwin.org> References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> <5BEFD03E-B8DA-11D8-A7D6-000D93AE2252@opendarwin.org> Message-ID: On Jun 7, 2004, at 7:28 PM, Markus W. Weissmann wrote: > On Jun 07, 2004, at 21:12, Bob Ippolito wrote: > >> On Jun 7, 2004, at 2:49 PM, Russell E. Owen wrote: >> >>> In article , >>> has wrote: >>> >>>> Looks like my genius shell script just blew up. I'm open to >>>> suggestions: >>>> >>>> - Could a better 'python exe locator' be written? >>> >>> Certainly. >>> >>> Perhaps you could base it on locate: >>> % locate python >>> (huge list of stuff that you'd have to grep through, unless you can >>> figure out how to locate ^python$) >>> >>> Another, probably better, option is to only search the path (e.g. >>> sys.path) for things called "python". >> >> find is definitely way too slow to use for this. >> > > what about just "which python"? This will most probably hit the python > that the > user wants. At least its the python he/she uses. Not necessarily, a GUI app doesn't see the same environment as a terminal running the user's default shell does. And if you did start up their default shell to do it, you'd have to deal with various edge cases.. for example, I run tcsh and I could have an alias for python which would result in something that looks like: [crack:~] bob% which ls ls: aliased to /bin/ls -G -F -h Not a good approach to take. The search order I presented shouldn't have any surprises for anyone. Always use the Python that is distributed with the machine (most common case by far), unless the user chooses otherwise. A few reasonable locations should be looked at (I listed the three most common). If it's installed anywhere else, the user who installed it surely knows where they put it. Speaking to this *specific* class of GUI application dependent on Python if they are installing modules for dp or fink, they *probably should not be using this tool*. It has no knowledge of the "native" package management system. So for this basically leaves maybe one or two MacPython users who build their own and would use a GUI tool to install packages for it. If either one of you decides to speak up, we're listening! :) And if either one of you do speak up, it might also be reasonable to also have special support for framework Python builds (for the one or two users building+maintaining their own framework Python) so that they don't have to dig deep inside to find the "real" executable (even though I'm sure at least one of them knows where to find it, it would be a minor convenience). -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040607/9fd9e16d/smime-0001.bin From ronaldoussoren at mac.com Wed Jun 9 10:56:22 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed Jun 9 10:56:49 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> Message-ID: <2C39C730-BA25-11D8-A98E-0003931CFE24@mac.com> On 7-jun-04, at 14:38, has wrote: > Bob Ippolito > > [snip 'Bill Cosby' moment] > >> PackageManager was designed to have as simple of an *implementation* >> as possible, and it pretty much does. You do a lot of hand-waving >> about how awful it is, but the reality is that it is VERY simple and >> works pretty well. The GUI application is horrible and has lots of >> bugs, but that is easy to fix. The underlying system doesn't have >> very many real problems. > > My problem isn't that it's inherently awful, it's that it's inherently > pointless. 1. Expending 100% of labour creating a solution that caters > to <1% of module installations if not an efficient use of extremely > scarce, and therefore extremely valuable, manpower and brainpower > resources (i.e. yours, Jack's and the other core MacPython > developers). 2. Its administration model is inherently non-scalable, > being utterly dependent on the good will and hard work of a few elite > MacPython gurus to maintain its custom databases. PackMan tries to provide an easy to use interface for installing *tested* packages. I hope it will grow an easy to use interface for maintaining a database and for doing coopereative management of the database. The debian projects seems to manage this just fine for an entire Linux distribution :-) What you seem to forget is that there is a difference between theory and practice. In theory installing a package is as easy as 'tar zxf some-packaget.tgz && cd some-package && python setup.py install'. In practice, there are a number of interesting packages where you have to modify setup.py or some other configuration file before you get a working installation. An anecdote from the real world: this morning I tried to install the perl BerkelyDB package on a Solaris machine at work. The obvious way to do this is "perl -MCPAN -e 'install BerkelyDB'", but that didn't work because it's config.in contained data that didn't work on this particular machine. I've had simular problems with python python packages. There's also a big mound of software that assumes that the entire Unix world uses Linux. > > I've stated several times that I couldn't care less about the state of > its GUI. PackMan's major problem _isn't_ its technical glitches (which > can be easily resolved with a bit of elbow grease as we're both happy > to acknowledge). It's a complete failure to perform a proper > cost-vs-benefit analysis of its basic concept/design, which would > quickly show it to be a classic white elephant, impossible to support > at the kind of level that would make it genuinely useful due to the > high ongoing support costs that will spiral out of control long before > you ever reach that point. And _that_ is the foundation of my argument > for abandoning PackMan and starting over again. (So please don't haul > out the old "minor technical glitches" canard again, because it'll > only annoying me... and Hulk Smash when he get angry, which won't do > any of us any favours.) > > So if you want to refute my argument as an unmigitated load of old > codswallop then you're going to have to explain how the logistics of > creating, expanding and maintaining a centrally managed package > database can be justified, and how they're not going to cause the > entire system to slowly suffocate under its own weight. (Because, you > know, that whole central planning and control thing really didn't pan > out too well for the old USSR or People's Republic of China.) And how > it's going to be more cost-effective than cutting a deal with > something like PyPI that already has a robust and sustainable - not to > mention well established and quite successful - model for doing this > sort of thing. (Decentralisation rocks. Cooperation rocks.) Because as > the whole history of software development shows, a 50%-good practical > solution that addresses 90% of the common need will beat out a > 100%-perfect ivory tower one that obsesses over a few % of corner > cases to the neglect of everything else. > > I realise a lot of programmers get a bit funny about throwing out > "working" software, but that's just something y'all need to get over. > e.g. See the arts and sciences which, being rather older and wiser > than software dev, have no such hangups about letting go and moving > on. Time to cast aside your inner albatrosses, yes? The hardware engeneering folks are very serious about creating working stuff, I suppose programmers get inspired by that (why else would we have the misnomer software engeneering?). BTW. PyPI isn't very useful as a component of a larger system (at least not at the moment). It doesn't seem to have a UI for querying it programmaticly, there are no links to downloadable archives (neither source nor binary), .... Fixing those issues is at least as much work as fixing PackMan, that's without considering the "politics" that would be needed to get those changes accepted. > > >> - I can't focus the application because it's busy doing something. >> There is no indication of what this something is. > > There's a few seconds' delay upon startup as it initialises itself. I > suspect the bottleneck is the following shell script: > > find /usr -name python; find /usr -name pythonw Like some others noted I'd hardcode a few know locations (/usr/bin/python, /usr/local/bin/python, /opt/darwinports/python, /sw/bin/python, ...) instead of running find. Your find manages to mis some of the interesting locations :-) ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From eichin at metacarta.com Wed Jun 9 11:26:09 2004 From: eichin at metacarta.com (eichin@metacarta.com) Date: Wed Jun 9 11:26:17 2004 Subject: [Pythonmac-SIG] Package Manager questions In-Reply-To: <29C5BD2A-B88A-11D8-868A-000A959B24A6@earthlink.net> References: <29C5BD2A-B88A-11D8-868A-000A959B24A6@earthlink.net> Message-ID: <7g8yew92i6.fsf@pikespeak.metacarta.com> > (2) The MacPython PackageManager page doesn't make it clear which URLs > are appropriate for MacOSX 10.3 users and which (if any) aren't. Ohh, that didn't even occur to me (given how late I was in upgrading to 10.3, I thought I was trailing edge...): is this why PyGame doesn't install? "Problem with dependency: (WriteableBin): This package cannot be installed automatically (no Download-URL field" "Problem with dependency: (WriteableInclude): This package cannot be installed automatically (no Download-URL field" (This comes up because someone at EuroPython just asked if I had pygame on my Mac... and I hadn't gotten around to seeing if this was fixed... there were *lots* of cool pygame-based animated presentations, so I'm going to try it, but it looks like I have to build it myself, which some of the "framework issues" discussions have caused me to fear :-) From bob at redivi.com Wed Jun 9 11:38:16 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Jun 9 11:38:27 2004 Subject: [Pythonmac-SIG] Package Manager questions In-Reply-To: <7g8yew92i6.fsf@pikespeak.metacarta.com> References: <29C5BD2A-B88A-11D8-868A-000A959B24A6@earthlink.net> <7g8yew92i6.fsf@pikespeak.metacarta.com> Message-ID: <06AE05CC-BA2B-11D8-A8F3-000A95686CD8@redivi.com> On Jun 9, 2004, at 11:26 AM, eichin@metacarta.com wrote: > >> (2) The MacPython PackageManager page doesn't make it clear which URLs >> are appropriate for MacOSX 10.3 users and which (if any) aren't. The baked-in URL is always for the exact OS you are running. My database ( http://undefined.org/python/pimp/ ) is for 10.3, though I do have an old NOT AT ALL MAINTAINED database for those poor 10.2 users, which is so much harder to find that I won't bother looking myself. > Ohh, that didn't even occur to me (given how late I was in upgrading > to 10.3, I thought I was trailing edge...): is this why PyGame doesn't > install? > > "Problem with dependency: (WriteableBin): This package cannot be > installed automatically (no Download-URL field" > "Problem with dependency: (WriteableInclude): This package cannot be > installed automatically (no Download-URL field" You need to do some chmod'ing.. turn on hidden packages and read the description. This is just one of those "holy crap the PackageManager UI is garbage" things. A future version will allow you to authenticate in these scenarios. When that future version will exist, nobody knows :) > (This comes up because someone at EuroPython just asked if I had > pygame on my Mac... and I hadn't gotten around to seeing if this was > fixed... there were *lots* of cool pygame-based animated > presentations, so I'm going to try it, but it looks like I have to > build it myself, which some of the "framework issues" discussions have > caused me to fear :-) No. But it should build fine yourself if you have all the prerequisites (dev frameworks for SDL, SDL_image, SDL_mixer, SDL_ttf, and PyObjC.. off the top of my head). -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040609/6b1398c4/smime.bin From kevino at tulane.edu Wed Jun 9 12:38:22 2004 From: kevino at tulane.edu (Kevin Ollivier) Date: Wed Jun 9 12:38:30 2004 Subject: [Pythonmac-SIG] Pack Man issues on OS X 10.3.4 In-Reply-To: <2C39C730-BA25-11D8-A98E-0003931CFE24@mac.com> References: <2C7D8951-B5FA-11D8-AFF7-00039345C610@darwin.in-berlin.de> <7A2C0330-B657-11D8-B453-000A95686CD8@redivi.com> <658E6C3B-B662-11D8-B453-000A95686CD8@redivi.com> <2C39C730-BA25-11D8-A98E-0003931CFE24@mac.com> Message-ID: <6BF91980-BA33-11D8-A833-000393CB1C86@tulane.edu> Hi Ronald, On Jun 9, 2004, at 7:56 AM, Ronald Oussoren wrote: > > On 7-jun-04, at 14:38, has wrote: > >> Bob Ippolito >> >> [snip 'Bill Cosby' moment] >> >>> PackageManager was designed to have as simple of an *implementation* >>> as possible, and it pretty much does. You do a lot of hand-waving >>> about how awful it is, but the reality is that it is VERY simple and >>> works pretty well. The GUI application is horrible and has lots of >>> bugs, but that is easy to fix. The underlying system doesn't have >>> very many real problems. >> >> My problem isn't that it's inherently awful, it's that it's >> inherently pointless. 1. Expending 100% of labour creating a solution >> that caters to <1% of module installations if not an efficient use of >> extremely scarce, and therefore extremely valuable, manpower and >> brainpower resources (i.e. yours, Jack's and the other core MacPython >> developers). 2. Its administration model is inherently non-scalable, >> being utterly dependent on the good will and hard work of a few elite >> MacPython gurus to maintain its custom databases. > > PackMan tries to provide an easy to use interface for installing > *tested* packages. I hope it > will grow an easy to use interface for maintaining a database and for > doing coopereative management of the database. The debian projects > seems to manage this just fine for an entire > Linux distribution :-) Yes, but that's because they've got a good number of people using Debian testing/unstable. If they had no one testing packages, and had to QA all packages with no help from the outside world, their stable packages would probably be based on even older packages than it is now. ;-) The point, IMHO, is that while a few gurus can maintain "the database" and make sure all contributions are on the up-and-up, I'm not sure it's a good idea to put all the work of developing packages, testing and QA on their shoulders alone, as they can't test on a very large number of machines and we'll end up having so few QA packages that it won't really be much of a Package Manager. Instead, there should be a "testing" or "unstable" branch built into PM (which people can enable after clicking yes to an "ARE YOU SURE!?" type of dialog) so that people like myself can install packages, report any problems, and not have to wait until everything is QA'd to use it. I'll be happy to test a package if it means getting access to the package faster, and by all accounts, this strategy ensures a lot of package testing for the Debian folks. So I don't think it means we'll end up with a bunch of "non-QA'd" packages in the database, rather, the packages would get QA'd faster. Build/install problems are caught by the software itself, so the error could be forwarded directly to the "scapegoat" along with the version of Python/OS X they are using, and I think that would actually speed up the diagnosis and resolution of problems. We could also implement ways of keeping track of the number of successful installs on Jaguar, Panther, etc. BTW, as for the interface, for the Windows/Linux version of PackMan (I guess Mac will be using Cocoa), I plan on providing a GUI wrapper to Bob's buildpkg script so that people can "submit" packages for inclusion into the database, and once a scapegoat properly ensures the package installs on their machine, it goes into the "testing/unstable" branch. I think this would encourage more contributions and help build the database. Hopefully I will have more time to do contributions now that summer is here and I have *finally* finished my schooling. ;-) But we need to get wxPython 2.5.2 out first, which should be in the next week or two. > What you seem to forget is that there is a difference between theory > and practice. In theory > installing a package is as easy as 'tar zxf some-packaget.tgz && cd > some-package && python setup.py install'. In practice, there are a > number of interesting packages where you have to modify setup.py or > some other configuration file before you get a working installation. > > An anecdote from the real world: this morning I tried to install the > perl BerkelyDB package on a Solaris machine at work. The obvious way > to do this is "perl -MCPAN -e 'install BerkelyDB'", but that didn't > work because it's config.in contained data that didn't work on this > particular machine. This is exactly why I think we need a testing/unstable branch to find and work out the "corner cases". Of course, making a package work on Panther or Jaguar alone provides a more homogeneous environment that needs less testing, but we should still be mindful of the various ways in which people configure their machines. (Off hand, I can think of library conflicts due to other versions of libraries installed as well, etc.) QA'd packages should only blow up if the user REALLY mucked up their machine, but it should at least provide warnings for problems with alternative configurations. [snip] > The hardware engeneering folks are very serious about creating working > stuff, I suppose programmers get inspired by that (why else would we > have the misnomer software engeneering?). > > BTW. PyPI isn't very useful as a component of a larger system (at > least not at the moment). It doesn't seem to have a UI for querying it > programmaticly, there are no links to downloadable archives (neither > source nor binary), .... Fixing those issues is at least as much work > as fixing PackMan, that's without considering the "politics" that > would be needed to get those changes accepted. There is room for integration, though, and I think we should visibly integrate with PyPI if only for political reasons. =) It would show some goodwill to show we're not really trying to step on the work of others. In the end, I see it as providing a web-based interface to PackMan. Source and Binary "links" could be made that fire up PackMan and have it start fetching the package you clicked on. Thanks, Kevin From Jack.Jansen at cwi.nl Wed Jun 9 16:19:44 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Jun 9 16:20:04 2004 Subject: [Pythonmac-SIG] Package Manager questions In-Reply-To: <7g8yew92i6.fsf@pikespeak.metacarta.com> References: <29C5BD2A-B88A-11D8-868A-000A959B24A6@earthlink.net> <7g8yew92i6.fsf@pikespeak.metacarta.com> Message-ID: <58D685FA-BA52-11D8-9875-000D934FF6B4@cwi.nl> On 9 Jun 2004, at 17:26, eichin@metacarta.com wrote: > "Problem with dependency: (WriteableBin): This package cannot be > installed automatically (no Download-URL field" As Bob already stated the problem here is the error message. The most user-friendly and technically correct error message would be something like "The package you tried to install depends on package "(WriteableBin)", and that is a package I cannot install automatically for you (there is no Download-URL field for it). Please select the "(WriteableBin)" package and read the description, it should contain instructions on how to proceed". Does anyone have any suggestions for saying something equivalent to this in a one- or two-line message box? -- 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 bob at redivi.com Wed Jun 9 16:32:09 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Jun 9 16:32:15 2004 Subject: [Pythonmac-SIG] Package Manager questions In-Reply-To: <58D685FA-BA52-11D8-9875-000D934FF6B4@cwi.nl> References: <29C5BD2A-B88A-11D8-868A-000A959B24A6@earthlink.net> <7g8yew92i6.fsf@pikespeak.metacarta.com> <58D685FA-BA52-11D8-9875-000D934FF6B4@cwi.nl> Message-ID: <14E5A282-BA54-11D8-A8F3-000A95686CD8@redivi.com> On Jun 9, 2004, at 4:19 PM, Jack Jansen wrote: > > On 9 Jun 2004, at 17:26, eichin@metacarta.com wrote: >> "Problem with dependency: (WriteableBin): This package cannot be >> installed automatically (no Download-URL field" > > As Bob already stated the problem here is the error message. > > The most user-friendly and technically correct error message would be > something like "The package you tried to install depends on package > "(WriteableBin)", and that is a package I cannot install automatically > for you (there is no Download-URL field for it). Please select the > "(WriteableBin)" package and read the description, it should contain > instructions on how to proceed". > > Does anyone have any suggestions for saying something equivalent to > this in a one- or two-line message box? How about a dialog box named "Authenticate" with the following text: PackageManager requires that you type your password. It would also have two fields, "Name" and "Password", with a disclosure triangle called "Details", that should show information such as: Requested right: system.privilege.admin Application: /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ Python.app Additionally, it would have two buttons, "OK" and "Cancel". What do you think? ;) (yes, I know we need a different dialog for WxPython and TclTkAqua dependencies.. but it's retarded that we don't just fix this -- the most common problem -- the right way) -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040609/a8e061cc/smime.bin From ronaldoussoren at mac.com Wed Jun 9 17:00:41 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed Jun 9 17:00:56 2004 Subject: [Pythonmac-SIG] Package Manager questions In-Reply-To: <14E5A282-BA54-11D8-A8F3-000A95686CD8@redivi.com> References: <29C5BD2A-B88A-11D8-868A-000A959B24A6@earthlink.net> <7g8yew92i6.fsf@pikespeak.metacarta.com> <58D685FA-BA52-11D8-9875-000D934FF6B4@cwi.nl> <14E5A282-BA54-11D8-A8F3-000A95686CD8@redivi.com> Message-ID: <10F97EE7-BA58-11D8-A98E-0003931CFE24@mac.com> On 9-jun-04, at 22:32, Bob Ippolito wrote: > > On Jun 9, 2004, at 4:19 PM, Jack Jansen wrote: > >> >> On 9 Jun 2004, at 17:26, eichin@metacarta.com wrote: >>> "Problem with dependency: (WriteableBin): This package cannot be >>> installed automatically (no Download-URL field" >> >> As Bob already stated the problem here is the error message. >> >> The most user-friendly and technically correct error message would be >> something like "The package you tried to install depends on package >> "(WriteableBin)", and that is a package I cannot install >> automatically for you (there is no Download-URL field for it). Please >> select the "(WriteableBin)" package and read the description, it >> should contain instructions on how to proceed". >> >> Does anyone have any suggestions for saying something equivalent to >> this in a one- or two-line message box? > > How about a dialog box named "Authenticate" with the following text: > > PackageManager requires that you type your password. > > It would also have two fields, "Name" and "Password", with a > disclosure triangle called "Details", that should show information > such as: > Requested right: system.privilege.admin > Application: > /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python.app > > Additionally, it would have two buttons, "OK" and "Cancel". > > What do you think? ;) > > (yes, I know we need a different dialog for WxPython and TclTkAqua > dependencies.. but it's retarded that we don't just fix this -- the > most common problem -- the right way) IMHO the existance of (WriteableBin) is a bug in all packman databases (*). We could easily arange to install scripts somewhere else (such as /usr/local/bin, or /Applications/MacPython-2.3/Extras/bin). This can be done using the '--install-scripts=' option of setup.py. (WriteableLib) and (WritableIncludes) are needed (sadly enough), unless we install a modified version of distutils (see the mailinglist archive for a method of patching distutils at runtime). While I do think distutils should be modified to support multiple include/library diretories, I do not think this problem is serious enough to circumvent the usual procedures (e.g. we need to find someone who is stupid enough to volunteer to write a pep and patch ;) That said, adding builtin support for (WriteableFOO) would solve some problems and interfacing with SecurityServices is not very hard. The major problem with these pseudo-packages is that they tell the user to perform some "scary" actions, while the wxPython and TclTkAqua dependencies can (and do) point to an installer which is much less scary for a novice user. Adding generic support for executing arbitrary code as root would be stupid. BTW. We don't need a different dialog for wxPython, your packaging of pygame proves that you can install non-python packages through packman. wxWidgets could be installed through packman, and wxPython is just like any other random wrapper package (although you need a lot of patience or a fast machine when you want to install from source). Ronald (*) The problem is in PackMan for 'source' packages, but there is no such excuse for 'binary' packages. > > -bob > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From bob at redivi.com Wed Jun 9 17:15:43 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Jun 9 17:15:56 2004 Subject: [Pythonmac-SIG] Package Manager questions In-Reply-To: <10F97EE7-BA58-11D8-A98E-0003931CFE24@mac.com> References: <29C5BD2A-B88A-11D8-868A-000A959B24A6@earthlink.net> <7g8yew92i6.fsf@pikespeak.metacarta.com> <58D685FA-BA52-11D8-9875-000D934FF6B4@cwi.nl> <14E5A282-BA54-11D8-A8F3-000A95686CD8@redivi.com> <10F97EE7-BA58-11D8-A98E-0003931CFE24@mac.com> Message-ID: <2B6504C4-BA5A-11D8-A247-000A95686CD8@redivi.com> On Jun 9, 2004, at 5:00 PM, Ronald Oussoren wrote: > > On 9-jun-04, at 22:32, Bob Ippolito wrote: > >> >> On Jun 9, 2004, at 4:19 PM, Jack Jansen wrote: >> >>> >>> On 9 Jun 2004, at 17:26, eichin@metacarta.com wrote: >>>> "Problem with dependency: (WriteableBin): This package cannot be >>>> installed automatically (no Download-URL field" >>> >>> As Bob already stated the problem here is the error message. >>> >>> The most user-friendly and technically correct error message would >>> be something like "The package you tried to install depends on >>> package "(WriteableBin)", and that is a package I cannot install >>> automatically for you (there is no Download-URL field for it). >>> Please select the "(WriteableBin)" package and read the description, >>> it should contain instructions on how to proceed". >>> >>> Does anyone have any suggestions for saying something equivalent to >>> this in a one- or two-line message box? >> >> How about a dialog box named "Authenticate" with the following text: >> >> PackageManager requires that you type your password. >> >> It would also have two fields, "Name" and "Password", with a >> disclosure triangle called "Details", that should show information >> such as: >> Requested right: system.privilege.admin >> Application: >> /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ >> Python.app >> >> Additionally, it would have two buttons, "OK" and "Cancel". >> >> What do you think? ;) >> >> (yes, I know we need a different dialog for WxPython and TclTkAqua >> dependencies.. but it's retarded that we don't just fix this -- the >> most common problem -- the right way) > > IMHO the existance of (WriteableBin) is a bug in all packman databases > (*). We could easily arange to install scripts somewhere else (such as > /usr/local/bin, or /Applications/MacPython-2.3/Extras/bin). This can > be done using the '--install-scripts=' option of setup.py. > > (WriteableLib) and (WritableIncludes) are needed (sadly enough), > unless we install a modified version of distutils (see the mailinglist > archive for a method of patching distutils at runtime). While I do > think distutils should be modified to support multiple include/library > diretories, I do not think this problem is serious enough to > circumvent the usual procedures (e.g. we need to find someone who is > stupid enough to volunteer to write a pep and patch ;) > > That said, adding builtin support for (WriteableFOO) would solve some > problems and interfacing with SecurityServices is not very hard. The > major problem with these pseudo-packages is that they tell the user to > perform some "scary" actions, while the wxPython and TclTkAqua > dependencies can (and do) point to an installer which is much less > scary for a novice user. > > Adding generic support for executing arbitrary code as root would be > stupid. > > BTW. We don't need a different dialog for wxPython, your packaging of > pygame proves that you can install non-python packages through > packman. wxWidgets could be installed through packman, and wxPython is > just like any other random wrapper package (although you need a lot of > patience or a fast machine when you want to install from source). > > Ronald > > (*) The problem is in PackMan for 'source' packages, but there is no > such excuse for 'binary' packages. Here's an excuse: I'm too busy (or maybe lazy) to bother twiddling the setup.py flags ;) I agree though, but I think we should also fix distutils while we're at it. Since wxPython and TclTkAqua already provide .pkg installers, we should probably just exec the package installer tool (GUI or otherwise, I guess we could let the user choose) to install their packages, instead of reinventing wheels. Perhaps maybe we should start using .pkg files as the standard way of doing things, and automating it behind the scenes? We get nice receipts that way, and it makes our work a little bit more reusable for PackageManager haters :) Is /usr/local/bin writable by admin by default? What if the user is not an admin? I wrapped Authorization almost 8 months ago, pretty much for this specific use case: http://undefined.org/python/#Authorization. We could display the code that will be executed as root before it runs.. We already allow arbitrary admin-level code to execute without prompting "This package requires a script to...", which scares me more than asking for root and then doing something nasty; I'd be more pissed off if someone did rm -rf ~ than rm -rf /bin. FWIW, the Installer just asks for admin access and then the .pkg scripts can do whatever they want without any real checks and balances after that point. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040609/e60db977/smime-0001.bin From hengist.podd at virgin.net Wed Jun 9 18:21:55 2004 From: hengist.podd at virgin.net (has) Date: Wed Jun 9 18:22:18 2004 Subject: [Pythonmac-SIG] [FWD] OSABase (update) In-Reply-To: References: <346FBE4C-B5B7-11D8-B453-000A95686CD8@redivi.com> <541009EE-B662-11D8-BCCF-000D934FF6B4@cwi.nl> Message-ID: Hi all, Spoken to Philip Aker again vis-a-vis the OSABase licence... and, for better or worse, he's holding out for the fame, wealth and babes. So unless anyone can russle up a good ol' sugar daddy for the lad, looks like OSABase is a non-starter as far as 'official' (i.e. bundled) MacPython OSA support goes. Anyway, Philip's currently cooking up his own MacPython OSA component; he's already done a quick version using OSABase's AppleScript-based bridge, and is currently genning up on Python and its C APIs with a view to doing a version. If anyone's interested in helping him on that, drop him a mail. Or if anyone wants to start on 'official' OSA component to go into the standard distribution, a good starting point might be Brent Simmon's OSAShell. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From Jack.Jansen at cwi.nl Thu Jun 10 07:11:59 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Jun 10 07:13:59 2004 Subject: [Pythonmac-SIG] Temporarily discarding non-member mail to the PythonMac-SIG mailing list Message-ID: Folks, for some reason the pythonmac-sig mailing lists seems to be particularly hard hit with the barrage of nazi spam that started this morning (at least: much harder than any other mailing list I maintain), there's about a hundred messages per hour coming in right now. For the time being I've set the list policy for non-member posts to auto-discard in stead of hold (with a cc to the mailman owner, so Skip and myself do get a last chance at telling ligitimate posters that we've discarded their messages). I'll revert to the normal situation once this is over (keeping my fingers crossed that the viruses shut themselves down when the polling stations close in germany some time tonight). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2086 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040610/5ea5688f/smime.bin From mww at opendarwin.org Thu Jun 10 10:09:52 2004 From: mww at opendarwin.org (Markus W. Weissmann) Date: Thu Jun 10 10:11:48 2004 Subject: [Pythonmac-SIG] Temporarily discarding non-member mail to the PythonMac-SIG mailing list In-Reply-To: References: Message-ID: On Jun 10, 2004, at 13:11, Jack Jansen wrote: > Folks, > for some reason the pythonmac-sig mailing lists seems to be > particularly hard hit with the barrage of nazi spam that started this > morning (at least: much harder than any other mailing list I > maintain), there's about a hundred messages per hour coming in right > now. > > For the time being I've set the list policy for non-member posts to > auto-discard in stead of hold (with a cc to the mailman owner, so Skip > and myself do get a last chance at telling ligitimate posters that > we've discarded their messages). I'll revert to the normal situation > once this is over (keeping my fingers crossed that the viruses shut > themselves down when the polling stations close in germany some time > tonight). the election(s) will be on sunday... cheers, Markus --- Markus W. Weissmann http://www.mweissmann.de/ http://www.opendarwin.org/~mww/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040610/85d381a5/PGP.bin From daniel at brightfire.org Thu Jun 10 22:15:25 2004 From: daniel at brightfire.org (Daniel Lord) Date: Thu Jun 10 22:15:33 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 14, Issue 12 Message-ID: <333B9116-BB4D-11D8-88ED-000A95ACE052@brightfire.org> On Jun 10, 2004, at 9:05, pythonmac-sig-request@python.org wrote: > Anyway, Philip's currently cooking up his own MacPython OSA component; > he's already done a quick version using OSABase's AppleScript-based > bridge, and is currently genning up on Python and its C APIs with a > view to doing a version. If anyone's interested in helping him on > that, drop him a mail. If I have but one byte to give, let me give it for free and open source so...no thanks... > Or if anyone wants to start on 'official' OSA component to go into the > standard distribution, a good starting point might be Brent Simmon's > OSAShell. Sounds like a plan. Now if I could just find the time...and the talent Daniel From Jack.Jansen at cwi.nl Fri Jun 11 04:09:04 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jun 11 04:09:07 2004 Subject: [Pythonmac-SIG] [FWD] OSABase (update) In-Reply-To: References: <346FBE4C-B5B7-11D8-B453-000A95686CD8@redivi.com> <541009EE-B662-11D8-BCCF-000D934FF6B4@cwi.nl> Message-ID: <9AAFD5E0-BB7E-11D8-AD94-000D934FF6B4@cwi.nl> On 10 Jun 2004, at 00:21, has wrote: > Anyway, Philip's currently cooking up his own MacPython OSA component; > he's already done a quick version using OSABase's AppleScript-based > bridge, and is currently genning up on Python and its C APIs with a > view to doing a version. If anyone's interested in helping him on > that, drop him a mail. Or if anyone wants to start on 'official' OSA > component to go into the standard distribution, a good starting point > might be Brent Simmon's OSAShell. Donovan Preston has done some work on an OSA component for Python, and he promised he'd try to find some time Real Soon Now to continue with it (and I promised to help). IIRC he used OSAshell as inspiration when he last looked at this, but I'm not sure whether any code was actually used. And since then Bill Fancher's OSAPython has also re-appeared. OSAPython does a lot more (it's not only an OSA component but also yet another Python interface to sending AppleEvents, like appscript), but it can at least be used as reference. The main issue to finding out what can be reused is licensing. -- 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 ronaldoussoren at mac.com Fri Jun 11 04:20:46 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri Jun 11 04:21:03 2004 Subject: [Pythonmac-SIG] [FWD] OSABase (update) In-Reply-To: <9AAFD5E0-BB7E-11D8-AD94-000D934FF6B4@cwi.nl> References: <346FBE4C-B5B7-11D8-B453-000A95686CD8@redivi.com> <541009EE-B662-11D8-BCCF-000D934FF6B4@cwi.nl> <9AAFD5E0-BB7E-11D8-AD94-000D934FF6B4@cwi.nl> Message-ID: <3D788C60-BB80-11D8-A98E-0003931CFE24@mac.com> On 11-jun-04, at 10:09, Jack Jansen wrote: > And since then Bill Fancher's OSAPython has also re-appeared. where? the only reference to OSAPython that I've found is and that is ancient (latest update is feb 2002). Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From Jonathan.Peirce at nottingham.ac.uk Fri Jun 11 11:22:35 2004 From: Jonathan.Peirce at nottingham.ac.uk (Jon Peirce) Date: Fri Jun 11 11:22:40 2004 Subject: [Pythonmac-SIG] vorbis library Message-ID: <40C9CE3B.2080904@psychology.nottingham.ac.uk> Bob, Using your pygame package as well as the pygame dependency (SDL) package I still got unstuck with the mixer module. It did install but seems to link to a library that I didn't have (a Vorbis codec?): libvorbisfile.3.dylib This is the underlying error messsage: /usr/local/lib/libvorbisfile.3.dylib: dyld: /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ Python.app/Contents/MacOS/Python can't open library: /usr/local/lib/libvorbisfile.3.dylib (No such file or directory, errno = 2) Could the vorbis libraries be added to the pygame dependencies package? Or the SDL people should pack it with their libraries? Or is there a better solution? Jon This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From bob at redivi.com Fri Jun 11 11:36:59 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jun 11 11:37:15 2004 Subject: [Pythonmac-SIG] vorbis library In-Reply-To: <40C9CE3B.2080904@psychology.nottingham.ac.uk> References: <40C9CE3B.2080904@psychology.nottingham.ac.uk> Message-ID: <2E033BAD-BBBD-11D8-8071-000A95686CD8@redivi.com> On Jun 11, 2004, at 11:22 AM, Jon Peirce wrote: > Bob, > > Using your pygame package as well as the pygame dependency (SDL) > package I still got unstuck with the mixer module. It did install but > seems to link to a library that I didn't have (a Vorbis codec?): > libvorbisfile.3.dylib > > This is the underlying error messsage: > > /usr/local/lib/libvorbisfile.3.dylib: dyld: > /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python.app/Contents/MacOS/Python can't open library: > /usr/local/lib/libvorbisfile.3.dylib (No such file or directory, > errno = 2) > > Could the vorbis libraries be added to the pygame dependencies > package? Or the SDL people should pack it with their libraries? Or is > there a better solution? When did you install that? I could've sworn I fixed it. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040611/bcd42c56/smime.bin From Jonathan.Peirce at nottingham.ac.uk Fri Jun 11 13:09:20 2004 From: Jonathan.Peirce at nottingham.ac.uk (Jon Peirce) Date: Fri Jun 11 13:09:26 2004 Subject: [Pythonmac-SIG] vorbis library In-Reply-To: References: Message-ID: <40C9E740.4020800@psychology.nottingham.ac.uk> Aah, sorry, I was using http://undefined.org/python/pimp/darwin-6.6-Power_Macintosh.plist as linked from the packmanager page http://www.python.org/packman/ In the version http://undefined.org/python/pimp/darwin-7.2-Power_Macintosh.plist it is indeed fixed. Thanks Maybe the packman page should be updated (or pointed at http://undefined.org/python/pimp/ so that Bob can change his version more easily?) Jon > > > ------------------------------------------------------------------------ > > Subject: > [Pythonmac-SIG] vorbis library > From: > Jon Peirce > Date: > Fri, 11 Jun 2004 16:22:35 +0100 > To: > pythonmac-sig@python.org > > To: > pythonmac-sig@python.org > > > Bob, > > Using your pygame package as well as the pygame dependency (SDL) > package I still got unstuck with the mixer module. It did install but > seems to link to a library that I didn't have (a Vorbis codec?): > libvorbisfile.3.dylib > > This is the underlying error messsage: > > /usr/local/lib/libvorbisfile.3.dylib: dyld: > /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python.app/Contents/MacOS/Python can't open library: > /usr/local/lib/libvorbisfile.3.dylib (No such file or directory, > errno = 2) > > Could the vorbis libraries be added to the pygame dependencies > package? Or the SDL people should pack it with their libraries? Or is > there a better solution? > > Jon > > This message has been scanned but we cannot guarantee that it and any > attachments are free from viruses or other damaging content: you are > advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > > > > > ------------------------------------------------------------------------ > > Subject: > Re: [Pythonmac-SIG] vorbis library > From: > Bob Ippolito > Date: > Fri, 11 Jun 2004 11:36:59 -0400 > To: > Jon Peirce > > To: > Jon Peirce > CC: > pythonmac-sig@python.org > > > > On Jun 11, 2004, at 11:22 AM, Jon Peirce wrote: > >> Bob, >> >> Using your pygame package as well as the pygame dependency (SDL) >> package I still got unstuck with the mixer module. It did install but >> seems to link to a library that I didn't have (a Vorbis codec?): >> libvorbisfile.3.dylib >> >> This is the underlying error messsage: >> >> /usr/local/lib/libvorbisfile.3.dylib: dyld: >> /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ >> Python.app/Contents/MacOS/Python can't open library: >> /usr/local/lib/libvorbisfile.3.dylib (No such file or directory, >> errno = 2) >> >> Could the vorbis libraries be added to the pygame dependencies >> package? Or the SDL people should pack it with their libraries? Or is >> there a better solution? > > > When did you install that? I could've sworn I fixed it. > > -bob > This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From hengist.podd at virgin.net Sat Jun 12 09:16:08 2004 From: hengist.podd at virgin.net (has) Date: Sat Jun 12 09:17:55 2004 Subject: PyMod take-two (Re: [Pythonmac-SIG] Re: Pack Man issues on OS X 10.3.4) Message-ID: Hi all, Apologies for slow reply, just busy with other stuff (what's new?). Anyway, thanks to everyone who's given suggestions on finding python executables, and especially to Bob for his thorough pounding of my pymod app and its usability problems. (So many in such a small space; who'da thunk? So much for a slam-dunk.) I've gone back to the drawing board and come up with a revised design that should be an improvement on the last one. I've posted a screenshot here if anyone would like to take a look and let me know what they think: http://freespace.virgin.net/hamish.sanderson/distutils-gui.gif Basic operation: The new design is pure drag-n-drop powered: drag one or more package folders or setup.py scripts onto the application, and their paths will show up in the list in the upper part of the window. Anything that isn't a DU package will cause a dialog to appear notifying the user of this and won't be included in the list. Clicking the build/install buttons will build or install all listed packages as a single batch operation. Not sure if the window would be best labelled 'DistUtils Packages' or named after the application itself - any preferences? I've also chucked the separate Prefs dialog and put the combo box for specifying the python executable path into the main window. I'm not sure if the Build/Install buttons should be disabled until both packages and Python path are specified. It seems logical on the surface, but as Bob pointed out it totally sucks for user feedback. So I'm thinking a more helpful, self-explanatory solution would be to enable the buttons as soon as there's packages added to the list, and if users click them while no valid python path is given then a dialog should appear telling them to specify the python path before trying again. How's that sound? I'll also rework the icon so it looks more 'drag-n-droppy', like DropStuff or Expander. And I'm toying with new names: 'distutilsGUI', 'duGUI', 'DistUtils-GUI' or 'DU-GUI' are the obvious choices at this point, given that the app is just a GUI frontend to basic DistUtils functions. Feel free to laugh, make alternative suggestions, etc. If anyone's any thoughts on this new approach, please drop us a note. Or if all's well, I'll whip up a working version for next week and see if the baying mobs can shred that one as well. Many thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From eichin at metacarta.com Sat Jun 12 13:45:41 2004 From: eichin at metacarta.com (eichin@metacarta.com) Date: Sat Jun 12 13:45:47 2004 Subject: [Pythonmac-SIG] Package Manager questions In-Reply-To: <7g8yew92i6.fsf@pikespeak.metacarta.com> References: <29C5BD2A-B88A-11D8-868A-000A959B24A6@earthlink.net> <7g8yew92i6.fsf@pikespeak.metacarta.com> Message-ID: <7gd644sm9m.fsf@pikespeak.metacarta.com> Thanks, all, I am much enlightened. (That certainly is one of those "once you know what it means, you know what it means" messages :-) (Perhaps an error that involves a hidden package should force "view hidden packages" on?) From kenneth.m.mcdonald at sbcglobal.net Mon Jun 14 01:28:25 2004 From: kenneth.m.mcdonald at sbcglobal.net (Kenneth McDonald) Date: Mon Jun 14 01:28:30 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X Message-ID: The following comes from some experiences I've had recently whilst wrangling with wxPython/SPE, plus some others encountered in the past while doing custom installs of Tk and tkinter. I don't want to start any flame wars, and I certainly don't want to hurt any feelings--the Python people at Apple are doing a great job, and I really appreciate their effort. However, the "Apple Philosophy" as applied to Python (and indeed as applied to much of the UNIX subsurface in OS X) is making things painfully, and in my opinion unnecessarily, difficult to use. First, the obvious: Having a "required, custom" build of Python on OS X is a Bad Idea. Last I heard, this was the official OS X way of doing things, i.e. the Python you got was what you should use, don't try replacing it, and no, it's not a stock Python. I believe this has been recognized to be a problem and is being worked on--sorry if I'm ignorant of recent fixes, I "threw out" the stock OS X Python some time ago, as I needed my own custom compilations. In general (and I'm sure the Apple techs understand this, but perhaps you could pass this on to those in management who don't?), DON'T EVER take a community standard tool such as Python and "improve" it in such a manner as to make it incompatible with what people have come to expect. If you must produce an Apple-specific version which requires special consideration when being used with other packages, then observe the following: 1) The _standard_ version should be the standard; even on OS X. People who want to use Python without caring about the OS its on will then be able to use it properly. Those who want to make use of the os-enhanced version will know what to do. 2) Make sure that an 'enhanced' version can coexist peacefully with the standard version. One of the things that is expected is that I can download, compile, and install a more recent version of Python without problem (assuming the newer version itself doesn't have problems.) Another is that add-ons for Python which have been written to install nicely in a generic UNIX environment should continue to do so under OS X. Next, paths. I can understand why Apple (actually, probably NeXT) decided to come up with improvements on the UNIX file structure. But why, oh why, couldn't they have maintained some sort of backward compatibility using links? I've effectively recreated my own UNIX file structure using links, to make up for this, and would be surprised if others haven't as well. In particular, why the heck isn't there the equivalent of /usr/local? Having this basic de facto standard sort of file structure in place would save us UNIX software users countless hours in headaches. Yes, it's easy to argue that the problems are the fault of bad installation scripts and makefiles. Well, yes, in theory that's probably true; but so what? The point of software is to be a useful tool, not to drive the customer crazy by insisting that somebody else, in assuming a de facto standard of the time would continue into the future, made a mistake. I find this a particular problem when it comes to Frameworks and Libraries. Here's a typical example of installing a couple of Python modules recently: 1) Compile module A--works, great. Install it. Where the heck are the files? Do a search on the disk. Ah, there they are in /Library/Frameworks/Python/.../.../... and so on .../2.3/site-packages. Create a link from a more reasonable location so they'll be on the python path. 2) Compile and install module B. Where is it? Disk search. Ah, it's in /Library/Python/2.3. Create link. Why did it end up here, vs. Module A in Frameworks? Beats me. And why, for that matter, are all of these modules always ending up in a '2.3' directory? I happen to know that some of them aren't dependent on the Python binary, and it looks to me as if, when 2.3 changes to 2.4, I'm gonna have some unnecessary work, again. Trust me, if a module is incompatible with 2.4, I'll know it soon enough; you don't have to force me to move everything manually to the 2.4 path. None of this is going to make me move off of OS X, of course; it still is, by far, the best OS for most users IMHO, myself included. But this situation will cost Apple some money; I generally keep fairly up-to-date with hardware, and was planning on getting a new Powerbook when they hit 2 GHz. However, I've had to do so much manual tweaking to my system that the effort needed to recreate that on a new drive is a little too much to want to repeat in the forseeable future, so Apple's probably going to have to hit 3GHz for me to decide it's worth the pain. (Yes, I know I don't have to do a "clean" install of everything when I go to a new system, but that's one of the things I do to help me clean all the cruft out.) I'm looking forward to what comes out in the future, I have a lot of confidence in the Python people at Apple, and I have no problems at all in continuing to pay for new versions of OS X which bring new features and improvements. I just hope that the above is of some help in deciding how some of those features should be implemented in the future. Thanks, Ken McDonald From bob at redivi.com Mon Jun 14 01:54:52 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jun 14 01:55:05 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: References: Message-ID: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> On Jun 14, 2004, at 1:28 AM, Kenneth McDonald wrote: > The following comes from some experiences I've had recently whilst > wrangling with wxPython/SPE, plus some others encountered in the > past while doing custom installs of Tk and tkinter. I don't want to > start > any flame wars, and I certainly don't want to hurt any feelings--the > Python > people at Apple are doing a great job, and I really appreciate their > effort. However, the "Apple Philosophy" as applied to Python (and > indeed as applied to much of the UNIX subsurface in OS X) is making > things painfully, and in my opinion unnecessarily, difficult to use. > > First, the obvious: Having a "required, custom" build of Python on > OS X is a Bad Idea. Last I heard, this was the official OS X way of > doing things, i.e. the Python you got was what you should use, don't > try replacing it, and no, it's not a stock Python. I believe this has > been > recognized to be a problem and is being worked on--sorry if I'm > ignorant of recent fixes, I "threw out" the stock OS X Python some > time ago, as I needed my own custom compilations. It's not custom. It's highly suggested not to replace it because there are various bugs here and there on the Python side that make it a bad idea to do so. > In general (and I'm sure the Apple techs understand this, but perhaps > you could pass this on to those in management who don't?), DON'T > EVER take a community standard tool such as Python and "improve" > it in such a manner as to make it incompatible with what people have > come to expect. If you must produce an Apple-specific version which > requires special consideration when being used with other packages, > then observe the following: > > 1) The _standard_ version should be the standard; even on OS X. > People who want to use Python without caring about the OS its > on will then be able to use it properly. Those who want to make use > of the os-enhanced version will know what to do. > > 2) Make sure that an 'enhanced' version can coexist peacefully with > the standard version. It *is* standard. It's not "improved". The only difference between what Apple distributes and what was in 2.3.0 is the location that it is installed in (/System rather than /) and the additional CoreGraphics extension, which has nothing to do with how it was compiled. > One of the things that is expected is that I can download, compile, > and install a more recent version of Python without problem (assuming > the newer version itself doesn't have problems.) Another is that > add-ons for Python which have been written to install nicely in a > generic UNIX environment should continue to do so under OS X. It will work just fine, but it must supersede the system installation due to bugs that were in 2.3.0 that we can not fix. Once you install your own Python, you can no longer expect to be able to compile software for the stock 2.3.0. Any Python extensions that have been written properly already use distutils, and thus already work fine on OS X. If anything is designed to work in a "generic UNIX environment" and does NOT work on OS X is simply not done correctly. Things should work on Windows too, and that means using distutils. > Next, paths. I can understand why Apple (actually, probably NeXT) > decided to come up with improvements on the UNIX file structure. > But why, oh why, couldn't they have maintained some sort of backward > compatibility using links? I've effectively recreated my own UNIX file > structure using links, to make up for this, and would be surprised if > others > haven't as well. In particular, why the heck isn't there the > equivalent of > /usr/local? Having this basic de facto standard sort of file structure > in > place would save us UNIX software users countless hours in headaches. > Yes, it's easy to argue that the problems are the fault of bad > installation > scripts and makefiles. Well, yes, in theory that's probably true; but > so > what? The point of software is to be a useful tool, not to drive the > customer > crazy by insisting that somebody else, in assuming a de facto standard > of > the time would continue into the future, made a mistake. Uh, there is a /usr/local. > I find this a particular problem when it comes to Frameworks and > Libraries. > Here's a typical example of installing a couple of Python modules > recently: > > 1) Compile module A--works, great. Install it. Where the heck are the > files? Do a search on the disk. Ah, there they are in > /Library/Frameworks/Python/.../.../... and so on .../2.3/site-packages. > Create a link from a more reasonable location so they'll be on the > python path. /Library/Python/2.3 is the more reasonable link, it already exists. > 2) Compile and install module B. Where is it? Disk search. Ah, it's in > /Library/Python/2.3. Create link. Why did it end up here, vs. Module > A in Frameworks? Beats me. They're the SAME PLACE unless you or some broken installation script screwed that up. > And why, for that matter, are all of these modules always ending up in > a '2.3' directory? I happen to know that some of them aren't dependent > on the Python binary, and it looks to me as if, when 2.3 changes to > 2.4, > I'm gonna have some unnecessary work, again. Trust me, if a module > is incompatible with 2.4, I'll know it soon enough; you don't have to > force me to move everything manually to the 2.4 path. This happens on EVERY Python platform. If you want to install "version independent" Python files somewhere else, feel free to do so. There are many options that you may pass to distutils to control this behavior. Then you simply need to make a pth file that points to your "version independent" site directory. > None of this is going to make me move off of OS X, of course; it still > is, by far, the best OS for most users IMHO, myself included. But this > situation will cost Apple some money; I generally keep fairly > up-to-date > with hardware, and was planning on getting a new Powerbook when > they hit 2 GHz. However, I've had to do so much manual tweaking to my > system that the effort needed to recreate that on a new drive is a > little too > much to want to repeat in the forseeable future, so Apple's probably > going > to have to hit 3GHz for me to decide it's worth the pain. (Yes, I know > I don't have to do a "clean" install of everything when I go to a new > system, > but that's one of the things I do to help me clean all the cruft out.) > > I'm looking forward to what comes out in the future, I have a lot of > confidence in the Python people at Apple, and I have no problems at > all in continuing to pay for new versions of OS X which bring new > features and improvements. I just hope that the above is of some help > in deciding how some of those features should be implemented in the > future. There aren't really "Python people at Apple", at least not that I'm aware of. Any problems with the Python distribution for OS X are at least partially our fault. Start filing bugs and feature requests, and making patches if you REALLY want a particular issue fixed in a way that suits you. I think a lot of your troubles are just because you expect things to work as they do in Linux, and that's just not the case. There are equivalent or better ways of doing things on OS X, that you either don't accept or haven't figured out yet. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040614/c9c0cd65/smime.bin From mww at opendarwin.org Mon Jun 14 03:35:52 2004 From: mww at opendarwin.org (Markus W. Weissmann) Date: Mon Jun 14 03:36:04 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> References: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> Message-ID: <76CEB6CC-BDD5-11D8-9046-000D93AE2252@opendarwin.org> On Jun 14, 2004, at 07:54, Bob Ippolito wrote: > > On Jun 14, 2004, at 1:28 AM, Kenneth McDonald wrote: > >> The following comes from some experiences I've had recently whilst >> wrangling with wxPython/SPE, plus some others encountered in the >> past while doing custom installs of Tk and tkinter. I don't want to >> start >> any flame wars, and I certainly don't want to hurt any feelings--the >> Python >> people at Apple are doing a great job, and I really appreciate their >> effort. However, the "Apple Philosophy" as applied to Python (and >> indeed as applied to much of the UNIX subsurface in OS X) is making >> things painfully, and in my opinion unnecessarily, difficult to use. >> >> First, the obvious: Having a "required, custom" build of Python on >> OS X is a Bad Idea. Last I heard, this was the official OS X way of >> doing things, i.e. the Python you got was what you should use, don't >> try replacing it, and no, it's not a stock Python. I believe this has >> been >> recognized to be a problem and is being worked on--sorry if I'm >> ignorant of recent fixes, I "threw out" the stock OS X Python some >> time ago, as I needed my own custom compilations. > > It's not custom. It's highly suggested not to replace it because > there are > various bugs here and there on the Python side that make it a bad idea > to do so. as an Unix-migrant you might see at least the site-packages path as being 'custom'. > >> In general (and I'm sure the Apple techs understand this, but perhaps >> you could pass this on to those in management who don't?), DON'T >> EVER take a community standard tool such as Python and "improve" >> it in such a manner as to make it incompatible with what people have >> come to expect. If you must produce an Apple-specific version which >> requires special consideration when being used with other packages, >> then observe the following: >> >> 1) The _standard_ version should be the standard; even on OS X. >> People who want to use Python without caring about the OS its >> on will then be able to use it properly. Those who want to make use >> of the os-enhanced version will know what to do. >> >> 2) Make sure that an 'enhanced' version can coexist peacefully with >> the standard version. > > It *is* standard. It's not "improved". The only difference between > what Apple distributes and what was in 2.3.0 is the location that it > is installed in (/System rather than /) and the additional > CoreGraphics extension, which has nothing to do with how it was > compiled. > >> One of the things that is expected is that I can download, compile, >> and install a more recent version of Python without problem (assuming >> the newer version itself doesn't have problems.) Another is that >> add-ons for Python which have been written to install nicely in a >> generic UNIX environment should continue to do so under OS X. > > It will work just fine, but it must supersede the system installation > due to bugs that were in 2.3.0 that we can not fix. Once you install > your own Python, you can no longer expect to be able to compile > software for the stock 2.3.0. > huh? I have a non-apple installation of python here on my machine, though apple's python still works. (of course I didn't install it into /usr...) > Any Python extensions that have been written properly already use > distutils, and thus already work fine on OS X. If anything is > designed to work in a "generic UNIX environment" and does NOT work on > OS X is simply not done correctly. Things should work on Windows too, > and that means using distutils. > thats _not_ true. 1. OS-X is a bit picky about compiling stuff (-> flat_namespace etc.) - many SWIG generated wrappers fail with apple's python 2. On stock OS-X you are doomed if you need /dev/dsp for sound (Dan Christiansen is developing a kext to fix this at least on OpenDarwin) >> Next, paths. I can understand why Apple (actually, probably NeXT) >> decided to come up with improvements on the UNIX file structure. >> But why, oh why, couldn't they have maintained some sort of backward >> compatibility using links? I've effectively recreated my own UNIX file >> structure using links, to make up for this, and would be surprised if >> others >> haven't as well. In particular, why the heck isn't there the >> equivalent of >> /usr/local? Having this basic de facto standard sort of file >> structure in >> place would save us UNIX software users countless hours in headaches. >> Yes, it's easy to argue that the problems are the fault of bad >> installation >> scripts and makefiles. Well, yes, in theory that's probably true; but >> so >> what? The point of software is to be a useful tool, not to drive the >> customer >> crazy by insisting that somebody else, in assuming a de facto >> standard of >> the time would continue into the future, made a mistake. > > Uh, there is a /usr/local. > and just in case there isnt: "sudo mkdir -p /usr/local" :) >> I find this a particular problem when it comes to Frameworks and >> Libraries. >> Here's a typical example of installing a couple of Python modules >> recently: >> >> 1) Compile module A--works, great. Install it. Where the heck are the >> files? Do a search on the disk. Ah, there they are in >> /Library/Frameworks/Python/.../.../... and so on >> .../2.3/site-packages. >> Create a link from a more reasonable location so they'll be on the >> python path. > > /Library/Python/2.3 is the more reasonable link, it already exists. > ever tried to install mod_python with apple's python? You'll get the modules clobbered somewhere into /System - and it wouldn't work if you just moved them to /Library/Python/2.3. >> 2) Compile and install module B. Where is it? Disk search. Ah, it's in >> /Library/Python/2.3. Create link. Why did it end up here, vs. Module >> A in Frameworks? Beats me. > > They're the SAME PLACE unless you or some broken installation script > screwed that up. > >> And why, for that matter, are all of these modules always ending up in >> a '2.3' directory? I happen to know that some of them aren't dependent >> on the Python binary, and it looks to me as if, when 2.3 changes to >> 2.4, >> I'm gonna have some unnecessary work, again. Trust me, if a module >> is incompatible with 2.4, I'll know it soon enough; you don't have to >> force me to move everything manually to the 2.4 path. > > This happens on EVERY Python platform. If you want to install > "version independent" Python files somewhere else, feel free to do so. > There are many options that you may pass to distutils to control this > behavior. Then you simply need to make a pth file that points to your > "version independent" site directory. Bob is right - on Unix the modules are placed in PREFIX/lib/python2.3/site-packages/ by default; > >> None of this is going to make me move off of OS X, of course; it still >> is, by far, the best OS for most users IMHO, myself included. But this >> situation will cost Apple some money; I generally keep fairly >> up-to-date >> with hardware, and was planning on getting a new Powerbook when >> they hit 2 GHz. However, I've had to do so much manual tweaking to my >> system that the effort needed to recreate that on a new drive is a >> little too >> much to want to repeat in the forseeable future, so Apple's probably >> going >> to have to hit 3GHz for me to decide it's worth the pain. (Yes, I know >> I don't have to do a "clean" install of everything when I go to a new >> system, >> but that's one of the things I do to help me clean all the cruft out.) >> >> I'm looking forward to what comes out in the future, I have a lot of >> confidence in the Python people at Apple, and I have no problems at >> all in continuing to pay for new versions of OS X which bring new >> features and improvements. I just hope that the above is of some help >> in deciding how some of those features should be implemented in the >> future. > > There aren't really "Python people at Apple", at least not that I'm > aware of. Any problems with the Python distribution for OS X are at > least partially our fault. Start filing bugs and feature requests, > and making patches if you REALLY want a particular issue fixed in a > way that suits you. > hmmm... thats true - ever tried to install python on non-apple darwin? If ./configure recognizes 'darwin' it doesn't care if your host is x86 - it just tries to compile for ppc. > I think a lot of your troubles are just because you expect things to > work as they do in Linux, and that's just not the case. There are > equivalent or better ways of doing things on OS X, that you either > don't accept or haven't figured out yet. cheers, Markus --- Markus W. Weissmann http://www.mweissmann.de/ http://www.opendarwin.org/~mww/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040614/fb2edb4e/PGP-0001.bin From Jack.Jansen at cwi.nl Mon Jun 14 03:57:40 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jun 14 03:59:17 2004 Subject: [Pythonmac-SIG] Package Manager questions In-Reply-To: <7gd644sm9m.fsf@pikespeak.metacarta.com> References: <29C5BD2A-B88A-11D8-868A-000A959B24A6@earthlink.net> <7g8yew92i6.fsf@pikespeak.metacarta.com> <7gd644sm9m.fsf@pikespeak.metacarta.com> Message-ID: <823E9E2A-BDD8-11D8-AEEC-000A958D1666@cwi.nl> On 12-jun-04, at 19:45, eichin@metacarta.com wrote: > Thanks, all, I am much enlightened. (That certainly is one of those > "once you know what it means, you know what it means" messages :-) > > (Perhaps an error that involves a hidden package should force "view > hidden packages" on?) That fix went into the sources about 2 days after the distribution went out the door:-) I have an upgrade for PackMan 99% finished, I'll be releasing it shortly, I hope. But then, this upgrade has been 99% finished since last february:-( -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2086 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040614/8383ef40/smime.bin From Jack.Jansen at cwi.nl Mon Jun 14 04:04:56 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jun 14 04:06:39 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: <76CEB6CC-BDD5-11D8-9046-000D93AE2252@opendarwin.org> References: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> <76CEB6CC-BDD5-11D8-9046-000D93AE2252@opendarwin.org> Message-ID: <8649FD29-BDD9-11D8-AEEC-000A958D1666@cwi.nl> On 14-jun-04, at 9:35, Markus W. Weissmann wrote: >> There aren't really "Python people at Apple", at least not that I'm >> aware of. Any problems with the Python distribution for OS X are at >> least partially our fault. Start filing bugs and feature requests, >> and making patches if you REALLY want a particular issue fixed in a >> way that suits you. >> > > hmmm... thats true - ever tried to install python on non-apple darwin? > If ./configure > recognizes 'darwin' it doesn't care if your host is x86 - it just > tries to compile for ppc. I'd love a patch for this: I don't have access to 386-based darwin machines, but I assume the fix would be a one-liner for configure.in or Makefile.pre.in or something, and I'd like to have it in the sourcetree. Hmm, are there any 386-darwin machines at sourceforge, or at any other publicly accessible compile farm? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2086 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040614/2f099656/smime.bin From kenneth.m.mcdonald at sbcglobal.net Mon Jun 14 04:07:30 2004 From: kenneth.m.mcdonald at sbcglobal.net (Kenneth McDonald) Date: Mon Jun 14 04:07:41 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> References: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> Message-ID: Bob, Thanks for the responses. Sorry I was wrong on some points: I'd received the impression that Apple's Python was somehow "special", and for that I apologise. In my own defense, I definitely received that impression on this group due to messages from folks at Apple; they weren't being misleading, they simply said, "Don't muck around with the Apple installation, because replacing it with your own Python distro will do bad things", or words to that effect. Without further details, it's not difficult to conclude that this must mean Apple distro != Python distro. And while I haven't actually used Linux in a long time (and never particularly enthusiastically), you are partly right about expecting certain things to be done in a UNIXish manner. There never was a real "standard" for the UNIX file structure, but Apple's structure is, uh, somewhat less standard than standard :-). What would really help--for me at least, and perhaps for others-- is a good document explaining how and why Apple has implemented certain structures, how they map to "old" structures. I've looked through a number of the OS X books available, and though I can find bits and pieces here and there, I've never seen a good, coherent overview. For example, I'd love to see a good explanation as to why Frameworks exist, why to put things into a framework structure rather than placing libraries, binaries, etc. into /.../lib, /.../bin, how to deal with Makefiles that don't know about frameworks (most of them), and so on. I also apologise for getting /usr/local wrong. As I say, I've ended up creating a number of 'old-style' UNIX directories. I guess it must've been another one. Definitely, the fact that /Library/Python/2.3 and /Library/Frameworks/Python/...{somewhere} are supposed to be the same place is news to me. They aren't the same on my system, I have no idea whether due to me or to some installer script, and now I'm scared to try to fix this :-) As regards to 'distutils', well first, I'll absolutely claim stupidity on my part about distutils always installing into a 'versioned' subdirectory, that's useful knowledge, and I'm certainly turning bright red. However, simply saying that "distutils understands OS X, so anything written properly using distutils should work on OS X" is a little too facile. I've spent too many hours trying to tell Python (and other things) where to find (non-Python) libs, files, etc. because the OS X default paths/file structure didn't seem adequate for 'legacy' UNIX software. And again, this was not intended to be criticism, at least not in the derogatory sense. I like OS X, I like programming on it, and I'm extremely glad to be back using Python after several years away from it. However, I have spent some time wrestling with problems largely caused by the "Apple-ness" of OS X at the UNIX level, and I know others have had similar problems, and I thought it would be a good idea to talk about some of these. I've certainly learned some useful things from your response. Thanks, Ken On Jun 14, 2004, at 12:54 AM, Bob Ippolito wrote: > > On Jun 14, 2004, at 1:28 AM, Kenneth McDonald wrote: > >> The following comes from some experiences I've had recently whilst >> wrangling with wxPython/SPE, plus some others encountered in the >> past while doing custom installs of Tk and tkinter. I don't want to >> start >> any flame wars, and I certainly don't want to hurt any feelings--the >> Python >> people at Apple are doing a great job, and I really appreciate their >> effort. However, the "Apple Philosophy" as applied to Python (and >> indeed as applied to much of the UNIX subsurface in OS X) is making >> things painfully, and in my opinion unnecessarily, difficult to use. >> >> First, the obvious: Having a "required, custom" build of Python on >> OS X is a Bad Idea. Last I heard, this was the official OS X way of >> doing things, i.e. the Python you got was what you should use, don't >> try replacing it, and no, it's not a stock Python. I believe this has >> been >> recognized to be a problem and is being worked on--sorry if I'm >> ignorant of recent fixes, I "threw out" the stock OS X Python some >> time ago, as I needed my own custom compilations. > > It's not custom. It's highly suggested not to replace it because > there are various bugs here and there on the Python side that make it > a bad idea to do so. > >> In general (and I'm sure the Apple techs understand this, but perhaps >> you could pass this on to those in management who don't?), DON'T >> EVER take a community standard tool such as Python and "improve" >> it in such a manner as to make it incompatible with what people have >> come to expect. If you must produce an Apple-specific version which >> requires special consideration when being used with other packages, >> then observe the following: >> >> 1) The _standard_ version should be the standard; even on OS X. >> People who want to use Python without caring about the OS its >> on will then be able to use it properly. Those who want to make use >> of the os-enhanced version will know what to do. >> >> 2) Make sure that an 'enhanced' version can coexist peacefully with >> the standard version. > > It *is* standard. It's not "improved". The only difference between > what Apple distributes and what was in 2.3.0 is the location that it > is installed in (/System rather than /) and the additional > CoreGraphics extension, which has nothing to do with how it was > compiled. > >> One of the things that is expected is that I can download, compile, >> and install a more recent version of Python without problem (assuming >> the newer version itself doesn't have problems.) Another is that >> add-ons for Python which have been written to install nicely in a >> generic UNIX environment should continue to do so under OS X. > > It will work just fine, but it must supersede the system installation > due to bugs that were in 2.3.0 that we can not fix. Once you install > your own Python, you can no longer expect to be able to compile > software for the stock 2.3.0. > > Any Python extensions that have been written properly already use > distutils, and thus already work fine on OS X. If anything is > designed to work in a "generic UNIX environment" and does NOT work on > OS X is simply not done correctly. Things should work on Windows too, > and that means using distutils. > >> Next, paths. I can understand why Apple (actually, probably NeXT) >> decided to come up with improvements on the UNIX file structure. >> But why, oh why, couldn't they have maintained some sort of backward >> compatibility using links? I've effectively recreated my own UNIX file >> structure using links, to make up for this, and would be surprised if >> others >> haven't as well. In particular, why the heck isn't there the >> equivalent of >> /usr/local? Having this basic de facto standard sort of file >> structure in >> place would save us UNIX software users countless hours in headaches. >> Yes, it's easy to argue that the problems are the fault of bad >> installation >> scripts and makefiles. Well, yes, in theory that's probably true; but >> so >> what? The point of software is to be a useful tool, not to drive the >> customer >> crazy by insisting that somebody else, in assuming a de facto >> standard of >> the time would continue into the future, made a mistake. > > Uh, there is a /usr/local. > >> I find this a particular problem when it comes to Frameworks and >> Libraries. >> Here's a typical example of installing a couple of Python modules >> recently: >> >> 1) Compile module A--works, great. Install it. Where the heck are the >> files? Do a search on the disk. Ah, there they are in >> /Library/Frameworks/Python/.../.../... and so on >> .../2.3/site-packages. >> Create a link from a more reasonable location so they'll be on the >> python path. > > /Library/Python/2.3 is the more reasonable link, it already exists. > >> 2) Compile and install module B. Where is it? Disk search. Ah, it's in >> /Library/Python/2.3. Create link. Why did it end up here, vs. Module >> A in Frameworks? Beats me. > > They're the SAME PLACE unless you or some broken installation script > screwed that up. > >> And why, for that matter, are all of these modules always ending up in >> a '2.3' directory? I happen to know that some of them aren't dependent >> on the Python binary, and it looks to me as if, when 2.3 changes to >> 2.4, >> I'm gonna have some unnecessary work, again. Trust me, if a module >> is incompatible with 2.4, I'll know it soon enough; you don't have to >> force me to move everything manually to the 2.4 path. > > This happens on EVERY Python platform. If you want to install > "version independent" Python files somewhere else, feel free to do so. > There are many options that you may pass to distutils to control this > behavior. Then you simply need to make a pth file that points to your > "version independent" site directory. > >> None of this is going to make me move off of OS X, of course; it still >> is, by far, the best OS for most users IMHO, myself included. But this >> situation will cost Apple some money; I generally keep fairly >> up-to-date >> with hardware, and was planning on getting a new Powerbook when >> they hit 2 GHz. However, I've had to do so much manual tweaking to my >> system that the effort needed to recreate that on a new drive is a >> little too >> much to want to repeat in the forseeable future, so Apple's probably >> going >> to have to hit 3GHz for me to decide it's worth the pain. (Yes, I know >> I don't have to do a "clean" install of everything when I go to a new >> system, >> but that's one of the things I do to help me clean all the cruft out.) >> >> I'm looking forward to what comes out in the future, I have a lot of >> confidence in the Python people at Apple, and I have no problems at >> all in continuing to pay for new versions of OS X which bring new >> features and improvements. I just hope that the above is of some help >> in deciding how some of those features should be implemented in the >> future. > > There aren't really "Python people at Apple", at least not that I'm > aware of. Any problems with the Python distribution for OS X are at > least partially our fault. Start filing bugs and feature requests, > and making patches if you REALLY want a particular issue fixed in a > way that suits you. > > I think a lot of your troubles are just because you expect things to > work as they do in Linux, and that's just not the case. There are > equivalent or better ways of doing things on OS X, that you either > don't accept or haven't figured out yet. > > -bob From Jack.Jansen at cwi.nl Mon Jun 14 04:24:43 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jun 14 04:26:49 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: References: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> Message-ID: <49E9A103-BDDC-11D8-B338-000A958D1666@cwi.nl> On 14-jun-04, at 10:07, Kenneth McDonald wrote: > And while I haven't actually used Linux in a long time (and never > particularly enthusiastically), you are partly right about expecting > certain things to be done in a UNIXish manner. There never was > a real "standard" for the UNIX file structure, but Apple's structure > is, uh, somewhat less standard than standard :-). > > What would really help--for me at least, and perhaps for others-- > is a good document explaining how and why Apple has implemented > certain structures, how they map to "old" structures. While this isn't possible in general, because some of the Apple structures are there specifically to enable things that aren't easy/common/possible in other unixen (Apple didn't invent these new structures just for fun:-), it is definitely possible to create a document that explains the structure of Python on the Mac to people familiar with Python on other unix platforms. Anyone willing to do a first draft of this, that we can then improve and post on the website? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2086 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040614/640852b0/smime.bin From jn_list at rebisoft.com Mon Jun 14 05:34:10 2004 From: jn_list at rebisoft.com (Jack Nutting) Date: Mon Jun 14 05:32:37 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: References: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> Message-ID: On Jun 14, 2004, at 10:07 AM, Kenneth McDonald wrote: > What would really help--for me at least, and perhaps for others-- > is a good document explaining how and why Apple has implemented > certain structures, how they map to "old" structures. I've looked > through a number of the OS X books available, and though I can > find bits and pieces here and there, I've never seen a good, > coherent overview. For example, I'd love to see a good explanation > as to why Frameworks exist, why to put things into a framework > structure rather than placing libraries, binaries, etc. into > /.../lib, /.../bin, how to deal with Makefiles that don't know about > frameworks (most of them), and so on. My short answer to your Frameworks question is: "encapsulation". You might want to look at some of the documentation on kernelthread.com. This page, for instance: http://kernelthread.com/mac/osx/programming.html contains some explanation of bundles and frameworks, for instance. -- // Jack Nutting // http://www.nuthole.com From bob at redivi.com Mon Jun 14 11:20:42 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jun 14 11:20:55 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: <76CEB6CC-BDD5-11D8-9046-000D93AE2252@opendarwin.org> References: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> <76CEB6CC-BDD5-11D8-9046-000D93AE2252@opendarwin.org> Message-ID: <66CCB32E-BE16-11D8-BEB2-000A95686CD8@redivi.com> On Jun 14, 2004, at 3:35 AM, Markus W. Weissmann wrote: > On Jun 14, 2004, at 07:54, Bob Ippolito wrote: > >> >> On Jun 14, 2004, at 1:28 AM, Kenneth McDonald wrote: >> >>> One of the things that is expected is that I can download, compile, >>> and install a more recent version of Python without problem (assuming >>> the newer version itself doesn't have problems.) Another is that >>> add-ons for Python which have been written to install nicely in a >>> generic UNIX environment should continue to do so under OS X. >> >> It will work just fine, but it must supersede the system installation >> due to bugs that were in 2.3.0 that we can not fix. Once you install >> your own Python, you can no longer expect to be able to compile >> software for the stock 2.3.0. >> > > huh? I have a non-apple installation of python here on my machine, > though > apple's python still works. (of course I didn't install it into > /usr...) If you have another *framework* python installed in /Library or ~/Library then your /System python will no longer be able to link modules correctly due to a bug in 2.3.0. >> Any Python extensions that have been written properly already use >> distutils, and thus already work fine on OS X. If anything is >> designed to work in a "generic UNIX environment" and does NOT work on >> OS X is simply not done correctly. Things should work on Windows >> too, and that means using distutils. >> > > thats _not_ true. > 1. OS-X is a bit picky about compiling stuff (-> flat_namespace etc.) > - many SWIG generated > wrappers fail with apple's python > 2. On stock OS-X you are doomed if you need /dev/dsp for sound (Dan > Christiansen is developing > a kext to fix this at least on OpenDarwin) That has nothing to do with Python. >>> I find this a particular problem when it comes to Frameworks and >>> Libraries. >>> Here's a typical example of installing a couple of Python modules >>> recently: >>> >>> 1) Compile module A--works, great. Install it. Where the heck are the >>> files? Do a search on the disk. Ah, there they are in >>> /Library/Frameworks/Python/.../.../... and so on >>> .../2.3/site-packages. >>> Create a link from a more reasonable location so they'll be on the >>> python path. >> >> /Library/Python/2.3 is the more reasonable link, it already exists. >> > > ever tried to install mod_python with apple's python? You'll get the > modules clobbered > somewhere into /System - and it wouldn't work if you just moved them > to /Library/Python/2.3. mod_python is not really a module, it's an extending+embedding of Python. It sounds like it doesn't use distutils correctly. I didn't think it still supported Apache 1.3.x anyway? -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040614/4685a619/smime.bin From kevino at tulane.edu Mon Jun 14 11:33:14 2004 From: kevino at tulane.edu (Kevin Ollivier) Date: Mon Jun 14 11:33:30 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: References: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> Message-ID: <26CC358D-BE18-11D8-A833-000393CB1C86@tulane.edu> Hi Kenneth, On Jun 14, 2004, at 1:07 AM, Kenneth McDonald wrote: > Bob, > > Thanks for the responses. Sorry I was wrong on some points: I'd > received > the impression that Apple's Python was somehow "special", and for that > I apologise. In my own defense, I definitely received that impression > on this group due to messages from folks at Apple; they weren't > being misleading, they simply said, "Don't muck around with the > Apple installation, because replacing it with your own Python > distro will do bad things", or words to that effect. Without further > details, > it's not difficult to conclude that this must mean Apple distro != > Python distro. The reason people say this is that Apple not only includes Python in OS X, they also *use* it at the system level, and they may do so even more in the future now that they can use CoreGraphics from Python. So if you replace Apple's Python with something else, you run the risk of breaking any OS X system scripts/utilities that haven't been tested with 2.3.3, for example, which definitely would not be a good thing. > And while I haven't actually used Linux in a long time (and never > particularly enthusiastically), you are partly right about expecting > certain things to be done in a UNIXish manner. There never was > a real "standard" for the UNIX file structure, but Apple's structure > is, uh, somewhat less standard than standard :-). Just remember that Apple's top priority was to make a Mac desktop that Mac users could be comfortable with - and then to provide UNIX compatibility. The UNIX filesystem is cryptic enough that the average user would be intimidated by it, and it doesn't fit well at all with Apple's concept of self-contained applications. (BTW, small rant, I think it's a semi-standard standard that *needs* to be broken for *nix to target the Desktop.) > What would really help--for me at least, and perhaps for others-- > is a good document explaining how and why Apple has implemented > certain structures, how they map to "old" structures. I've looked > through a number of the OS X books available, and though I can > find bits and pieces here and there, I've never seen a good, > coherent overview. For example, I'd love to see a good explanation > as to why Frameworks exist, why to put things into a framework > structure rather than placing libraries, binaries, etc. into > /.../lib, /.../bin, how to deal with Makefiles that don't know about > frameworks (most of them), and so on. See: http://www.macdevcenter.com/pub/a/mac/2002/10/22/macforunix.html for some answers to FAQs from UNIX users, including the filesystem issue (you may want to consider picking up the book, O'Reilly books are usually a good investment), and see here: http://developer.apple.com/unix/index.html For more information about OS X UNIX support from the source. There's documentation on how to port UNIX apps to OS X, and even a mailing list for it, among other things here. > I also apologise for getting /usr/local wrong. As I say, I've ended up > creating a number of 'old-style' UNIX directories. I guess it must've > been another one. > > Definitely, the fact that /Library/Python/2.3 and > /Library/Frameworks/Python/...{somewhere} > are supposed to be the same place is news to me. They aren't the same > on my system, I have no idea whether due to me or to some installer > script, and now I'm scared to try to fix this :-) /System/Library/Frameworks/Python.Framework/Versions/2.3/lib/site- packages should just be a symlink to /Library/Python/2.3. All packages should install to /Library/Python/2.3. Any packages that install directory into /System/Library have broken installers and you should report the problem to the package maintainer. (Note that old versions of wxPython did break the symlink, but recent ones have fixed the problems.) > As regards to 'distutils', well first, I'll absolutely claim stupidity > on my > part about distutils always installing into a 'versioned' subdirectory, > that's useful knowledge, and I'm certainly turning bright red. > However, simply saying that "distutils understands OS X, so anything > written properly using distutils should work on OS X" is a little too > facile. I've spent too many hours trying to tell Python (and other > things) > where to find (non-Python) libs, files, etc. because the OS X default > paths/file structure didn't seem adequate for 'legacy' UNIX software. Well, there are two types of non-Python libs - UNIX libs and Mac Frameworks. The UNIX libs should work fine as 'legacy' UNIX software, and any Makefile that doesn't work (as Bob said) is a poorly written makefile that probably isn't even compatible with all variants of UNIX/Linux. As for Frameworks, they are linked with "-framework FrameworkName" and headers are included by using the #include syntax, but the person who authored the Python extension should know this and deal with this. The end result is that for the most part, if the developer wrote their distutils scripts/makefiles correctly, things should just "work" out of the box on OS X. Is it SPE that's giving you so much trouble, or another package? Are several of them doing this? > And again, this was not intended to be criticism, at least not > in the derogatory sense. I like OS X, I like programming on it, and > I'm extremely glad to be back using Python after several years away > from it. However, I have spent some time wrestling with problems > largely caused by the "Apple-ness" of OS X at the UNIX level, and > I know others have had similar problems, and I thought it would be > a good idea to talk about some of these. I've certainly learned some > useful things from your response. It is a "learning experience", but just be careful not to assume it's always due to it being a problem with Apple's UNIX distro. ;-) The fact is that developing truly "portable" makefiles, for example, is not an easy task and some UNIX software may break if ported to Solaris or any other platform the developer didn't test on, unless they created their makefiles in a very specific manner. This can also apply to distutils scripts as well. There are, of course, some issues specific to OS X, but the problems you're having sound like there's something else going on here. HTH, Kevin > Thanks, > Ken > > > On Jun 14, 2004, at 12:54 AM, Bob Ippolito wrote: > >> >> On Jun 14, 2004, at 1:28 AM, Kenneth McDonald wrote: >> >>> The following comes from some experiences I've had recently whilst >>> wrangling with wxPython/SPE, plus some others encountered in the >>> past while doing custom installs of Tk and tkinter. I don't want to >>> start >>> any flame wars, and I certainly don't want to hurt any feelings--the >>> Python >>> people at Apple are doing a great job, and I really appreciate their >>> effort. However, the "Apple Philosophy" as applied to Python (and >>> indeed as applied to much of the UNIX subsurface in OS X) is making >>> things painfully, and in my opinion unnecessarily, difficult to use. >>> >>> First, the obvious: Having a "required, custom" build of Python on >>> OS X is a Bad Idea. Last I heard, this was the official OS X way of >>> doing things, i.e. the Python you got was what you should use, don't >>> try replacing it, and no, it's not a stock Python. I believe this >>> has been >>> recognized to be a problem and is being worked on--sorry if I'm >>> ignorant of recent fixes, I "threw out" the stock OS X Python some >>> time ago, as I needed my own custom compilations. >> >> It's not custom. It's highly suggested not to replace it because >> there are various bugs here and there on the Python side that make it >> a bad idea to do so. >> >>> In general (and I'm sure the Apple techs understand this, but perhaps >>> you could pass this on to those in management who don't?), DON'T >>> EVER take a community standard tool such as Python and "improve" >>> it in such a manner as to make it incompatible with what people have >>> come to expect. If you must produce an Apple-specific version which >>> requires special consideration when being used with other packages, >>> then observe the following: >>> >>> 1) The _standard_ version should be the standard; even on OS X. >>> People who want to use Python without caring about the OS its >>> on will then be able to use it properly. Those who want to make use >>> of the os-enhanced version will know what to do. >>> >>> 2) Make sure that an 'enhanced' version can coexist peacefully with >>> the standard version. >> >> It *is* standard. It's not "improved". The only difference between >> what Apple distributes and what was in 2.3.0 is the location that it >> is installed in (/System rather than /) and the additional >> CoreGraphics extension, which has nothing to do with how it was >> compiled. >> >>> One of the things that is expected is that I can download, compile, >>> and install a more recent version of Python without problem (assuming >>> the newer version itself doesn't have problems.) Another is that >>> add-ons for Python which have been written to install nicely in a >>> generic UNIX environment should continue to do so under OS X. >> >> It will work just fine, but it must supersede the system installation >> due to bugs that were in 2.3.0 that we can not fix. Once you install >> your own Python, you can no longer expect to be able to compile >> software for the stock 2.3.0. >> >> Any Python extensions that have been written properly already use >> distutils, and thus already work fine on OS X. If anything is >> designed to work in a "generic UNIX environment" and does NOT work on >> OS X is simply not done correctly. Things should work on Windows >> too, and that means using distutils. >> >>> Next, paths. I can understand why Apple (actually, probably NeXT) >>> decided to come up with improvements on the UNIX file structure. >>> But why, oh why, couldn't they have maintained some sort of backward >>> compatibility using links? I've effectively recreated my own UNIX >>> file >>> structure using links, to make up for this, and would be surprised >>> if others >>> haven't as well. In particular, why the heck isn't there the >>> equivalent of >>> /usr/local? Having this basic de facto standard sort of file >>> structure in >>> place would save us UNIX software users countless hours in headaches. >>> Yes, it's easy to argue that the problems are the fault of bad >>> installation >>> scripts and makefiles. Well, yes, in theory that's probably true; >>> but so >>> what? The point of software is to be a useful tool, not to drive the >>> customer >>> crazy by insisting that somebody else, in assuming a de facto >>> standard of >>> the time would continue into the future, made a mistake. >> >> Uh, there is a /usr/local. >> >>> I find this a particular problem when it comes to Frameworks and >>> Libraries. >>> Here's a typical example of installing a couple of Python modules >>> recently: >>> >>> 1) Compile module A--works, great. Install it. Where the heck are the >>> files? Do a search on the disk. Ah, there they are in >>> /Library/Frameworks/Python/.../.../... and so on >>> .../2.3/site-packages. >>> Create a link from a more reasonable location so they'll be on the >>> python path. >> >> /Library/Python/2.3 is the more reasonable link, it already exists. >> >>> 2) Compile and install module B. Where is it? Disk search. Ah, it's >>> in >>> /Library/Python/2.3. Create link. Why did it end up here, vs. Module >>> A in Frameworks? Beats me. >> >> They're the SAME PLACE unless you or some broken installation script >> screwed that up. >> >>> And why, for that matter, are all of these modules always ending up >>> in >>> a '2.3' directory? I happen to know that some of them aren't >>> dependent >>> on the Python binary, and it looks to me as if, when 2.3 changes to >>> 2.4, >>> I'm gonna have some unnecessary work, again. Trust me, if a module >>> is incompatible with 2.4, I'll know it soon enough; you don't have to >>> force me to move everything manually to the 2.4 path. >> >> This happens on EVERY Python platform. If you want to install >> "version independent" Python files somewhere else, feel free to do >> so. There are many options that you may pass to distutils to control >> this behavior. Then you simply need to make a pth file that points >> to your "version independent" site directory. >> >>> None of this is going to make me move off of OS X, of course; it >>> still >>> is, by far, the best OS for most users IMHO, myself included. But >>> this >>> situation will cost Apple some money; I generally keep fairly >>> up-to-date >>> with hardware, and was planning on getting a new Powerbook when >>> they hit 2 GHz. However, I've had to do so much manual tweaking to my >>> system that the effort needed to recreate that on a new drive is a >>> little too >>> much to want to repeat in the forseeable future, so Apple's probably >>> going >>> to have to hit 3GHz for me to decide it's worth the pain. (Yes, I >>> know >>> I don't have to do a "clean" install of everything when I go to a >>> new system, >>> but that's one of the things I do to help me clean all the cruft >>> out.) >>> >>> I'm looking forward to what comes out in the future, I have a lot of >>> confidence in the Python people at Apple, and I have no problems at >>> all in continuing to pay for new versions of OS X which bring new >>> features and improvements. I just hope that the above is of some help >>> in deciding how some of those features should be implemented in the >>> future. >> >> There aren't really "Python people at Apple", at least not that I'm >> aware of. Any problems with the Python distribution for OS X are at >> least partially our fault. Start filing bugs and feature requests, >> and making patches if you REALLY want a particular issue fixed in a >> way that suits you. >> >> I think a lot of your troubles are just because you expect things to >> work as they do in Linux, and that's just not the case. There are >> equivalent or better ways of doing things on OS X, that you either >> don't accept or haven't figured out yet. >> >> -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bill at janssen.org Mon Jun 14 12:34:05 2004 From: bill at janssen.org (Bill Janssen) Date: Mon Jun 14 12:35:15 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: Your message of "Mon, 14 Jun 2004 08:33:14 PDT." <26CC358D-BE18-11D8-A833-000393CB1C86@tulane.edu> Message-ID: <04Jun14.093407pdt."58612"@synergy1.parc.xerox.com> > /System/Library/Frameworks/Python.Framework/Versions/2.3/lib/site- > packages should just be a symlink to /Library/Python/2.3. I think you mean /System/Library/Frameworks/Python.Framework/Versions/2.3/lib/python2.3/site-packages. Bill From sarwat at sarwat.net Mon Jun 14 16:07:58 2004 From: sarwat at sarwat.net (Sarwat Khan) Date: Mon Jun 14 16:08:08 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: References: Message-ID: <87E1059F-BE3E-11D8-99DD-003065C9DF8C@sarwat.net> On Jun 14, 2004, at 1:28 AM, Kenneth McDonald wrote: > ignorant of recent fixes, I "threw out" the stock OS X Python some > time ago, as I needed my own custom compilations. I think the non-custom-ness of the stock installation has been addressed, but I think removing the standard install is a Bad Idea. YMMV. > One of the things that is expected is that I can download, compile, > and install a more recent version of Python without problem (assuming The problem is that when something like Python is part of the system, you can only really expect the OS vendor to be able to upgrade it. Python is installed in /usr/bin, which means you shouldn't touch it (or upgrade it). > the newer version itself doesn't have problems.) Another is that > add-ons for Python which have been written to install nicely in a > generic UNIX environment should continue to do so under OS X. distutils handles this, methinks. I actually don't use Apple's python for development, for similar reasons that you've got gripes with. But if you need to distribute an app that uses Python (say, Tomato), having a version of Python as a base install and developing against that is wonderful. > > Next, paths. I can understand why Apple (actually, probably NeXT) > decided to come up with improvements on the UNIX file structure. > But why, oh why, couldn't they have maintained some sort of backward > compatibility using links? Well, they do :-/ All the Unix stuff is there, they've just grafted OS X-specific stuff on top of it, using /Library (which is actually /Local/Library, and /Users is /Local/Users), /Network, and /System. > In particular, why the heck isn't there the equivalent of > /usr/local? /usr/local is for non-vendor stuff, so there's no reason for Apple to populate it with anything (Linux does make a mess of this). Personally, I hate /usr/local. I use a /opt and install stuff in there (for example, /opt/jpeg-6b/(bin, include, lib, ...)). A shell script lets me define my PATH variables by aggregating the stuff in /opt/(foo)/bin. This lets you remove /opt/jpeg-6b or upgrade it easily. Similarly, I put my own builds of Python in their own spot and use that instead of Apple's. > Having this basic de facto standard sort of file structure in > place would save us UNIX software users countless hours in headaches. > Yes, it's easy to argue that the problems are the fault of bad > installation > scripts and makefiles. Ah. You've never used Solaris. Headaches are part of the True Unix Experience. Here's some stuff that's probably good for you to read, if you haven't already. Porting Unix/Linux Applications to Mac OS X http://developer.apple.com/documentation/Porting/Conceptual/ PortingUnix/index.html This is mildly useful, Technology Overview. http://developer.apple.com/documentation/MacOSX/Conceptual/ OSX_Technology_Overview/index.html Frameworks Overview http://developer.apple.com/documentation/MacOSX/Conceptual/ BPFrameworks/index.html {sarwat khan : http://sarwat.net} From skip at pobox.com Mon Jun 14 16:09:25 2004 From: skip at pobox.com (Skip Montanaro) Date: Mon Jun 14 16:09:30 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> References: <5A90E9CC-BDC7-11D8-BEB2-000A95686CD8@redivi.com> Message-ID: <16590.1525.30253.187780@montanaro.dyndns.org> >> And why, for that matter, are all of these modules always ending up >> in a '2.3' directory? I happen to know that some of them aren't >> dependent on the Python binary, and it looks to me as if, when 2.3 >> changes to 2.4, I'm gonna have some unnecessary work, again. Trust >> me, if a module is incompatible with 2.4, I'll know it soon enough; >> you don't have to force me to move everything manually to the 2.4 >> path. Bob> This happens on EVERY Python platform. If you want to install Bob> "version independent" Python files somewhere else, feel free to do Bob> so. There are many options that you may pass to distutils to Bob> control this behavior. Then you simply need to make a pth file Bob> that points to your "version independent" site directory. Note that in the current scheme of things there's no reasonable way to separate .py[co] files from their .py ancestors. So even if you have an entirely platform-independent module written in Python the generated bytecode may differ from version-to-version. The current scheme allows you to have multiple versions of Python installed which can coexist peacefully. Skip From Chris.Barker at noaa.gov Mon Jun 14 16:29:23 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Jun 14 16:30:30 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: <87E1059F-BE3E-11D8-99DD-003065C9DF8C@sarwat.net> References: <87E1059F-BE3E-11D8-99DD-003065C9DF8C@sarwat.net> Message-ID: <40CE0AA3.2080001@noaa.gov> Sarwat Khan wrote: >> One of the things that is expected is that I can download, compile, >> and install a more recent version of Python without problem (assuming > > The problem is that when something like Python is part of the system, > you can only really expect the OS vendor to be able to upgrade it. > Python is installed in /usr/bin, which means you shouldn't touch it (or > upgrade it). Just because it hasn't been stated in this thread specifically: The problem is not that you can't remove or upgrade the version Apple installed (you don't want to do that on RedHat, for instance, either). The problem is that if you install a newer version alongside the Apple one, the two can clash. This is a bug, and, as I understand it, solutions have been found, but it not clear to me whether a consensus was reached about which one to use. I'm hoping it will be solved in time for whenever Apple does decide to upgrade Python. > /usr/local is for non-vendor stuff, so there's no reason for Apple to > populate it with anything (Linux does make a mess of this). How so? Vendors don't put stuff there, most non-vendor distributed stuff does get put there. some individuals screw it up, but what do you expect? > Personally, > I hate /usr/local. I use a /opt and install stuff in there (for > example, /opt/jpeg-6b/(bin, include, lib, ...)). how is this different than /usr/local/jpeg-6b/... ? Just taste, I imagine. > Similarly, I put my own builds of Python in their own spot and use that > instead of Apple's. I haven't tried this, but I understand that people have had conflicts. -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 sarwat at sarwat.net Mon Jun 14 17:38:44 2004 From: sarwat at sarwat.net (Sarwat Khan) Date: Mon Jun 14 17:38:51 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: <40CE0AA3.2080001@noaa.gov> References: <87E1059F-BE3E-11D8-99DD-003065C9DF8C@sarwat.net> <40CE0AA3.2080001@noaa.gov> Message-ID: <362AEDC2-BE4B-11D8-99DD-003065C9DF8C@sarwat.net> On Jun 14, 2004, at 4:29 PM, Chris Barker wrote: > How so? Vendors don't put stuff there, most non-vendor distributed > stuff does get put there. some individuals screw it up, but what do > you expect? Uh, forget I said that. I was thinking of something else. >> Personally, I hate /usr/local. I use a /opt and install stuff in >> there (for example, /opt/jpeg-6b/(bin, include, lib, ...)). > > how is this different than /usr/local/jpeg-6b/... ? Just taste, I > imagine. Stuff is inevitably going to install stuff in /usr/local (I had to install some gimp-print stuff in 10.2 that came with a .pkg installer), so it prevents stuff I personally installed and other stuff from getting tangled. I consider /usr/local to be the unmanaged stuff that's not from the vendor and /opt to be the stuff that I manage. It also makes it easy to either copy or symlink the /opt to another OS X installation. /opt is a 'standard' (I've seen it used by a few installations, most notably the Solaris bugger I had the joy of using for a few years). {sarwat khan : http://sarwat.net} From bob at redivi.com Mon Jun 14 19:05:36 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jun 14 19:05:47 2004 Subject: [Pythonmac-SIG] Some thoughts on Python and OS X In-Reply-To: <40CE0AA3.2080001@noaa.gov> References: <87E1059F-BE3E-11D8-99DD-003065C9DF8C@sarwat.net> <40CE0AA3.2080001@noaa.gov> Message-ID: <58C5D36A-BE57-11D8-BEB2-000A95686CD8@redivi.com> On Jun 14, 2004, at 4:29 PM, Chris Barker wrote: > Sarwat Khan wrote: > >> Personally, I hate /usr/local. I use a /opt and install stuff in >> there (for example, /opt/jpeg-6b/(bin, include, lib, ...)). > > how is this different than /usr/local/jpeg-6b/... ? Just taste, I > imagine. Well /usr/local is typically used as the "root" of everything you install there.. so there is no /usr/local/jpeg-6b. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040614/7fc267ed/smime.bin From hengist.podd at virgin.net Tue Jun 15 20:03:31 2004 From: hengist.podd at virgin.net (has) Date: Tue Jun 15 20:10:58 2004 Subject: [Pythonmac-SIG] [ann] DistUtils-GUI 0.1.0 Message-ID: Hi folks, Latest attempt at a graphical front-end to DistUtils posted for your amusement: http://freespace.virgin.net/hamish.sanderson/DistUtils-GUI.app.sit Comments welcome. has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Thu Jun 17 19:41:10 2004 From: hengist.podd at virgin.net (has) Date: Sun Jun 20 23:30:27 2004 Subject: [Pythonmac-SIG] icons? Message-ID: Hey folks, Just been doing icon artwork for Distutils-GUI, and it occurred to me to ask if MacPython 2.4 could use some fresh icons? If so, let us know if you'd like us to try whipping some up. e.g. See the DuGUI icon on my site; generic Python application icon: Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From kenneth.m.mcdonald at sbcglobal.net Thu Jun 17 20:55:45 2004 From: kenneth.m.mcdonald at sbcglobal.net (Kenneth McDonald) Date: Sun Jun 20 23:48:10 2004 Subject: [Pythonmac-SIG] How to provide additions to python path such that all executions of a given python binary will see them? Message-ID: <3B2481C4-C0C2-11D8-9C6D-000A956870AC@sbcglobal.net> Currently, I modify my python path through inclusion of a PYTHONPATH variable in the .login file. However, I need to add a /local/python/packages directory to the path in such a manner that all executions of the system python binary see /local/python/packages. I was just wondering up the best (least hacky) way of doing this might be. Thanks, Ken McDonald From mmellor1 at yahoo.com Thu Jun 17 22:25:21 2004 From: mmellor1 at yahoo.com (Mellor Mike) Date: Mon Jun 21 00:22:11 2004 Subject: [Pythonmac-SIG] Auto-completion Editor for OS X Message-ID: <20040618022521.63588.qmail@web13524.mail.yahoo.com> Is there an editor for OS X that suports auto-completion? I have used the ActivePython editor on my work (WinXP) computer, and I would like to have the same features on OS X. Thanks. Mike From kenneth.m.mcdonald at sbcglobal.net Fri Jun 18 16:25:18 2004 From: kenneth.m.mcdonald at sbcglobal.net (Kenneth McDonald) Date: Mon Jun 21 00:24:53 2004 Subject: [Pythonmac-SIG] What are the bug fixes that have been made by Apple to Python? Message-ID: <9D83364B-C165-11D8-AA09-000A956870AC@sbcglobal.net> As has been discussed before in this forum, Apple has a "special" version of Python in its Frameworks which is necessary due to the fact that the normal Python has some bugs. Is there a list anywhere detailing these bugs? In particular, if I want to completely cut myself loose from the Python that comes with OS X, what impacts can I expect to see throughout the rest of the system? At the moment I don't know, nor do I know where to even start looking for this information. Thanks, Ken McDonald From sw at wordtech-software.com Tue Jun 22 02:23:54 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Tue Jun 22 02:24:52 2004 Subject: [Pythonmac-SIG] Python app bundles for download Message-ID: <40D7D07A.2000508@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have put together an assortment of Python programs--Leo, Pears, PyUnit and wxGlade--into Mac application bundles for download, which I thought would be of interest to some on the list. I've also put together a tutorial documenting how I did this--by hacking "save as applet" rather than using bundlebuilder, which I have never been successful with. These ~ packages have all of the appropriate application files/scripts included, but do not include the supporting libraries (Tcl/Tk, wxPython, etc.). I thought the tutorial might be useful to other, such as myself, who really like the simplicity of "save as applet" but wanted to put together complete application packages. The relevant page with links is http://www.wordtech-software.com/python.html. Comments, suggestions and other feedback are welcomed. - -- Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA19B6F6m9qPmThLQRAk/fAJ9UFYwIJR1O/mfig9evS3nWOr/vmgCdH6S+ 0+qZT5t2O8U6vBna1PFOQk0= =Y9Ue -----END PGP SIGNATURE----- From mwh at python.net Tue Jun 22 06:18:59 2004 From: mwh at python.net (Michael Hudson) Date: Tue Jun 22 09:41:51 2004 Subject: [Pythonmac-SIG] icons? In-Reply-To: (has's message of "Fri, 18 Jun 2004 00:41:10 +0100") References: Message-ID: <2m4qp37v58.fsf@starship.python.net> has writes: > Hey folks, > > Just been doing icon artwork for Distutils-GUI, and it occurred to me > to ask if MacPython 2.4 could use some fresh icons? If so, let us know > if you'd like us to try whipping some up. e.g. See the DuGUI icon on > my site; generic Python application icon: > You mean you susbscribed to this list *after* the immense flamewar that happened last time this got mentioned ? The Standard Objections to your icon, btw, are: (a) "Python" is named after "Monty Python", not the snake, and (b) some people really hate snakes. Cheers, mwh -- But maybe I've just programmed in enough different languages to assume that they are, in fact, different. -- Tony J Ibbs explains why Python isn't Java on comp.lang.python From ronaldoussoren at mac.com Tue Jun 22 10:25:07 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue Jun 22 10:25:22 2004 Subject: [Pythonmac-SIG] How to provide additions to python path such thatall executions of a given python binary will see them? Message-ID: <4509969.1087914307213.JavaMail.ronaldoussoren@mac.com> On Friday, June 18, 2004, at 02:55AM, Kenneth McDonald wrote: >Currently, I modify my python path through inclusion of a PYTHONPATH >variable >in the .login file. However, I need to add a /local/python/packages >directory >to the path in such a manner that all executions of the system python >binary >see /local/python/packages. I was just wondering up the best (least >hacky) >way of doing this might be. create /Library/Python/2.3/local.pth containing the line /local/python/packages. The exact name of the file is not important, as long as it has the suffix '.pth'. Ronald > >Thanks, >Ken McDonald > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig > > From bob at redivi.com Tue Jun 22 12:07:33 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jun 22 12:07:44 2004 Subject: [Pythonmac-SIG] How to provide additions to python path such that all executions of a given python binary will see them? In-Reply-To: <3B2481C4-C0C2-11D8-9C6D-000A956870AC@sbcglobal.net> References: <3B2481C4-C0C2-11D8-9C6D-000A956870AC@sbcglobal.net> Message-ID: <45A2101F-C466-11D8-99AC-000A95686CD8@redivi.com> On Jun 17, 2004, at 8:55 PM, Kenneth McDonald wrote: > Currently, I modify my python path through inclusion of a PYTHONPATH > variable > in the .login file. However, I need to add a /local/python/packages > directory > to the path in such a manner that all executions of the system python > binary > see /local/python/packages. I was just wondering up the best (least > hacky) > way of doing this might be. Add a one line text file named "arbitraryuniquename.pth" to ~/Library/Python/2.3/site-packages/ (or /Library/Python/2.3[/site-packages] if you want it to be system wide. Apple's version is with site-packages, the standard distribution is without) with the contents "/local/python/packages" sans quotes. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040622/829d1d29/smime.bin From hengist.podd at virgin.net Tue Jun 22 13:50:37 2004 From: hengist.podd at virgin.net (has) Date: Tue Jun 22 13:50:50 2004 Subject: [Pythonmac-SIG] icons? Message-ID: Michael Hudson wrote: > > Just been doing icon artwork for Distutils-GUI, and it occurred to me > > to ask if MacPython 2.4 could use some fresh icons? > >You mean you susbscribed to this list *after* the immense flamewar >that happened last time this got mentioned ? Oh, goody... >The Standard Objections to your icon, btw, are: (a) "Python" is named >after "Monty Python", not the snake, Look-look! They did it first! :) Sure it's a clich?, but it's a _cute_ clich?. Think of it as a form of shorthand (it's a bit tight trying to fit the fine Messers Cleese, Palin, et-al onto a desktop icon, even at OS X's mighty 128x128:). Also happy to knock up non reptile-related illustrations if folk have any preferences. >and (b) some people really hate snakes. You mean Perl users? has -- http://freespace.virgin.net/hamish.sanderson/ From smithsm at samuelsmith.org Tue Jun 22 13:56:02 2004 From: smithsm at samuelsmith.org (Samuel M. Smith) Date: Tue Jun 22 13:56:48 2004 Subject: [Pythonmac-SIG] Codeville on OSX In-Reply-To: <3B2481C4-C0C2-11D8-9C6D-000A956870AC@sbcglobal.net> References: <3B2481C4-C0C2-11D8-9C6D-000A956870AC@sbcglobal.net> Message-ID: <6CF4BB42-C475-11D8-9CF9-000A95C4B360@samuelsmith.org> Anyone tried to compile/install codeville on OSX? http://www.codeville.org/ From Jack.Jansen at cwi.nl Tue Jun 22 17:50:43 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jun 22 17:50:39 2004 Subject: [Pythonmac-SIG] How to provide additions to python path such that all executions of a given python binary will see them? In-Reply-To: <3B2481C4-C0C2-11D8-9C6D-000A956870AC@sbcglobal.net> References: <3B2481C4-C0C2-11D8-9C6D-000A956870AC@sbcglobal.net> Message-ID: <35C7C6BA-C496-11D8-B2DF-000D934FF6B4@cwi.nl> On 18 Jun 2004, at 02:55, Kenneth McDonald wrote: > Currently, I modify my python path through inclusion of a PYTHONPATH > variable > in the .login file. However, I need to add a /local/python/packages > directory > to the path in such a manner that all executions of the system python > binary > see /local/python/packages. I was just wondering up the best (least > hacky) > way of doing this might be. You set them in ~/.MacOSX/environment.plist, environment variables set in that file are read at login time, so they are also available to GUI programs. The MacPython FAQ has the details. -- 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 sarwat at sarwat.net Tue Jun 22 15:47:18 2004 From: sarwat at sarwat.net (Sarwat Khan) Date: Tue Jun 22 20:20:24 2004 Subject: [Pythonmac-SIG] How to provide additions to python path In-Reply-To: <3B2481C4-C0C2-11D8-9C6D-000A956870AC@sbcglobal.net> References: <3B2481C4-C0C2-11D8-9C6D-000A956870AC@sbcglobal.net> Message-ID: On Jun 17, 2004, at 8:55 PM, Kenneth McDonald wrote: > Currently, I modify my python path through inclusion of a PYTHONPATH > variable > in the .login file. However, I need to add a /local/python/packages > directory > to the path in such a manner that all executions of the system python > binary > see /local/python/packages. I was just wondering up the best (least > hacky) > way of doing this might be. Check out lib/python2.x/site.py, it will tell you what you need to know. The simplest is to put a .pth file (foo.pth) in site-packages that contains the path that you'd normally add to PYTHONPATH. {sarwat khan : http://sarwat.net} From janssen at parc.com Tue Jun 22 22:52:54 2004 From: janssen at parc.com (Bill Janssen) Date: Tue Jun 22 22:55:07 2004 Subject: [Pythonmac-SIG] fink package for system-python? Message-ID: <04Jun22.195258pdt."58612"@synergy1.parc.xerox.com> I notice that Fink has a number of Python packages, such as "python23" and "python23-nox" (but I have no idea what the difference is between them). I also notice that for some packages, like the X11 system and Perl 5.8.1, there are packages called, for example, "system-perl581", which is "a placeholder package for the manually installed perl 5.8.1". Is anyone making a Fink placeholder package for the system MacPython? Bill From amundsen463 at yahoo.com Wed Jun 23 12:08:54 2004 From: amundsen463 at yahoo.com (Craig Amundsen) Date: Wed Jun 23 12:09:10 2004 Subject: [Pythonmac-SIG] Building rpy Message-ID: <20040623160854.578.qmail@web81408.mail.yahoo.com> i - I"m trying to build rpy on a reasonably vanilla OSX (10.3.4) system. I"ve installed the 10.3 Python extras and used PackMan to install Numeric. I built R 1.9.0 using the Mac specific config options (--with-blas="-framework vecLib" --with-lapack --with-aqua) and --enable-R-shlib as the rpy docs require. I have RHOME pointing to /Library/Frameworks/R.framework/Resources/bin I have a link in /usr/local/bin R@ -> /Library/Frameworks/R.framework/Resources/bin/R and on in /usr/local/lib libR.dylib@ -> /Library/Frameworks/R.framework/Resources/bin/libR.dylib When I try to build rpy (python setup.py build) I get the following errors: building "_rpy" extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -DPRE_2_2 -DR_HOME="/Library/Frameworks/R.framework/Resources" -DWITH_NUMERIC -I/Library/Frameworks/R.framework/Resources/include -Isrc -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c src/rpymodule.c -o build/temp.darwin-7.4.0-Power_Macintosh-2.3/src/rpymodule.o In file included from src/rpymodule.c:24: src/RPy.h:39:33: Numeric/arrayobject.h: No such file or directory src/rpymodule.c: In function `to_Rarray": src/rpymodule.c:247: error: `PyArrayObject" undeclared (first use in this function) src/rpymodule.c:247: error: (Each undeclared identifier is reported only once src/rpymodule.c:247: error: for each function it appears in.) src/rpymodule.c:247: error: `obj" undeclared (first use in this function) It looks like I"m not finding Numeric during the compilation. I installed Numeric with PackMan using the source, is there something else I need to do for this work? TIA, -Craig From speno at isc.upenn.edu Wed Jun 23 18:14:57 2004 From: speno at isc.upenn.edu (John P Speno) Date: Wed Jun 23 18:14:58 2004 Subject: [Pythonmac-SIG] What are the bug fixes that have been made by Apple to Python? In-Reply-To: <9D83364B-C165-11D8-AA09-000A956870AC@sbcglobal.net> References: <9D83364B-C165-11D8-AA09-000A956870AC@sbcglobal.net> Message-ID: <20040623221457.GA7849@isc.upenn.edu> On Fri, Jun 18, 2004 at 03:25:18PM -0500, Kenneth McDonald wrote: > As has been discussed before in this forum, Apple has a "special" > version > of Python in its Frameworks which is necessary due to the fact that the > normal Python has some bugs. Is there a list anywhere detailing these You can get the source of python as it appears in 10.3.4 here: http://www.opensource.apple.com/darwinsource/tarballs/other/python-7.tar.gz From ronaldoussoren at mac.com Thu Jun 24 01:53:33 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu Jun 24 01:53:47 2004 Subject: [Pythonmac-SIG] What are the bug fixes that have been made by Apple to Python? In-Reply-To: <9D83364B-C165-11D8-AA09-000A956870AC@sbcglobal.net> References: <9D83364B-C165-11D8-AA09-000A956870AC@sbcglobal.net> Message-ID: On 18-jun-04, at 22:25, Kenneth McDonald wrote: > As has been discussed before in this forum, Apple has a "special" > version > of Python in its Frameworks which is necessary due to the fact that the > normal Python has some bugs. Has it? AFAIK the only discussion has been about not replacing random system components, even if you can. The risk is mostly about breaking part of the system because that relied on a feature that was changed after 2.3.0 was released. > Is there a list anywhere detailing these > bugs? In particular, if I want to completely cut myself loose from the > Python that comes with OS X, what impacts can I expect to see > throughout > the rest of the system? At the moment I don't know, nor do I know > where to > even start looking for this information. Python is part of darwin, you could run a diff between that version and plain python 2.3.0. (See http://www.opensource.apple.com/darwinsource/10.3.4/ for a place to download the python in darwin). Ronald > > Thanks, > Ken McDonald > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From mario at ruggier.org Thu Jun 24 10:27:52 2004 From: mario at ruggier.org (Mario Ruggier) Date: Thu Jun 24 10:27:34 2004 Subject: [Pythonmac-SIG] How to provide additions to python path such thatall executions of a given python binary will see them? In-Reply-To: <4509969.1087914307213.JavaMail.ronaldoussoren@mac.com> References: <4509969.1087914307213.JavaMail.ronaldoussoren@mac.com> Message-ID: On Jun 22, 2004, at 4:25 PM, Ronald Oussoren wrote: > On Friday, June 18, 2004, at 02:55AM, Kenneth McDonald > wrote: > >> Currently, I modify my python path through inclusion of a PYTHONPATH >> variable >> in the .login file. However, I need to add a /local/python/packages >> directory >> to the path in such a manner that all executions of the system python >> binary >> see /local/python/packages. I was just wondering up the best (least >> hacky) >> way of doing this might be. > > create /Library/Python/2.3/local.pth containing the line > /local/python/packages. > > The exact name of the file is not important, as long as it has the > suffix '.pth'. What exactly should /Library/Python/2.3/local.pth contain? I.e. what is the syntax for adding a dir to pythonpath in this way? And, are the effects of doing it this way different than the way that Jack has just posted, that is to add env. variables to ~/.MacOSX/environment.plist that are then read at login time? In my /Library/Python/2.3 directory, the README says: ==== This directory exists so that 3rd party packages can be installed here. Read the source for site.py for more details. ==== But, there is no site.py ? Where should this be? mario > Ronald >> >> Thanks, >> Ken McDonald From tony.mcdonald at ncl.ac.uk Thu Jun 24 11:17:33 2004 From: tony.mcdonald at ncl.ac.uk (Tony McDonald) Date: Thu Jun 24 11:18:00 2004 Subject: [Pythonmac-SIG] Auto-completion Editor for OS X In-Reply-To: <20040618022521.63588.qmail@web13524.mail.yahoo.com> References: <20040618022521.63588.qmail@web13524.mail.yahoo.com> Message-ID: <9DF69920-C5F1-11D8-9AB0-000A95AB99B2@ncl.ac.uk> I *think* that PyOxide can do this... tone On 18 Jun 2004, at 03:25, Mellor Mike wrote: > Is there an editor for OS X that suports > auto-completion? I have used the ActivePython editor > on my work (WinXP) computer, and I would like to have > the same features on OS X. Thanks. > > Mike > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > -- Dr Tony McDonald, Asst Director, FMSC. 0191 246 4543 Project Manager, FDTL-4 ePortfolios http://www.eportfolios.ac.uk/ From marmille at adobe.com Thu Jun 24 12:04:42 2004 From: marmille at adobe.com (Martin Miller) Date: Thu Jun 24 13:19:04 2004 Subject: [Pythonmac-SIG] Re: Python app bundles for download In-Reply-To: <200406241303.i5OD3oQq018008@smtp-relay-4.corp.adobe.com> References: <200406241303.i5OD3oQq018008@smtp-relay-4.corp.adobe.com> Message-ID: <40DAFB9A.7090001@adobe.com> A very fine technique and tutorial. Any ideas on how to automate the process? Ideally this could be done via a Python script. -Martin ============================================== Kevin Walzer wrote: > Send Pythonmac-SIG mailing list submissions to > pythonmac-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/pythonmac-sig > or, via email, send a message with subject or body 'help' to > pythonmac-sig-request@python.org > > You can reach the person managing the list at > pythonmac-sig-owner@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pythonmac-SIG digest..." > > > ------------------------------------------------------------------------ > > Today's Topics: > > 1. Python app bundles for download (Kevin Walzer) > 2. Re: icons? (Michael Hudson) > 3. Re: How to provide additions to python path such thatall > executions of a given python binary will see them? (Ronald Oussoren) > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > > Subject: > [Pythonmac-SIG] Python app bundles for download > From: > Kevin Walzer > Date: > Tue, 22 Jun 2004 02:23:54 -0400 > To: > pythonmac-sig@python.org > > To: > pythonmac-sig@python.org > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have put together an assortment of Python programs--Leo, Pears, PyUnit > and wxGlade--into Mac application bundles for download, which I thought > would be of interest to some on the list. I've also put together a > tutorial documenting how I did this--by hacking "save as applet" rather > than using bundlebuilder, which I have never been successful with. These > ~ packages have all of the appropriate application files/scripts > included, but do not include the supporting libraries (Tcl/Tk, wxPython, > etc.). I thought the tutorial might be useful to other, such as myself, > who really like the simplicity of "save as applet" but wanted to put > together complete application packages. > > The relevant page with links is > http://www.wordtech-software.com/python.html. > > Comments, suggestions and other feedback are welcomed. > > - -- > Kevin Walzer, PhD > WordTech Software--Open Source Applications and Packages for OS X > http://www.wordtech-software.com > http://www.smallbizmac.com > mailto:sw@wordtech-software.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFA19B6F6m9qPmThLQRAk/fAJ9UFYwIJR1O/mfig9evS3nWOr/vmgCdH6S+ > 0+qZT5t2O8U6vBna1PFOQk0= > =Y9Ue > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > > Subject: > Re: [Pythonmac-SIG] icons? > From: > Michael Hudson > Date: > Tue, 22 Jun 2004 11:18:59 +0100 > To: > pythonmac-sig@python.org > > To: > pythonmac-sig@python.org > > > has writes: > > >>Hey folks, >> >>Just been doing icon artwork for Distutils-GUI, and it occurred to me >>to ask if MacPython 2.4 could use some fresh icons? If so, let us know >>if you'd like us to try whipping some up. e.g. See the DuGUI icon on >>my site; generic Python application icon: >> > > > You mean you susbscribed to this list *after* the immense flamewar > that happened last time this got mentioned ? > > The Standard Objections to your icon, btw, are: (a) "Python" is named > after "Monty Python", not the snake, and (b) some people really hate > snakes. > > Cheers, > mwh > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > > Subject: > Re: [Pythonmac-SIG] How to provide additions to python path such thatall > executions of a given python binary will see them? > From: > Ronald Oussoren > Date: > Tue, 22 Jun 2004 16:25:07 +0200 > To: > Kenneth McDonald > > To: > Kenneth McDonald > CC: > pythonmac-sig@python.org > > > > On Friday, June 18, 2004, at 02:55AM, Kenneth McDonald wrote: > > >>Currently, I modify my python path through inclusion of a PYTHONPATH >>variable >>in the .login file. However, I need to add a /local/python/packages >>directory >>to the path in such a manner that all executions of the system python >>binary >>see /local/python/packages. I was just wondering up the best (least >>hacky) >>way of doing this might be. > > > create /Library/Python/2.3/local.pth containing the line /local/python/packages. > > The exact name of the file is not important, as long as it has the suffix '.pth'. > > Ronald > >>Thanks, >>Ken McDonald >> >> >>_______________________________________________ >>Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > > > From ronaldoussoren at mac.com Thu Jun 24 14:00:32 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu Jun 24 14:01:30 2004 Subject: [Pythonmac-SIG] How to provide additions to python path such thatall executions of a given python binary will see them? In-Reply-To: References: <4509969.1087914307213.JavaMail.ronaldoussoren@mac.com> Message-ID: <627B9954-C608-11D8-A70D-0003931CFE24@mac.com> On 24-jun-04, at 16:27, Mario Ruggier wrote: > On Jun 22, 2004, at 4:25 PM, Ronald Oussoren wrote: >> On Friday, June 18, 2004, at 02:55AM, Kenneth McDonald >> wrote: >> >>> Currently, I modify my python path through inclusion of a PYTHONPATH >>> variable >>> in the .login file. However, I need to add a /local/python/packages >>> directory >>> to the path in such a manner that all executions of the system python >>> binary >>> see /local/python/packages. I was just wondering up the best (least >>> hacky) >>> way of doing this might be. >> >> create /Library/Python/2.3/local.pth containing the line >> /local/python/packages. >> >> The exact name of the file is not important, as long as it has the >> suffix '.pth'. > > What exactly should /Library/Python/2.3/local.pth contain? I.e. what > is the syntax for adding a dir to pythonpath in this way? The file should contain one or more directory names, seperated by newlines. > > And, are the effects of doing it this way different than the way that > Jack has just posted, that is to add env. variables to > ~/.MacOSX/environment.plist that are then read at login time? Jack's method is a per-user setting, mine is system-wide. > > In my /Library/Python/2.3 directory, the README says: > ==== > This directory exists so that 3rd party packages can be installed > here. Read the source for site.py for more details. > ==== > But, there is no site.py ? Where should this be? $ python -c 'import site; print site.__file__[:-1]' /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site.py > > mario > > >> Ronald >>> >>> Thanks, >>> Ken McDonald > > -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From robert.ferguson at gmail.com Thu Jun 24 15:23:44 2004 From: robert.ferguson at gmail.com (Robert Ferguson) Date: Thu Jun 24 15:23:53 2004 Subject: [Pythonmac-SIG] Scripting and Packaging for an OSX release of an X11 Python App Message-ID: <4a1b0ece04062412234102c007@mail.gmail.com> Dear List, I'm trying to roll out a package (.pkg) distribution of an X11 application called Gamera without using the graphical tools (there will be lots of builds, I would prefer to script when possible). Unfortunately Python/Distutils under OSX puts the binary in /System/Library/Frameworks/Python.framework/Versions/2.3/bin and when I create a package for this it trashes the symbolic links because of the well known issues with pax. I have the following goals: 1) Script the build process (no GUI tools) 2) Not require the user to download extra software beyond wxPython 3) Create a double clickable ".app" file for the GUI (gamera_gui) 4) Put the whole thing in a .dmg via scripting To a certain extent I understand what is involved, but I would like opinions and suggestions on the most correct method. Just so you know, I noticed i-Installer, but it would require our users downloading more software and I would likely not be able to script the build process. Below is a list of what I've found. Please suggest any improvements or alternatives: SCRIPTABLE PACKAGING buildpkg is a tool in python, but it does use pax in the "_addArchive" function. Since tar retains symbolic links it might be modified with something like: import tarfile # create archive os.chdir(self.sourceFolder) base = basename(self.packageInfo["Title"]) + ".tar" self.archPath = join(self.packageResourceFolder, base) archPath = self._escapeBlanks(self.archPath) # Original Line: # cmd = "pax -w -f %s %s" % (archPath, ".") tar = tarfile.open(base, "w") tar.add(archPath) tar.close() targz = tarfile.open(base+".gz", "w:gz") targz.add(base) targz.close() I'm not sure on this at all yet. Is there any better solutions out there? It seems like this has been a problem for a while. DOUBLE CLICKABLE .APP There was already a macosxhints conversation about this problem, but I didn't see a conclusive answer. I did notice that the gimp.app uses a modifed version of Platypus. I was able to take an O'reilly Hack and Platypus to make a double clickable version. I didn't mind this other than that it seem 1) A little convoluded 2) Would require either using a GUI or writing a modified version in Xcode in order to script it. Is there a better way? DMG In order to make a DMG file I noticed an easier method . Is there any problems with doing it this way instead of the builddmg.dmg method? My colleague came up with this method. It too could likely be improved by using the simple method by Rich Kilmer. Any thoughts? Kind Regards, Robert Ferguson From gandreas at delver.com Thu Jun 24 17:08:27 2004 From: gandreas at delver.com (Glenn Andreas) Date: Thu Jun 24 17:08:54 2004 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.6.2 - Cocoa based Python IDE Message-ID: PyOXIDE 0.6.2 is now available for abuse. There aren't a lot of changes since 0.6.1, but it now properly handles PyObjC not being isntalled, allows for command-period to stop running scripts, adds unicode support for find regex's and dramatically speeds up scrolling large files (and a couple other bug fixes). There are several important reasons for it's release however: This will be the last version that compiles under Project Builder (everything will be upgraded to XCode for the next release, but targetting 10.2 SDK so should still run under 10.2) I wanted to get the latest stuff out before WWDC (anybody else going?) There will be internal architectual changes for the next release (I'll skip boring you with "unique line identiers") PyOXIDE 0.6.2 has only been tested with 10.3, but should work with 10.2 (assuming it can find the python framework). The sources are built using XCode 1.1 on 10.3, but again, probably would compile on 10.2 with Project Builder (since they haven't been converted yet to XCode native projects). PyOXIDE 0.6.2 is now available on my idisk (as PyOXIDE_0.6.2.dmg): from the pather finder, "connect to other public folder" and type in "gandreas" or http://projects.gandreas.com/pyoxide/ If you want to build from source, you'll need to get PyOXIDE_Src_0.6.2.dmg, and IDEKit_0.2.2.dmg (also built XCode 1.2 on 10.3 but should build with ProjectBuilder on 10.2). IDEKit_0.2.2.dmg is found either on the idisk above or PyOXIDE source is covered under a BSD-style license. The IDEKit framework is covered under LGPL, so you can freely link it in other projects. Note - these archives are now be automatically created by a series of shell scripts, so hopefully they package up everything needed, and not too much that isn't, and I'll be able to crank out updates easier in the future. If you have problems, questions, enhancment request, etc, please submit request at (hopefully it should work - you'll have to make a new account, but the PyOXIDE database is publically available), and feel free to post questions/comments/public discussion to -- Glenn Andreas gandreas@gandreas.com mondo blobbo, Cythera, Theldrow, oh my! Mad, Bad, and Dangerous to Know From jwblist at olympus.net Thu Jun 24 14:13:50 2004 From: jwblist at olympus.net (John W. Baxter) Date: Thu Jun 24 17:52:18 2004 Subject: [Pythonmac-SIG] icons? In-Reply-To: Message-ID: On 6/22/2004 10:50, "has" wrote: >> and (b) some people really hate snakes. > > You mean Perl users? Ducks are quite different critters. ;-) --John From mario at ruggier.org Thu Jun 24 19:12:27 2004 From: mario at ruggier.org (Mario Ruggier) Date: Thu Jun 24 19:12:07 2004 Subject: [Pythonmac-SIG] How to provide additions to python path such thatall executions of a given python binary will see them? In-Reply-To: <627B9954-C608-11D8-A70D-0003931CFE24@mac.com> References: <4509969.1087914307213.JavaMail.ronaldoussoren@mac.com> <627B9954-C608-11D8-A70D-0003931CFE24@mac.com> Message-ID: On Jun 24, 2004, at 8:00 PM, Ronald Oussoren wrote: > On 24-jun-04, at 16:27, Mario Ruggier wrote: > >> On Jun 22, 2004, at 4:25 PM, Ronald Oussoren wrote: >>> On Friday, June 18, 2004, at 02:55AM, Kenneth McDonald >>> wrote: >>> >>>> Currently, I modify my python path through inclusion of a PYTHONPATH >>>> variable >>>> in the .login file. However, I need to add a /local/python/packages >>>> directory >>>> to the path in such a manner that all executions of the system >>>> python >>>> binary >>>> see /local/python/packages. I was just wondering up the best (least >>>> hacky) >>>> way of doing this might be. >>> >>> create /Library/Python/2.3/local.pth containing the line >>> /local/python/packages. >>> >>> The exact name of the file is not important, as long as it has the >>> suffix '.pth'. >> >> What exactly should /Library/Python/2.3/local.pth contain? I.e. what >> is the syntax for adding a dir to pythonpath in this way? > > The file should contain one or more directory names, seperated by > newlines. Thanks for the replies... I have put a file mypackages.pth in Library/Python/2.3 containing the line: /Volumes/Other/dev/python-packages that corresponds well to the file system... but python does not see/find any modules in this location. If I run python and ask fro sys.path, I get: $ pythonPython 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python23.zip', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages'] >>> I am on 10,3,4. Any ideas? >> And, are the effects of doing it this way different than the way that >> Jack has just posted, that is to add env. variables to >> ~/.MacOSX/environment.plist that are then read at login time? > > Jack's method is a per-user setting, mine is system-wide. > >> >> In my /Library/Python/2.3 directory, the README says: >> ==== >> This directory exists so that 3rd party packages can be installed >> here. Read the source for site.py for more details. >> ==== >> But, there is no site.py ? Where should this be? > > $ python -c 'import site; print site.__file__[:-1]' > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site.py Tr?s cool... I easily forget all these neat things about python... mario >> mario >> >> >>> Ronald >>>> >>>> Thanks, >>>> Ken McDonald >> >> > -- > X|support bv http://www.xsupport.nl/ > T: +31 610271479 F: +31 204416173 From rutledge.50 at osu.edu Thu Jun 24 21:28:14 2004 From: rutledge.50 at osu.edu (LINCOLN RUTLEDGE) Date: Thu Jun 24 21:28:20 2004 Subject: [Pythonmac-SIG] Mac OS X 10.3 and Tkinter Message-ID: <1dde0f1de1a8.1de1a81dde0f@osu.edu> Hi folks, I haven't read the archives yet, sorry. This is a fairly low traffic list, so... I installed the add-on package for Mac Python, and IDLE does not work. Also the IDE crashes when running my little curses game code. This is about the third time after reloading. I reloaded because I thought the 10.3.4 update broke it. I just found out that WMP9 dies because I used the Unix file system instead of HFS+. Is that why Python is dying? The message that I get when hit the traceback says that I am getting the message because my system is not configured for Tkinter. It sure is installed though. I IDLE working flawlessly under FINK, but the Python site says I should use MacPython instead. I understand that, it's a lot cleaner, but I want to play with Tkinter... Thanks for a great list folks! Lincoln From bob at redivi.com Thu Jun 24 21:44:39 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Jun 24 21:44:59 2004 Subject: [Pythonmac-SIG] How to provide additions to python path such thatall executions of a given python binary will see them? In-Reply-To: References: <4509969.1087914307213.JavaMail.ronaldoussoren@mac.com> Message-ID: <38AC61BE-C649-11D8-94F6-000A95686CD8@redivi.com> On Jun 24, 2004, at 10:27 AM, Mario Ruggier wrote: > On Jun 22, 2004, at 4:25 PM, Ronald Oussoren wrote: >> On Friday, June 18, 2004, at 02:55AM, Kenneth McDonald >> wrote: >> >>> Currently, I modify my python path through inclusion of a PYTHONPATH >>> variable >>> in the .login file. However, I need to add a /local/python/packages >>> directory >>> to the path in such a manner that all executions of the system python >>> binary >>> see /local/python/packages. I was just wondering up the best (least >>> hacky) >>> way of doing this might be. >> >> create /Library/Python/2.3/local.pth containing the line >> /local/python/packages. >> >> The exact name of the file is not important, as long as it has the >> suffix '.pth'. > > What exactly should /Library/Python/2.3/local.pth contain? I.e. what > is the syntax for adding a dir to pythonpath in this way? It should contain EXACTLY and ONLY the path you would like added. Literally, the line "/local/python/packages", sans quotes. % python -c 'file("/Library/Python/2.3/local.pth", "w").write("/local/python/packages")' > And, are the effects of doing it this way different than the way that > Jack has just posted, that is to add env. variables to > ~/.MacOSX/environment.plist that are then read at login time? It's not a PITA like PYTHONPATH (worst.. idea... ever..). > In my /Library/Python/2.3 directory, the README says: > ==== > This directory exists so that 3rd party packages can be installed > here. Read the source for site.py for more details. > ==== > But, there is no site.py ? Where should this be? site.py is part of Python itself, and it thus at: /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site.py -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040624/f29603cc/smime-0001.bin From bob at redivi.com Thu Jun 24 23:05:14 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Jun 24 23:05:23 2004 Subject: [Pythonmac-SIG] Auto-completion Editor for OS X In-Reply-To: <9DF69920-C5F1-11D8-9AB0-000A95AB99B2@ncl.ac.uk> References: <20040618022521.63588.qmail@web13524.mail.yahoo.com> <9DF69920-C5F1-11D8-9AB0-000A95AB99B2@ncl.ac.uk> Message-ID: <7AD3CA36-C654-11D8-94F6-000A95686CD8@redivi.com> It's not that hard to (naively) implement. I think that PyInterpreter in the PyObjC Examples does this. If it doesn't, then someone let me know and I'll try and find my local version that does :) On Jun 24, 2004, at 11:17 AM, Tony McDonald wrote: > I *think* that PyOxide can do this... > > On 18 Jun 2004, at 03:25, Mellor Mike wrote: > >> Is there an editor for OS X that suports >> auto-completion? I have used the ActivePython editor >> on my work (WinXP) computer, and I would like to have >> the same features on OS X. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040624/8b1c97e4/smime.bin From bob at redivi.com Fri Jun 25 01:17:15 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jun 25 01:17:24 2004 Subject: [Pythonmac-SIG] Scripting and Packaging for an OSX release of an X11 Python App In-Reply-To: <4a1b0ece04062412234102c007@mail.gmail.com> References: <4a1b0ece04062412234102c007@mail.gmail.com> Message-ID: On Jun 24, 2004, at 3:23 PM, Robert Ferguson wrote: > I'm trying to roll out a package (.pkg) distribution of an X11 > application called Gamera > without using the graphical tools (there will be lots of builds, I > would prefer to script when possible). Unfortunately Python/Distutils > under OSX puts the binary in > /System/Library/Frameworks/Python.framework/Versions/2.3/bin and when > I create a package for this it trashes the symbolic links because of > the well known issues with pax. You can put the tools elsewhere. distutils install/bdist/etc. take options that let you change those paths. I think the option to change the script install path is --install-scripts, for example. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040625/cf2d1b9e/smime.bin From ronaldoussoren at mac.com Fri Jun 25 05:09:16 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri Jun 25 05:09:31 2004 Subject: [Pythonmac-SIG] Auto-completion Editor for OS X In-Reply-To: <7AD3CA36-C654-11D8-94F6-000A95686CD8@redivi.com> References: <20040618022521.63588.qmail@web13524.mail.yahoo.com> <9DF69920-C5F1-11D8-9AB0-000A95AB99B2@ncl.ac.uk> <7AD3CA36-C654-11D8-94F6-000A95686CD8@redivi.com> Message-ID: <55861C66-C687-11D8-A70D-0003931CFE24@mac.com> On 25-jun-04, at 5:05, Bob Ippolito wrote: > It's not that hard to (naively) implement. I think that PyInterpreter > in the PyObjC Examples does this. If it doesn't, then someone let me > know and I'll try and find my local version that does :) That example should do completion, but it's not an editor ;-) Ronald > > On Jun 24, 2004, at 11:17 AM, Tony McDonald wrote: > >> I *think* that PyOxide can do this... >> >> On 18 Jun 2004, at 03:25, Mellor Mike wrote: >> >>> Is there an editor for OS X that suports >>> auto-completion? I have used the ActivePython editor >>> on my work (WinXP) computer, and I would like to have >>> the same features on OS X. >>> Thanks._______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From bob at redivi.com Fri Jun 25 05:12:05 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jun 25 05:12:16 2004 Subject: [Pythonmac-SIG] Auto-completion Editor for OS X In-Reply-To: <55861C66-C687-11D8-A70D-0003931CFE24@mac.com> References: <20040618022521.63588.qmail@web13524.mail.yahoo.com> <9DF69920-C5F1-11D8-9AB0-000A95AB99B2@ncl.ac.uk> <7AD3CA36-C654-11D8-94F6-000A95686CD8@redivi.com> <55861C66-C687-11D8-A70D-0003931CFE24@mac.com> Message-ID: On Jun 25, 2004, at 5:09 AM, Ronald Oussoren wrote: > > On 25-jun-04, at 5:05, Bob Ippolito wrote: > >> It's not that hard to (naively) implement. I think that >> PyInterpreter in the PyObjC Examples does this. If it doesn't, then >> someone let me know and I'll try and find my local version that does >> :) > > That example should do completion, but it's not an editor ;-) Of course, but it's an implementation of completion that you could probably use if you were writing an editor.. though you would need to work with ASTs or something instead of globals() and locals() :) >> On Jun 24, 2004, at 11:17 AM, Tony McDonald wrote: >> >>> I *think* that PyOxide can do this... >>> >>> On 18 Jun 2004, at 03:25, Mellor Mike wrote: >>> >>>> Is there an editor for OS X that suports >>>> auto-completion? I have used the ActivePython editor >>>> on my work (WinXP) computer, and I would like to have >>>> the same features on OS X. >>>> Thanks._______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > -- > X|support bv http://www.xsupport.nl/ > T: +31 610271479 F: +31 204416173 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040625/612ea09b/smime.bin From gandreas at delver.com Fri Jun 25 09:22:39 2004 From: gandreas at delver.com (Glenn Andreas) Date: Fri Jun 25 09:24:35 2004 Subject: [Pythonmac-SIG] Auto-completion Editor for OS X In-Reply-To: <55861C66-C687-11D8-A70D-0003931CFE24@mac.com> References: <20040618022521.63588.qmail@web13524.mail.yahoo.com> <9DF69920-C5F1-11D8-9AB0-000A95AB99B2@ncl.ac.uk> <7AD3CA36-C654-11D8-94F6-000A95686CD8@redivi.com> <55861C66-C687-11D8-A70D-0003931CFE24@mac.com> Message-ID: At 11:09 AM +0200 6/25/04, Ronald Oussoren wrote: >On 25-jun-04, at 5:05, Bob Ippolito wrote: > >>It's not that hard to (naively) implement. I think that >>PyInterpreter in the PyObjC Examples does this. If it doesn't, >>then someone let me know and I'll try and find my local version >>that does :) > >That example should do completion, but it's not an editor ;-) > >Ronald >> >>On Jun 24, 2004, at 11:17 AM, Tony McDonald wrote: >> >>>I *think* that PyOxide can do this... PyOXIDE does auto-completion for both the interpreters and the editors (and uses an XCode style UI for it as well). Both work in similar, but not identical fashions. The interpreter window looks in locals()/globals() (based on the existing auto-complete module), while the editor windows try this if possible (if you've run the script before, or done something similar somewhere else) but it will also try to look through the code for matching symbols. Needless to say, this works better for the intepreter since that has more context (but there's currently a bug in the interpreter windows that cause the autocompletion to include more than it should). Call tips works similarly (again, the editor can parse out function declarations where possible). Regardless, due to the dynamic nature of python, function completion in an editor is difficult to provide anything terribly useful in many cases (after all, if "foo" is a parameter to a function, where would you look to complete "foo."?) -- Glenn Andreas gandreas@gandreas.com mondo blobbo, Cythera, Theldrow, oh my! Mad, Bad, and Dangerous to Know From Jack.Jansen at cwi.nl Fri Jun 25 09:49:26 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jun 25 09:48:41 2004 Subject: [Pythonmac-SIG] Mac OS X 10.3 and Tkinter In-Reply-To: <1dde0f1de1a8.1de1a81dde0f@osu.edu> References: <1dde0f1de1a8.1de1a81dde0f@osu.edu> Message-ID: <79260C3E-C6AE-11D8-A026-000A958D1666@cwi.nl> On 25-jun-04, at 3:28, LINCOLN RUTLEDGE wrote: > Hi folks, > > I haven't read the archives yet, sorry. This is a fairly low traffic > list, so... > > I installed the add-on package for Mac Python, and IDLE does not work. There's a really good chance that this is because _tkinter isn't installed. You say later "it is installed", but is it installed for the right Python, and the right version? Here's how to make sure: - Start Package Manager - To forestall another bug, select the "show hidden packages" checkmark - Check whether the _tkinter line says "installed". If it doesn't: select it, press Install. - If you get an error message about TclTkAqua: select that package and follow the instructions in the description field. Note that Tkinter scripts will *not* work under the IDE. > Also the IDE crashes when running my little curses game code. This > is about the third time after reloading. I'm not sure using curses under the IDE works, but it sure shouldn't crash. Could you send me the stack trace (if you have one: it may be in the Console window (Applications->Utilities->Console), or only in an IDE dialog (in which case it's diffficult to send). Otherwise send me the script, if it isn't too big, plus instructions on how to get the crash. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2086 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040625/cceaa34b/smime-0001.bin From sw at wordtech-software.com Fri Jun 25 11:47:36 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Fri Jun 25 11:47:41 2004 Subject: [Pythonmac-SIG] Tkinter/IDLE Message-ID: <40DC4918.2010306@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To use Tkinter with the MacPython tools, you need Tcl/Tk Aqua installed as well. Go to http://tcltkaqua.sourceforge.net to download. - -- 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 iD8DBQFA3EkYF6m9qPmThLQRApSgAJ423GzeJYiZJyYQYcYyckbqx0e4bwCdHU0R f2uPD2OLKHpCCsA3zBHUIRE= =PSY0 -----END PGP SIGNATURE----- From sw at wordtech-software.com Fri Jun 25 11:51:22 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Fri Jun 25 11:51:27 2004 Subject: [Pythonmac-SIG] Python .apps Message-ID: <40DC49FA.3070402@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 |>Any ideas on how to automate the process? Ideally this could be done |>via a Python script. Well, that method already exists--the bundlebuilder script. It's a more complete and powerful tool than what I've outlined, but also much more complex. My approach is designed for the more inexperienced developer (like myself). As I get further along with Python I expect I will start doing more with bundlebuilder. Or, if a complete GUI for it comes along...:-) - -- 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 iD8DBQFA3En6F6m9qPmThLQRAoaIAJ9PtMGXE+9YCXG7jYW6OndJFLDIqgCfX2Kq JIg43SpSWSGxj3kAOBnIJ7g= =AIcf -----END PGP SIGNATURE----- From gohaku at earthlink.net Fri Jun 25 14:04:30 2004 From: gohaku at earthlink.net (gohaku) Date: Fri Jun 25 14:04:44 2004 Subject: [Pythonmac-SIG] pythonw question Message-ID: <1AAF907B-C6D2-11D8-B2F6-000A9574CFD8@earthlink.net> Hello everyone, I am currently using python v2.2 ( /usr/bin/python ) I also have python v2.3 ( /usr/bin/pythonw ) Other than running wxPython apps with pythonw, I would like to know what the difference between python and pythonw is and if I overwrite /usr/bin/python with /usr/bin/python, will I experience any problems? Also, is there a better method of updating my python distribution than compiling the sources from scratch? Thanks in advance. -gohaku From Jack.Jansen at cwi.nl Fri Jun 25 17:23:47 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jun 25 17:23:54 2004 Subject: [Pythonmac-SIG] pythonw question In-Reply-To: <1AAF907B-C6D2-11D8-B2F6-000A9574CFD8@earthlink.net> References: <1AAF907B-C6D2-11D8-B2F6-000A9574CFD8@earthlink.net> Message-ID: On 25 Jun 2004, at 20:04, gohaku wrote: > Hello everyone, > I am currently using python v2.2 ( /usr/bin/python ) > I also have python v2.3 ( /usr/bin/pythonw ) Are you sure this is indeed the case? Because normally you would have one of two situations: - If you're running 10.2 (Panther) you'd have only /usr/bin/python, which would be 2.2 - If you're running 10.3 (Jaguar) you'd have both /usr/bin/python and /usr/bin/pythonw, and they would both be 2.3. If you indeed have the situation you sketch you've installed something into /usr/bin yourself, which is probably not a good idea. > Other than running wxPython apps with pythonw, I would like to know > what the difference between python and pythonw is and > if I overwrite /usr/bin/python with /usr/bin/python, will I experience > any problems? The difference is that "python" cannot access the GUI, and "pythonw" can. There is a very small performance disadvantage to using "pythonw" (it's a shellscript that runs the "real" windowing interpreter), but only during startup. I can't think of any real problems that could be caused by always using pythonw, but I think you should really fix the real problem (that the two seem to refer to different Python versions). -- 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 bob at redivi.com Fri Jun 25 17:49:00 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jun 25 17:49:10 2004 Subject: [Pythonmac-SIG] pythonw question In-Reply-To: References: <1AAF907B-C6D2-11D8-B2F6-000A9574CFD8@earthlink.net> Message-ID: <77BCEECA-C6F1-11D8-90E2-000A95686CD8@redivi.com> On Jun 25, 2004, at 5:23 PM, Jack Jansen wrote: > > On 25 Jun 2004, at 20:04, gohaku wrote: > >> Hello everyone, >> I am currently using python v2.2 ( /usr/bin/python ) >> I also have python v2.3 ( /usr/bin/pythonw ) > > Are you sure this is indeed the case? Because normally you would have > one of two situations: > - If you're running 10.2 (Panther) you'd have only /usr/bin/python, > which would be 2.2 > - If you're running 10.3 (Jaguar) you'd have both /usr/bin/python and > /usr/bin/pythonw, and they would both be 2.3. Jack has his kittens confused.. 10.2 is Jaguar, and 10.3 is Panther.. but the rest of what he said is correct :) -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040625/f14dacb5/smime.bin From gohaku at earthlink.net Fri Jun 25 20:23:00 2004 From: gohaku at earthlink.net (gohaku) Date: Fri Jun 25 20:23:06 2004 Subject: [Pythonmac-SIG] pythonw question In-Reply-To: References: <1AAF907B-C6D2-11D8-B2F6-000A9574CFD8@earthlink.net> Message-ID: I installed python23 through fink and copied: cp /sw/bin/python2.3 /sw/bin/python I noticed that pythonw and python import the same files: warnings.pyc, linecache.pyc,... anyway, will I experience any problems with the following command? %cp /sw/bin/python2.3 /sw/bin/python Thanks again. -gohaku On Jun 25, 2004, at 5:23 PM, Jack Jansen wrote: > > Are you sure this is indeed the case? Because normally you would have > one of two situations: > - If you're running 10.2 (Panther) you'd have only /usr/bin/python, > which would be 2.2 > - If you're running 10.3 (Jaguar) you'd have both /usr/bin/python and > /usr/bin/pythonw, and they would both be 2.3. > > If you indeed have the situation you sketch you've installed something > into /usr/bin yourself, which is probably not a good idea. > >> Other than running wxPython apps with pythonw, I would like to know >> what the difference between python and pythonw is and >> if I overwrite /usr/bin/python with /usr/bin/python, will I >> experience any problems? > > The difference is that "python" cannot access the GUI, and "pythonw" > can. There is a very small performance disadvantage to using "pythonw" > (it's a shellscript that runs the "real" windowing interpreter), but > only during startup. I can't think of any real problems that could be > caused by always using pythonw, but I think you should really fix the > real problem (that the two seem to refer to different Python > versions). > -- > 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 andy47 at halfcooked.com Sat Jun 26 12:07:20 2004 From: andy47 at halfcooked.com (Andy Todd) Date: Sat Jun 26 12:10:15 2004 Subject: [Pythonmac-SIG] Re: Auto-completion Editor for OS X In-Reply-To: <20040618022521.63588.qmail@web13524.mail.yahoo.com> References: <20040618022521.63588.qmail@web13524.mail.yahoo.com> Message-ID: Mellor Mike wrote: > Is there an editor for OS X that suports > auto-completion? I have used the ActivePython editor > on my work (WinXP) computer, and I would like to have > the same features on OS X. Thanks. > > Mike > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > Vim (http://vim.sf.net/) with the pydiction plugin (http://www.vim.org/scripts/script.php?script_id=850) work well for me. Add the taglist plugin (http://www.vim.org/scripts/script.php?script_id=273) and you've got everything you want from an IDE, without all of that unnecessary pointy-clicky stuff ;-) Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From Jack.Jansen at cwi.nl Sat Jun 26 18:40:39 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Jun 26 18:40:41 2004 Subject: [Pythonmac-SIG] pythonw question In-Reply-To: References: <1AAF907B-C6D2-11D8-B2F6-000A9574CFD8@earthlink.net> Message-ID: I think now you're messing up "/sw" and "/usr". /sw/bin/python* is fink-installed, and copying /sw/bin/python2.3 to /sw/bin/python isn't useful at all: if the fink installation is anything like a normal Python install then /sw/bin/python should be no more than a symlink to /sw/bin/python2.3. But: why not keep a copy of your original (call it "python-" or something) and just what happens if you do the copy? If it turns out there are bad side effects you can always go back... On 26 Jun 2004, at 02:23, gohaku wrote: > I installed python23 through fink and copied: > cp /sw/bin/python2.3 /sw/bin/python > > I noticed that pythonw and python import the same files: > warnings.pyc, linecache.pyc,... > > anyway, will I experience any problems with the following command? > %cp /sw/bin/python2.3 /sw/bin/python > > Thanks again. > -gohaku > On Jun 25, 2004, at 5:23 PM, Jack Jansen wrote: >> >> Are you sure this is indeed the case? Because normally you would have >> one of two situations: >> - If you're running 10.2 (Panther) you'd have only /usr/bin/python, >> which would be 2.2 >> - If you're running 10.3 (Jaguar) you'd have both /usr/bin/python and >> /usr/bin/pythonw, and they would both be 2.3. >> >> If you indeed have the situation you sketch you've installed >> something into /usr/bin yourself, which is probably not a good idea. >> >>> Other than running wxPython apps with pythonw, I would like to know >>> what the difference between python and pythonw is and >>> if I overwrite /usr/bin/python with /usr/bin/python, will I >>> experience any problems? >> >> The difference is that "python" cannot access the GUI, and "pythonw" >> can. There is a very small performance disadvantage to using >> "pythonw" (it's a shellscript that runs the "real" windowing >> interpreter), but only during startup. I can't think of any real >> problems that could be caused by always using pythonw, but I think >> you should really fix the real problem (that the two seem to refer to >> different Python versions). >> -- >> Jack Jansen, , http://www.cwi.nl/~jack >> If I can't dance I don't want to be part of your revolution -- Emma >> Goldman >> >> -- 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 jeremy.knope at gmail.com Sat Jun 26 20:20:24 2004 From: jeremy.knope at gmail.com (Jerome) Date: Sat Jun 26 20:20:28 2004 Subject: [Pythonmac-SIG] Crash when using PyGame and click dock icon Message-ID: <2c9aa7fe04062617202443b4d9@mail.gmail.com> Anybody else experience a crash with PyGame based python code? I haven't been able to figure it out because some games like Pathological don't seem to crash, but if I try to use it's pygame libraries and python libraries it still crashes when used with other code. Basically pygame at all is prone to crash if you cilck on the dock icon, sipmlest code i used to test: import pygame pygame.init() pygame.display.set_mode((640,480)) while 1: evt = pygame.event.wait() know where i should report to? i'm unsure it's a python/pygame/sdl or what bug.... From bob at redivi.com Sat Jun 26 20:44:48 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jun 26 20:44:55 2004 Subject: [Pythonmac-SIG] Crash when using PyGame and click dock icon In-Reply-To: <2c9aa7fe04062617202443b4d9@mail.gmail.com> References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> Message-ID: <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> On Jun 26, 2004, at 8:20 PM, Jerome wrote: > Anybody else experience a crash with PyGame based python code? I > haven't been able to figure it out because some games like > Pathological don't seem to crash, but if I try to use it's pygame > libraries and python libraries it still crashes when used with other > code. > > Basically pygame at all is prone to crash if you cilck on the dock > icon, sipmlest code i used to test: Doesn't crash here, tell us about your configuration.. What relevant things you have installed, complete with version information. The traceback and/or crash log could be useful as well. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040626/bdddf9c8/smime.bin From mmellor1 at yahoo.com Sat Jun 26 22:10:41 2004 From: mmellor1 at yahoo.com (Mike Mellor) Date: Sat Jun 26 22:10:46 2004 Subject: [Pythonmac-SIG] Auto-completion Editor for OS X In-Reply-To: Message-ID: On 6/25/04 9:22 AM, "Glenn Andreas" wrote: > > PyOXIDE does auto-completion for both the interpreters and the > editors (and uses an XCode style UI for it as well). Glenn - Thanks for the info, I have the latest version of PyOxide and it does auto-completion. I am having trouble using it to run my scripts. Does it need a specific version of python installed? I have both MacPython and the fink version (the fink version is the default, I usually use pythonw to use the MacPython version). What is happening when I run a script (command R) it will launch the GUI but I cannot use the GUI. I then have to manually kill python to get the script to quit. Thanks. Mike From jeremy.knope at gmail.com Sat Jun 26 22:22:26 2004 From: jeremy.knope at gmail.com (Jerome) Date: Sat Jun 26 22:22:33 2004 Subject: [Pythonmac-SIG] Crash when using PyGame and click dock icon In-Reply-To: <2c9aa7fe0406261920547196c6@mail.gmail.com> References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe0406261920547196c6@mail.gmail.com> Message-ID: <2c9aa7fe040626192237499e12@mail.gmail.com> http://homepage.mac.com/jeremy_knope/Python.crash.log is the crash log of the script i mentioned, PyObjC, PyGame, PyOpenGL, are installed, not sure what else... Python 2.3 on OS X 10.3.4 I can't seem to tell what small revision python is, if it's Python 2.3.3 or what. what else should I look for? On Sat, 26 Jun 2004 20:44:48 -0400, Bob Ippolito wrote: > > On Jun 26, 2004, at 8:20 PM, Jerome wrote: > > Doesn't crash here, tell us about your configuration.. What relevant > things you have installed, complete with version information. The > traceback and/or crash log could be useful as well. > > -bob From jeremy.knope at gmail.com Sat Jun 26 23:52:37 2004 From: jeremy.knope at gmail.com (Jerome) Date: Sat Jun 26 23:52:43 2004 Subject: [Pythonmac-SIG] Crash when using PyGame and click dock icon In-Reply-To: <1C4C6344-C7E1-11D8-B553-000A95686CD8@redivi.com> References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe0406261920547196c6@mail.gmail.com> <1C4C6344-C7E1-11D8-B553-000A95686CD8@redivi.com> Message-ID: <2c9aa7fe040626205232c63bb5@mail.gmail.com> from http://undefined.org/python/pimp/ PyObjC 1.0 PyGame 1.6 On Sat, 26 Jun 2004 22:24:26 -0400, Bob Ippolito wrote: > > OS X 10.3 comes with Python 2.3.0. > > What versions of PyObjC and pygame are you using? > > -bob From bob at redivi.com Sun Jun 27 00:05:49 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jun 27 00:05:57 2004 Subject: [Pythonmac-SIG] Crash when using PyGame and click dock icon In-Reply-To: <2c9aa7fe040626205232c63bb5@mail.gmail.com> References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe0406261920547196c6@mail.gmail.com> <1C4C6344-C7E1-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe040626205232c63bb5@mail.gmail.com> Message-ID: <45FBD25B-C7EF-11D8-B553-000A95686CD8@redivi.com> Please try downloading and installing PyObjC 1.1 from http://pyobjc.sf.net/ -- we fixed so many bugs between 1.0 and 1.1 that it's hard for me to even guess what the problem may be. I haven't had the time to keep my repository up to date lately.. but I've (crossing fingers) got a product launch on Monday so hopefully that will change soon.. but next week is WWDC and then HOPE soon after, so I'll still be pretty busy for a while. On Jun 26, 2004, at 11:52 PM, Jerome wrote: > from http://undefined.org/python/pimp/ > PyObjC 1.0 > PyGame 1.6 > > On Sat, 26 Jun 2004 22:24:26 -0400, Bob Ippolito > wrote: >> >> OS X 10.3 comes with Python 2.3.0. >> >> What versions of PyObjC and pygame are you using? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040627/4f6d0703/smime.bin From jeremy.knope at gmail.com Sun Jun 27 00:29:24 2004 From: jeremy.knope at gmail.com (Jerome) Date: Sun Jun 27 00:29:27 2004 Subject: [Pythonmac-SIG] Crash when using PyGame and click dock icon In-Reply-To: <45FBD25B-C7EF-11D8-B553-000A95686CD8@redivi.com> References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe0406261920547196c6@mail.gmail.com> <1C4C6344-C7E1-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe040626205232c63bb5@mail.gmail.com> <45FBD25B-C7EF-11D8-B553-000A95686CD8@redivi.com> Message-ID: <2c9aa7fe0406262129441bedfd@mail.gmail.com> that appears to work, awesome, only problem which is minor, is if i choose to quit my simple python script using the dock menu i get an error while it's quitting 2004-06-27 00:18:22.566 Python[1754] An uncaught exception was raised 2004-06-27 00:18:22.566 Python[1754] exceptions.NameError: global name 'pyame' is not defined 2004-06-27 00:18:22.566 Python[1754] *** Uncaught exception: exceptions.NameError: global name 'pyame' is not defined Trace/BPT trap but other than that it seems to fix the main big problem :) thanks, should've checked for more up to date versions first off On Sun, 27 Jun 2004 00:05:49 -0400, Bob Ippolito wrote: > > Please try downloading and installing PyObjC 1.1 from > http://pyobjc.sf.net/ -- we fixed so many bugs between 1.0 and 1.1 that > it's hard for me to even guess what the problem may be. > > I haven't had the time to keep my repository up to date lately.. but > I've (crossing fingers) got a product launch on Monday so hopefully > that will change soon.. but next week is WWDC and then HOPE soon after, > so I'll still be pretty busy for a while. > > > From bob at redivi.com Sun Jun 27 00:33:06 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jun 27 00:33:13 2004 Subject: [Pythonmac-SIG] Crash when using PyGame and click dock icon In-Reply-To: <2c9aa7fe0406262129441bedfd@mail.gmail.com> References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe0406261920547196c6@mail.gmail.com> <1C4C6344-C7E1-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe040626205232c63bb5@mail.gmail.com> <45FBD25B-C7EF-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe0406262129441bedfd@mail.gmail.com> Message-ID: <15A7E9F0-C7F3-11D8-B553-000A95686CD8@redivi.com> That is a typo somewhere.. grep your source and pygame's source for "pyame". If it's pygame's source, let me know, so I can fix it (if it's not already fixed in CVS)! On Jun 27, 2004, at 12:29 AM, Jerome wrote: > that appears to work, awesome, only problem which is minor, is if i > choose to quit my simple python script using the dock menu i get an > error while it's quitting > 2004-06-27 00:18:22.566 Python[1754] An uncaught exception was raised > 2004-06-27 00:18:22.566 Python[1754] exceptions.NameError: global name > 'pyame' is not defined > 2004-06-27 00:18:22.566 Python[1754] *** Uncaught exception: > exceptions.NameError: global name 'pyame' is not > defined > Trace/BPT trap > > but other than that it seems to fix the main big problem :) thanks, > should've checked for more up to date versions first off > > On Sun, 27 Jun 2004 00:05:49 -0400, Bob Ippolito > wrote: >> >> Please try downloading and installing PyObjC 1.1 from >> http://pyobjc.sf.net/ -- we fixed so many bugs between 1.0 and 1.1 >> that >> it's hard for me to even guess what the problem may be. >> >> I haven't had the time to keep my repository up to date lately.. but >> I've (crossing fingers) got a product launch on Monday so hopefully >> that will change soon.. but next week is WWDC and then HOPE soon >> after, >> so I'll still be pretty busy for a while. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040627/f8668ea8/smime.bin From jeremy.knope at gmail.com Sun Jun 27 02:54:47 2004 From: jeremy.knope at gmail.com (Jerome) Date: Sun Jun 27 02:54:53 2004 Subject: [Pythonmac-SIG] Bundlebuilder + pygame troubles Message-ID: <2c9aa7fe0406262354ac3c614@mail.gmail.com> After using solutions from my previous emails on the list, I modified lib/macosx.py file in pygame-1.6 source and re-built and installed it now when i bundle build a python game, it won't run because it says from pygame.locals import * ImportError: No module named locals which just doesn't make sense to me, running the game in it's original form works, and it used to work before re-building/re-installing pygame 1.6 any suggestions? --jerome From artelse at mohr-i.nl Sun Jun 27 07:31:29 2004 From: artelse at mohr-i.nl (Arthur Elsenaar) Date: Sun Jun 27 07:31:37 2004 Subject: [Pythonmac-SIG] Other PyGame problems In-Reply-To: <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> Message-ID: <8829556C-C82D-11D8-A642-000A95C887F8@mohr-i.nl> Hi, when I try to run some pygame examples pypanda or imgv, I get the errors listed below. Anyone have an idea how to fix this? I'm running PyObjC1.1, pygame 1.6, OS X 10.3.4. When I run the same examples from PyOXIDE, Python crashes. Thanks, Arthur. $ pythonw pypanda.py 2004-06-27 00:00:53.967 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x3159e0 of class NSCFArray autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.968 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x316cf0 of class NSCFArray autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.969 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35a730 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.970 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x315a40 of class NSCFArray autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.970 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x316e30 of class NSCFArray autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.971 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x359000 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.971 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x358f40 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.972 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x358f60 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.973 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x358f80 of class NSCFArray autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.975 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x3165a0 of class NSCFArray autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.976 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x359020 of class NSPathStore2 autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.977 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x359060 of class NSPathStore2 autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.977 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x359220 of class NSPathStore2 autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.978 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x359250 of class NSPathStore2 autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.979 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x359110 of class NSCFDictionary autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.980 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x3591b0 of class NSIdEnumerator autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.980 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dce8c4 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.981 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35a750 of class NSCFArray autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.982 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dce8d4 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.983 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dce924 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.984 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dce8a4 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.988 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dce864 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.989 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dce8f4 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.990 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dce884 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.991 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dce854 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:53.993 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x32e770 of class NSCFNumber autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.000 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35bba0 of class NSCFData autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.006 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dcb070 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.009 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35c5e0 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.011 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35a0f0 of class NSImage autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.013 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35ced0 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.014 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35cdb0 of class NSImage autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.015 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x359ae0 of class _NSThemeCloseWidget autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.016 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dcb070 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.017 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35d4f0 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.018 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35d340 of class NSImage autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.019 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35d390 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.020 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35d580 of class NSImage autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.021 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35d0c0 of class _NSThemeWidget autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.022 Python[7705] *** _NSAutoreleaseNoPool(): Object 0xa2dcb070 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.024 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35c4d0 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.024 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x359bb0 of class NSImage autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.025 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x34aa80 of class _NSCachedBitmapImageRep autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.026 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x34a780 of class NSImage autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.026 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35d860 of class _NSThemeWidget autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.029 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x35d1e0 of class NSCFString autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.030 Python[7705] *** _NSAutoreleaseNoPool(): Object 0x358f00 of class NSException autoreleased with no pool in place - just leaking 2004-06-27 00:00:54.031 Python[7705] *** Uncaught exception: Error (1002) creating CGSWindow Trace/BPT trap From thorthor at altern.org Sun Jun 27 12:27:54 2004 From: thorthor at altern.org (thor) Date: Sun Jun 27 11:27:33 2004 Subject: [Pythonmac-SIG] another pyGame question Message-ID: Hi List ! I've been using PyGame quite extensively and everything has been fine there, (apart from not being able to use wxPython and PyGame together). Now, last week I installed the pyObjC library and tested it, but for some reason now, pyGame is not working. Also I installed the PyOXIDE and tested that. It worked fine for a while but not anymore. (it won't start now). I don't know if it is related to the pyObjC or not. Here is what I get: Traceback (most recent call last): File "/Volumes/quaziir/programming/python/ BUEXpython/_pygame/tompong/pong.py", line 510, in ? main() File "/Volumes/quaziir/programming/python/ BUEXpython/_pygame/tompong/pong.py", line 368, in main pygame.init() File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pygame/__init__.py", line 164, in init import AppKit File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/PyObjC/AppKit/__init__.py", line 15, in ? from _AppKit import * RuntimeError: Cannot rescan method table Pygame Parachute Traceback: Basically it is on pygame.init() that the program halts. It has something to do with AppKit, but I don't have a clue about this. Do you have any tips about what I could do? From bob at redivi.com Sun Jun 27 16:30:12 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jun 27 16:30:29 2004 Subject: [Pythonmac-SIG] Other PyGame problems In-Reply-To: <8829556C-C82D-11D8-A642-000A95C887F8@mohr-i.nl> References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> <8829556C-C82D-11D8-A642-000A95C887F8@mohr-i.nl> Message-ID: On Jun 27, 2004, at 7:31 AM, Arthur Elsenaar wrote: > when I try to run some pygame examples pypanda or imgv, I get the > errors listed below. Anyone have an idea how to fix this? I'm running > PyObjC1.1, pygame 1.6, OS X 10.3.4. Maybe they don't call pygame.init()? I've never tried them, they're not part of the pygame source tree. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040627/ace6a489/smime.bin From bob at redivi.com Sun Jun 27 16:31:25 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jun 27 16:31:31 2004 Subject: [Pythonmac-SIG] another pyGame question In-Reply-To: References: Message-ID: On Jun 27, 2004, at 12:27 PM, thor wrote: > I've been using PyGame quite extensively and everything has > been fine there, (apart from not being able to use wxPython and > PyGame together). > > Now, last week I installed the pyObjC library and tested it, but > for some reason now, pyGame is not working. Also I installed > the PyOXIDE and tested that. It worked fine for a while but not > anymore. > (it won't start now). > > I don't know if it is related to the pyObjC or not. > > Here is what I get: > > Traceback (most recent call last): > File "/Volumes/quaziir/programming/python/ > BUEXpython/_pygame/tompong/pong.py", line 510, in ? > main() > File "/Volumes/quaziir/programming/python/ > BUEXpython/_pygame/tompong/pong.py", line 368, in main > pygame.init() > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/pygame/__init__.py", line 164, in init > import AppKit > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/PyObjC/AppKit/__init__.py", line 15, in ? > from _AppKit import * > RuntimeError: Cannot rescan method table > Pygame Parachute Traceback: > > Basically it is on > > pygame.init() > > that the program halts. > It has something to do with AppKit, but I don't have a clue about this. > > Do you have any tips about what I could do? rm -rf /Library/Python/2.3/PyObjC and install PyObjC 1.1 again, and make sure you're using the latest pygame as well. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040627/f479f7ba/smime.bin From thorthor at altern.org Sun Jun 27 18:12:38 2004 From: thorthor at altern.org (thor) Date: Sun Jun 27 17:12:18 2004 Subject: [Pythonmac-SIG] another pyGame question In-Reply-To: References: Message-ID: <19F80758-C887-11D8-9B38-0003930EC1EA@altern.org> Thanks Bob ! This was it. >> Basically it is on >> >> pygame.init() >> >> that the program halts. >> It has something to do with AppKit, but I don't have a clue about >> this. >> >> Do you have any tips about what I could do? > > rm -rf /Library/Python/2.3/PyObjC and install PyObjC 1.1 again, and > make sure you're using the latest pygame as well. Any ideas what the problem could have been? Finally I got a comment into the terminal saying that global name "pyame" does not exist. "pyame" is not in my code, so I guess there is a typo in the source code of PyGame ???? Thanks again. thor From artelse at mohr-i.nl Sun Jun 27 17:42:03 2004 From: artelse at mohr-i.nl (Arthur Elsenaar) Date: Sun Jun 27 17:42:10 2004 Subject: [Pythonmac-SIG] Other PyGame problems In-Reply-To: References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> <8829556C-C82D-11D8-A642-000A95C887F8@mohr-i.nl> Message-ID: On Jun 27, 2004, at 22:30, Bob Ippolito wrote: > > On Jun 27, 2004, at 7:31 AM, Arthur Elsenaar wrote: > >> when I try to run some pygame examples pypanda or imgv, I get the >> errors listed below. Anyone have an idea how to fix this? I'm running >> PyObjC1.1, pygame 1.6, OS X 10.3.4. > > Maybe they don't call pygame.init()? I've never tried them, they're > not part of the pygame source tree. yep, that worked for pypanda, thanks! Arthur From bob at redivi.com Sun Jun 27 19:55:12 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jun 27 19:57:32 2004 Subject: [Pythonmac-SIG] another pyGame question In-Reply-To: <19F80758-C887-11D8-9B38-0003930EC1EA@altern.org> References: <19F80758-C887-11D8-9B38-0003930EC1EA@altern.org> Message-ID: <6DB16438-C895-11D8-8BBD-000A95686CD8@redivi.com> On Jun 27, 2004, at 3:12 PM, thor wrote: > > Thanks Bob ! > > This was it. > >>> Basically it is on >>> >>> pygame.init() >>> >>> that the program halts. >>> It has something to do with AppKit, but I don't have a clue about >>> this. >>> >>> Do you have any tips about what I could do? >> >> rm -rf /Library/Python/2.3/PyObjC and install PyObjC 1.1 again, and >> make sure you're using the latest pygame as well. > > Any ideas what the problem could have been? Things can go wrong in PyObjC's build process if you have a sufficiently older version installed. > Finally I got a comment into the terminal saying that global name > "pyame" does not exist. > "pyame" is not in my code, so I guess there is a typo in the source > code of PyGame ???? Yes, there was a typo in the pygame source code. In macosx.py it says pyame.QUIT not pygame.QUIT. This was fixed some time ago, but there hasn't been a release since. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040627/eb597849/smime.bin From jeremy.knope at gmail.com Sun Jun 27 22:06:11 2004 From: jeremy.knope at gmail.com (Jerome) Date: Sun Jun 27 22:06:18 2004 Subject: [Pythonmac-SIG] another pyGame question In-Reply-To: <6DB16438-C895-11D8-8BBD-000A95686CD8@redivi.com> References: <19F80758-C887-11D8-9B38-0003930EC1EA@altern.org> <6DB16438-C895-11D8-8BBD-000A95686CD8@redivi.com> Message-ID: <2c9aa7fe0406271906559e82df@mail.gmail.com> I did this fix and now i can't bundle apps, they can't import pygame.locals oddly enough, i probably should try cleaning pygame/pyobjc out and reinstalling pyobjc 1.1 and pygame 1.6 with the fix and see if it helps > > Yes, there was a typo in the pygame source code. In macosx.py it says > pyame.QUIT not pygame.QUIT. > > This was fixed some time ago, but there hasn't been a release since. > > -bob From rutledge.50 at osu.edu Sun Jun 27 23:45:58 2004 From: rutledge.50 at osu.edu (LINCOLN RUTLEDGE) Date: Sun Jun 27 23:49:10 2004 Subject: [Pythonmac-SIG] Mac OS X 10.3 and Tkinter Message-ID: <3486483475ba.3475ba348648@osu.edu> Thanks for all of the responses, I'm working with PackageManager to get _tkinter, which it says is not installed. I just installed the OS X 10.3 Addons... I am also downloading TkAqua to handle that dependency problem. Jack, when I run my little poor game, in IDE, it crashes. The only log entry I have found is: Error opening terminal: unknown. It does that every time, whether I select "Run All" or "Run Selection" with the code selected. Thanks for the help! Lincoln ----- Original Message ----- From? Jack Jansen Date? Fri, 25 Jun 2004 15:49:26 +0200 To? LINCOLN RUTLEDGE Cc? pythonmac-sig@python.org Subject? Re: [Pythonmac-SIG] Mac OS X 10.3 and Tkinter On 25-jun-04, at 3:28, LINCOLN RUTLEDGE wrote: > Hi folks, > > I haven't read the archives yet, sorry.? This is a fairly low traffic > list, so... > > I installed the add-on package for Mac Python, and IDLE does not work. There's a really good chance that this is because _tkinter isn't installed. You say later "it is installed", but is it installed for the ? right Python, and the right version? Here's how to make sure: - Start Package Manager - To forestall another bug, select the "show hidden packages" checkmark - Check whether the _tkinter line says "installed". If it doesn't: select it, press Install. - If you get an error message about TclTkAqua: select that package and follow the instructions in the description field. Note that Tkinter scripts will *not* work under the IDE. >? Also the IDE crashes when running my little curses game code.? This > is about the third time after reloading. I'm not sure using curses under the IDE works, but it sure shouldn't crash. Could you send me the stack trace (if you have one: it may be in the Console window (Applications->Utilities->Console), or only in an IDE dialog (in which case it's diffficult to send). Otherwise send me the script, if it isn't too big, plus instructions on how to get the crash. -- 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 rutledge.50 at osu.edu Mon Jun 28 00:29:19 2004 From: rutledge.50 at osu.edu (LINCOLN RUTLEDGE) Date: Mon Jun 28 00:32:57 2004 Subject: [Pythonmac-SIG] Tkinter/IDLE Message-ID: <34b4443464c9.3464c934b444@osu.edu> Hi, Thanks for all of the help. IDLE works now! I have a question though: I *think* under OpenBSD IDLE would spit output from print statements and ncurses handling to the xterm I launched IDLE from... I have tried running my program from IDLE by launching IDLE from Finder or by typing "open /Applications...IDLE.app", both in Terminal.app and an xterm. I am getting some strange behaviors, such as crashing my program on unhandled input exceptions, when I haven't typed anything! Also I can't find my output from print statements etc. Any ideas how this ties together? Traceback (most recent call last): File "/Users/lrutled/incoming/galagASCII.pl2.py", line 407, in -toplevel- maingameloop() File "/Users/lrutled/incoming/galagASCII.pl2.py", line 354, in maingameloop if chr(key) == "j" and (ship.shipx > 0): ValueError: chr() arg not in range(256) This is even though I haven't typed anything! And I get the exact same errors from xterm as I said. Now I'm getting paranoid that I will have to get away from UFS and use HFS+. Could this be the problem? Thanks folks, happy hacking, Lincoln ---- Original Message ----- From? Kevin Walzer Date? Fri, 25 Jun 2004 11:47:36 -0400 To? pythonmac-sig@python.org, rutledge.50@osu.edu Subject? [Pythonmac-SIG] Tkinter/IDLE -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To use Tkinter with the MacPython tools, you need Tcl/Tk Aqua installed as well. Go to http://tcltkaqua.sourceforge.net to download. - -- Kevin Walzer, PhD From bob at redivi.com Mon Jun 28 12:18:25 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jun 28 12:19:42 2004 Subject: [Pythonmac-SIG] talkingpanda installer - PyObjC experience Message-ID: I'll only plug this once, but one of the things I've been working on for a while now is talking panda ( http://talkingpanda.com/ ), a set of foreign language phrase books for the version 2 and later firmware iPods (anything with buttons above the wheel, including the Mini). There's a flash demonstration and an iPod-installable Japanese demo up on the site (see the right sidebar) if you want to play before you pay :) The installer is written in about 95% PyObjC, with the rest in ObjC and C. I used the Xcode template to develop it. I did not use Cocoa Bindings as I wanted OS X 10.2 support. I had to do several things in PyObjC that I had not done before, such as creating a NSMatrix subclass, and doing AppleEvents asynchronously (via the low level interface of an unreleased copy of aeve I have). For OS X 10.2 support, I did it all by hand. I had my working application for 10.3, then I had it print all of the keys and values from sys.modules where the value had a sensible __file__. I then went to an OS X 10.2 machine and installed Python (from the MacPython page) and compiled the relevant packages (PyObjC, LaunchServices, TECManager). I then used this dependency list to strip down the framework to the bare essentials, and I used: find . -name "*.so" -exec install_name_tool -change /Library/Frameworks/Python.framework/Versions/2.3/Python @executable_path/../Frameworks/Python.framework/Versions/2.3/Python {} \; to rewrite the mach-o load commands (as well as install_name_tool -id @exec... on the Python dylib, of course). then I brought this all into my Xcode project and made a copy files build phase for the framework. I had to change main.m to inject the PYTHONHOME environment variable to [NSString stringWithFormat:@"%@/Frameworks/Python.framework/Versions/2.3", [[NSBundle mainBundle] bundlePath] (written in Mail, selectors may be wrong.. I did something slightly different in the code) so that Python could find its standard library. I did notice one bug, AppHelper.runEventLoop() seems to crash if installMachInterrupt=True (the default) with a 10.2 PyObjC. I haven't researched the issue, I simply made it false because I didn't need that functionality (it's basically to trap SIGINT) since the app was otherwise ready. Developing this installer application gave me several ideas for new tools, libraries, and tutorials to write. One of which is ripping bundlebuilder apart into tiny little orthogonal bits, and another is making a bdist_pkg for distutils (that PackageManager should use in lieu of tarballs). I'm also thinking that I should put some more work into aeve, because it's much better suited for *receiving* and *sending* apple events than appscript is, although it is pretty low level right now (but FAR FAR nicer than working with AEDesc myself) it worked out well for me with no surprises. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040628/93db217f/smime.bin From marmille at adobe.com Mon Jun 28 13:35:33 2004 From: marmille at adobe.com (marmille) Date: Mon Jun 28 13:35:49 2004 Subject: [Pythonmac-SIG] Problem Running PythonIDE Message-ID: <40E056E5.7040502@adobe.com> I have MacPython 2.3.3 installed on OS X 10.2.8. I've modified my login so that /usr/local/bin is the first folder on my PATH. I can run python from Terminal just fine, but when I try to start the PythonIDE app by double-clicking on it, all I see is the splash screen for a second then it quits -- and no error messages or dialogs are displayed. Since I don't have a clue what it's unhappy about, I was wondering if anyone had any suggestions. TIA, -Martin From eichin at metacarta.com Mon Jun 28 15:42:09 2004 From: eichin at metacarta.com (eichin@metacarta.com) Date: Mon Jun 28 15:42:17 2004 Subject: [Pythonmac-SIG] Crash when using PyGame and click dock icon In-Reply-To: <15A7E9F0-C7F3-11D8-B553-000A95686CD8@redivi.com> References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe0406261920547196c6@mail.gmail.com> <1C4C6344-C7E1-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe040626205232c63bb5@mail.gmail.com> <45FBD25B-C7EF-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe0406262129441bedfd@mail.gmail.com> <15A7E9F0-C7F3-11D8-B553-000A95686CD8@redivi.com> Message-ID: <7gvfhbfp0u.fsf@pikespeak.metacarta.com> Bob Ippolito writes: > That is a typo somewhere.. grep your source and pygame's source for > "pyame". If it's pygame's source, let me know, so I can fix it (if > it's not already fixed in CVS)! Umm, I posted this about two weeks ago, Subject: pygame 1.6: macosx applicationShouldTerminate_ typo, to pete@shinners.org and pygame@seul.org; is this a better place to have sent it? (the fix is the obvious one, pygame/macosx.py, line 42, fix "pyame.QUIT".) From eichin at metacarta.com Mon Jun 28 15:44:45 2004 From: eichin at metacarta.com (eichin@metacarta.com) Date: Mon Jun 28 15:44:48 2004 Subject: [Pythonmac-SIG] Crash when using PyGame and click dock icon In-Reply-To: <7gvfhbfp0u.fsf@pikespeak.metacarta.com> References: <2c9aa7fe04062617202443b4d9@mail.gmail.com> <314E18DE-C7D3-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe0406261920547196c6@mail.gmail.com> <1C4C6344-C7E1-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe040626205232c63bb5@mail.gmail.com> <45FBD25B-C7EF-11D8-B553-000A95686CD8@redivi.com> <2c9aa7fe0406262129441bedfd@mail.gmail.com> <15A7E9F0-C7F3-11D8-B553-000A95686CD8@redivi.com> <7gvfhbfp0u.fsf@pikespeak.metacarta.com> Message-ID: <7gpt7jfowi.fsf@pikespeak.metacarta.com> Oh, sorry, someone already check that it was in CVS. (It turns out that while most people see a warning, it actually shows up as a bug - if you hit quit from the dock menu [because you're debugging an app with a broken quit handler], it dies on the exception; if you *fix* the bug, the app then doesn't die at all :-) From Jack.Jansen at cwi.nl Mon Jun 28 16:45:41 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jun 28 16:45:42 2004 Subject: [Pythonmac-SIG] Problem Running PythonIDE In-Reply-To: <40E056E5.7040502@adobe.com> References: <40E056E5.7040502@adobe.com> Message-ID: <1E5860DA-C944-11D8-80A7-000D934FF6B4@cwi.nl> On 28 Jun 2004, at 19:35, marmille wrote: > I have MacPython 2.3.3 installed on OS X 10.2.8. I've modified my > login so that /usr/local/bin is the first folder on my PATH. > > I can run python from Terminal just fine, but when I try to start the > PythonIDE app by double-clicking on it, all I see is the splash screen > for a second then it quits -- and no error messages or dialogs are > displayed. There are two ways to try and see the error message: - Open Applications->Utilities->Console, and see whether there are any messages there. - Start the IDE from the command line, by running /Applications/MacPython-2.3/PythonIDE.app/Contents/MacOS/PythonIDE. -- 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 marmille at adobe.com Mon Jun 28 19:52:34 2004 From: marmille at adobe.com (marmille) Date: Mon Jun 28 19:53:24 2004 Subject: [Pythonmac-SIG] Problem Running PythonIDE In-Reply-To: <1E5860DA-C944-11D8-80A7-000D934FF6B4@cwi.nl> References: <40E056E5.7040502@adobe.com> <1E5860DA-C944-11D8-80A7-000D934FF6B4@cwi.nl> Message-ID: <40E0AF42.5000502@adobe.com> Jack Jansen wrote: > > On 28 Jun 2004, at 19:35, marmille wrote: > >> I have MacPython 2.3.3 installed on OS X 10.2.8. I've modified my >> login so that /usr/local/bin is the first folder on my PATH. >> >> I can run python from Terminal just fine, but when I try to start the >> PythonIDE app by double-clicking on it, all I see is the splash screen >> for a second then it quits -- and no error messages or dialogs are >> displayed. > > > There are two ways to try and see the error message: > - Open Applications->Utilities->Console, and see whether there are any > messages there. > - Start the IDE from the command line, by running > /Applications/MacPython-2.3/PythonIDE.app/Contents/MacOS/PythonIDE. > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma Goldman Thanks Jack. This is what was in shown in the Console window: > Traceback (most recent call last): > File "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/PythonIDE.py", line 59, in ? > _PythonIDEMain.PythonIDE() > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDEMain.py", line 41, in __init__ > Wapplication.Application.__init__(self, 'Pide') > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 28, in __init__ > FrameWork.Application.__init__(self) > File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/FrameWork.py", line 115, in __init__ > self.makemenubar() > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 275, in makemenubar > self.makeusermenus() > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDEMain.py", line 159, in makeusermenus > self.makescriptsmenu() > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDEMain.py", line 261, in makescriptsmenu > self.scriptswalk(fsr.as_pathname(), self.scriptsmenu) > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 309, in scriptswalk > self.scriptswalk(path, submenu, done) > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 309, in scriptswalk > self.scriptswalk(path, submenu, done) > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 309, in scriptswalk > self.scriptswalk(path, submenu, done) > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 309, in scriptswalk > self.scriptswalk(path, submenu, done) > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 309, in scriptswalk > self.scriptswalk(path, submenu, done) > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 309, in scriptswalk > self.scriptswalk(path, submenu, done) > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 309, in scriptswalk > self.scriptswalk(path, submenu, done) > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 309, in scriptswalk > self.scriptswalk(path, submenu, done) > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 308, in scriptswalk > submenu = FrameWork.SubMenu(menu, name) > File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/FrameWork.py", line 708, in SubMenu > return menu.addsubmenu(label, title) > File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/FrameWork.py", line 595, in addsubmenu > sub = Menu(self.bar, title, -1) > File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/FrameWork.py", line 545, in __init__ > self.id, self.menu = self.bar.addmenu(title, after, id) > File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/FrameWork.py", line 479, in addmenu > id = self.getnextid() > File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication.py", line 433, in getnextid > id = self.possibleIDs[0] > IndexError: list index out of range ...which is hopefully a clue to somebody, but way beyond my own meager MacPython abilities to diagnose at this point. -Martin From robin.meier at free.fr Mon Jun 28 20:31:12 2004 From: robin.meier at free.fr (robin meier) Date: Mon Jun 28 20:31:18 2004 Subject: [Pythonmac-SIG] tkinter, pythonw, standard modules Message-ID: <9FF116E8-C963-11D8-B678-000A95C574E4@free.fr> hello i had some hassle to get tcltk running with python (i finally figured out i had to type pythonw in the terminal and not just python). but now i cannot import modules like Numeric anymore... i'm on 10.3 using python 2.3.3 thank you for your help in advance r From Jack.Jansen at cwi.nl Tue Jun 29 05:49:46 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jun 29 05:48:41 2004 Subject: [Pythonmac-SIG] Problem Running PythonIDE In-Reply-To: <40E0AF42.5000502@adobe.com> References: <40E056E5.7040502@adobe.com> <1E5860DA-C944-11D8-80A7-000D934FF6B4@cwi.nl> <40E0AF42.5000502@adobe.com> Message-ID: On 29-jun-04, at 1:52, marmille wrote: >> File >> "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/ >> Wapplication.py", line 433, in getnextid >> id = self.possibleIDs[0] >> IndexError: list index out of range > > ...which is hopefully a clue to somebody, but way beyond my own meager > MacPython abilities to diagnose at this point. Yes, this is a known bug, it will be fixed in the next release. But luckily there is a workaround too. The problem is that the IDE recursively creates the "Scripts" menu with the contents of the files and folders in your scripts folder. If there are more than 256 of those it will run out of menu entries and crash. There are two ways you can get this problem, with different fixes: - if you really have more than 256 scripts in your scripts folder you need to delete some. - more often, you've selected a different folder as your scripts folder (maybe your home folder, or Documents, or something like that) that has more then 256 files. The solution now is to remove "~/Library/Preferences/Python/PythonIDE preferences", that should make the IDE start again. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2086 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040629/acc8d45c/smime-0001.bin From Jack.Jansen at cwi.nl Tue Jun 29 05:51:46 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jun 29 05:50:48 2004 Subject: [Pythonmac-SIG] tkinter, pythonw, standard modules In-Reply-To: <9FF116E8-C963-11D8-B678-000A95C574E4@free.fr> References: <9FF116E8-C963-11D8-B678-000A95C574E4@free.fr> Message-ID: On 29-jun-04, at 2:31, robin meier wrote: > hello > > i had some hassle to get tcltk running with python (i finally figured > out i had to type pythonw in the terminal and not just python). > but now i cannot import modules like Numeric anymore... > i'm on 10.3 using python 2.3.3 If you have really installed Python 2.3.3 on 10.3 (and you're not using Apple's pre-installed Python 2.3) you should read the FAQ, the section on problems with installing two copies of Python. You've probably done something like install Numeric into Apple-python 2.3 and _tkinter into your python-2.3.3 accidentally. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2086 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040629/491ec028/smime.bin From hengist.podd at virgin.net Tue Jun 29 07:00:08 2004 From: hengist.podd at virgin.net (has) Date: Tue Jun 29 08:21:54 2004 Subject: Re. [Pythonmac-SIG] talkingpanda installer - PyObjC experience Message-ID: Bob wrote: > I'm also thinking that I should put some more work into aeve, >because it's much better suited for *receiving* and *sending* apple >events than appscript is Yeah, appscript's basically been a one-trick pony to-date, and while it's very application scripter-friendly it's a bit of a non-starter as far as application developers are concerned. I've been aware of this problem for a while and have started breaking it up to allow other kinds of use. Early days, so nothing's close to working yet (there's a lot of dependencies to pull apart, new APIs to create, etc.), but here's an idea of what I'm doing: - The Python/AE type converters and AE dispatch code have moved to a new package, AEM. I've already started work on this. This should provide a basic interface for AE communication without being tied to application terminology resources. - Specifier construction and ApplicationTerminology will also be spun off into individual concerns. - Specifier construction needs to take a two-tier approach: the current, terminology-guided, validating, syntactically-sugared interface, and a slightly lower-level API for constructing complex specifiers using AE codes only which will probably end up in AEM. - 'appscript' itself will end up as 'just another' client to these services; in its case providing a high-level, AppleScript-like application scripting interface just as it currently does. (It'll get all the terminology-based specifier stuff.) So it should continue to work and feel much as it already does, but will no longer be the only way to do AEs. - I've not looked at AE receiving or asynchronous use yet, but should get round to it eventually. BTW, one of the reasons for putting lots of input-checking into Specifiers is that it'll make a nice system for handling incoming Apple events, able to do a lot of user input validation and intelligent error reporting (unlike Cocoa Scripting, which is atrocious for this sort of thing). The ultimate goal, of course, being to create a complete Python Scripting framework (like appscript, this is something I'll eventually need myself for another project I'm working on), although that is still a looong way off. I expect this work to take some months; I'll probably release 0.6.0 in the interim (I've knocked out a few bugs and tidied some code, and working with Ryan Wilcox to add remote scripting support). As always, I'm open to suggestions, requests, assistance, etc. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From mwh at python.net Tue Jun 29 10:05:25 2004 From: mwh at python.net (Michael Hudson) Date: Tue Jun 29 10:05:30 2004 Subject: [Pythonmac-SIG] apple's OSX 1.3x python: how did they compile it? In-Reply-To: <20040622154805.640a2916@bola.college-de-france.fr> (RenE J. V. Bertin's message of "Tue, 22 Jun 2004 15:48:05 +0200") References: <20040622154805.640a2916@bola.college-de-france.fr> Message-ID: <2msmce5uje.fsf@starship.python.net> "RenE J.V. Bertin" writes: > 1) I ran python 2.3.4 in its build directory; somehow this might > degrade its floating point performance?! Running Python in it's source directory makes startup quite a bit slower. How long did your benchmarks run for? Cheers, mwh -- Clue: You've got the appropriate amount of hostility for the Monastery, however you are metaphorically getting out of the safari jeep and kicking the lions. -- coonec -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html From marmille at adobe.com Tue Jun 29 13:55:25 2004 From: marmille at adobe.com (marmille) Date: Tue Jun 29 13:56:17 2004 Subject: [Pythonmac-SIG] Problem Running PythonIDE In-Reply-To: References: <40E056E5.7040502@adobe.com> <1E5860DA-C944-11D8-80A7-000D934FF6B4@cwi.nl> <40E0AF42.5000502@adobe.com> Message-ID: <40E1AD0D.2090005@adobe.com> On On 29-jun-04, at 2:49, Jack Jansen wrote: > > On 29-jun-04, at 1:52, marmille wrote: > >>> File >>> "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/ >>> Wapplication.py", line 433, in getnextid >>> id = self.possibleIDs[0] >>> IndexError: list index out of range >> >> >> ...which is hopefully a clue to somebody, but way beyond my own >> meager MacPython abilities to diagnose at this point. > > > Yes, this is a known bug, it will be fixed in the next release. But > luckily there is a workaround too. > > The problem is that the IDE recursively creates the "Scripts" menu with > the contents of the files and folders in your scripts folder. If there > are more than 256 of those it will run out of menu entries and crash. > > There are two ways you can get this problem, with different fixes: > - if you really have more than 256 scripts in your scripts folder you > need to delete some. > - more often, you've selected a different folder as your scripts folder > (maybe your home folder, or Documents, or something like that) that has > more then 256 files. The solution now is to remove > "~/Library/Preferences/Python/PythonIDE preferences", that should make > the IDE start again. > -- Since I've never run the PythonIDE before, there's no way I could have changed its default scripts folder... Anyway, trashing the PythonIDE preferences solved the problem -- yea! Thanks very much for the assistance. Cheers, -Martin From eric.nieuwland at xs4all.nl Tue Jun 29 14:26:30 2004 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Tue Jun 29 14:26:34 2004 Subject: [Pythonmac-SIG] Tiger info, anyone? Message-ID: Hi all, Just to be curious: is ther any news on the Python version etc. in Tiger? --eric From bob at redivi.com Tue Jun 29 15:52:16 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jun 29 16:03:05 2004 Subject: [Pythonmac-SIG] Tiger info, anyone? In-Reply-To: References: Message-ID: <0.31054300.1088538736@mastersofbranding.com> --- Original Message --- From: Eric Nieuwland Sent: Tue, 29 Jun 2004 20:26:30 +0200 To: PythonMac Subject: [Pythonmac-SIG] Tiger info, anyone? > Just to be curious: is ther any news on the Python version etc. in > Tiger? Unfortunately anyone who has that information is under NDA. However, Tiger is not coming out for quite some time (1H 2005), so the Python the developer preview shipped with is unlikely to be set in stone. -bob From brownr at ucalgary.ca Tue Jun 29 16:38:12 2004 From: brownr at ucalgary.ca (Robert Brown) Date: Tue Jun 29 16:38:40 2004 Subject: [Pythonmac-SIG] Tiger info, anyone? Message-ID: <3D391498-CA0C-11D8-B689-000A9575B6C8@ucalgary.ca> I guess I'm not supposed to say what's built into Tiger, but I will mention that the 2.3.2 version I compiled and we're standardized with in the lab at the moment works fine in Tiger even though it was compiled in Panther. VTK needs a rebuild, as usual though. --------------------------------------------------- Robb Brown Seaman Family MR Research Centre Calgary, Alberta, Canada From bob at redivi.com Tue Jun 29 17:44:21 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jun 29 18:23:25 2004 Subject: Re. [Pythonmac-SIG] talkingpanda installer - PyObjC experience In-Reply-To: References: Message-ID: <7B38C054-CA15-11D8-B737-000A95686CD8@redivi.com> On Jun 29, 2004, at 4:00 AM, has wrote: > Bob wrote: > >> I'm also thinking that I should put some more work into aeve, >> because it's much better suited for *receiving* and *sending* apple >> events than appscript is > > Yeah, appscript's basically been a one-trick pony to-date, and while > it's very application scripter-friendly it's a bit of a non-starter as > far as application developers are concerned. I've been aware of this > problem for a while and have started breaking it up to allow other > kinds of use. > > Early days, so nothing's close to working yet (there's a lot of > dependencies to pull apart, new APIs to create, etc.), but here's an > idea of what I'm doing: > > - The Python/AE type converters and AE dispatch code have moved to a > new package, AEM. I've already started work on this. This should > provide a basic interface for AE communication without being tied to > application terminology resources. > > - Specifier construction and ApplicationTerminology will also be spun > off into individual concerns. > > - Specifier construction needs to take a two-tier approach: the > current, terminology-guided, validating, syntactically-sugared > interface, and a slightly lower-level API for constructing complex > specifiers using AE codes only which will probably end up in AEM. > > - 'appscript' itself will end up as 'just another' client to these > services; in its case providing a high-level, AppleScript-like > application scripting interface just as it currently does. (It'll get > all the terminology-based specifier stuff.) So it should continue to > work and feel much as it already does, but will no longer be the only > way to do AEs. > > - I've not looked at AE receiving or asynchronous use yet, but should > get round to it eventually. BTW, one of the reasons for putting lots > of input-checking into Specifiers is that it'll make a nice system for > handling incoming Apple events, able to do a lot of user input > validation and intelligent error reporting (unlike Cocoa Scripting, > which is atrocious for this sort of thing). The ultimate goal, of > course, being to create a complete Python Scripting framework (like > appscript, this is something I'll eventually need myself for another > project I'm working on), although that is still a looong way off. > > I expect this work to take some months; I'll probably release 0.6.0 in > the interim (I've knocked out a few bugs and tidied some code, and > working with Ryan Wilcox to add remote scripting support). > > As always, I'm open to suggestions, requests, assistance, etc. You should use aeve instead of writing AEM. It does all of the low level stuff in a very strict and predictable way that's entirely separate from application terminologies. I'll probably be cleaning stuff up and making a release in the next few weeks. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040629/f46d4f56/smime.bin From bob at redivi.com Tue Jun 29 20:17:18 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jun 29 20:18:00 2004 Subject: [Pythonmac-SIG] Tiger info, anyone? In-Reply-To: <3D391498-CA0C-11D8-B689-000A9575B6C8@ucalgary.ca> References: <3D391498-CA0C-11D8-B689-000A9575B6C8@ucalgary.ca> Message-ID: On Jun 29, 2004, at 1:38 PM, Robert Brown wrote: > I guess I'm not supposed to say what's built into Tiger, but I will > mention that the 2.3.2 version I compiled and we're standardized with > in the lab at the moment works fine in Tiger even though it was > compiled in Panther. VTK needs a rebuild, as usual though. Apple has just released many of the sources included in the WWDC 2004 Tiger Developer Preview: http://www.opensource.apple.com/darwinsource/WWDC2004/ This includes a slightly modified Python 2.3.3. I'll be using them to post some bugs/patches against Python, though some of the changes should be replaced with other methods and I'll be talking to the responsible person at Apple to make that happen. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040629/c090b67e/smime.bin From hengist.podd at virgin.net Wed Jun 30 08:26:36 2004 From: hengist.podd at virgin.net (has) Date: Wed Jun 30 09:34:16 2004 Subject: Re. [Pythonmac-SIG] talkingpanda installer - PyObjC experience In-Reply-To: <7B38C054-CA15-11D8-B737-000A95686CD8@redivi.com> References: <7B38C054-CA15-11D8-B737-000A95686CD8@redivi.com> Message-ID: Hey, >>As always, I'm open to suggestions, requests, assistance, etc. > >You should use aeve instead of writing AEM. It does all of the low >level stuff in a very strict and predictable way that's entirely >separate from application terminologies. I'll probably be cleaning >stuff up and making a release in the next few weeks. AEM's the easy bit (it's mostly done already) - it's getting all the appscript stuff that sits on top just right that's going to take the time. I'm mostly resolving the architecture as I go. Performance sumps in the application terminology system also need addressed and the custom terminology question needs resolved; probably going to be a redesign and rewrite in there. And I've still to figure out how to support handling of incoming events, probably requiring some preliminary work on the Python Scripting framework to see how it's all going to fit together. I'll certainly take a look at your next aeve release, though unless it's much simplified from 0.4.0 I probably won't get very far; aside from really disliking its object specifier handling, 0.4.0's code is just too dense and complex for me to follow. e.g. AEM's codecs module is ~170LOC, most of which is one-line lambdas; I think aeve takes something like 700LOC and lots of classes to provide basic type conversions. (Though I'd be interested to hear why you decided to do it that way.) Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From Chris.Barker at noaa.gov Wed Jun 30 12:26:58 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Jun 30 12:28:51 2004 Subject: [Pythonmac-SIG] Tiger info, anyone? In-Reply-To: References: <3D391498-CA0C-11D8-B689-000A9575B6C8@ucalgary.ca> Message-ID: <40E2E9D2.9030107@noaa.gov> Bob Ippolito wrote: > This includes a slightly modified Python 2.3.3. I'll be using them to > post some bugs/patches against Python, though some of the changes should > be replaced with other methods and I'll be talking to the responsible > person at Apple to make that happen. Excellent! Thanks so much for doing this Bob. It has seemed like the Apple folks are completely uninvolved with the [Mac]Python development community, which has always seemed strange to me. I hope they pay attention to what you have to suggest. -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 Jun 30 12:39:24 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Jun 30 12:40:45 2004 Subject: [Pythonmac-SIG] Tiger info, anyone? In-Reply-To: <40E2E9D2.9030107@noaa.gov> References: <3D391498-CA0C-11D8-B689-000A9575B6C8@ucalgary.ca> <40E2E9D2.9030107@noaa.gov> Message-ID: <0BFB0AA1-CAB4-11D8-9118-000A95686CD8@redivi.com> On Jun 30, 2004, at 9:26 AM, Chris Barker wrote: > Bob Ippolito wrote: > >> This includes a slightly modified Python 2.3.3. I'll be using them >> to post some bugs/patches against Python, though some of the changes >> should be replaced with other methods and I'll be talking to the >> responsible person at Apple to make that happen. > > Excellent! Thanks so much for doing this Bob. It has seemed like the > Apple folks are completely uninvolved with the [Mac]Python development > community, which has always seemed strange to me. I hope they pay > attention to what you have to suggest. It seems like they are interested in performing a more active role this time around. If nothing else, I have email addresses to ping if they don't fix my radars :) -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040630/5d8e7faa/smime.bin