From bnbtezfyu at el-nacional.com Thu Jan 1 01:44:50 2004 From: bnbtezfyu at el-nacional.com (Romeo) Date: Thu Jan 1 01:42:37 2004 Subject: [Pythonmac-SIG] Re: HYQSPVFU, and then somebody Message-ID: stevenson dugout ambling configuration coney disyllable definition coca credenza churchill away hop bucolic afferent plain fatuous -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040101/82adc9ef/attachment.html From Larry.A.Meyn at nasa.gov Thu Jan 1 04:02:40 2004 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Thu Jan 1 04:02:48 2004 Subject: [Pythonmac-SIG] IDLE from MacPython 2.3 Panther Add ons In-Reply-To: <62255DA3-3BF8-11D8-AD9B-000A959A114E@sauria.com> References: <62255DA3-3BF8-11D8-AD9B-000A959A114E@sauria.com> Message-ID: <40FAA7A3-3C39-11D8-8EFA-000A277E7E9E@nasa.gov> On Dec 31, 2003, at 5:18 PM, Ted Leung wrote: > > I grabbed the MacPython 2.3 for Panther addons because I wanted to > play with IDLE, but when I double click IDLE an icon bounces in the > dock and then goes away, but nothing happens. PythonIDE and > PackageManager both seem to work fine. I'm interested in playing > with BicycleRepairMan inside of IDLE. I'd appreciate any suggestions > on how to track this down. > To get IDLE to work, you need to install Tcl/Tk Aqua (http://www.maths.mq.edu.au/~steffen/tcltk/TclTkAqua/) and then install _tkinter from the PackageManager. From klxmkgcnwm at terra.com Thu Jan 1 04:08:13 2004 From: klxmkgcnwm at terra.com (Stinson Lon) Date: Thu Jan 1 04:14:08 2004 Subject: [Pythonmac-SIG] Re: BFE, with her companion Message-ID: lookout fermion autocrat rebel nodule mist locale onyx vandal sharpshoot meringue archimedes pronto dadaist predilect dissident -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040101/e350c155/attachment-0001.html From Jack.Jansen at cwi.nl Thu Jan 1 18:01:33 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Jan 1 18:01:37 2004 Subject: [Pythonmac-SIG] building extensions for 2.3 (darwin build), and UUID generation In-Reply-To: <6.0.1.1.2.20031231142920.04e05f40@mail.fxtech.com> References: <38BC7888-359C-11D8-BDD3-003065517236@cwi.nl> <6.0.1.1.2.20031231104829.0512e648@mail.fxtech.com> <20031231171014.GA1039@uiuc.edu> <3FF31EBF.3010200@noaa.gov> <6.0.1.1.2.20031231142920.04e05f40@mail.fxtech.com> Message-ID: <719D2849-3CAE-11D8-B8D0-000A27B19B96@cwi.nl> On 31-dec-03, at 21:30, Paul Miller wrote: > >> with a setup.py I wrote on Linux, and writing the setup.py was EASY. >> Take a look at: >> >> http://www.python.org/doc/current/ext/building.html >> >> It should take you about 10 minutes to get your extension setup and >> built. > > Alas - the examples and docs there seem fairly unix-specific. What if > I need to include some CoreFoundation framework headers and use the > CoreFoundation framework? If you look at the setup.py file at the top of a Python source distribution you'll find there how all the standard MacPython modules are built. The trick is to use the extra_link_args arguments to link against the framework. For example, here's the distutils magic for the CF module: exts.append( Extension('_CF', ['cf/_CFmodule.c', 'cf/pycfbridge.c'], extra_link_args=['-framework', 'CoreFoundation']) ) -- 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 stuart at stuartbishop.net Thu Jan 1 21:33:37 2004 From: stuart at stuartbishop.net (Stuart Bishop) Date: Thu Jan 1 21:35:14 2004 Subject: [Pythonmac-SIG] MacPython 2.3.3 - Zope 2.70? In-Reply-To: References: Message-ID: <117C1C41-3CCC-11D8-BC8D-000A95A06FC6@stuartbishop.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/12/2003, at 2:49 PM, Jim Harrison wrote: > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ > os.py", > line 543, in spawnvp > return _spawnvef(mode, file, args, None, execvp) > File > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ > os.py", > line 504, in _spawnvef > wpid, sts = waitpid(pid, 0) > OSError: [Errno 10] No child processes Check your error logs (logs/event.log I think is the default) - zopectl tried to start Zope, but something stopped it from completing its startup. Permission errors, files that should exist but don't, a broken Product, syntax error in the config file - there are many things that could cause this, but you need to check the logs since zopectl won't tell you. I havn't tested myself with MacPython 2.3.3, since I'm waiting for a blessed Panther RC. Zope 2.7.0 beta runs just fine for most tasks with the Python that ships with OS X - you are unlikely to trigger the bugs so it is good enough for development work. - -- Stuart Bishop http://www.stuartbishop.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/9NiFAfqZj7rGN0oRAmHJAJ9L9orzjq71644LiEEAnaBOMQeQ5ACglPDT UXYb/YXp9CbOx8OB1Jy+Kfs= =olZZ -----END PGP SIGNATURE----- From lzdpnjrfyalac at el-nacional.com Fri Jan 2 01:58:03 2004 From: lzdpnjrfyalac at el-nacional.com (Roseann Chase) Date: Fri Jan 2 14:03:23 2004 Subject: [Pythonmac-SIG] Re: MVH, courtyard was good Message-ID: cellulose clinton con discuss decadent biometrika metric demitting pane cud dustbin reliant colloquium england ready alphanumeric apologia ounce hostess toast -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040102/86b6aab6/attachment.html From giqnbd at china.com Sat Jan 3 03:37:34 2004 From: giqnbd at china.com (Kidd Quentin) Date: Fri Jan 2 15:32:34 2004 Subject: [Pythonmac-SIG] Re: %RND_UC_CHAR[2-8], thunderclaps that seemed Message-ID: farmhouse barstow chard proud manifestation secretarial sting sw marco rainstorm lionel precambrian carlson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040103/936b51b1/attachment.html From p.oberndoerfer at urheberrecht.org Fri Jan 2 15:27:10 2004 From: p.oberndoerfer at urheberrecht.org (Pascal Oberndoerfer) Date: Fri Jan 2 15:37:23 2004 Subject: [Pythonmac-SIG] Building 2.3.3 on 10.2 from source Message-ID: I tried to build and install Python 2.3.3 as a Framework on MacOS X 10.2.8 from source. Starting with the usual './configure --enable-framework' I saw this unexpected line: > checking LINKCC... ld: Undefined symbols: > ___gxx_personality_v0 > $(PURIFY) $(CXX) The following 'make' and 'make test' went fine. The 'make frameworkinstall' first gave me this SyntaxError: > ... > Compiling /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/__ init__.py ... > File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/_ _init__.py", line 118 > class site-packages(Standard_Suite_Events, > ^ > SyntaxError: invalid syntax > ... and then wouldn't continue even before attempting to install all the nice stuff into /Applications/MacPython-2.3 on this line: > Compiling /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ro man.py ... > make: *** [libinstall] Error 1 Any suggestions for me? Thanks! Pascal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040102/b340865e/attachment.html From Jack.Jansen at cwi.nl Fri Jan 2 15:54:38 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 2 15:54:41 2004 Subject: [Pythonmac-SIG] Building 2.3.3 on 10.2 from source In-Reply-To: References: Message-ID: On 2-jan-04, at 21:27, Pascal Oberndoerfer wrote: > I tried to build and install Python 2.3.3 as a Framework > on MacOS X 10.2.8 from source. Starting with the usual > './configure --enable-framework' I saw this unexpected line: > > > checking LINKCC... ld: Undefined symbols: > > ___gxx_personality_v0 > > $(PURIFY) $(CXX) Strange... Could it be you have a second copy of the gcc and friends installed (maybe through fink?) and are picking up some of that? Or any funny environment variables that somehow cause the linker and/or gcc to behave funny? To test things like this I have an extra user on my system (short name: luser; long name: Bill Gates:-) who has no special permissions, no funny .profile, etc. > The following 'make' and 'make test' went fine. > > The 'make frameworkinstall' first gave me this SyntaxError: > > > ... > > Compiling > /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- > packages/__init__.py ... > > ??File > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- > packages/__init__.py", line 118 > > ????class site-packages(Standard_Suite_Events, > > ??????????????^ > > SyntaxError: invalid syntax This looks like you made a mistake with gensuitemodule at some point in the past, and dropped the OSA suite for some application straight in site-packages (in stead of one directory below). Your best bet is to completely clean out /Library/Frameworks/Python.framework and redo the "make frameworkinstall". -- 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 Chris.Barker at noaa.gov Fri Jan 2 16:46:02 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Jan 2 16:46:08 2004 Subject: [Pythonmac-SIG] building extensions for 2.3 (darwin build), and UUID generation In-Reply-To: <6.0.1.1.2.20031231142920.04e05f40@mail.fxtech.com> Message-ID: <0F06E525-3D6D-11D8-9E37-000393A96660@noaa.gov> Paul et all: Using Jack's hint, I got your module to compile, link and run! I think. I have no idea what genguid is supposed to do. It does this: >>> genguid.genguid() 'D83FD1FB-3D6B-11D8-AD2C-000393A96660' Here is the setup.py: #!/usr/bin/env python2.3 from distutils.core import setup, Extension module1 = Extension('genguid', sources = ['genguid.cpp'], libraries = [], library_dirs = [], extra_link_args=['-framework', 'CoreFoundation']) setup (name = 'genguiid', version = '1.0', description = 'This is a single module that does something with core foundation', ext_modules = [module1]) And here is the module code (provided by Paul): #include #include static PyObject *s_genguid(PyObject *self, PyObject *args, PyObject *keywds) { char buf[100]; CFUUIDRef ref = ::CFUUIDCreate(kCFAllocatorDefault); CFStringRef str = ::CFUUIDCreateString(kCFAllocatorDefault, ref); bool result = ::CFStringGetCString(str, buf, sizeof(buf), kCFStringEncodingASCII); ::CFRelease(ref); ::CFRelease(str); return PyString_FromString(buf); } static PyMethodDef s_methods[] = { { "genguid", (PyCFunction)s_genguid, METH_VARARGS }, { NULL, NULL, 0 } }; #pragma export on extern "C" void initgenguid() { PyObject *module = ::Py_InitModule("genguid", s_methods); } #pragma export off By the way, as of 2.3, the is a handy macro to help you with all that extern "C" stuff, so the end of that could be: PyMODINIT_FUNC initgenguid(void) { (void) Py_InitModule("genguid", s_methods); } with no need for the pragma. This is particularly usefull if you're writing a cross platform extension, as it will do the right thing on windows also. there is also a warning: genguid.cpp:10: warning: unused variable `bool result' but it works as is. -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 paul at fxtech.com Fri Jan 2 17:06:45 2004 From: paul at fxtech.com (Paul Miller) Date: Fri Jan 2 17:04:55 2004 Subject: [Pythonmac-SIG] building extensions for 2.3 (darwin build), and UUID generation In-Reply-To: <0F06E525-3D6D-11D8-9E37-000393A96660@noaa.gov> References: <6.0.1.1.2.20031231142920.04e05f40@mail.fxtech.com> <0F06E525-3D6D-11D8-9E37-000393A96660@noaa.gov> Message-ID: <6.0.1.1.2.20040102160548.02d0ae70@mail.fxtech.com> >Using Jack's hint, I got your module to compile, link and run! I think. I >have no idea what genguid is supposed to do. It does this: Wow - cool! Many thanks! FYI - I had actually just found a work-around. There happens to be a handy little program in /usr/bin called uuidgen, which does basically the same thing. I wrote a wrapper and called it with popen and it worked as a suitable replacement! But, good to know the setup.py trick for real code. Cheers! From bob at redivi.com Fri Jan 2 17:15:29 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 2 17:14:01 2004 Subject: [Pythonmac-SIG] building extensions for 2.3 (darwin build), and UUID generation In-Reply-To: <0F06E525-3D6D-11D8-9E37-000393A96660@noaa.gov> References: <0F06E525-3D6D-11D8-9E37-000393A96660@noaa.gov> Message-ID: <2C4EA2AE-3D71-11D8-996B-000A95686CD8@redivi.com> On Jan 2, 2004, at 4:46 PM, Chris Barker wrote: > Paul et all: > > Using Jack's hint, I got your module to compile, link and run! I > think. I have no idea what genguid is supposed to do. It does this: Cool, but why is it even C++? The equivalent C code wouldn't have ::namespace ::garbage all over it (actually that's all it should change other than the file's extension). genguid is supposed to create a new Globally Unique IDentifier.. typically a GUID generator will use your system's MAC address, the current time, a random number generator, etc. to make it very likely that the GUID is indeed globally unique. CoreFoundation uses GUIDs in a couple places, and they're extremely popular on win32 because COM depends on them. In fact, some OS X applications, typically the ones written in C++ by Apple that have plugins, force you to write plugins with COM. Contextual Menu plugins are the most prominent example that I can think of. -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/20040102/44587889/smime.bin From paul at fxtech.com Fri Jan 2 17:23:05 2004 From: paul at fxtech.com (Paul Miller) Date: Fri Jan 2 17:21:15 2004 Subject: [Pythonmac-SIG] building extensions for 2.3 (darwin build), and UUID generation In-Reply-To: <2C4EA2AE-3D71-11D8-996B-000A95686CD8@redivi.com> References: <0F06E525-3D6D-11D8-9E37-000393A96660@noaa.gov> <2C4EA2AE-3D71-11D8-996B-000A95686CD8@redivi.com> Message-ID: <6.0.1.1.2.20040102161958.02b00ec0@mail.fxtech.com> >>Using Jack's hint, I got your module to compile, link and run! I think. I >>have no idea what genguid is supposed to do. It does this: > >Cool, but why is it even C++? The equivalent C code wouldn't have >::namespace ::garbage all over it (actually that's all it should change >other than the file's extension). Not to start a language war here, but it's in C++ because I firmly believe that C++ is "a better C". I like being able to declare my variables at their point of first use, which is why that PARTICULAR code is in C++, trivial as it is. I don't write anything in plain C anymore. >genguid is supposed to create a new Globally Unique IDentifier.. typically >a GUID generator will use your system's MAC address, That extension module is needed for an AAF I/O system I am responsible for. AAF "objects" are tagged with UUIDs. Thanks again for both of your help! Alas, I thought this was the last hurdle to getting my code working, but it is not. We are using 4Suite for the XML Domlette stuff and unfortunately it doesn't seem to like Panther's Python. I can't get it to build. :-( If anyone has done this, I'd love to hear how you did it! From bob at redivi.com Fri Jan 2 19:24:00 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 2 19:22:26 2004 Subject: [Pythonmac-SIG] Building 4Suite on Panther (Mac OS X 10.3.x) Message-ID: <2073AB06-3D83-11D8-996B-000A95686CD8@redivi.com> There are two relatively small platform bugs in the 4Suite build process that prevent it from building properly on Panther. This is from looking at 1.0a3, not all of the tests passed and I don't have any experience with 4Suite to determine whether or not these are "expected" so I am not going to put it in my PackageManager repository yet. 1) It assumes a really brain-dead Python and tries to link it with -flat_namespace. That's not necessary nor desired (except MAYBE on OS X 10.2's awfully broken Python 2.2.0, but you don't need -flat_namespace if you use -bundle_loader). Edit Ft/Lib/DistExt/PackageManager.py and remove the code that adds '-flat_namespace' to the linker flags if the platform is 'darwin'. 2) It assumes that you can get a pointer to environ from a bundle/dylib, you can't. Change the "environ" trap in Ft/Server/Server/src/process.c to the following: #if !defined(_MSC_VER) && !defined(__APPLE__) && ( !defined(__WATCOMC__) || defined(__QNX__) ) extern char **environ; #elif defined(__APPLE__) #include #define environ (*_NSGetEnviron()) #endif /* !_MSC_VER */ -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/20040102/042272f2/smime.bin From ybifmvmsdnmutm at el-nacional.com Sat Jan 3 04:13:33 2004 From: ybifmvmsdnmutm at el-nacional.com (Mobley) Date: Sat Jan 3 06:18:32 2004 Subject: [Pythonmac-SIG] Re: KX, "who is registered Message-ID: arbitrary category credo diaper meat veldt carmela diamagnetism trailblaze debt madam comprehend airfare absinthe apostrophe taunt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040103/abd3614d/attachment.html From bvrim at tom.com Fri Jan 2 19:56:05 2004 From: bvrim at tom.com (Barr) Date: Sat Jan 3 08:04:05 2004 Subject: [Pythonmac-SIG] Re: CJNJBNIH, torments that still Message-ID: afforest diadem dynast submittal rattail applejack yucca argonne bore ciliate beatify conservative cohort diebold library tacit madam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040103/603c5e21/attachment.html From paul at fxtech.com Sat Jan 3 09:44:33 2004 From: paul at fxtech.com (Paul Miller) Date: Sat Jan 3 09:42:41 2004 Subject: [Pythonmac-SIG] Building 4Suite on Panther (Mac OS X 10.3.x) In-Reply-To: <2073AB06-3D83-11D8-996B-000A95686CD8@redivi.com> References: <2073AB06-3D83-11D8-996B-000A95686CD8@redivi.com> Message-ID: <6.0.1.1.2.20040103084247.054ee640@mail.fxtech.com> >There are two relatively small platform bugs in the 4Suite build process >that prevent it from building properly on Panther. This is from looking >at 1.0a3, not all of the tests passed and I don't have any experience with >4Suite to determine whether or not these are "expected" so I am not going >to put it in my PackageManager repository yet. Wow Bob - many thanks for looking into this. >1) It assumes a really brain-dead Python and tries to link it with >-flat_namespace. That's not necessary nor desired (except MAYBE on OS X >10.2's awfully broken Python 2.2.0, but you don't need -flat_namespace if >you use -bundle_loader). Edit Ft/Lib/DistExt/PackageManager.py and remove >the code that adds '-flat_namespace' to the linker flags if the platform >is 'darwin'. I couldn't find any -flat_namespace references in PackageManager.py. I do have 1.0a3. >2) It assumes that you can get a pointer to environ from a bundle/dylib, >you can't. Change the "environ" trap in Ft/Server/Server/src/process.c to >the following: This change I made and the setup process was able to complete. But when I try to use Ft.Xml.Domlette.Node, it fails to find the Node type. Assuming Node is implemented in the C code, could the first issue be causing the bundle not to load, thus it not being able to find Node? Any other ideas on fixing #1? From bob at redivi.com Sat Jan 3 10:22:32 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 3 10:21:07 2004 Subject: [Pythonmac-SIG] Building 4Suite on Panther (Mac OS X 10.3.x) In-Reply-To: <6.0.1.1.2.20040103084247.054ee640@mail.fxtech.com> References: <2073AB06-3D83-11D8-996B-000A95686CD8@redivi.com> <6.0.1.1.2.20040103084247.054ee640@mail.fxtech.com> Message-ID: On Jan 3, 2004, at 9:44 AM, Paul Miller wrote: >> There are two relatively small platform bugs in the 4Suite build >> process that prevent it from building properly on Panther. This is >> from looking at 1.0a3, not all of the tests passed and I don't have >> any experience with 4Suite to determine whether or not these are >> "expected" so I am not going to put it in my PackageManager >> repository yet. > > Wow Bob - many thanks for looking into this. > >> 1) It assumes a really brain-dead Python and tries to link it with >> -flat_namespace. That's not necessary nor desired (except MAYBE on >> OS X 10.2's awfully broken Python 2.2.0, but you don't need >> -flat_namespace if you use -bundle_loader). Edit >> Ft/Lib/DistExt/PackageManager.py and remove the code that adds >> '-flat_namespace' to the linker flags if the platform is 'darwin'. > > I couldn't find any -flat_namespace references in PackageManager.py. I > do have 1.0a3. It's in Ft/Lib/DistExt/BuildExt.py not Ft/Lib/DistExt/PackageManager.py.. sorry, must not have been paying attention. > >> 2) It assumes that you can get a pointer to environ from a >> bundle/dylib, you can't. Change the "environ" trap in >> Ft/Server/Server/src/process.c to the following: > > This change I made and the setup process was able to complete. But > when I try to use Ft.Xml.Domlette.Node, it fails to find the Node > type. Assuming Node is implemented in the C code, could the first > issue be causing the bundle not to load, thus it not being able to > find Node? > > Any other ideas on fixing #1? How about some example code that should work (but doesn't)? I don't know (or have a desire to learn) this API. -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/20040103/57f2a1f7/smime.bin From paul at fxtech.com Sat Jan 3 10:51:23 2004 From: paul at fxtech.com (Paul Miller) Date: Sat Jan 3 10:49:31 2004 Subject: [Pythonmac-SIG] Building 4Suite on Panther (Mac OS X 10.3.x) In-Reply-To: References: <2073AB06-3D83-11D8-996B-000A95686CD8@redivi.com> <6.0.1.1.2.20040103084247.054ee640@mail.fxtech.com> Message-ID: <6.0.1.1.2.20040103095045.050d4ec0@mail.fxtech.com> >>I couldn't find any -flat_namespace references in PackageManager.py. I do >>have 1.0a3. > >It's in Ft/Lib/DistExt/BuildExt.py not Ft/Lib/DistExt/PackageManager.py.. >sorry, must not have been paying attention. Ah, thanks. Didn't seem to make a difference though. >>Any other ideas on fixing #1? > >How about some example code that should work (but doesn't)? I don't know >(or have a desire to learn) this API. Nevermind - Looks like they got rid of one of the types, which has been subsumed into the base PyXML module. Seems to be working!! From bob at redivi.com Sat Jan 3 11:00:10 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 3 10:58:38 2004 Subject: [Pythonmac-SIG] Building 4Suite on Panther (Mac OS X 10.3.x) In-Reply-To: <6.0.1.1.2.20040103095045.050d4ec0@mail.fxtech.com> References: <2073AB06-3D83-11D8-996B-000A95686CD8@redivi.com> <6.0.1.1.2.20040103084247.054ee640@mail.fxtech.com> <6.0.1.1.2.20040103095045.050d4ec0@mail.fxtech.com> Message-ID: On Jan 3, 2004, at 10:51 AM, Paul Miller wrote: > >>> I couldn't find any -flat_namespace references in PackageManager.py. >>> I do have 1.0a3. >> >> It's in Ft/Lib/DistExt/BuildExt.py not >> Ft/Lib/DistExt/PackageManager.py.. sorry, must not have been paying >> attention. > > Ah, thanks. Didn't seem to make a difference though. Using -flat_namespace will make the runtime linking process slower and can make your runtime susceptible to a new class of unlikely (because people avoid using the same name for exported symbols in separate modules for other operating systems) but potential problems. It's not going to make any obvious difference, but you shouldn't use it except in some cases where you need binary compatibility with MacOS X 10.1 (or earlier). -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/20040103/b0985492/smime-0001.bin From joaoleao at gmx.net Sat Jan 3 12:47:15 2004 From: joaoleao at gmx.net (=?ISO-8859-1?Q?Jo=E3o_Le=E3o?=) Date: Sat Jan 3 12:49:22 2004 Subject: [Pythonmac-SIG] No '/System/.../include' Folder Message-ID: Hi list! I recently installed the MacPyton 2.3 for Panther addons. I followed the instructions and everything works fine as far as I tested. Using Package Manager i found that my instalation doesn't have the '/System/Library/Frameworks/Python.framework/Versions/2.3/include' folder. Is that serious? What should I do about that? I realised this only when I tried to follow the instructions in the 'WritableInclude' item in the PackMan list. No problem with the 'WritableBin' which let me install successfully several packages as PyGame, PyObj-C, PIL etc... Thanks. _ joao From Martina at Oefelein.de Sat Jan 3 12:59:46 2004 From: Martina at Oefelein.de (Martina Oefelein) Date: Sat Jan 3 12:59:54 2004 Subject: [Pythonmac-SIG] No '/System/.../include' Folder In-Reply-To: References: Message-ID: <9DE00566-3E16-11D8-8A50-000A957DBE94@Oefelein.de> Hi Joao, > Using Package Manager i found that my instalation doesn't have the > '/System/Library/Frameworks/Python.framework/Versions/2.3/include' > folder. > Is that serious? What should I do about that? It means that you don't have the Developer Tools installed. Just install them from the CD which came with MacOS X. ciao Martina From bob at redivi.com Sat Jan 3 13:07:47 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 3 13:06:20 2004 Subject: [Pythonmac-SIG] No '/System/.../include' Folder In-Reply-To: References: Message-ID: On Jan 3, 2004, at 12:47 PM, Jo?o Le?o wrote: > Hi list! > > I recently installed the MacPyton 2.3 for Panther addons. I followed > the instructions and everything works fine as far as I tested. > > Using Package Manager i found that my instalation doesn't have the > '/System/Library/Frameworks/Python.framework/Versions/2.3/include' > folder. > Is that serious? What should I do about that? > > I realised this only when I tried to follow the instructions in the > 'WritableInclude' item in the PackMan list. > No problem with the 'WritableBin' which let me install successfully > several packages as PyGame, PyObj-C, PIL etc... If you don't have that folder, then install Xcode.. and make sure to install the BSD SDK. I can't imagine why it wouldn't be there otherwise. -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/20040103/b9fa28e6/smime.bin From bulan at optonline.net Sat Jan 3 18:43:40 2004 From: bulan at optonline.net (bulan) Date: Sat Jan 3 18:43:48 2004 Subject: [Pythonmac-SIG] Looking for Free cable TV? Save $ now... w ekenis Message-ID: Hey I need cable so if you can send it like tomorrow that would be cool From hinsen at cnrs-orleans.fr Sun Jan 4 08:23:35 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Sun Jan 4 08:22:01 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac Message-ID: <200401041423.35532.hinsen@cnrs-orleans.fr> Having regular access to a Mac now, I would like to prepare Mac-friendly distributions of my scientific applications, all written in Python. The goal is to make them available to users who don't know nor care much about Python, so the installation procedure should be as simple as possible. At the moment I see two options: 1) Via fink. Very easy to do for me (so easy that I'll do it anyway), but my impression is that fink is not the Mac user's idea of user friendliness. 2) On top of MacPython using the package manager. That looks simpler for the users, but it seems to be a significant effort for me. I would have to provide a package directory on my Web server and prepare binary packages for all combinations of Python and MacOS versions, because automatic installation from source code doesn't work due to the header file installation problems (all my C modules are based on NumPy). I am not terribly enthusiastic about either option. Is there perhaps another one? My wish list is: - Simple installation for the user, via an installer or through simple file copy operations. - Possibility to prepare distributions for a wide range of machines having only a single one for packaging (MacOS 10.3.2, MacPython 2.3.3). - Automatic generation of distribution packages from the development source code. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From bob at redivi.com Sun Jan 4 08:53:46 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 4 08:52:25 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: <200401041423.35532.hinsen@cnrs-orleans.fr> References: <200401041423.35532.hinsen@cnrs-orleans.fr> Message-ID: <6A9C0016-3EBD-11D8-ACF7-000A95686CD8@redivi.com> On Jan 4, 2004, at 8:23 AM, Konrad Hinsen wrote: > Having regular access to a Mac now, I would like to prepare > Mac-friendly > distributions of my scientific applications, all written in Python. > The goal > is to make them available to users who don't know nor care much about > Python, > so the installation procedure should be as simple as possible. > > At the moment I see two options: > > 1) Via fink. Very easy to do for me (so easy that I'll do it anyway), > but my > impression is that fink is not the Mac user's idea of user > friendliness. Not the typical Mac user's idea of friendliness, but pretty popular in the scientific community. That may be just the ticket for your applications, whatever they are. > 2) On top of MacPython using the package manager. That looks simpler > for > the users, but it seems to be a significant effort for me. I would > have to > provide a package directory on my Web server and prepare binary > packages for all combinations of Python and MacOS versions, because > automatic installation from source code doesn't work due to the > header > file installation problems (all my C modules are based on NumPy). Package Manager is only good for distributing Python packages (as in a collection of Python modules/extensions), not applications. It doesn't sound like you're trying to distribute Python packages, because "users who don't know nor care much about Python" aren't going to have any use for them. > I am not terribly enthusiastic about either option. Is there perhaps > another > one? My wish list is: > > - Simple installation for the user, via an installer or through simple > file > copy operations. > - Possibility to prepare distributions for a wide range of machines > having > only a single one for packaging (MacOS 10.3.2, MacPython 2.3.3). > - Automatic generation of distribution packages from the development > source code. Why don't you tell us what your applications are and how they are used? It makes a difference. For example, if the applications are X11 based or have no GUI you're probably better off just trying to get them in Fink. However, if the applications have some sort of native GUI you may want to distribute application bundles with an embedded version of Python and any included extensions, since you can't depend on them being installed and Apple doesn't provide Python 2.3.3 with any version of Mac OS X. -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/20040104/bb06fa8a/smime.bin From Jack.Jansen at cwi.nl Sun Jan 4 17:44:14 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Jan 4 17:44:18 2004 Subject: [Pythonmac-SIG] How does the XCode documentation index work? Message-ID: <85607B83-3F07-11D8-B56A-000A27B19B96@cwi.nl> Does anyone know whether I can access the index that XCode uses to search the Apple Developer documentation? The IDE has a function "Lookup in Apple Developer Documentation", and that worked reasonable under 10.2, but under 10.3 it doesn't work: it usually returns the "nothing found" page. And if I type in API call names in Help Viewer directly I also get no hits. But XCode apparently uses a different index, it can find API calls pretty well. Unfortunately I can't seem to find the right OSA invocations to make XCode display help for me. I'd like to get the functionality back of looking things up in the developer help, either through Help Viewer or through XCode, but I can't seem to find a way to do it. Any suggestions? -- 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 Jack.Jansen at cwi.nl Sun Jan 4 18:01:34 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Jan 4 18:01:38 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: <200401041423.35532.hinsen@cnrs-orleans.fr> References: <200401041423.35532.hinsen@cnrs-orleans.fr> Message-ID: On 4-jan-04, at 14:23, Konrad Hinsen wrote: > Having regular access to a Mac now, I would like to prepare > Mac-friendly > distributions of my scientific applications, all written in Python. > The goal > is to make them available to users who don't know nor care much about > Python, > so the installation procedure should be as simple as possible. Konrad, if you really mean "applications", as in turnkey standalone things to be run by end users, the neither fink nor Package Manager are the best solution to your problem. What I think the best solution would be is to first package your application with everything it needs. Bundlebuilder is the tool you want to look at for this, it packages everything up into a single ".app" bundle, which looks like one file to the end user. There's one slight problem: if you want your applications to run on both 10.2 and 10.3 you will have to create it on 10.2 right now. Create the application with --standalone, and it will include everything it needs, including all the bits of Python that you use. If 10.3 only is good enough: create the application on 10.3 and *don't* use --standalone, and it will use the standard MacPython that Apple supplies. The app will be quite a bit smaller too. You can create 10.2-compatible apps on 10.3, but it is a bit difficult right now. Even if your applications are programs to be run from a Terminal window I think I would use bundlebuilder, after hacking the bootstrap script that it uses to run Python in a Terminal window in stead of directly. After you've created your application the standard "installer" for MacOSX is simply a disk image with the application: people drag and drop it to where they want to have it. If your installer needs to do more you can look at either Apple's PackageMaker tool, or the somewhat equivalent Mac/scripts/buildpkg.py script in a Python source distribution. -- 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 njriley at uiuc.edu Sun Jan 4 20:24:44 2004 From: njriley at uiuc.edu (Nicholas Riley) Date: Sun Jan 4 20:24:50 2004 Subject: [Pythonmac-SIG] How does the XCode documentation index work? In-Reply-To: <85607B83-3F07-11D8-B56A-000A27B19B96@cwi.nl> References: <85607B83-3F07-11D8-B56A-000A27B19B96@cwi.nl> Message-ID: <20040105012444.GA9108@uiuc.edu> On Sun, Jan 04, 2004 at 11:44:14PM +0100, Jack Jansen wrote: > Does anyone know whether I can access the index that XCode uses to > search the Apple Developer documentation? > > The IDE has a function "Lookup in Apple Developer Documentation", and > that worked reasonable under 10.2, but under 10.3 it doesn't work: it > usually returns the "nothing found" page. And if I type in API call > names in Help Viewer directly I also get no hits. > > But XCode apparently uses a different index, it can find API calls > pretty well. Unfortunately I can't seem to find the right OSA > invocations to make XCode display help for me. >From the Xcode release notes: * The developer documentation released with Panther (Mac OS X 10.3) had a problem that prevented full-text searches of the Tools group in the documentation window from finding anything outside of the release notes. Thus, search results from the Xcode, gcc, make, and related tools documentation were never returned. To enable searching of the primary tools documentation, run this command in a Terminal window: sudo ln -s /Developer/Documentation/DeveloperTools/DeveloperTools\ idx /Developer/Documentation/DeveloperTools/Tools\ idx In subsequent releases of the developer documentation, this problem has been solved. (If /Developer/Documentation/DeveloperTools/Tools idx exists on your system, there's no need to run the command above.) I have found the documentation window in Xcode very useful and have largely switched to using it instead of Safari/LaunchBar for documentation lookups. It also refers to using /Developer/Tools/pbhelpindexer, which is a very long and involved zsh script with lots of special cases. Good luck... -- =Nicholas Riley | From hinsen at cnrs-orleans.fr Mon Jan 5 05:57:18 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Mon Jan 5 05:57:40 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: References: <200401041423.35532.hinsen@cnrs-orleans.fr> Message-ID: On 05.01.2004, at 00:01, Jack Jansen wrote: > What I think the best solution would be is to first package your > application with everything it needs. Bundlebuilder is the tool you > want to look at for this, it packages everything up into a single > ".app" bundle, which looks like one file to the end user. There's one > slight Thanks, that sounds like what I want! > problem: if you want your applications to run on both 10.2 and 10.3 > you will have to create it on 10.2 right now. Create the application > with --standalone, and it will include everything it needs, including > all the bits of Python that you use. If 10.3 only is good enough: > create the application on 10.3 and *don't* use --standalone, and it > will use the standard MacPython that Apple supplies. The app will be > quite a bit smaller too. You can create 10.2-compatible apps on 10.3, > but it is a bit difficult right now. I guess I'll go for 10.3 only then and tell the others to use Fink. Perhaps I could ask Apple for subsidies for that approach ;-) > Even if your applications are programs to be run from a Terminal > window I think I would use bundlebuilder, after hacking the bootstrap > script that it uses to run Python in a Terminal window in stead of > directly. The applications use Tk, and the users I have in mind at the moment don't even know what Python is. Will those bundles include Tk as well? Konrad. From hinsen at cnrs-orleans.fr Mon Jan 5 06:03:48 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Mon Jan 5 06:03:56 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: <6A9C0016-3EBD-11D8-ACF7-000A95686CD8@redivi.com> References: <200401041423.35532.hinsen@cnrs-orleans.fr> <6A9C0016-3EBD-11D8-ACF7-000A95686CD8@redivi.com> Message-ID: On 04.01.2004, at 14:53, Bob Ippolito wrote: > Package Manager is only good for distributing Python packages (as in a > collection of Python modules/extensions), not applications. It > doesn't sound like you're trying to distribute Python packages, > because "users who don't know nor care much about Python" aren't going > to have any use for them. It's a bit more complicated than that. I have a couple of libraries that contain all of the computational stuff. Then I have some Tk applications for those who wouldn't touch a text editor. The applications contain little more than the Tk interface. It happens that users start with the Tk applications and then get sufficiently motivated to look at Python and my libraries. Ideally, they would then have them available ready to use already. For Linux, I distribute RPMs for the libraries and the applications, and I was looking for the closest equivalent under MacOS. That seems to be fink, except that it doesn't seem to have the same popularity. > sort of native GUI you may want to distribute application bundles with > an embedded version of Python and any included extensions, since you > can't depend on them being installed and Apple doesn't provide Python > 2.3.3 with any version of Mac OS X. > The Python version is not critical, all my stuff still works with 1.5.2. Konrad. From aleaxit at yahoo.com Mon Jan 5 06:49:08 2004 From: aleaxit at yahoo.com (Alex Martelli) Date: Mon Jan 5 06:49:14 2004 Subject: [Pythonmac-SIG] hi, everybody! Message-ID: <200401051249.08356.aleaxit@yahoo.com> Hi there, folks -- I just joined this mailing list. I'm quite experienced with Python (and other programming languages and technologies, and Unix-y systems in general, including BSD dialects), but a total newbie to the Mac, having just bought my very first ever for Christmas (12" iBook G4 -- I think I've installed all current SW and upgrades, incl. OSX 10.3.2, the latest Apple developer tools, fink, Apple's X11 1.0, TclTkAqua, MacPython and everything in the standard package db, etc, etc). I'm slowly starting to learn about the dazzling arrays of new-to-me technologies. Can anybody suggests a good tutorial/with/examples for me to learn to use Python for OSA/AppleScript tasks? I'd rather learn as little as possible about AppleScript itself as a language, but I assume I'll have to learn & understand at least something about "AppleEvents" and the like. Thanks! Alex From Jack.Jansen at cwi.nl Mon Jan 5 06:54:33 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jan 5 06:53:47 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: References: <200401041423.35532.hinsen@cnrs-orleans.fr> Message-ID: On 5-jan-04, at 11:57, Konrad Hinsen wrote: > > I guess I'll go for 10.3 only then and tell the others to use Fink. > Perhaps I could ask Apple for subsidies for that approach ;-) > [...] > The applications use Tk, and the users I have in mind at the moment > don't even know what Python is. > > Will those bundles include Tk as well? I've never tried it, but it should work. If you're going for 10.3 only you should probably use the --semi-standalone option to bundlebuilder (include all your python modules, but assume anything in the standard Python lib is available on the target system). You can add third-party frameworks and libraries (such as the Tcl/Tk stuff) with the --lib option. Please let us know whether it works, -- 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 skip at pobox.com Mon Jan 5 07:15:37 2004 From: skip at pobox.com (Skip Montanaro) Date: Mon Jan 5 07:15:49 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: References: <200401041423.35532.hinsen@cnrs-orleans.fr> <6A9C0016-3EBD-11D8-ACF7-000A95686CD8@redivi.com> Message-ID: <16377.21865.919316.699198@montanaro.dyndns.org> Konrad> For Linux, I distribute RPMs for the libraries and the Konrad> applications, and I was looking for the closest equivalent under Konrad> MacOS. That seems to be fink, except that it doesn't seem to Konrad> have the same popularity. As someone else mentioned, many people doing scientific work on Macs already use fink. If you take a look at the list of relevant libraries which have been ported (atlas, scipy, scilab, scientificpython , etc), I think you'll see why. Skip From hinsen at cnrs-orleans.fr Mon Jan 5 07:44:31 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Mon Jan 5 07:44:56 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: <16377.21865.919316.699198@montanaro.dyndns.org> References: <200401041423.35532.hinsen@cnrs-orleans.fr> <6A9C0016-3EBD-11D8-ACF7-000A95686CD8@redivi.com> <16377.21865.919316.699198@montanaro.dyndns.org> Message-ID: On 05.01.2004, at 13:15, Skip Montanaro wrote: > As someone else mentioned, many people doing scientific work on Macs > already > use fink. If you take a look at the list of relevant libraries which > have > been ported (atlas, scipy, scilab, scientificpython , etc), I > think > you'll see why. > Sure, those are people like me. But many of my users are biologists who use computers only for typing. I have a really nice collection of support questions. The best among the recent ones was a Windows user who I explained that he needed a C compiler to use my libraries. He then wrote back asking if he could perhaps "do the compilation by hand" instead of installing a compiler, and asked me for instructions for manual compilation ;-) I will certainly put my stuff on fink, but I will also try to make a nice bundle. Konrad. From bob at redivi.com Mon Jan 5 07:58:12 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 5 07:56:55 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: <200401051249.08356.aleaxit@yahoo.com> References: <200401051249.08356.aleaxit@yahoo.com> Message-ID: On Jan 5, 2004, at 6:49 AM, Alex Martelli wrote: > Hi there, folks -- I just joined this mailing list. I'm quite > experienced > with Python (and other programming languages and technologies, and > Unix-y systems in general, including BSD dialects), but a total newbie > to the Mac, having just bought my very first ever for Christmas (12" > iBook > G4 -- I think I've installed all current SW and upgrades, incl. OSX > 10.3.2, > the latest Apple developer tools, fink, Apple's X11 1.0, TclTkAqua, > MacPython and everything in the standard package db, etc, etc). I'm > slowly starting to learn about the dazzling arrays of new-to-me > technologies. Can anybody suggests a good tutorial/with/examples > for me to learn to use Python for OSA/AppleScript tasks? I'd rather > learn as little as possible about AppleScript itself as a language, but > I assume I'll have to learn & understand at least something about > "AppleEvents" and the like. Thanks! Welcome to the community, Alex. It's good to see that yet another large contributor to the Python (and PyPy) community has been tempted ;) There's (no less than) four ways to do OSA/AppleScript tasks via Python - low level and raw (this would mostly be in the Carbon.AE / Carbon.AppleEvents pair, it's abstracted by the other three) - via the standard library gensuitemodule stuff (to be deprecated soonish in favor of AppScripting and/or aeve) - AppScripting : http://freespace.virgin.net/hamish.sanderson/appscripting.html - aeve : http://undefined.org/python/#aeve The current version of AppScripting probably supports more applications and has better documentation than the current version of aeve, however I have a new version of aeve to be released Very Soon Now (this month, probably 1-2 weeks) that's significantly different (at least internally) from what's out there now. Your best bet is to get AppScripting and/or aeve and plug away. If you run into any problems with any approach, it is appropriate to ask this list or the module author, but any python-on-the-mac question is welcome here. You will need a familiarity with Script Editor (/Applications/AppleScript/Script Editor), particularly the "Open Dictionary" command, and some of the AppleScript syntax. The biggest thing is that AppleScript "evaluates" from right to left (the name of the first playlist of the first library) rather than Python's left to right (library.first.playlist.first.name). AppleScript is also extremely lazy about evaluation and does a lot of type adaptation behind the scenes, which can cause some impedance mismatch with Python. Apple Events are a kind of RPC used to pass around "serialized objects". Typically Apple Events are passed around between processes on the same machine, but the mechanisms exist to do it over a network (but are turned off by default in OS X for security reasons). These serialized objects have a target (a process id, basically), a command (get, set, play track, quit, open, new, etc), and arguments to a command. The target (or runtime) will pass back a serialized object (an error, list, nothing, integer, string, reference, etc) as a result. All of this is strongly typed and carries around a simple form of RTTI. In the Apple world, the run time typing information associated with this serialization in the form of a four character code such as '8BIM' or 'hook'. They are literally four-chars-as-a-little-endian-32bit-integer, and generally stick to the ASCII range (but sometimes have a \x00 or two). The kind of objects you can pass around are pretty rich, and are a mix of value objects (strings, integers, lists, etc) and reference objects ("the desktop" -- a property reference of the Application subclass, if you're talking to Finder). Apple Events are not particularly human readable, but AppleScript is. It is highly likely that an application that has worthwhile scripting support has a "terminology" resource, which is sort of like a C header file full of #define's. They map human-readable names and documentation (including additional type information) to four character codes, but there is no guarantee that the terminology is actually correct (though they often are). These terminologies and an extremely simple runtime are basically what AppleScript is, and the three high level Apple Event wrappers for Python (gensuitemodule, AppScripting, aeve) consist primarily of code that tries to locate, decode, and translate these terminologies into something that can be easily used from Python. Fortunately, all this said, you probably don't need to know much of anything about Apple Events to take advantage of them as a client of scriptable applications. In addition to the standard PackageManager database (maintained by Jack), there is a separately maintained (by me) "experimental" package database at http://undefined.org/python/pimp/ -- which has some software that is not in the standard database or has non-standard compilation options (such as Numeric compiled against Apple's vecLib, which means Altivec acceleration for some operations on that shiny new G4). You should also take a good look at PyObjC ( http://pyobjc.sf.net/ ), which is the runtime bridge between Objective C and Python, that lets you rather seamlessly take advantage of just about any Objective C framework with the convenience of Python. This means that you can write Python applications using Apple's flagship Cocoa UI framework, and even use Interface Builder to build the GUIs. -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/20040105/3af74cf0/smime-0001.bin From bob at redivi.com Mon Jan 5 11:14:36 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 5 11:13:00 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: References: <200401051249.08356.aleaxit@yahoo.com> Message-ID: <41CF4C05-3F9A-11D8-90C9-000A95686CD8@redivi.com> On Jan 5, 2004, at 7:58 AM, Bob Ippolito wrote: > There's (no less than) four ways to do OSA/AppleScript tasks via Python Just FYI, all of this information has been slightly edited/formatted and injected into the pythonmac.org wiki ( http://pythonmac.org/wiki/AppleScript ) at Jack's request. I'll add a FAQ ( http://pythonmac.org/wiki/FAQ ) entry later. -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/20040105/a5464160/smime.bin From Chris.Barker at noaa.gov Mon Jan 5 13:23:06 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Jan 5 13:33:27 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: <16377.21865.919316.699198@montanaro.dyndns.org> References: <200401041423.35532.hinsen@cnrs-orleans.fr> <6A9C0016-3EBD-11D8-ACF7-000A95686CD8@redivi.com> <16377.21865.919316.699198@montanaro.dyndns.org> Message-ID: <3FF9AB8A.3080100@noaa.gov> Skip Montanaro wrote: > As someone else mentioned, many people doing scientific work on Macs already > use fink. If you take a look at the list of relevant libraries which have > been ported (atlas, scipy, scilab, scientificpython , etc), I think > you'll see why. FWIW, I use Macs for scientific work, and use Linux as my preferred system, and still don't like fink, and have managed to avoid it so far. I highly commend Konrad for looking for a "Macish" installation option. By the way, welcome Konrad and Alex -- I really look forward to your participation on this list. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker at noaa.gov Mon Jan 5 13:30:05 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Jan 5 13:40:25 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: <200401041423.35532.hinsen@cnrs-orleans.fr> References: <200401041423.35532.hinsen@cnrs-orleans.fr> Message-ID: <3FF9AD2D.60603@noaa.gov> Konrad Hinsen wrote: > because > automatic installation from source code doesn't work due to the header > file installation problems (all my C modules are based on NumPy). What's the problem? while the headers are not included in the binary install of Numeric, they are included in the source install (aren't they? -- they used to be, and certainly should be). If your users install both eh source and binary Numeric packages, they should get the headers and not have to compile Numeric. The only downside is that they might get scared away by the "source" concept, and they'll have a bunch of extra code lying around that they don't need. By the way, IIRC, Jack had a good reason to not include the headers as part of the binary package, but I don't' recall what it is.. personally, I'd like to see that. I have no particular desire to compile Numeric for myself, but I do need to compile against the headers, and I think that's a pretty common use case for Numeric. The general argument is that if you are compiling custom extensions, you know enough to compile Numeric, but with distutils, it is so easy to compile extensions, I'm not sure that logic holds anymore. -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 Jan 5 14:04:27 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 5 14:02:53 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: <3FF9AD2D.60603@noaa.gov> References: <200401041423.35532.hinsen@cnrs-orleans.fr> <3FF9AD2D.60603@noaa.gov> Message-ID: On Jan 5, 2004, at 1:30 PM, Chris Barker wrote: > Konrad Hinsen wrote: >> because >> automatic installation from source code doesn't work due to the >> header >> file installation problems (all my C modules are based on NumPy). > > What's the problem? while the headers are not included in the binary > install of Numeric, they are included in the source install (aren't > they? -- they used to be, and certainly should be). If your users > install both eh source and binary Numeric packages, they should get > the headers and not have to compile Numeric. The only downside is that > they might get scared away by the "source" concept, and they'll have a > bunch of extra code lying around that they don't need. The real downside is the fact they need to install Xcode / Developer Tools. From PackageManager it's hard to perceive any difference between installing from source or binary (other than the package name and compilation time of course). The headers are surely "included" in the source install, but I'm not sure if Jack has the WriteableInclude (yes, writable is consistently spelled wrong in PackageManager world) dependency enabled for the source build. If he does not have this enabled, it's possible that the setup.py will install everything it can, but fail to install the headers due to permission issues. > By the way, IIRC, Jack had a good reason to not include the headers as > part of the binary package, but I don't' recall what it is.. > personally, I'd like to see that. I have no particular desire to > compile Numeric for myself, but I do need to compile against the > headers, and I think that's a pretty common use case for Numeric. The > general argument is that if you are compiling custom extensions, you > know enough to compile Numeric, but with distutils, it is so easy to > compile extensions, I'm not sure that logic holds anymore. The good reason is that the include folder is writable only by root, so it's easier for the user to skip the includes. The sudo chmod must be explicitly done from the Terminal, and PackageManager's error reporting (for the "missing" WriteableInclude dependency) is rather minimal and unintuitive it's better to just avoid them whenever possible. -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/20040105/b57beb58/smime.bin From jpetrone at cnri.reston.va.us Mon Jan 5 15:35:53 2004 From: jpetrone at cnri.reston.va.us (Jason Petrone) Date: Mon Jan 5 15:36:00 2004 Subject: [Pythonmac-SIG] Re: hi, everybody! In-Reply-To: <200401051249.08356.aleaxit@yahoo.com> References: <200401051249.08356.aleaxit@yahoo.com> Message-ID: <20040105203553.GA11333@cnri.reston.va.us> On Mon, Jan 05, 2004 at 12:49:08PM +0100, Alex Martelli wrote: > Hi there, folks -- I just joined this mailing list. I'm quite experienced > with Python (and other programming languages and technologies, and > Unix-y systems in general, including BSD dialects), but a total newbie > to the Mac, having just bought my very first ever for Christmas (12" iBook > G4 -- I think I've installed all current SW and upgrades, incl. OSX 10.3.2, > the latest Apple developer tools, fink, Apple's X11 1.0, TclTkAqua, > MacPython and everything in the standard package db, etc, etc). I'm > slowly starting to learn about the dazzling arrays of new-to-me > technologies. Can anybody suggests a good tutorial/with/examples > for me to learn to use Python for OSA/AppleScript tasks? I'd rather > learn as little as possible about AppleScript itself as a language, but > I assume I'll have to learn & understand at least something about > "AppleEvents" and the like. Thanks! I understand your apprehension about learning AppleScript, and maybe as a Python luminary that makes sense for you. But for me, learning at least a little AppleScript was vital, because it was too difficult to figure out what to do in Python just from looking at AppleScript dictionaries and example code. Aside from Apple's docs, I really like this site(at my alma mater no less): http://wilbur.acm.uiuc.edu/afs/sig/macwarriors/www/applescript/ jason From jwblist at olympus.net Mon Jan 5 15:42:02 2004 From: jwblist at olympus.net (John W. Baxter) Date: Mon Jan 5 15:43:01 2004 Subject: [Pythonmac-SIG] Distributing Python applications for the Mac In-Reply-To: Message-ID: On 1/5/2004 11:04, "Bob Ippolito" wrote: > The headers are surely "included" in > the source install, but I'm not sure if Jack has the WriteableInclude > (yes, writable is consistently spelled wrong in PackageManager world) > dependency enabled for the source build. Well, writable is wrongly spelt in English. Spelled without the inner "e", it should be pronounced with a short i, and would have something to do with the modified object being able to have writs served upon it. Oh, well. [Our English heritage includes wild spelling changes (viz Chaucer versus the present)...Shakespeare spelled his name many different ways, including at least one instance of the rather far afield "Wilm Shaxby".] --John From jwblist at olympus.net Mon Jan 5 15:50:28 2004 From: jwblist at olympus.net (John W. Baxter) Date: Mon Jan 5 15:50:49 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: <200401051249.08356.aleaxit@yahoo.com> Message-ID: On 1/5/2004 3:49, "Alex Martelli" wrote: > Hi there, folks -- I just joined this mailing list. I'm quite experienced > with Python Hi, Alex, and welcome. Bob has dealt with you query much better than I could have. I think it fair to point out to those of the group who don't know that your comment above is rather an understatement...you're an important, long-time part of the Python community, which owes much to you. --John From hinsen at cnrs-orleans.fr Mon Jan 5 17:20:07 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Mon Jan 5 17:20:22 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: <200401051249.08356.aleaxit@yahoo.com> References: <200401051249.08356.aleaxit@yahoo.com> Message-ID: <51748CC3-3FCD-11D8-8FB7-000A95AB5F10@cnrs-orleans.fr> On 05.01.2004, at 12:49, Alex Martelli wrote: > to the Mac, having just bought my very first ever for Christmas (12" > iBook > G4 -- I think I've installed all current SW and upgrades, incl. OSX > 10.3.2, That must be a virus - I did just the same (not "Christmas" but "end-of-yearly-budget spending frenzy", but the result is the same). Welcome to the club ;-) I find the iBook positively addictive. I got one because of the nice combination of size, weight, and autonomy, but I find myself prefer it to my desktop machine more and more because the iBook is so silent. Konrad. From piwfpzxg at india.com Mon Jan 5 06:43:41 2004 From: piwfpzxg at india.com (Navarro Porfirio) Date: Mon Jan 5 18:46:28 2004 Subject: [Pythonmac-SIG] Re: KASXSZKB, things caught fire Message-ID: austria slavonic stun erudition nonchalant pancreatic slang rime squawk allan sphinx lawbreaking imposition earth almanac seepage crimp whee herr broaden choke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040105/bbf64f33/attachment.html From paul.sargent at dsl.pipex.com Mon Jan 5 20:05:06 2004 From: paul.sargent at dsl.pipex.com (Paul Sargent) Date: Mon Jan 5 20:05:23 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: <51748CC3-3FCD-11D8-8FB7-000A95AB5F10@cnrs-orleans.fr> References: <200401051249.08356.aleaxit@yahoo.com> <51748CC3-3FCD-11D8-8FB7-000A95AB5F10@cnrs-orleans.fr> Message-ID: <5DBA7524-3FE4-11D8-808C-000A95C5A776@dsl.pipex.com> On 5 Jan 2004, at 22:20, Konrad Hinsen wrote: > On 05.01.2004, at 12:49, Alex Martelli wrote: > >> to the Mac, having just bought my very first ever for Christmas (12" >> iBook >> G4 -- I think I've installed all current SW and upgrades, incl. OSX >> 10.3.2, > > That must be a virus - I did just the same (not "Christmas" but > "end-of-yearly-budget spending frenzy", but the result is the same). > Welcome to the club ;-) > > I find the iBook positively addictive. I got one because of the nice > combination of size, weight, and autonomy, but I find myself prefer it > to my desktop machine more and more because the iBook is so silent. > I've gone and done the same thing. Bought myself the G4 iBook a couple of months back. First Mac... just joined the list. Good to know I'm in not alone in my madness. And Alex. Thanks for "Python in a Nutshell". It's my python bible. :-) -------------- 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/20040106/8de41308/PGP-0001.bin From bob at redivi.com Mon Jan 5 20:26:01 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 5 20:24:27 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: <5DBA7524-3FE4-11D8-808C-000A95C5A776@dsl.pipex.com> References: <200401051249.08356.aleaxit@yahoo.com> <51748CC3-3FCD-11D8-8FB7-000A95AB5F10@cnrs-orleans.fr> <5DBA7524-3FE4-11D8-808C-000A95C5A776@dsl.pipex.com> Message-ID: <499EC290-3FE7-11D8-A8F3-000A95686CD8@redivi.com> On Jan 5, 2004, at 8:05 PM, Paul Sargent wrote: > On 5 Jan 2004, at 22:20, Konrad Hinsen wrote: > >> On 05.01.2004, at 12:49, Alex Martelli wrote: >> >>> to the Mac, having just bought my very first ever for Christmas (12" >>> iBook >>> G4 -- I think I've installed all current SW and upgrades, incl. OSX >>> 10.3.2, >> >> That must be a virus - I did just the same (not "Christmas" but >> "end-of-yearly-budget spending frenzy", but the result is the same). >> Welcome to the club ;-) >> >> I find the iBook positively addictive. I got one because of the nice >> combination of size, weight, and autonomy, but I find myself prefer >> it to my desktop machine more and more because the iBook is so >> silent. >> > I've gone and done the same thing. Bought myself the G4 iBook a couple > of months back. > First Mac... just joined the list. Good to know I'm in not alone in my > madness. WARNING: I "switched" just a little over 2 years ago and I've personally bought three powermacs (G4-400 on ebay, G4-867 used from a friend, G5-2x2ghz), two powerbooks (667mhz, 1ghz 15"), two iPods (5g and 20g), and an iSight. I've also spent far too much of my life figuring out OS X / Darwin quirks, porting software to the platform, and wrapping Apple's C libraries with Python. And worst of all, my personal experience probably pales in comparison to the amount of Apple I've inflicted on other people through evangelism of OS X and MacPython and standardizing on the platform for desktops at work (we're about 75% OS X, the rest is XP). -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/20040105/bec85c04/smime.bin From krjackson at lbl.gov Mon Jan 5 23:03:03 2004 From: krjackson at lbl.gov (Keith Jackson) Date: Mon Jan 5 23:03:12 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: <499EC290-3FE7-11D8-A8F3-000A95686CD8@redivi.com> Message-ID: <39AD201D-3FFD-11D8-97E7-000A9577489A@lbl.gov> Well on the plus side Bob, I switched a year ago, and *really* appreciate yours and others on this lists efforts. I've also spent way to much time figuring out OSX / Darwin, MachO link format, and doing ports, but your efforts have saved me considerable amounts of time. just thought I'd say thanks, --keith On Monday, January 5, 2004, at 05:26 PM, Bob Ippolito wrote: > WARNING: > > I "switched" just a little over 2 years ago and I've personally bought > three powermacs (G4-400 on ebay, G4-867 used from a friend, > G5-2x2ghz), two powerbooks (667mhz, 1ghz 15"), two iPods (5g and 20g), > and an iSight. I've also spent far too much of my life figuring out > OS X / Darwin quirks, porting software to the platform, and wrapping > Apple's C libraries with Python. > > And worst of all, my personal experience probably pales in comparison > to the amount of Apple I've inflicted on other people through > evangelism of OS X and MacPython and standardizing on the platform for > desktops at work (we're about 75% OS X, the rest is XP). From aleaxit at yahoo.com Tue Jan 6 11:35:14 2004 From: aleaxit at yahoo.com (Alex Martelli) Date: Tue Jan 6 11:35:24 2004 Subject: [Pythonmac-SIG] the iBook's irresistible charms In-Reply-To: References: Message-ID: <4DBB5573-4066-11D8-9670-000A95EFAE9E@yahoo.com> Paul Sargent writes: >>> to the Mac, having just bought my very first ever for Christmas (12" >>> iBook >>> G4 -- I think I've installed all current SW and upgrades, incl. OSX >>> 10.3.2, >> >> That must be a virus - I did just the same (not "Christmas" but >> "end-of-yearly-budget spending frenzy", but the result is the same). >> Welcome to the club ;-) >> >> I find the iBook positively addictive. I got one because of the nice >> combination of size, weight, and autonomy, but I find myself prefer >> it to my desktop machine more and more because the iBook is so >> silent. Oh yes! And, in my case, preferring it to other laptops because the screen is crystal-sharp, the low weight makes it comfortable on my lap as I curl up in my favourite armchair, the battery's long life and the Airport Extreme together free me from cables, the sleep functionality works flawlessly (which it doesn't on my Linux laptops, natch), etc etc (starting to sound like an Apple testimonial, I realize!-). With X working so well, too, I'm more and more ssh -X'ing into my other machines and staying right here in my nice armchair rather than walking over to my study...!-) [[now what I _really_ need is a good port of OO.o 1.1, with PyUNO scripting and all... 1.0.3 just doesn't cut it, and I sure ain't gonna splurge on MS Office X...]] > I've gone and done the same thing. Bought myself the G4 iBook a couple > of months back. > First Mac... just joined the list. Good to know I'm in not alone in my > madness. Anything BUT alone, I'd say -- the iBook's price/functionality ratio is really irresistible these days. I had a confirmation of that just yesterday while reading an Italian magazine, "Portatile e Wireless" -- of all the excellent-quality laptops they recommend in their buying-suggestions, the iBook, at EUR 1199 entry price VAT included, is the *cheapest* one! Actually, I think it's a clever "loss leader" kind of move from Apple (not that I imagine they're making an actual LOSS on it, just not the same kinds of gross profit margins they have elsewhere on their product line) to attract new-to-the-Mac buyers... together with Mac OS X's allure to Unix-savvy buyers, etc, etc, it sure seems to be working... e.g., while until a few days ago my sights for "a future 64-bit-CPU machine" were firmly fixed on AMD-64 boxes, right now a Powermac G5 _is_ starting to look very alluring (even though _its_ price/performance ratio vs cheap AMD-64 boxes isn't really all that good...)! Of course, such things are also contagious -- the many brand-new Mac laptops I saw in use at various conferences and pypy sprints in 2003 (WAY more than I saw in 2002) was definitely part of what prompted me to start looking; and right now I'm looking for SOME excuse to write about how wonderfully well Python runs on the Mac (and what a great machine the Mac is:-), which in turn may help their sales further...:-). > And Alex. Thanks for "Python in a Nutshell". It's my python bible. :-) Why, thanks for the kudos! Alex From aleaxit at yahoo.com Tue Jan 6 11:46:40 2004 From: aleaxit at yahoo.com (Alex Martelli) Date: Tue Jan 6 12:03:15 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: Message-ID: Jason Petrone writes: >> technologies. Can anybody suggests a good tutorial/with/examples >> for me to learn to use Python for OSA/AppleScript tasks? I'd rather >> learn as little as possible about AppleScript itself as a language, >> but >> I assume I'll have to learn & understand at least something about >> "AppleEvents" and the like. Thanks! > > I understand your apprehension about learning AppleScript, and maybe as > a Python luminary that makes sense for you. But for me, learning at Well, it's not so much "apprehension", but rather a case of there being SO many important things to learn, that one englishy-syntax, proprietary, non-cross-platform, apparently-feeblish scripting language, per se, wasn't high on my to-do list. However, studying it may still well be the best approach, of course. > least a little AppleScript was vital, because it was too difficult to > figure out what to do in Python just from looking at AppleScript > dictionaries and example code. Yeah, much as I found I really had to learn Visual Basic back when I was serving time on Windows to actually make use of Automation (aka COM aka OLE Automation) -- all of the docs for various applications' object models being SO oriented to VB (or VBA or VBScript), I really needed to grok some VB to grasp what they were saying (originally to develop the COM/OLE integration for a proprietary scripting language and the commercial applications of my employer, later to use Automation from Perl, later still Python...). > Aside from Apple's docs, I really like this site(at my alma mater no > less): > http://wilbur.acm.uiuc.edu/afs/sig/macwarriors/www/applescript/ Thanks for the tip! Looks like a really neat site and I've added it to my fast-growing list of Safari bookmarks...:-). (BTW, as an aside: what Mac OS X newsreader would y'all suggest? I've just downloaded MT-NewsWatcher, basically guessing among the available ones, but I really have no idea which ones are worthwhile on this platform... sorry for the OT, but maybe I can find a Python-scriptable one to make this back ontopic...:-). Alex From aleaxit at yahoo.com Tue Jan 6 12:21:58 2004 From: aleaxit at yahoo.com (Alex Martelli) Date: Tue Jan 6 12:22:03 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: References: <200401051249.08356.aleaxit@yahoo.com> Message-ID: On Jan 5, 2004, at 1:58 PM, Bob Ippolito wrote: ... > Welcome to the community, Alex. It's good to see that yet another > large contributor to the Python (and PyPy) community has been tempted > ;) Thanks! > There's (no less than) four ways to do OSA/AppleScript tasks via Python Excellent and very useful presentation of the issues -- thanks again (also for putting it in the FAQs)! > In addition to the standard PackageManager database (maintained by > Jack), there is a separately maintained (by me) "experimental" package > database at http://undefined.org/python/pimp/ -- which has some > software that is not in the standard database or has non-standard > compilation options (such as Numeric compiled against Apple's vecLib, > which means Altivec acceleration for some operations on that shiny new > G4). And MORE thanks -- looks very interesting and I've bookmarked it. > You should also take a good look at PyObjC ( http://pyobjc.sf.net/ ), > which is the runtime bridge between Objective C and Python, that lets > you rather seamlessly take advantage of just about any Objective C > framework with the convenience of Python. This means that you can > write Python applications using Apple's flagship Cocoa UI framework, > and even use Interface Builder to build the GUIs. I guess I should gain some passing acquaintance with Objective C for the purpose...? I did look at that language many, many years ago, when Brad Cox's book came out (gosh, that must be TWENTY years ago... oh my...!!!), but don't really remember all that much about it (it WAS long ago, and I never really used the language at all, just studied the book...). Could you suggest some URL and/or book for the purpose? Or shd I just dive right into the "runtime bridge" without needing any understanding of the language on one side of it...? Alex From mwh at python.net Tue Jan 6 12:28:37 2004 From: mwh at python.net (Michael Hudson) Date: Tue Jan 6 12:28:40 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: (Alex Martelli's message of "Tue, 6 Jan 2004 18:21:58 +0100") References: <200401051249.08356.aleaxit@yahoo.com> Message-ID: <2m8ykl2dh6.fsf@starship.python.net> Alex Martelli writes: > I guess I should gain some passing acquaintance with Objective C for > the purpose...? I think you can get by on very little. You need to know enough to read Apple's docs, but that's not very much. I mean, it's just C with a bit of smalltalk wedged into it, right? :-) > Could you suggest some URL and/or book for the purpose? Or shd I > just dive right into the "runtime bridge" without needing any > understanding of the language on one side of it...? My advice would be: 1) Do Apple's tutorial in Obj-C. 2) Do the first two(?) PyObjC tutorials (one of which is the same as Apple's but in Python). 3) Dive in! Cheers, mwh -- For their next act, they'll no doubt be buying a firewall running under NT, which makes about as much sense as building a prison out of meringue. -- -:Tanuki:- -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html From oussoren at cistron.nl Tue Jan 6 12:30:11 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Tue Jan 6 12:30:16 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: References: <200401051249.08356.aleaxit@yahoo.com> Message-ID: On 6 jan 2004, at 18:21, Alex Martelli wrote: > >> You should also take a good look at PyObjC ( http://pyobjc.sf.net/ ), >> which is the runtime bridge between Objective C and Python, that lets >> you rather seamlessly take advantage of just about any Objective C >> framework with the convenience of Python. This means that you can >> write Python applications using Apple's flagship Cocoa UI framework, >> and even use Interface Builder to build the GUIs. > > I guess I should gain some passing acquaintance with Objective C for > the purpose...? I did look at that language many, many years ago, > when Brad Cox's book came out (gosh, that must be TWENTY years ago... > oh my...!!!), but don't really remember all that much about it (it WAS > long ago, and I never really used the language at all, just studied > the book...). Could you suggest some URL and/or book for the purpose? > Or shd I just dive right into the "runtime bridge" without needing > any understanding of the language on one side of it...? > The semantics of the Objective-C object model are simular to the Python semantics. Just diving in should work, please let us know if http://pyobjc.sourceforge.net/doc/intro.php does not contain enough information to get started. The most difficult part of Cocoa is understanding the class library, Ronald From bob at redivi.com Tue Jan 6 12:49:59 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 6 12:48:25 2004 Subject: [Pythonmac-SIG] hi, everybody! In-Reply-To: References: <200401051249.08356.aleaxit@yahoo.com> Message-ID: On Jan 6, 2004, at 12:21 PM, Alex Martelli wrote: > > On Jan 5, 2004, at 1:58 PM, Bob Ippolito wrote: > ... >> You should also take a good look at PyObjC ( http://pyobjc.sf.net/ ), >> which is the runtime bridge between Objective C and Python, that lets >> you rather seamlessly take advantage of just about any Objective C >> framework with the convenience of Python. This means that you can >> write Python applications using Apple's flagship Cocoa UI framework, >> and even use Interface Builder to build the GUIs. > > I guess I should gain some passing acquaintance with Objective C for > the purpose...? I did look at that language many, many years ago, > when Brad Cox's book came out (gosh, that must be TWENTY years ago... > oh my...!!!), but don't really remember all that much about it (it WAS > long ago, and I never really used the language at all, just studied > the book...). Could you suggest some URL and/or book for the purpose? > Or shd I just dive right into the "runtime bridge" without needing > any understanding of the language on one side of it...? http://developer.apple.com/ and file:///Developer/Documentation/ should be sufficient. Here are some quick tips: * Objective C is reference counting, but PyObjC does it all for you (yay!) * Objective C has a flat namespace for classes * Modules that define Objective C classes can NOT be unloaded, ever (modules as in bundles or dylibs). * You can not throw away classes, ever. * You can't replace classes, ever (but you can pose for them, put categories and override their methods, etc.. none of it is recommended). * ObjC methods are done with selectors that look like "foo:bar:" and are called like [obj foo:someFoo bar:someBar]. In PyObjC this turns into obj.foo_bar_(someFoo, someBar). So learn how to translate between colons and underscores, de-interleave selectors and arguments, and never forget the trailing underscore. * ObjC has separate namespaces for class methods and instance methods, like metamethods and instance methods in Python (if you're using the PEAK way of metamethods, where you're allowed to have an instance method as well). * ObjC does not support multiple inheritance, but.... * ObjC uses categories, which are like mixins except they happen after class creation. They can not add new instance variables to the class, but can add or replace methods. * Watch out for ObjC selectors that use pointers to C structures and datatypes, the selectors might need to be tweaked (to specify whether the data is "in", "out", or "in-out"), or worst case some helper code may need to be written to aid PyObjC. This is all mostly taken care of by PyObjC for Apple's frameworks. * You can subclass ObjC from Python, just do it like you normally would. You can mixin Python classes, but still single inheritance from ObjC. That's all I can think of at the moment. -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/20040106/1b79fada/smime.bin From tibs at tibsnjoan.co.uk Tue Jan 6 13:46:16 2004 From: tibs at tibsnjoan.co.uk (Tony Ibbs) Date: Tue Jan 6 13:46:23 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: Message-ID: <9BC89328-4078-11D8-A032-000A95DC16B8@tibsnjoan.co.uk> On 6 Jan2004, at 16:46, Alex Martelli wrote: > (BTW, as an aside: what Mac OS X newsreader would y'all suggest? I've > just downloaded MT-NewsWatcher, basically guessing among the available > ones, but I really have no idea which ones are worthwhile on this > platform... sorry for the OT, but maybe I can find a Python-scriptable > one to make this back ontopic...:-). Having recently "switched" myself, albeit to a PowerBook, MT-NewsWatcher does look like the least-worst (as a friend described it) Mac OS/X newsreader. For the moment, however, I'm trying to see if I can live with Pan under X, since that's what I used to use on Debian - I've acquired it from fink, and will probably try hand-building a later version since the stable fink version doesn't appear to be. It's not as pretty as an Aqua interface, but maybe I can live with that... On the other hand, I have a definite interest if anyone has better advice! Tibs From paul at donovansbrain.co.uk Tue Jan 6 14:31:36 2004 From: paul at donovansbrain.co.uk (Paul Donovan) Date: Tue Jan 6 14:31:41 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: <9BC89328-4078-11D8-A032-000A95DC16B8@tibsnjoan.co.uk> References: <9BC89328-4078-11D8-A032-000A95DC16B8@tibsnjoan.co.uk> Message-ID: On 6 Jan 2004, at 18:46, Tony Ibbs wrote: > > On 6 Jan2004, at 16:46, Alex Martelli wrote: >> (BTW, as an aside: what Mac OS X newsreader would y'all suggest? >> I've just downloaded MT-NewsWatcher, basically guessing among the >> available ones, but I really have no idea which ones are worthwhile >> on this platform... sorry for the OT, but maybe I can find a >> Python-scriptable one to make this back ontopic...:-). > > Having recently "switched" myself, albeit to a PowerBook, > MT-NewsWatcher does look like the least-worst (as a friend described > it) Mac OS/X newsreader. For the moment, however, I'm trying to see if > I can live with Pan under X, since that's what I used to use on Debian > - I've acquired it from fink, and will probably try hand-building a > later version since the stable fink version doesn't appear to be. It's > not as pretty as an Aqua interface, but maybe I can live with that... > > On the other hand, I have a definite interest if anyone has better > advice! > This subject gets discussed at least twice a month on uk.comp.sys.mac, usually from recent switchers :-) A lot of the old OS 9 people swear by MacSOUP, but I've never tried it. I believe it's a bit strange if you're used to regular newsreaders. I use Mozilla Thunderbird, which is also what I use at work on my Windows machine. It's like Outlook Express (!) - simple to use, but it also has some more advanced features. Here's a link to the latest thread, the second reply being particularly amusing ;-) http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF -8&threadm=1g4tm5n.18pudqlhs9lejN%40de-ster.xs4all.nl&rnum=8&prev=/ groups%3Fq%3Dwhich%2Bnewsreader%2Bgroup: uk.comp.sys.mac%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF -8%26as_drrb%3Db%26as_mind%3D12%26as_minm%3D11%26as_miny%3D2003%26as_max d%3D6%26as_maxm%3D1%26as_maxy%3D2004%26selm%3D1g4tm5n.18pudqlhs9lejN%254 0de-ster.xs4all.nl%26rnum%3D8 (sorry, tinyurl.com isn't responding at the moment) Hope this helps, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2377 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040106/ecceaf71/smime-0001.bin From bob at redivi.com Tue Jan 6 14:44:08 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 6 14:42:32 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: <9BC89328-4078-11D8-A032-000A95DC16B8@tibsnjoan.co.uk> References: <9BC89328-4078-11D8-A032-000A95DC16B8@tibsnjoan.co.uk> Message-ID: On Jan 6, 2004, at 1:46 PM, Tony Ibbs wrote: > On 6 Jan2004, at 16:46, Alex Martelli wrote: >> (BTW, as an aside: what Mac OS X newsreader would y'all suggest? >> I've just downloaded MT-NewsWatcher, basically guessing among the >> available ones, but I really have no idea which ones are worthwhile >> on this platform... sorry for the OT, but maybe I can find a >> Python-scriptable one to make this back ontopic...:-). > > Having recently "switched" myself, albeit to a PowerBook, > MT-NewsWatcher does look like the least-worst (as a friend described > it) Mac OS/X newsreader. For the moment, however, I'm trying to see if > I can live with Pan under X, since that's what I used to use on Debian > - I've acquired it from fink, and will probably try hand-building a > later version since the stable fink version doesn't appear to be. It's > not as pretty as an Aqua interface, but maybe I can live with that... > > On the other hand, I have a definite interest if anyone has better > advice! I started writing a news reader in PyObjC in order to learn the new Controller/KVC stuff and playing with the new NSStream stuff (async runloop integrated sockets). maybe it's worth putting some more effort into? I've never seen a newsreader on OS X that I've liked. I was modeling it after Mail.app, but I was disappointed in several areas because not all of the widgets in Mail.app are in Cocoa yet and I didn't feel like coding widgets. -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/20040106/53b35df8/smime.bin From hinsen at cnrs-orleans.fr Tue Jan 6 18:19:15 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Tue Jan 6 18:19:33 2004 Subject: [Pythonmac-SIG] Re: the iBook's irresistible charms In-Reply-To: <4DBB5573-4066-11D8-9670-000A95EFAE9E@yahoo.com> References: <4DBB5573-4066-11D8-9670-000A95EFAE9E@yahoo.com> Message-ID: On 06.01.2004, at 17:35, Alex Martelli wrote: > Oh yes! And, in my case, preferring it to other laptops because the > screen is crystal-sharp, the low weight makes it comfortable on my lap > as I curl up in my favourite armchair, That is exactly what I am doing now ;-) > than walking over to my study...!-) [[now what I _really_ need is a > good port of OO.o 1.1, with PyUNO scripting and all... 1.0.3 just > doesn't cut it, and I sure ain't gonna splurge on MS Office X...]] I am waiting for that as well... > until a few days ago my sights for "a future 64-bit-CPU machine" were > firmly fixed on AMD-64 boxes, right now a Powermac G5 _is_ starting to > look very alluring (even though _its_ price/performance ratio vs cheap > AMD-64 boxes isn't really all that good...)! I still prefer AMD boxes for number crunching, but those noisy beasts needn't be on my desktop. > Of course, such things are also contagious -- the many brand-new Mac > laptops I saw in use at various conferences and pypy sprints in 2003 > (WAY more than I saw in 2002) was Me too. SciPy was full of iBooks. There is a nice tool that I found for use with Python on the Mac (to get back on topic...), although it isn't really advertised as such. It is called VoodooPad (at www.flyingmeat.com). It is best described as a Wiki for local use, but it has some nice extras, one of which being the possibility to execute a page as a script, also in Python. This won't replace an IDE (no way to write modules for example), but I find it great for throw-away scripts that I do want to keep for reference ("What did I do three months ago?"). Keeping the scripts in a Wiki-like environment makes it possible to put them together with explanations, other scripts, output, graphics, etc., which I find a lot more attractive that dozens of files with names such as "run2.py" that can easily get lost. From havexbxkm at hongkong.com Tue Jan 6 08:37:23 2004 From: havexbxkm at hongkong.com (Finch Michel) Date: Tue Jan 6 20:51:12 2004 Subject: [Pythonmac-SIG] Re: KJMWIMG, yourself! and meanwhile Message-ID: thesis mammal cathy thuban rodriguez floodlight stamford salacious shields snook aboveboard bale antonym postulate bernadine minneapolis springboard true seafare water congestion heard breadroot sclerosis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040106/2495cd7b/attachment.html From davieengdrfc at mindspring.com Tue Jan 6 21:42:13 2004 From: davieengdrfc at mindspring.com (hack) Date: Tue Jan 6 21:42:34 2004 Subject: [Pythonmac-SIG] Fwd: Get Rid of SPAM for GOOD Message-ID: <200401070242.i072gR4b024081@mxzilla1.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040106/df262c99/attachment.html From marlong at rogers.com Tue Jan 6 23:05:17 2004 From: marlong at rogers.com (Marlon A. Griffith) Date: Tue Jan 6 23:05:23 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: <9BC89328-4078-11D8-A032-000A95DC16B8@tibsnjoan.co.uk> Message-ID: At 2:44 PM -0500 1/6/04, Bob Ippolito wrote: >On Jan 6, 2004, at 1:46 PM, Tony Ibbs wrote: > >>On 6 Jan2004, at 16:46, Alex Martelli wrote: >>>(BTW, as an aside: what Mac OS X newsreader would y'all suggest? >>>I've just downloaded MT-NewsWatcher, basically guessing among the >>>available ones, but I really have no idea which ones are >>>worthwhile on this platform... sorry for the OT, but maybe I can >>>find a Python-scriptable one to make this back ontopic...:-). >> >>Having recently "switched" myself, albeit to a PowerBook, >>MT-NewsWatcher does look like the least-worst (as a friend >>described it) Mac OS/X newsreader. For the moment, however, I'm >>trying to see if I can live with Pan under X, since that's what I >>used to use on Debian - I've acquired it from fink, and will >>probably try hand-building a later version since the stable fink >>version doesn't appear to be. It's not as pretty as an Aqua >>interface, but maybe I can live with that... >> >>On the other hand, I have a definite interest if anyone has better advice! > >I started writing a news reader in PyObjC in order to learn the new >Controller/KVC stuff and playing with the new NSStream stuff (async >runloop integrated sockets). maybe it's worth putting some more >effort into? I've never seen a newsreader on OS X that I've liked. >I was modeling it after Mail.app, but I was disappointed in several >areas because not all of the widgets in Mail.app are in Cocoa yet >and I didn't feel like coding widgets. > >-bob Hi Alex, As a newcomer to this list serv, I am rather in awe that someone of your experience and python talents have joined us. Welcome. I suspect that you like Linux style newsreaders and I am not too sure if you want a free or shareware product. Nonetheless, I like Thoth which is shareware at $25US. It is stable, easy to learn, very customizable and freely usable until you decide to pay for it. When not paid for, it is has a limited number of downloads you can perform before stopping. Then, you quit the app and start it up again to continue downloading. The interface consists of a main window listing all the newsgroups. A group is displayed in a separate window with articles listed in several possible orders, i.e. date, author, title, etc. The feature I like the best is the filter field at the top of windows. I switch to regular expressions, type in an expression and only the matching messages are displayed. Very useful for me! I would suggest the site http://www.versiontracker.com/macox/ when you want to search for mac software. The programs are listed with user reviews with not too much flaming. -- Make it a great day! http://members.rogers.com/kalyxsis "We move ahead by going deeper." Jennifer James (1943- ) American Writer "Don't let your schooling interfere with your education." Mark Twain "Do not parrot the words of famous people. Learn the meaning of what they say and repeat it in your own words." Mark Twain (not an exact quote). From dinu at mac.com Wed Jan 7 02:29:54 2004 From: dinu at mac.com (Dinu Gherman) Date: Wed Jan 7 02:29:09 2004 Subject: [Pythonmac-SIG] the iBook's irresistible charms In-Reply-To: <4DBB5573-4066-11D8-9670-000A95EFAE9E@yahoo.com> Message-ID: <49EB212C-40E3-11D8-B36F-00039345C610@mac.com> Alex Martelli: > Anything BUT alone, I'd say -- the iBook's price/functionality > ratio is really irresistible these days. Hi Alex! The price/functionality ratio would be even more irre- sistible if Apple would pass on the current conversion rate be- tween dollars and euros. If they did, an iBook G4, 12" would be a mere 880,- EUR (1100,- USD)... BTW, is anybody keen on taking a flight, placing and executing some iBook orders? ;-) Dinu -- Dinu C. Gherman - http://python.net/~gherman/MacOSXStuff.html ...................................................................... "I once asked Ivan, 'How is it possible for you to have invented computer graphics, done the first object oriented software system and the first real time constraint solver all by yourself in one year?' And he said 'I didn't know it was hard.'" (Alan Kay on Ivan Sutherland) From gherman at darwin.in-berlin.de Wed Jan 7 02:32:09 2004 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Wed Jan 7 02:39:06 2004 Subject: [Pythonmac-SIG] the iBook's irresistible charms In-Reply-To: <4DBB5573-4066-11D8-9670-000A95EFAE9E@yahoo.com> Message-ID: <9A6575CC-40E3-11D8-B36F-00039345C610@darwin.in-berlin.de> Alex Martelli: > Anything BUT alone, I'd say -- the iBook's price/functionality > ratio is really irresistible these days. Hi Alex! The price/functionality ratio would be even more irre- sistible if Apple would pass on the current conversion rate be- tween dollars and euros. If they did, an iBook G4, 12" would be a mere 880,- EUR (1100,- USD)... BTW, is anybody keen on taking a flight, placing and executing some iBook orders? ;-) Dinu PS: Sorry, if you receive this twice... -- Dinu C. Gherman - http://python.net/~gherman/MacOSXStuff.html ...................................................................... "I once asked Ivan, 'How is it possible for you to have invented computer graphics, done the first object oriented software system and the first real time constraint solver all by yourself in one year?' And he said 'I didn't know it was hard.'" (Alan Kay on Ivan Sutherland) From aleaxit at yahoo.com Wed Jan 7 04:29:03 2004 From: aleaxit at yahoo.com (Alex Martelli) Date: Wed Jan 7 04:29:11 2004 Subject: [Pythonmac-SIG] the iBook's irresistible charms In-Reply-To: <49EB212C-40E3-11D8-B36F-00039345C610@mac.com> References: <49EB212C-40E3-11D8-B36F-00039345C610@mac.com> Message-ID: <200401071029.03199.aleaxit@yahoo.com> On Wednesday 07 January 2004 08:29 am, Dinu Gherman wrote: > Alex Martelli: > > Anything BUT alone, I'd say -- the iBook's price/functionality > > ratio is really irresistible these days. > > Hi Alex! The price/functionality ratio would be even more irre- > sistible if Apple would pass on the current conversion rate be- > tween dollars and euros. If they did, an iBook G4, 12" would be > a mere 880,- EUR (1100,- USD)... BTW, is anybody keen on taking > a flight, placing and executing some iBook orders? ;-) True! But that goes for ALL sort of products -- the drop in USD/EUR exchange rates over the last year isn't really reflected in most retail pricing (making shopping in the US for all sort of reasonably transportable stuff more and more attractive to us Europeans). VAT also plays an important role: a 12" entrylevel iBook is EUR 1200 _VAT included_ here, that's 1000+VAT, while the 1100 USD price excludes sales taxes (typical sales taxes being 5% or so, but some states may not have any), which explains part of the difference. I did get my iBook in the US (had Anna get it for me, actually -- the advantages of having a fiancee who's a US resident often going back and forth, AND has weightlifting as her hobby, are really huge;-). There is some natural market segmentation in laptops thanks to keyboard layouts: buying in the US, my keyboard choices were limited to US English or Western Spanish. NP for me (I _far_ prefer US keyboard layouts -- indeed that's part of why I never buy laptops here, except from _sensible_ sellers that let me specify US keyboard layout, such as Dell... or Apple!), but most buyers used to QZERTY or AZERTY or whatever probably wouldn't take kindly to QWERTY, now would they?-). Nothing as blatant and hateful as the "Region Codes" for DVD's (where the market-segmentation purpose is so openly obvious!), but still... Unfortunately, I suspect that going for US purchases in anything but onesies and twosies "for personal use" is going to require licensing and customs and nullify the advantage:-(. I've explored the possibility of ordering on the Web, but even just for minor accessories most sellers just won't ship to Europe, and if they do, postage + customs + hassles makes it a bother. So, my advice to y'all is to get American fiancees...!-) [[Ideally Pythonista ones, of course -- but, not everybody can be as lucky as me, I guess:-)]] Alex From aleaxit at yahoo.com Wed Jan 7 05:07:23 2004 From: aleaxit at yahoo.com (Alex Martelli) Date: Wed Jan 7 05:07:28 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: Message-ID: <200401071107.23566.aleaxit@yahoo.com> On Wednesday 07 January 2004 05:05 am, Marlon A. Griffith wrote: ... > As a newcomer to this list serv, I am rather in awe that > someone of your experience and python talents have joined us. Welcome. Thanks! > I suspect that you like Linux style newsreaders and I am not I'm currently most used to KNode, which, while being a Linux newsreader, actually imitates Windows' Outlook Express newsreading GUI functionality somewhat closely (with all kinds of little enhancements) -- something that, give or take a little, can be said of many KDE components. But, for example, I'm not feeling any pain whatsoever doing most of my mailreading/answering on the iBook's Mail app, and some still on the Linux/KDE Kmail, like right now; yes, the GUIs are different, but both are sensible and consistent enough that I got used to switching between them in no time flat. I just wish MacOSX came with a News app to go with the Mail one with a similarly simple and consistent interface...:-). > too sure if you want a free or shareware product. Nonetheless, I like > Thoth which is shareware at $25US. It is stable, easy to learn, very > customizable and freely usable until you decide to pay for it. When Ok, tx for the advice! With MT-Newswatcher I was starting out fine until I started posting and found out that I apparently get no more than 4 lines' worth of screenspace to compose my post -- most of the screen's real estate is taken up by auxiliary controls and I don't see how to "maximize" the screenspace I get to actually compose my post... feels like writing mail on Yahoo's online mailreader -- usable in emergencies, but NOT comfortable AT ALL. So, unless I can find out how to customize THAT, I'm ready to switch again...;-). > etc. The feature I like the best is the filter field at the top of > windows. I switch to regular expressions, type in an expression and > only the matching messages are displayed. Very useful for me! Sounds nice, yes. > I would suggest the site http://www.versiontracker.com/macox/ > when you want to search for mac software. The programs are listed > with user reviews with not too much flaming. Thanks! This meta-advice is particularly precious to me. Alex From aleaxit at yahoo.com Wed Jan 7 06:16:13 2004 From: aleaxit at yahoo.com (Alex Martelli) Date: Wed Jan 7 06:16:19 2004 Subject: [Pythonmac-SIG] Re: the iBook's irresistible charms In-Reply-To: References: <4DBB5573-4066-11D8-9670-000A95EFAE9E@yahoo.com> Message-ID: <200401071216.13769.aleaxit@yahoo.com> On Wednesday 07 January 2004 12:19 am, Konrad Hinsen wrote: ... > > than walking over to my study...!-) [[now what I _really_ need is a > > good port of OO.o 1.1, with PyUNO scripting and all... 1.0.3 just > > doesn't cut it, and I sure ain't gonna splurge on MS Office X...]] > > I am waiting for that as well... There's a 1.1 RC3 -- working on the X side only, but still... -- that I've found, downloaded, and am gonna try out as soon as I get some free time -- I'm gonna let you know once I've tried it. > > until a few days ago my sights for "a future 64-bit-CPU machine" were > > firmly fixed on AMD-64 boxes, right now a Powermac G5 _is_ starting to > > look very alluring (even though _its_ price/performance ratio vs cheap > > AMD-64 boxes isn't really all that good...)! > > I still prefer AMD boxes for number crunching, but those noisy beasts > needn't be on my desktop. Right, unless you need unbelievably fast bandwidth from the number crunching to the video output, I guess; that's when the Powermac G5 quiet operation would be a real winner, I suspect. Not really my application area, though; the heavy computations are "batch-like", I don't really need truly advanced interactive / video visualization, I believe. > There is a nice tool that I found for use with Python on the Mac (to > get back on topic...), although it isn't really advertised as such. It > is called VoodooPad (at www.flyingmeat.com). It is best described as a > Wiki for local use, but it has some nice extras, one of which being the > possibility to execute a page as a script, also in Python. > > This won't replace an IDE (no way to write modules for example), but I > find it great for throw-away scripts that I do want to keep for > reference ("What did I do three months ago?"). Keeping the scripts in a > Wiki-like environment makes it possible to put them together with > explanations, other scripts, output, graphics, etc., which I find a lot > more attractive that dozens of files with names such as "run2.py" that > can easily get lost. Neat advice, thanks! And yes, it does sound like a really useful tool. Alex From gherman at darwin.in-berlin.de Wed Jan 7 07:01:04 2004 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Wed Jan 7 07:00:15 2004 Subject: [Pythonmac-SIG] the iBook's irresistible charms In-Reply-To: <200401071029.03199.aleaxit@yahoo.com> Message-ID: <2B58B6EA-4109-11D8-B162-00039345C610@darwin.in-berlin.de> Alex Martelli: > True! But that goes for ALL sort of products -- the drop in USD/EUR > exchange > rates over the last year isn't really reflected in most retail pricing > (making shopping in the US for all sort of reasonably transportable > stuff > more and more attractive to us Europeans). VAT also plays an > important role: > a 12" entrylevel iBook is EUR 1200 _VAT included_ here, that's > 1000+VAT, > while the 1100 USD price excludes sales taxes (typical sales taxes > being 5% or > so, but some states may not have any), which explains part of the > difference. True, but if I remember correctly in the U.S. there are strange ways to minimize/bypass things like VAT by having stuff shipped to you from a different state (which certainly helps the transport and logistics industries). OTOH, it would be interesting to know if European companies have increased prices of EU-manufactured products sold overseas... Is there any U.S.-owner of a new Porsche/Mercedes/BMW/Ferrari on this list? ;-) > [...] So, my advice to y'all is to get American fiancees...!-) That is certainly not an option for everybody! ;-) Anyway... Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "I never apologize for the United States of America, I don't care what the facts are." (George Bush, Sr.) From mwh at python.net Wed Jan 7 07:33:34 2004 From: mwh at python.net (Michael Hudson) Date: Wed Jan 7 07:33:37 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: (Alex Martelli's message of "Tue, 6 Jan 2004 17:46:40 +0100") References: Message-ID: <2m3cas2b1d.fsf@starship.python.net> Alex Martelli writes: > BTW, as an aside: what Mac OS X newsreader would y'all suggest? There's always Gnus (but that's probably a red rag to someone like you :-) Cheers, mwh -- I've even been known to get Marmite *near* my mouth -- but never actually in it yet. Vegamite is right out. UnicodeError: ASCII unpalatable error: vegamite found, ham expected -- Tim Peters, comp.lang.python From bob at redivi.com Wed Jan 7 08:29:33 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 7 08:27:55 2004 Subject: [Pythonmac-SIG] the iBook's irresistible charms In-Reply-To: <2B58B6EA-4109-11D8-B162-00039345C610@darwin.in-berlin.de> References: <2B58B6EA-4109-11D8-B162-00039345C610@darwin.in-berlin.de> Message-ID: <87BE41CC-4115-11D8-B0D7-000A95686CD8@redivi.com> On Jan 7, 2004, at 7:01 AM, Dinu Gherman wrote: > Alex Martelli: > >> True! But that goes for ALL sort of products -- the drop in USD/EUR >> exchange >> rates over the last year isn't really reflected in most retail pricing >> (making shopping in the US for all sort of reasonably transportable >> stuff >> more and more attractive to us Europeans). VAT also plays an >> important role: >> a 12" entrylevel iBook is EUR 1200 _VAT included_ here, that's >> 1000+VAT, >> while the 1100 USD price excludes sales taxes (typical sales taxes >> being 5% or >> so, but some states may not have any), which explains part of the >> difference. > > True, but if I remember correctly in the U.S. there are strange > ways to minimize/bypass things like VAT by having stuff shipped > to you from a different state (which certainly helps the transport > and logistics industries). There's three ways to get around US sales tax that I'm aware of (but I'm no expert): (a) You're a reseller. Government issues you a reseller id, you should be able to convince companies to exempt you from sales tax with this id (but it's a hassle). (b) You're a non-profit. I'm not really sure about this one because I've never been directly involved with a non-profit, but I believe they get the same sort of treatment as a reseller does (except they're not expected to resell the product). (c) You're in a state that the company does have a presence in. Sales tax is by state. Apple has stores just about everywhere, so this doesn't really work. The best way I've found to get cheap Apple stuff is to find 9 friends who want to purchase machines and sign up for ADC Premiere (which is also awesome if you're starting a new mac-based company, whether or not you develop software ;). You get 10 hardware discounts, which in the US ends up being about 20% off. Bonus is that a discount is a system plus accessories, so you can get an iPod, cinema display, airport hub, etc on the cheap (maybe not "cheap" but reasonable :). It actually makes adding RAM cheap enough such that you may not bother buying it 3rd party. You also get a bunch of developer tech support, a free ticket to WWDC (sans transportation), and all the ADC mailings (which includes a copy of whatever OS they release that year and all the public betas). It's not cheap, $3500 I believe, but it pays for itself in discounts alone if you end up spending an average of $1750 or more each purchase, which isn't that hard. If you sign up for ADC select you don't get a whole lot the first year, but for every year you renew you get one hardware discount. If your ADC Premiere subscription is expiring you can renew as select and get this hardware discount. I don't really know how the hardware purchase program works in Europe, but hopefully it's something like it is here. Basically you go to a particular URL, click on a store which takes you to a version of store.apple.com with discount prices. I think you get a similar deal if you're a student or educator (though I think it may be more like 15%), so maybe that would be an easier/cheaper route? -bob (who has paid ADC prices for two personal machines and an iPod because there were left over hardware discounts from work) -------------- 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/20040107/7d3faf9f/smime.bin From bob at redivi.com Wed Jan 7 08:34:24 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 7 08:32:46 2004 Subject: [Pythonmac-SIG] Re: [Twisted-Python] BEEPy - a Python BEEP library In-Reply-To: <20040107054745.GA19868@snafu.eigenmagic.com> References: <20040107054745.GA19868@snafu.eigenmagic.com> Message-ID: <3513EC08-4116-11D8-B0D7-000A95686CD8@redivi.com> On Jan 7, 2004, at 12:47 AM, Justin Warren wrote: > I'm relatively new to twisted, but I saw some discussion early in 2003 > around BEEP and twisted lamenting the lack of a Python library. I hope > this is the right place to post. > > I'm the developer of a library called BEEPy which is a BEEP > implementation written in pure Python. I recently redesigned the core > to use twisted for TCP and SSL comms, so I figured you folks might be > interested in it. > > BEEPy is LGPL licensed and hosted over at sourceforge: > http://beepy.sourceforge.net/ for the curious. Neat! I've heard Apple's new Xgrid cluster-communication-stuff is based on XML property lists on top of BEEP. Might be worth my time to look into reverse engineering it now that this exists :) -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/20040107/c40fbb54/smime.bin From mjb at uma.pt Wed Jan 7 08:34:43 2004 From: mjb at uma.pt (Michael J. Barber) Date: Wed Jan 7 08:34:55 2004 Subject: [Pythonmac-SIG] Re: the iBook's irresistible charms In-Reply-To: <200401071216.13769.aleaxit@yahoo.com> Message-ID: <407D1960-4116-11D8-9B37-0050E4794D0F@uma.pt> On Wednesday, Jan 7, 2004, at 11:16 Europe/Lisbon, Alex Martelli wrote: > On Wednesday 07 January 2004 12:19 am, Konrad Hinsen wrote: > ... > >> is called VoodooPad (at www.flyingmeat.com). It is best described as a >> Wiki for local use, but it has some nice extras, one of which being >> the >> possibility to execute a page as a script, also in Python. >> >> This won't replace an IDE (no way to write modules for example), but I >> find it great for throw-away scripts that I do want to keep for >> reference ("What did I do three months ago?"). Keeping the scripts in >> a >> Wiki-like environment makes it possible to put them together with >> explanations, other scripts, output, graphics, etc., which I find a >> lot >> more attractive that dozens of files with names such as "run2.py" that >> can easily get lost. > > Neat advice, thanks! And yes, it does sound like a really useful tool. > Check out TextExtras as well at . That should make VoodooPad even nicer for those throw-away scripts. Essentially, you get a lot of features you normally only expect in a dedicated text editor loaded into every Cocoa application -- auto-indent, changing of indent levels, matching braces, word completions, etc. Actually, whether you use VoodooPad or not, check out TextExtras! There are also some rather useful little programs and services at . In particular, WordService has some useful tools for the Python programmer. The usual disclaimer: no connection to the programs' authors, just a satisfied user. -- Michael From aleaxit at yahoo.com Wed Jan 7 09:19:04 2004 From: aleaxit at yahoo.com (Alex Martelli) Date: Wed Jan 7 09:19:09 2004 Subject: [Pythonmac-SIG] the iBook's irresistible charms In-Reply-To: <2B58B6EA-4109-11D8-B162-00039345C610@darwin.in-berlin.de> References: <2B58B6EA-4109-11D8-B162-00039345C610@darwin.in-berlin.de> Message-ID: <200401071519.04162.aleaxit@yahoo.com> On Wednesday 07 January 2004 01:01 pm, Dinu Gherman wrote: ... > OTOH, it would be interesting to know if European companies have > increased prices of EU-manufactured products sold overseas... > Is there any U.S.-owner of a new Porsche/Mercedes/BMW/Ferrari on > this list? ;-) I don't know about car companies in specific (and Mercedes, being manufactured by a roughly 50/50 US/EU company, Daimler-Chrysler, is an especially peculiar situation anyway), but I do know that a EU exporter to the US faced with growing EU/US exchange rate can adopt a mix of two strategies: pass some of the increase on to prices, hurting sales, vs swallow some of the increase, hurting profit margins. The ability to do the former without hurting sales _too_ badly is also known as "pricing power", and it depends on how sensitive the demand for your goods (or services) is to price (which in good part, in turn, depends on how directly affected you are by competition -- if you sell perfectly replaceable products, known as "commodities", the effect of competition is maximal, your pricing power is about zero -- that, for example, is the typical situation of an exporter of steel, with possible exception for niche "specialty" steels/workings). SAP, for example, explained in their latest yearly report (at the end of the summer, if I recall correctly) that their profitability was up, but sales were hurting "due to the strong Euro". This implies they had passed on to their prices a strong portion of the Euro's increases, which, in turn, means they judge their pricing power to be high; there is little direct competition for their products/services -- customers faced with higher prices may delay purchasing/upgrading/increasing their purchases of SAP products and services, but aren't switching en masse to SAP's competitors (or else, SAP would _have_ to accept decreased profits to keep prices more stable and save their market share). Vice versa, Nokia and Ericsson appear to have steady sales and market shares but declining profitability -- this implies they have low pricing power (there's strong competition in the cellphone market, a high risk of losing a sale to a competitor if you try raising prices) and have passed little or nothing of the exchange-rate increase onto product prices. I've never specifically studied the converse situation, that of an exporter from a country whose currency is rapidly declining, but it seems to me that the situation is exactly the reverse -- the choice being to pocket more profits by keeing prices stable, or expand market share by lowering prices; again, price-sensitivity of demand being key. It gets more interesting if you think of an exporter who has a whole line of products -- some squarely aimed at a captive market (high pricing power, low price sensitivity of demand), others aggressively competing in a crowded market (low pricing power, high price sensitivity), AND some measure of "internal" competition between product lines (the aggressively priced line may "steal" sales that might have gone to the high-profit line, if the price/performance difference between the lines becomes too high). Craftfully maintaining market segmentation and jostling between profits and market share under such conditions will be truly an art. It seems to me that Apple is exactly in that position -- e.g. with iBook vs Powerbook product lines -- and is handling the difficulties with great finesse. > > [...] So, my advice to y'all is to get American fiancees...!-) > > That is certainly not an option for everybody! ;-) True -- the population of the US is smaller than that of EU countries, and with the EU's expansion coming this spring the ratio will further tilt; so, not _every_ EU citizen can get a US fiancee...:-). Alex From mjb at uma.pt Wed Jan 7 09:42:03 2004 From: mjb at uma.pt (Michael J. Barber) Date: Wed Jan 7 09:42:32 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: Message-ID: On Tuesday, Jan 6, 2004, at 16:46 Europe/Lisbon, Alex Martelli wrote: > Jason Petrone writes: > >> I understand your apprehension about learning AppleScript, and maybe >> as >> a Python luminary that makes sense for you. But for me, learning at > > Well, it's not so much "apprehension", but rather a case of there > being SO many important things to learn, that one englishy-syntax, > proprietary, non-cross-platform, apparently-feeblish scripting > language, per se, wasn't high on my to-do list. However, studying it > may still well be the best approach, of course. > Your description of AppleScript is not far off, I'd say, but AppleScript is better than a lot of websites would have you believe. The core language is semantically like Python, but dumber. IMO, it is most significantly marred by not having first-class functions or decent mapping objects. The syntax can be awkward when writing scripts, but does make examples easy to read, at least. Most OSA examples are in AppleScript, and Apple seems to like to treat OSA and AppleScript like they were synonyms. However, AppleScript isn't the only OSA language. How about Javascript? . There are a number of examples there in a language that you probably already know, and doesn't suffer from the shortcomings you listed. The documentation is aimed at programmers, including some examples of how to construct and send raw AppleEvents. That could be a useful starting point for sending AppleEvents in Python. You'll probably want the AppleScript language reference, at any rate . If you decide to bite the bullet and learn some AppleScript, has some nice examples. FWIW, it is reasonably easy to segregate all of the OSA work into a few commands, and just pipe some short AppleScript lines to the osascript command. This is the approach I usually take. I used to use (read: struggle with) gensuitemodule, but found that I tended to experiment in AppleScript then convert to Python, so I now skip the conversion. I haven't tried aeve or AppScripting yet, which do look nicer than gensuitemodule. -- Michael From hengist.podd at virgin.net Wed Jan 7 11:26:14 2004 From: hengist.podd at virgin.net (has) Date: Wed Jan 7 11:29:42 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: Message-ID: Alex Martelli wrote: >>>Can anybody suggests a good tutorial/with/examples >>>for me to learn to use Python for OSA/AppleScript tasks? >> >>I understand your apprehension about learning AppleScript, and maybe as >>a Python luminary that makes sense for you. But for me, learning at > >Well, it's not so much "apprehension", but rather a case of there >being SO many important things to learn, that one englishy-syntax, >proprietary, non-cross-platform, apparently-feeblish scripting >language, per se, wasn't high on my to-do list. However, studying >it may still well be the best approach, of course. The big problems with learning AppleScript are 1. its incredibly muddled semantics and syntax, 2. the difficulty of finding really well-written example code, 3. the drudgery of learning its myriad bugs and the various workarounds for them. The first is a fundamental fault of AppleScript's design and implementation. The second a natural consequence of having a non-CS literate userbase. While waiting for Apple to rectify the third is like watching paint drying... only over years, not months.;p [1] Now, I'm optimistic that sometime this year MacPython will become a viable - if not compelling(!) - alternative to AppleScript for the majority of IAC tasks. The work is already underway, and roughly breaks down as: 1. implementing a high-level interface to Apple Event Manager; 2. writing a guide to application scripting (introduction, tutorials, examples) that's geared specifically towards Python users; 3. implementing decent OSA support[2]. As far as doing IAC today goes, none of the Python IAC solutions quite match AppleScript's level of support yet; for example, you can't currently control remote apps or apps without creator codes (e.g. Address Book). And right now the only literature available on application scripting is written around the AppleScript language. So if you're brand new to application scripting then you'll probably fare better if you grit your teeth, haul out the crusty old AppleScript Language Guide [3]: and start off with the simple stuff in AppleScript for now. Finder scripting, while it has some bugs, is reasonably good. Tex-Edit Plus's scripting support is very good indeed and about as close to canonical as they get. OTOH, Apple's iApps are pretty notorious; if you want to script these, learn how good scripting should work first before attempting to grasp the ugly realities of controlling apps whose designers don't seem to understand IAC either. BTW, one other thing: it'll save you a LOT of mental anguish if you realise from the start that application objects are referred to using basic relational queries [4]. Most folk don't realise this, especially since AppleScript uses syntax that looks much like standard OO [5]. I posted a message to the MACSCRPT list in the last couple of days where I've talked about this issue; I do recommend you check it out. Here's the archives; look for the 'Perl (and Python)' thread: HTH has [1] The AppleScript engineers _are_ working on this... tho' some of these bugs are so old they'll soon be getting telegrams from the Queen...;) [2] Most of #3 should be straightforward, but I think attachability will present a significant problem as the Cocoa API only provides support for the AppleScript component. (Which biases attachable Cocoa apps against any language whose names does not start with "Apple".) But this can be addressed at the time. [3] For the basics of IAC, the chapters on Commands and Objects and References are the ones you probably want. [4] e.g. From : "An attribute of an object is a one-to-one relationship of a certain type. It is synonymous with the AppleScript concept of a property of an object. For example, color is an attribute of a graphic shape, but a document is not an attribute of a window, even though the window has only one associated document. This use of the term attribute is not related to the Apple event attribute defined above. "The term relationship is used to describe an object's one-to-many relationships or its non-attribute one-to-one relationships. For example, a paragraph has a one-to-many relationship with its words, but a a one-to-one relationship with its document (though the document is not an attribute of the paragraph). Traditional AppleScript terminology refers to each object contained in another object as an element (words are elements of a paragraph)." Also see the ASLG for discussion of the different reference forms that are supported. [5] Including some application designers. So don't be surprised when some apps refuse to handle commands and references as expected; often as not is cos their scripting support just sucks. e.g.: tell application "iTunes" delete (every file track of every playlist of every source whose location is missing value) end tell ought to delete all tracks whose original audio file is missing. Alas, in practice it doesn't even come close to working correctly, and you'll have to use a workaround like the one Bob provides as one of his aeve examples. -- http://freespace.virgin.net/hamish.sanderson/ From hinsen at cnrs-orleans.fr Wed Jan 7 12:51:04 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Wed Jan 7 12:51:16 2004 Subject: [Pythonmac-SIG] Re: the iBook's irresistible charms In-Reply-To: <407D1960-4116-11D8-9B37-0050E4794D0F@uma.pt> References: <407D1960-4116-11D8-9B37-0050E4794D0F@uma.pt> Message-ID: <1008D088-413A-11D8-AA7B-000A95AB5F10@cnrs-orleans.fr> On 07.01.2004, at 14:34, Michael J. Barber wrote: > Check out TextExtras as well at > . That Thanks a lot for that recommendation! This is clearly a hacker tool (if only for the style of the documentation), but a nice one :-) > There are also some rather useful little programs and services at > . In particular, > WordService has some useful tools for the Python programmer. Indeed. I also like HotService, the default behaviour is quite annoying. Side remark: am I the only one who finds the most useful hints on just about any computing topic on Python lists? Perhaps it's time for comp.lang.python.offtopic ;-) Konrad. From Jack.Jansen at cwi.nl Wed Jan 7 18:05:45 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Jan 7 18:05:51 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: Message-ID: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> On 7-jan-04, at 17:26, has wrote: > BTW, one other thing: it'll save you a LOT of mental anguish if you > realise from the start that application objects are referred to using > basic relational queries [4]. Most folk don't realise this, especially > since AppleScript uses syntax that looks much like standard OO [5]. I > posted a message to the MACSCRPT list in the last couple of days where > I've talked about this issue; I do recommend you check it out. Here's > the archives; look for the 'Perl (and Python)' thread: > > A0=macscrpt&D=1&H=0&O=D&T=1> This paragraph leads me to believe that you're the first person (or one of the first people) I've met in my 8 year quest to understand the AppleScript machinery who actually understands what is going on. Unfortunately, however, I'm not sure I understand what you're saying, either in this paragraph or in the discussion on the scripting mailing list. It would help me immensely if you could help me (and probably numerous others) get things straight.... Here's what I understand so far, please tell me what's wrong with this, and where I miss things. The whole things is a layered set of protocols and APIs. At the very bottom we have IAC (Inter-Application Communication), which is basically a low-level API to do message passing, both inter and intra-machine. Under OS9 you could use this raw, but as far as I can tell that is no longer true under OSX. The next level up is AppleEvents, which is a number of things all entangled: 1. An API for doing RPC (remote procedure calls), 2. A data encoding format for RPC parameters (similar to what ASN-1 or XDR provides), 3. A data model (classes, properties, iterators, tests, etc), 4. An API for encoding and decoding the format of (2) and (3). All in all this level provides similar services to what COM or Corba provides. Then there's dictionary/terminology level, which is really unclear to me. In part it is part of the previous level. In part it is a level by itself: it allows applications to build on the data model and define which classes, properties, etc. it supports and communicate that to other applications. In part it is part of the next level: all sorts of AppleScript words appear in the dictionaries. Documentation on this level appears to be completely lacking: getting the terminology resource of application is a black art (sometimes you can use AppleEvents to get it, sometimes you have to hunt for an 'aeut' or 'aete' resource, sometimes there's only an XML file in an unspecified format). Next level up is actual scripting languages. AppleScript is the main one here, but in principle this level is open. Frontier is (or used to be) another scripting language within this architecture, and we want Python to be usable at this level too. Next level up is the OSA (Open Scripting Architecture) API. OSA is used by Apple sometimes to denote this whole stack of layers, sometimes to denote only this level (the topmost one). The OSA API seems to refer only to the topmost layer. This is the API used by host applications, and it should in principle allow an application to be scripting-language-agnostic: if you are a server for the AppleEvents level and a client to the OSA API level users can use any scripting language to script your application. And of course you can also be only a server (most scriptable applications) or client (MacPython 2.3). -- 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 Jan 7 18:25:59 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 7 18:23:49 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> Message-ID: On Jan 7, 2004, at 6:05 PM, Jack Jansen wrote: > > On 7-jan-04, at 17:26, has wrote: >> BTW, one other thing: it'll save you a LOT of mental anguish if you >> realise from the start that application objects are referred to using >> basic relational queries [4]. Most folk don't realise this, >> especially since AppleScript uses syntax that looks much like >> standard OO [5]. I posted a message to the MACSCRPT list in the last >> couple of days where I've talked about this issue; I do recommend you >> check it out. Here's the archives; look for the 'Perl (and Python)' >> thread: >> >> > A0=macscrpt&D=1&H=0&O=D&T=1> >> > This paragraph leads me to believe that you're the first person (or > one of the first people) I've met in my 8 year quest to understand the > AppleScript machinery who actually understands what is going on. > Unfortunately, however, I'm not sure I understand what you're saying, > either in this paragraph or in the discussion on the scripting mailing > list. He certainly knows a whole lot more than I do about AppleEvents.. I've had less than a year of experience with them and don't have significant AppleScript experience. > It would help me immensely if you could help me (and probably numerous > others) get things straight.... > > Here's what I understand so far, please tell me what's wrong with > this, and where I miss things. > > The whole things is a layered set of protocols and APIs. At the very > bottom we have IAC (Inter-Application Communication), which is > basically a low-level API to do message passing, both inter and > intra-machine. Under OS9 you could use this raw, but as far as I can > tell that is no longer true under OSX. I think you can still use some of these mechanisms, but I don't think anyone ever really did. From what I remember it's called PPC (Program to Program Communication? It sure as hell isn't the PPC we're used to hearing) and sits on top of Mach ports in OS X. > The next level up is AppleEvents, which is a number of things all > entangled: > 1. An API for doing RPC (remote procedure calls), > 2. A data encoding format for RPC parameters (similar to what ASN-1 or > XDR provides), > 3. A data model (classes, properties, iterators, tests, etc), > 4. An API for encoding and decoding the format of (2) and (3). > All in all this level provides similar services to what COM or Corba > provides. > > Then there's dictionary/terminology level, which is really unclear to > me. In part it is part of the previous level. In part it is a level by > itself: it allows applications to build on the data model and define > which classes, properties, etc. it supports and communicate that to > other applications. In part it is part of the next level: all sorts of > AppleScript words appear in the dictionaries. Documentation on this > level appears to be completely lacking: getting the terminology > resource of application is a black art (sometimes you can use > AppleEvents to get it, sometimes you have to hunt for an 'aeut' or > 'aete' resource, sometimes there's only an XML file in an unspecified > format). The dictionary/terminology level is just (unvalidated) metadata. AppleScript uses it, and it's the only good way for humans to use Apple Events. I'm relatively sure that the XML file only happens for Cocoa applications. I believe the format is indeed specified somewhere, and I'm also relatively sure that anything that has this kind of XML file is going to respond to the AppleEvent method of fetching it. In any case, dictionaries/terminologies are not part of the RPC mechanism (other than the fact that some applications are nice enough to send you a terminology via AppleEvents). I'm pretty sure that compiled AppleScript doesn't have any references to the original terminology entries, it's all four character codes. There is no API to do anything with identifiers from terminologies (other than to ask an OSA language to compile code). > Next level up is actual scripting languages. AppleScript is the main > one here, but in principle this level is open. Frontier is (or used > to be) another scripting language within this architecture, and we > want Python to be usable at this level too. > > Next level up is the OSA (Open Scripting Architecture) API. OSA is > used by Apple sometimes to denote this whole stack of layers, > sometimes to denote only this level (the topmost one). The OSA API > seems to refer only to the topmost layer. This is the API used by host > applications, and it should in principle allow an application to be > scripting-language-agnostic: if you are a server for the AppleEvents > level and a client to the OSA API level users can use any scripting > language to script your application. And of course you can also be > only a server (most scriptable applications) or client (MacPython > 2.3). There's three things: (1) OSA language (e.g. AppleScript) (2) Application that responds to more than the very basic AppleEvents (e.g. Finder) (3) Application that sends AppleEvents to other applications (e.g. MacPython via AppScripting/aeve/gensuitemodule) You can actually do (2) from MacPython.. I don't know if the Carbon wrappers have enough chops to handle it (I'd imagine they do).. but *definitely* via PyObjC you have access to enough juice to make a scriptable application (on 10.2 or later). -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/20040107/9e5e3bd4/smime.bin From jxbeejow at tom.com Wed Jan 7 13:37:01 2004 From: jxbeejow at tom.com (Holcomb Ernest) Date: Thu Jan 8 01:41:41 2004 Subject: [Pythonmac-SIG] Re: QH, that your novel Message-ID: disembowel vertices catharsis electroencephalograph course bloodroot curt femur eddie traverse oxide strange calfskin bowdoin saga precursor celeste conceptual composite -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040107/6cb5404e/attachment.html From hengist.podd at virgin.net Wed Jan 7 22:10:09 2004 From: hengist.podd at virgin.net (has) Date: Thu Jan 8 05:34:24 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> Message-ID: Bob wrote: >>>BTW, one other thing: it'll save you a LOT of mental anguish if >>>you realise from the start that application objects are referred >>>to using basic relational queries [4]. Most folk don't realise >>>this, especially since AppleScript uses syntax that looks much >>>like standard OO [5]. >>> >>This paragraph leads me to believe that you're the first person (or >>one of the first people) I've met in my 8 year quest to understand >>the AppleScript machinery who actually understands what is going >>on. Unfortunately, however, I'm not sure I understand what you're >>saying, either in this paragraph or in the discussion on the >>scripting mailing list. I shouldn't be surprised - I often can't understand me either. The gold-to-bullsh*t ratio is often rather poor to begin with, but I generally just keep on trying till I get it more or less right. >He certainly knows a whole lot more than I do about AppleEvents.. >I've had less than a year of experience with them and don't have >significant AppleScript experience. Depends what you mean. I expect you can find your way around the Carbon APIs and all the other low-level stuff a LOT easier than I can, given that I have no C or other low-level programming experience. What I do have a very good grasp of the high-level principles by which AppleEvent-based interapplication control operates - or ought to operate anyway (given the amount of applications, documentation, APIs, etc. that seem to get it wrong in one respect or another). This is due to an almost unbelievable amount of time spent banging away at the AppleScript language and application scripting until I finally understood it close to perfectly as makes no difference. In fact, AppleScript is very much my alma-mater; I didn't have any coding experience (other than a little 80's BASIC from childhood) before then, and like most folk I got into it because I was lazy and wanted to automate a bunch of stuff at work, and because it had that "friendly English-like syntax" that tends to draw in so many naive and unsuspecting newcomers. (And I'll leave you to think up your own florid metaphors for this seduction of the innocent; of seedy men driving slowly past schoolyards in unmarked vans, etc.;) The only difference being that most folk get 'just good enough' at it to do what they want, whereas I just kept going - I'm stupid/persistent like that. With a lot of red face moments from heading down every wrong turn till finally getting it right, of course. Needless to say, I'm still very peeved that it's taken me so long to get to where I am now, and I've every sympathy for others who brave the same path. And AppScripting is now my second attempt to do something concrete about it, given that Apple seem so frustratingly content to let the many problems with IAC, AppleScript and - most especially - their documentation of it just amble along year on year when what's really needed is some massive action (and maybe a ton or two of TNT too). (Short version: have some patience with the crazy guy bouncing annoyingly in the corner - he's often wrong, but when he gets on the right track he can be very right indeed.;) >>It would help me immensely if you could help me (and probably >>numerous others) get things straight.... >> >>Here's what I understand so far, please tell me what's wrong with >>this, and where I miss things. >> >>The whole things is a layered set of protocols and APIs. At the >>very bottom we have IAC (Inter-Application Communication), which is >>basically a low-level API to do message passing, both inter and >>intra-machine. Under OS9 you could use this raw, but as far as I >>can tell that is no longer true under OSX. > >I think you can still use some of these mechanisms, but I don't >think anyone ever really did. From what I remember it's called PPC >(Program to Program Communication? It sure as hell isn't the PPC >we're used to hearing) and sits on top of Mach ports in OS X. You're thinking of MacOS's Process-to-Process Communications Toolbox. This is absent in OS X, which uses Mach messaging instead. Like you say, hardly anyone ever ventured that far down to the basement in practice; certainly for our purposes you really don't need to know about anything below the Apple Event Manager and Apple events. So this stuff can (and should) be ignored. >>The next level up is AppleEvents, which is a number of things all entangled: >>1. An API for doing RPC (remote procedure calls), >>2. A data encoding format for RPC parameters (similar to what ASN-1 >>or XDR provides), >>3. A data model (classes, properties, iterators, tests, etc), >>4. An API for encoding and decoding the format of (2) and (3). >>All in all this level provides similar services to what COM or >>Corba provides. Uh-huh. The Apple Event Manager provides the API for your #1 and #4. (No point asking me about COM and Corba as I'm not familiar with those, but will take your word for their being similar.) As for the data model stuff, it's very much provided in flat-pack form: while AEM has occasionally heard of curious things called "classes" and "properties", it's not really all that interested in such high-falutin' stuff. All it really cares about is structs, strings, and lots and lots of mechanically efficient though deeply human-unfriendly four-letter codes that describe the many meanings of the various collections of crude parts that pass through it. It's also worth noting that this layer provided the day-to-day interapplication communication services that appeared in System 7, which was the first version of MacOS to provide native support for cooperative multitasking. The obvious example is of the Finder using AEs to communicate with other applications, sending them lists of files to open or print, telling them to quit when the system was shut down, etc. I suppose it would be inevitable that some bright spark would at some point realise that this mechanism could be harnessed by other types of clients... like, oh... say, a high-level scripting language. So controlling applications from scripts is more a fringe benefit of AEs and AEM - albeit one that turned out to be very valuable to a lot of important Apple customers (i.e. the publishing market) - than its core raison-d'etre. ... All of which takes us onto the next topic of interest: the Open Scripting Architecture (and associates). >>Then there's dictionary/terminology level, which is really unclear >>to me. In part it is part of the previous level. In part it is a >>level by itself: it allows applications to build on the data model >>and define which classes, properties, etc. it supports and >>communicate that to other applications. In part it is part of the >>next level: all sorts of AppleScript words appear in the >>dictionaries. Documentation on this level appears to be completely >>lacking: getting the terminology resource of application is a black >>art (sometimes you can use AppleEvents to get it, sometimes you >>have to hunt for an 'aeut' or 'aete' resource, sometimes there's >>only an XML file in an unspecified format). > >The dictionary/terminology level is just (unvalidated) metadata. Yes. Although the 'unvalidated' bit may not be entirely true: one should reasonably assume that it has at least been checked for correctness by its original authors before they stuck it in (ho-ho), and I think Cocoa also makes some use of it in performing sanity-checking on incoming events that will be handled through the Cocoa framework's scripting support facilities. >AppleScript uses it, and it's the only good way for humans to use >Apple Events. Except if you're the sort of sick puppy who genuinely enjoys dealing with vast swathes of utterly cryptic computer-y codes. In which case I can probably find you a nice 1980s list of Z80 and 6502 assembler codes that'll totally float your boat.;) For everyone else though, it's a way to translate AE codes into something meaningful, as well as being a form of user documentation in itself. In addition to providing mappings between the four-letter codes used by AEM, the application terminology resource also contains information describing how a particular application's scripting interface works. (Although this information is far from comprehensive, much to the chagrin of many a user left to fill in the missing knowledge for themselves through folk wisdom and much trial and error.) > I'm relatively sure that the XML file only happens for Cocoa >applications. I believe the format is indeed specified somewhere, >and I'm also relatively sure that anything that has this kind of XML >file is going to respond to the AppleEvent method of fetching it. The encoding of the terminology resource is irrelevant to clients; only application developers need worry their heads about such nonsense, and the smart ones will likely use tools to generate it all anyway. (In OS7-9 it was binary format; in OS X it's either key-value lists or in XML plist format.) As for clients getting hold of the terminology for a particular app, this should be done via the OSA API which provides the necessary services. (I'm sure I don't need to lecture anyone on the follies of nipping around official APIs and sticking their bits in where they're not meant to be. And any accusations of aeve and appscript doing just such a thing themselves shall be dismissed as temporary technical difficulties; soon to be resolved, etc.;) >I'm pretty sure that compiled AppleScript doesn't have any >references to the original terminology entries, it's all four >character codes. Correct. What a particular OSA client chooses to do with the application terminology is up to it. The AppleScript language component uses it only to translate between 'plain English' keywords and AE codes when compiling and decompiling scripts. While applications such as Script Editor, Smile and Script Debugger use it to generate user-readable documentation describing an application's scriptable interface, just as the application's printed/electronic manual typically describes its graphical interface (and/or command-line interfaces for folk that like that sort o' thing). >>Next level up is actual scripting languages. AppleScript is the >>main one here, but in principle this level is open. Frontier is >>(or used to be) another scripting language within this >>architecture, and we want Python to be usable at this level too. >> >>Next level up is the OSA (Open Scripting Architecture) API. You've got these the wrong way around. OSA provides a component mechanism for handling OSA-compatible language components. (The old MacOS being very big on component architecture for providing hot-swappable software plug-n-play at runtime. Probably the best-known of these components being Apple's famous Quicktime.) Scripting languages can then plug into OSA. Some might employ it just for fetching terminology resources from apps, while others will use it to elevate themselves to full-blown component-hood. (Even then, some may support more OSA-based services than others; aside from the core commands such as compile and execute, most are optional.) BTW, remember that OSA and AEM are two separate things. I tend to think of OSA as sitting at a level higher than AEM myself. But while OSA is itself a client of AEM, you can, for example, have an OSA client that isn't a client of AEM (e.g. Brent Simmon's OSAShell language component; the old Script Editor [which didn't associate with AEM like the new one does, aside from having to support the Required Suite like all good Mac apps, of course]), or an AEM client that has nothing to do with OSA (aside from the obvious example of direct application-to-application communication, the current release of appscript immediately comes to mind). >>OSA is used by Apple sometimes to denote this whole stack of layers, True. But considering that Apple uses the name "AppleScript" to cover everything from "Programming-for-Beginners" (Basilisk edition), to scripts-based interapplication control, to the Ultimate Answer to Life, the Universe, and Whatever Else Might Ail You, I shouldn't pay too much attention to what Apple declares OSA to be on any particular day of the week.;p >>This is the API used by host applications, and it should in >>principle allow an application to be scripting-language-agnostic: No. All scriptable applications are client-agnostic, knowing nothing of the client that's sending them AppleEvents. (Exactly as things should be.) Both client and server in this case use AEM: the client to construct and dispatch AppleEvents; the server to decode the incoming AppleEvents and, in many cases, to assist in performing the operations requested by these events as well. Some applications - aside from Script Editor and co. - do employ both AEM and OSA. These are the applications that fall into the Recordable and/or Attachable categories. A recordable application is one that monitors messages sent from the GUI to the application model and converts them into AppleEvents as this happens; spewing these into a nearby script that the user can then run themselves every time they want to replay their original actions; basically just an elaborate system for creating macros. Attachable apps range from applications that include a Scripts menu (e.g. Eudora, Tex-Edit Plus) which allows users to execute scripts without having to open and execute them in the Script Editor (or launch them from the Finder if they're saved as applets) to something like Smile, which has an extensive scripting interface where every application object can have a script directly attached to it (while its core is C/C++[?], a large chunk of the Smile app is actually written in AppleScript). Man, what a doozy. It's now 3 a.m. here, so if you have trouble grokking this [rather lengthy] response then rest assured it's at least as likely my fault as yours. ;) HTH has -- http://freespace.virgin.net/hamish.sanderson/ From mwh at python.net Thu Jan 8 07:51:30 2004 From: mwh at python.net (Michael Hudson) Date: Thu Jan 8 07:51:32 2004 Subject: [Pythonmac-SIG] Re: the iBook's irresistible charms In-Reply-To: <1008D088-413A-11D8-AA7B-000A95AB5F10@cnrs-orleans.fr> (Konrad Hinsen's message of "Wed, 7 Jan 2004 18:51:04 +0100") References: <407D1960-4116-11D8-9B37-0050E4794D0F@uma.pt> <1008D088-413A-11D8-AA7B-000A95AB5F10@cnrs-orleans.fr> Message-ID: <2mekuazjql.fsf@starship.python.net> Konrad Hinsen writes: > Side remark: am I the only one who finds the most useful hints on > just about any computing topic on Python lists? Certainly not: the clue density on pyobjc-devel far outstrips that on cocoa-dev, just to pick a Mac related example... Cheers, mwh -- The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism. -- Paul Tomblin, asr From mjb at uma.pt Thu Jan 8 08:41:40 2004 From: mjb at uma.pt (Michael J. Barber) Date: Thu Jan 8 08:41:47 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: Message-ID: <63893F7F-41E0-11D8-9B37-0050E4794D0F@uma.pt> On Thursday, Jan 8, 2004, at 03:10 Europe/Lisbon, has wrote: >>>> BTW, one other thing: it'll save you a LOT of mental anguish if you >>>> realise from the start that application objects are referred to >>>> using basic relational queries [4]. Most folk don't realise this, >>>> especially since AppleScript uses syntax that looks much like >>>> standard OO [5]. >>>> > That is an extremely interesting comment. I've certainly never considered that point of view before, but it seems to address some of the murkier aspects of AppleScript's "object oriented" behavior. I'm not at all sure I that I understand the consequences of this fact, though. Specifically, what does this say about how Python should look as a substitute for AppleScript? Is the gensuitemodule-style approach of making an OO package that mimics the application dictionary just fundamentally misguided? That seems like a fair conclusion to draw from some of your comments on the MACSCRPT list that you pointed us towards earlier, if I understood things correctly. At any rate, thanks a lot for this message! I've found it really thought provoking and informative. From hengist.podd at virgin.net Thu Jan 8 09:52:45 2004 From: hengist.podd at virgin.net (has) Date: Thu Jan 8 09:53:48 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: Message-ID: Michael J. Barber wrote: >Your description of AppleScript is not far off, I'd say, but >AppleScript is better than a lot of websites would have you believe. >The core language is semantically like Python, but dumber. IMO, it >is most significantly marred by not having first-class functions or >decent mapping objects. Handlers are first-class objects; however this is not an officially supported behaviour and suffers from variable scoping problems that can introduce bugs in non-trivial use. Its lack of a native hash class is one of the many feature omissions that are, by modern standards, unacceptable for any high-level scripting language that wants to be taken seriously. Its lack of a built-in mechanism for managing and loading modules is another, and probably goes some way in explaining the dreadful dearth of decent libraries available for the language. (Whereas some features, like its prototype-based OOP model and native support for persistent objects, are - with a few inevitable caveats - actually rather nice and could actually put quite a lot of others to shame if they weren't being dragged down by AppleScript's other faults.) >The syntax can be awkward when writing scripts, but does make >examples easy to read, at least. Well-written AppleScript code is an absolute joy to read, and I personally prefer it over any other syntax I've yet encountered, including - in many respects - Python's own (which, despite its flaws, I've considerable admiration for). But as you say it can be a royal PITA learning how to put code together yourself. Consider AppleScript the "anti-Perl" - the definitive example of a "read-only language". :) >Most OSA examples are in AppleScript, and Apple seems to like to >treat OSA and AppleScript like they were synonyms. Yes. Probably a Marketing habit. Downright annoying. IMO this unfortunate association has done far more harm than good over the years, considering that high-level, AppleEvent-based Inter-Application Communication should, by rights, be as central to the whole Mac OS concept as pipes are to Unix's. (Though considering the fate of much 90s Mac OS technology, it should probably consider itself lucky just to be still around.) BTW, they also frequently conflate OSA (Open Scripting Architecture) with AEM (Apple Event Manager). (Something you just did here yourself, but as it's really their fault I'll let you off.;) Though I'm encouraged to see Chris Nebel actively attempting to clarify this issue over on the MACSCRPT list these last few days (The man deserves a solid pat on the back... followed by hearty cries of "Tell Us More!!":) >[JavaScriptOSA] >The documentation is aimed at programmers, including some examples >of how to construct and send raw AppleEvents. That could be a >useful starting point for sending AppleEvents in Python. Not really; working directly with AppleEvents is a right PITA to do in practice, which is why any self-respecting high-level language should plaster sufficient high-level APIs over it till it can no longer be seen. Bob's aeve module attempts to do this, as does my appscript, and Pudge's Mac::Glue. (There may be others, though I haven't heard about them.) Coming up with a _really good_ IAC API is pretty hard, however; and maybe impossible if you've not grokked the whole application scripting concept 100%. Which is actually damned difficult to do... the whole lot is deeply shrouded in fog and mystery, and what explanation is available from Apple is often less than helpful in dispelling this. [1] The first few early adopters who already know something of Mac IAC and are willing to brave some missing wiring and the odd hole in the wall are starting to appear now. But "just about usable" is still quite some way way from being ready for prime-time use, and until there's some decent documentation for it (tours, tutorials, examples of use, etc.) then I can't really recomment it for newcomers. All I can say is: 1. be patient; and: 2. it _will_ happen. :) Regards, has [1] Now I've grokked IAC, AEM, et-al for myself, I'm absolutely confident of developing just such an API at some point this year. It's just a matter of spending the time and effort to get it right. Once it's done, I'll publish the spec as a reference for others planning to develop IAC support in other languages. -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Thu Jan 8 11:52:54 2004 From: hengist.podd at virgin.net (has) Date: Thu Jan 8 11:59:29 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: <63893F7F-41E0-11D8-9B37-0050E4794D0F@uma.pt> References: <63893F7F-41E0-11D8-9B37-0050E4794D0F@uma.pt> Message-ID: Michael J. Barber wrote: >>>>>BTW, one other thing: it'll save you a LOT of mental anguish if >>>>>you realise from the start that application objects are referred >>>>>to using basic relational queries [4]. Most folk don't realise >>>>>this, especially since AppleScript uses syntax that looks much >>>>>like standard OO [5]. >>>>> >> >That is an extremely interesting comment. I've certainly never >considered that point of view before, but it seems to address some >of the murkier aspects of AppleScript's "object oriented" behavior. Mind that I'm talking about the behaviour of the Apple Event Manager and applications' scripting interfaces here - not about the AppleScript language. The AppleScript language - as a client of these services - exposes these behaviours directly to users. Meanwhile it has its own set of rules governing its own objects. What trips almost everybody up is that both application objects and language objects are represented in AppleScript using the _same syntax_. So folk, going (not unreasonably) by appearance, think they're one and the same when in fact they are completely separate entities. Language objects behave according to one set of rules; application objects behave according to another.[1] This is _very roughly_ comparable to the distinction you have between Python types and Python classes, only the division is far, far greater. Because not only are there differences in behaviour caused by differences in implementation, you also have differences due to the fact that each follows a different paradigm! That is, OO for language objects versus relational for application objects, although both operate on a hierarchical model.[2] >I'm not at all sure I that I understand the consequences of this >fact, though. Specifically, what does this say about how Python >should look as a substitute for AppleScript? Is the >gensuitemodule-style approach of making an OO package that mimics >the application dictionary just fundamentally misguided? It CAN be done this way: gensuitemodule does it, as does aeve. And proxy objects/object models are not an uncommon idea: psyco does it, Cocoa does it, plenty of others do it too. The question is: is this the most efficient way of doing it? In my considered opinion, no. Because what you really want to model in your own API is not the application object model, but the various AEM reference forms. Because that's the bit that really matters. The application's scriptable 'object model' is simply a user interface, no different to a GUI dialog with buttons and fields for users to click on as they wish. And the application dictionary is merely the user documentation for this interface, along with some mappings to convert from human-friendly names to AppleEvent codes for those clients, such as AppleScript, who wish to use them. Trying to read anything more into them can be done, but personally I see it as just creating a lot of unnecessary complexity. Not to mention the bone-juddering crunches that shifting paradigms without a double de-clutch can cause...;) [3] >At any rate, thanks a lot for this message! I've found it really >thought provoking and informative. I'm only too happy to [try to] explain this stuff as best I can. Apart from anything else, it helps me to hone my own thinking and learn how to express these ideas better to others (i.e. gratitude means I done okay, raspberries means it's back to the ol' drawing board tomorrow;). The main reason though is that unless there's a body of other folks out there who also totally 'get' this stuff then it won't matter a toss if I create the best AEM bridge in the whole damn universe, because nobody else is ever going to care about it but me! Therefore, consider your mission - should you choose to accept it - to read, comprehend, filter, critique, refine, recycle, extend, edit, format, present and finally disseminate anything good that comes out of these posts as far and wide as you possibly can. (Note that I'm going to collect them later on my website, just as a matter of record. But I won't pretend that it's anything more than a bunch of ad-hoc thoughts of variable quality tossed together on the fly, and for the time being at least I'll have to leave it to others, like yourself, to make something more useful out of it.) 5...4...3...2...1... has [1] That some of the rules for one may be similar to the rules for another is neither here nor there. If anything, any similarities just cause more confusion amongst users when they encounter the differences. [2] i.e. Please don't start thinking 'tables' a-la SQL when I use such hot-topic words as 'queries' and 'relational', or I'll be even more embarrassed...;) [3] Or: "How to restrict yourself to the subset of AEM's useful behaviours that can be shoehorned into an OO paradigm without really realising." Or: "Welcome to a whole new world o' pain!" Or... (No offence to Bob, or anyone else, intended!) -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Thu Jan 8 12:04:32 2004 From: hengist.podd at virgin.net (has) Date: Thu Jan 8 12:04:20 2004 Subject: Subject: Re: [Pythonmac-SIG] Applescript (correction) Message-ID: I wrote: >It CAN be done this way: gensuitemodule does it, as does aeve. And >proxy objects/object models are not an uncommon idea: psyco does it, >Cocoa does it, plenty of others do it too. Sorry, meant pyro (PYthon Remote Objects), not psyco. has -- http://freespace.virgin.net/hamish.sanderson/ From amundsen463 at yahoo.com Thu Jan 8 12:08:30 2004 From: amundsen463 at yahoo.com (Craig Amundsen) Date: Thu Jan 8 12:08:35 2004 Subject: [Pythonmac-SIG] Packman Question Message-ID: <488BD7EC-41FD-11D8-A0AA-000A959D4466@yahoo.com> Hi - I think I'm seeing a upgrade from 10.2.x to 10.3 issue here. I''ve installed the MacPython (MacPython-Panther-2.3-2.dmg) additions, and when I try to start Packman it bounces a couple of times and then the icon goes away. Is there a way I can fix this behavior without having to anything drastic like a clean system install? - Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 394 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040108/e18198cc/attachment.bin From amundsen463 at yahoo.com Thu Jan 8 12:25:32 2004 From: amundsen463 at yahoo.com (Craig Amundsen) Date: Thu Jan 8 12:25:36 2004 Subject: [Pythonmac-SIG] Packman Question In-Reply-To: <488BD7EC-41FD-11D8-A0AA-000A959D4466@yahoo.com> References: <488BD7EC-41FD-11D8-A0AA-000A959D4466@yahoo.com> Message-ID: Hi - > I think I'm seeing a upgrade from 10.2.x to 10.3 issue here. I''ve > installed the MacPython (MacPython-Panther-2.3-2.dmg) additions, and > when I try to start Packman it bounces a couple of times and then the > icon goes away. Is there a way I can fix this behavior without having > to anything drastic like a clean system install? In the words of Roseanne Rosanadana (or however you spell that), "Nevermind." Following the directions at the MacPython wiki page (http://homepages.cwi.nl/~jack/macpython/uninstall.html) and re-installing the additions did the trick. - Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 652 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040108/16b45dbb/attachment.bin From mjb at uma.pt Thu Jan 8 12:47:18 2004 From: mjb at uma.pt (Michael J. Barber) Date: Thu Jan 8 12:47:27 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: Message-ID: On Thursday, Jan 8, 2004, at 14:52 Europe/Lisbon, has wrote: > Michael J. Barber wrote: > >> Your description of AppleScript is not far off, I'd say, but >> AppleScript is better than a lot of websites would have you believe. >> The core language is semantically like Python, but dumber. IMO, it is >> most significantly marred by not having first-class functions or >> decent mapping objects. > > Handlers are first-class objects; however this is not an officially > supported behaviour and suffers from variable scoping problems that > can introduce bugs in non-trivial use. Its lack of a native hash class > is one of the many feature omissions that are, by modern standards, > unacceptable for any high-level scripting language that wants to be > taken seriously. Its lack of a built-in mechanism for managing and > loading modules is another, and probably goes some way in explaining > the dreadful dearth of decent libraries available for the language. > Thanks for the clarification on the handlers. According to the AppleScript Language Guide, "You cannot nest subroutine definitions; that is, you cannot define a subroutine within a subroutine definition." It seems like a case (one of many, sadly) where there is an arbitrary syntactic restriction on something that the underlying semantics support. Not quite the same thing as not being first class, though. My apologies if I misled anyone! The hashes are just tragic. It would not be a big syntactic change for AppleScript records to be modified to hash tables that use strings as keys. Instead, we've got something that looks like nothing other than Lisp property lists with symbols as keys, and no ability to work with symbols except as literals. >> The syntax can be awkward when writing scripts, but does make >> examples easy to read, at least. > > Well-written AppleScript code is an absolute joy to read, and I > personally prefer it over any other syntax I've yet encountered, > including - in many respects - Python's own (which, despite its flaws, > I've considerable admiration for). > > But as you say it can be a royal PITA learning how to put code > together yourself. Consider AppleScript the "anti-Perl" - the > definitive example of a "read-only language". :) Learning it is just awful. Tutorials that seem frightened of using the word "programming" and many, many applications with buggy scripting support, and it is hard to even get started. I know that I tried to learn AppleScript and gave up at least twice before "getting it" enough to do something useful. Actually, for me, it was learning Python that made it all come together, in particular in showing just how to make use of lists effectively, which few tutorials even attempt. It's clear to me that you're engaging in a bit -- but just a bit ;) -- of hyperbole about "read-only language." In case there's any AppleScript novices reading who might get scared off, though, I'll just add that AppleScript programming can actually be a lot of fun, too. With well thought-out function names, you do get a feeling of just sort of relaxing and writing some simple descriptions of what you want done. Of course, then you run into a poorly supported reference form, or buggy application scripting support, or an arbitrary syntactic limitation, and all that frustration from getting started comes rushing back... >> [JavaScriptOSA] >> The documentation is aimed at programmers, including some examples >> of how to construct and send raw AppleEvents. That could be a useful >> starting point for sending AppleEvents in Python. > > Not really; working directly with AppleEvents is a right PITA to do in > practice, which is why any self-respecting high-level language should > plaster sufficient high-level APIs over it till it can no longer be > seen. > I seem to have misread Alex's original message about AppleScript alternatives incorrectly, taking his interest in Apple events as deeper than it seems upon rereading. I wouldn't recommend it either. -- Michael From Rick.Termath at gov.yk.ca Thu Jan 8 13:22:48 2004 From: Rick.Termath at gov.yk.ca (Rick.Termath) Date: Thu Jan 8 13:23:12 2004 Subject: [Pythonmac-SIG] Users and groups module Message-ID: <6DD7370C9452D31192A10008C75D07531DCF5192@RAPTOR> Hello, I am working on a script to gather resource use etc on our ASIP OS9 Servers, and I have been unable to find a module that can talk to the users and groups. I am trying to gather information on student logins to the servers, in users and groups a "last login" date is displayed and I am trying to find a way to pull that information (if possible), any help, tips, pointers or suggestions would be appreciated. Thanks, Rick Termath Infomation Technology Support Services Yukon Department of Education 867-667-8948 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040108/b77e2beb/attachment.html From hengist.podd at virgin.net Thu Jan 8 16:34:09 2004 From: hengist.podd at virgin.net (has) Date: Thu Jan 8 16:37:04 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: Message-ID: Michael J. Barber wrote: >The hashes are just tragic. Absolutely. >It would not be a big syntactic change for AppleScript records to be >modified to hash tables that use strings as keys. This'll be how they're implemented underneath, as are script objects. But this aspect isn't exposed to users via the AppleScript environment, because that's not the way they were intended to be used. Instead, they perform a similar role to C structs (albeit without the static typing of property values and with the ability to concatenate). >Instead, we've got something that looks like nothing other than Lisp >property lists with symbols as keys, and no ability to work with >symbols except as literals. If you really want, you could write an OSAX that can manipulate records hash-style; there's already one that does this for OS9, but it's never been ported. Shouldn't be too hard if you know C though and are willing to dredge through Inside Macintosh for information on AE types (an AppleScript record is represented as an AERecord, and its properties are either stored as individual entries or within a key-value list stored under the 'usrf' key, depending on whether they're language/application defined ), and you can find skeleton osax code on Chris Nebel's public iDisk. That said, it would still be a kludge, and not without its own costs. The real solution would be for Apple to provide a proper hash type, and like a lot of features this is on their TO DO list. Though who knows if/when it might see the light of day; I wouldn't hold your breath. BTW, amongst the libraries I've written for AppleScript is one that provides a basic Dict object. Nowhere near as fast as a native hash type would be, as it's written in interpreted code with O(log n) lookup, but good enough for a reasonable range of uses. Not sure when that stuff'll be making an appearance (I've handed all my old AS stuff to someone else now) - although I expect it'll be a lot sooner than any native AS hash type.;) So watch that space, as they say. >>Well-written AppleScript code is an absolute joy to read, [...] >>But as you say it can be a royal PITA learning how to put code >>together yourself. Consider AppleScript the "anti-Perl" - the >>definitive example of a "read-only language". :) > >Learning it is just awful. Tutorials that seem frightened of using >the word "programming" The AppleScript language is marketed primarily to non-programmers. Unfortunately, behind the pretty-looking syntax it's still a _very_traditional_ programming language. It's like showing someone Windows and then sticking them on DOS - the wrong type of environment for its intended market. But instead of addressing the root problem they try to pretend that it doesn't exist by avoiding the big scary words you refer to. Truth is, AppleScript is simply too much for the sort of Mac user it's traditionally been marketed at to cope with. And it's not nearly enough for the new types of users that OS X has brought along. Putting IAC into Python will neatly solve the latter by simply going around it. (As for the former, who knows? LogoOSA?) >and many, many applications with buggy scripting support, and it is >hard to even get started. Uh-huh. This is somewhat self-perpetuating: because there aren't that many folk doing IAC, it's low on most developer's essential features list; but it's hard to attract more folk to IAC because many apps are so horrid to script. >It's clear to me that you're engaging in a bit -- but just a bit ;) >-- of hyperbole about "read-only language." Only as much as Perl haters - and Perl lovers too(!) - like to indulge when describing Perl as the definitive "read-only" language. Anyway, I'll have to drop out of discussing the AppleScript language now, though I'm still more than happy to talk AEM, OSA and Python, of course. has -- http://freespace.virgin.net/hamish.sanderson/ From paul.sargent at dsl.pipex.com Thu Jan 8 16:48:17 2004 From: paul.sargent at dsl.pipex.com (Paul Sargent) Date: Thu Jan 8 16:48:29 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: Message-ID: <5DFB1C00-4224-11D8-8EDA-000A95C5A776@dsl.pipex.com> >> It's clear to me that you're engaging in a bit -- but just a bit ;) >> -- of hyperbole about "read-only language." > > Only as much as Perl haters - and Perl lovers too(!) - like to indulge > when describing Perl as the definitive "read-only" language. > I assume you meant Perl was "Write-Only". I love using Perl for hacking up various sorts of scripts (normally text-mangling), but woe betide you if you want need to look back at code a year after you wrote it. It's compact, fast and powerful, but it reads like Arabic to an Englishman. (or maybe I need to work on my coding style :) -------------- 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/20040108/ebff5ca0/PGP.bin From hengist.podd at virgin.net Thu Jan 8 17:03:58 2004 From: hengist.podd at virgin.net (has) Date: Thu Jan 8 17:03:59 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: <5DFB1C00-4224-11D8-8EDA-000A95C5A776@dsl.pipex.com> References: <5DFB1C00-4224-11D8-8EDA-000A95C5A776@dsl.pipex.com> Message-ID: Paul Sargent wrote: >>>It's clear to me that you're engaging in a bit -- but just a bit >>>;) -- of hyperbole about "read-only language." >> >>Only as much as Perl haters - and Perl lovers too(!) - like to >>indulge when describing Perl as the definitive "read-only" >>language. >> > >I assume you meant Perl was "Write-Only". Oops! has -- http://freespace.virgin.net/hamish.sanderson/ From Jack.Jansen at cwi.nl Thu Jan 8 18:15:28 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Jan 8 18:15:37 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> Message-ID: <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> I'm going to read and understand all the stuff you answered some time tomorrow, and then I'll incorporate it into a second version of "The AppleScript architecture as Jack understands it", and I hope we can have a second round over it, so eventually we should hopefully end up with something that is understandable (at least to me) and correct (at least according to you:-). In the mean time there are two issues still open: >>>> BTW, one other thing: it'll save you a LOT of mental anguish if you >>>> realise from the start that application objects are referred to >>>> using basic relational queries [4]. Most folk don't realise this, >>>> especially since AppleScript uses syntax that looks much like >>>> standard OO [5]. Could you elaborate on this, please? If it means we should use another paradigm for Python scripting support (or at least allow escape from the OO paradigm to the other, presumably lower level but richer paradigm) it is important. Second question: from your remarks I assume that we could call the class/object/terminology stuff a layer. Does this layer have a name? > The encoding of the terminology resource is irrelevant to clients; > only application developers need worry their heads about such > nonsense, and the smart ones will likely use tools to generate it all > anyway. (In OS7-9 it was binary format; in OS X it's either key-value > lists or in XML plist format.) Do you happen to know of a sure way to get at terminology information? Script Editor always manages, but I seem to manage only in about 30-40% of the cases, and even then often with hacks. -- 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 Thu Jan 8 18:30:01 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 8 18:27:50 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> Message-ID: <94E34364-4232-11D8-B1A2-000A95686CD8@redivi.com> On Jan 8, 2004, at 6:15 PM, Jack Jansen wrote: > I'm going to read and understand all the stuff you answered some time > tomorrow, and then I'll incorporate it into a second version of "The > AppleScript architecture as Jack understands it", and I hope we can > have a second round over it, so eventually we should hopefully end up > with something that is understandable (at least to me) and correct (at > least according to you:-). > > In the mean time there are two issues still open: > >>>>> BTW, one other thing: it'll save you a LOT of mental anguish if >>>>> you realise from the start that application objects are referred >>>>> to using basic relational queries [4]. Most folk don't realise >>>>> this, especially since AppleScript uses syntax that looks much >>>>> like standard OO [5]. > > Could you elaborate on this, please? If it means we should use another > paradigm for Python scripting support (or at least allow escape from > the OO paradigm to the other, presumably lower level but richer > paradigm) it is important. > > Second question: from your remarks I assume that we could call the > class/object/terminology stuff a layer. Does this layer have a name? > >> The encoding of the terminology resource is irrelevant to clients; >> only application developers need worry their heads about such >> nonsense, and the smart ones will likely use tools to generate it all >> anyway. (In OS7-9 it was binary format; in OS X it's either key-value >> lists or in XML plist format.) > > Do you happen to know of a sure way to get at terminology information? > Script Editor always manages, but I seem to manage only in about > 30-40% of the cases, and even then often with hacks. I've been pretty successful, this is what resfinder does in the unreleased aeve: 1) Look in the resource fork of the executable (or the executable in the bundle) for 'aete' or 'aeut' 2) Look in .rsrc files in the bundle for 'aete' or 'aeut' 3) OSATerminology.GetAppTerminology(applicationPath) 4) send the app 'ascr' 'gdte' and hope it responds One issue is that sometimes it will find more than one terminology, so it tries to merge them. In at least one case I've seen an app respond with a minimal aete one way, and a full aete another. -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/20040108/a65a52aa/smime.bin From xalojkzawi at china.com Fri Jan 9 13:38:11 2004 From: xalojkzawi at china.com (Donald) Date: Fri Jan 9 01:37:05 2004 Subject: [Pythonmac-SIG] Re: %RND_UC_CHAR[2-8], an agitated lady Message-ID: sora alcohol univariate pug preachy smother inseminate bobolink watchdog cryptogram covalent archaism shady -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040110/4175a43f/attachment.html From paul.sargent at dial.pipex.com Thu Jan 8 17:28:42 2004 From: paul.sargent at dial.pipex.com (Paul Sargent) Date: Fri Jan 9 05:28:43 2004 Subject: [Pythonmac-SIG] PyObjC Templates Message-ID: <03BEC9D0-422A-11D8-8EDA-000A95C5A776@dial.pipex.com> I've been working through various ObjC + Cocoa tutorials recently, in an attempt to learn how to do a proper Cocoa GUI. Now I've got to say, although Cocoa is nice enough, I'm a little less enamoured with Objective C. I'm not sure what it is, but it just feels inconsistent in some way. So.... PyObjC here I come. Now I've just been sifting through the PyObjC documentation and noticed that it talks about some project builder templates. I installed PyObjC through the Package Manager from http://undefined.org/python/pimp/darwin-7.2.0-Power_Macintosh.plist (Bob, I believe that's yours). Am I going crazy or are the templates not in those packages? I was just interested to see if they were any use. Is it worth my time tracking these down? Paul -------------- 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/20040108/f9aecc82/PGP.bin From mjb at uma.pt Fri Jan 9 05:38:00 2004 From: mjb at uma.pt (Michael J. Barber) Date: Fri Jan 9 05:38:21 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: Message-ID: On Thursday, Jan 8, 2004, at 21:34 Europe/Lisbon, has wrote: > Truth is, AppleScript is simply too much for the sort of Mac user it's > traditionally been marketed at to cope with. And it's not nearly > enough for the new types of users that OS X has brought along. Putting > IAC into Python will neatly solve the latter by simply going around > it. (As for the former, who knows? LogoOSA?) > Seems like we really need a strong summary of IAC possibilities for new OS X users. I'm fairly busy at the moment, but will see if I can't open up some time in my schedule. > Anyway, I'll have to drop out of discussing the AppleScript language > now, though I'm still more than happy to talk AEM, OSA and Python, of > course. > Sounds about right, we've drifted a ways from discussing MacPython issues. Thanks for the comments. Michael From oussoren at cistron.nl Fri Jan 9 06:23:25 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Fri Jan 9 06:23:31 2004 Subject: [Pythonmac-SIG] PyObjC Templates In-Reply-To: <03BEC9D0-422A-11D8-8EDA-000A95C5A776@dial.pipex.com> References: <03BEC9D0-422A-11D8-8EDA-000A95C5A776@dial.pipex.com> Message-ID: <3DD61322-4296-11D8-B390-0003931CFE24@cistron.nl> On 8 jan 2004, at 23:28, Paul Sargent wrote: > I've been working through various ObjC + Cocoa tutorials recently, in > an attempt to learn how to do a proper Cocoa GUI. Now I've got to say, > although Cocoa is nice enough, I'm a little less enamoured with > Objective C. I'm not sure what it is, but it just feels inconsistent > in some way. > > So.... PyObjC here I come. Welcome to the club! > > Now I've just been sifting through the PyObjC documentation and > noticed that it talks about some project builder templates. I > installed PyObjC through the Package Manager from > http://undefined.org/python/pimp/darwin-7.2.0-Power_Macintosh.plist > (Bob, I believe that's yours). > > Am I going crazy or are the templates not in those packages? I was > just interested to see if they were any use. Is it worth my time > tracking these down? IIRC the official Package Manager database contains a 'PyObjC Extras' package that contains at least the documentation and possibly also the templates. The PyObjC sources definitively include the templates. However, these templates are only usefull for Mac OS X 10.2, OSX 10.3 no longer uses Project Builder but uses Xcode. We have 1 Xcode template in CVS. Like the standard Project Builder/Xcode templates you'll get a fully functionally program when you instantiate a template. As a vi junky I usually don't bother with using PB/Xcode, so I cannot tell you if it will be worthwhile to spent time installing them. I suppose it's time to work on a new release for PyObjC, the official release is not as usefull as it could be on OSX 10.3. Ronald From hengist.podd at virgin.net Fri Jan 9 05:13:56 2004 From: hengist.podd at virgin.net (has) Date: Fri Jan 9 06:41:27 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> Message-ID: Jack wrote: >I'm going to read and understand all the stuff you answered some >time tomorrow, Good luck! >and then I'll incorporate it into a second version of "The >AppleScript architecture as Jack understands it", and I hope we can >have a second round over it, so eventually we should hopefully end >up with something that is understandable (at least to me) and >correct (at least according to you:-). :) Sounds good. >In the mean time there are two issues still open: > >>>>>BTW, one other thing: it'll save you a LOT of mental anguish if >>>>>you realise from the start that application objects are referred >>>>>to using basic relational queries [4]. Most folk don't realise >>>>>this, especially since AppleScript uses syntax that looks much >>>>>like standard OO [5]. > >Could you elaborate on this, please? If it means we should use >another paradigm for Python scripting support (or at least allow >escape from the OO paradigm to the other, presumably lower level but >richer paradigm) it is important. Well, I've followed AppleScript's approach, which is to do the query-building thing, then cover it with syntactic sugar to make it look and feel pleasant and familiar; eg: - AppleScript: a reference to first character of every paragraph of text of document "ReadMe.txt" - Python: app('TextEdit.app').documents['ReadMe.txt'].text.paragraphs.characters[0] Whereas the unsugared form would look like: app('TextEdit.app').elems('document').byName('ReadMe.txt').prop('text').elems('paragraph').elems('character').byIndex(0) Now this is perfectly usable (it's part of my 'generic API' specification), and for languages that don't provide any options to sugar it it's probably the only way to do it. But I doubt anyone but a masochist would ever _want_ to write it this way, at least not if they have any sort of choice. ;) IMO, one of the ironies of the AEM API, at least as it applies to scripters, is that had its designers cooked up some cheesy mini-language using some sort of crude SQL-ish syntax, we wouldn't all be in the fix we are today with folks confusing it for something else. Mastery of such icky crap would be a respected artform. Eventually, of course, some smart cookie would write a module that wraps all the nasty string-munging nonsense behind a nice programmatic API; and so on... Seriously though, I have considered writing such a beast, using, say, a hybrid syntax that'll look unfamiliar enough to avoid folk forming premature misconceptions about how it works. My knowledge of parsers is just about good enough, and of course Python has some excellent tools for building them. And maybe I will do this someday; it might have some value for folk who like the CLI, for example. But right now it'd just be a big ol' diversion for which I don't have the time. So I think we should go with the syntax we have. We just need to grab newcomers for the first five minutes - so they don't go looking at the syntax and forming any silly notions of how it works - while we explain to them that 'application scripting is hierarchical relational blah-blah-blah'. Some sort of in-your-face, one-page 'Introduction to Application Scripting for Python' document, full of big type and pretty pictures. Something to plan for. You think? >Second question: from your remarks I assume that we could call the >class/object/terminology stuff a layer. Does this layer have a name? The terminology resource is just that: a resource; 'metadata' as Bob put it. It's not a layer, but it's freely available to any layers that might wish to use it. >Do you happen to know of a sure way to get at terminology >information? Script Editor always manages, but I seem to manage only >in about 30-40% of the cases, and even then often with hacks. OSA's GetAppTerminology() ought to work - it _is_ the formal API for this, after all. I know Donovan's GetAppTerminology wrapper hasn't had much luck recently with this (he doesn't seem to know why either), so if you're having trouble with your own OSA wrapper then the best thing to do would be to post your problem to the AS Implementors List: Chris Nebel, one of the Apple engineers appears on there on a regular basis, and there's quite a few experienced developers that frequent it too. If it turns out that the problem is with OSA rather than anything on your side, it's something that'd merit lighting an almighty fire under Apple to fix asabp. If that doesn't get you anywhere, I'm on friendly terms with one of the Satimage guys (they do the Smile editor) and could try mining him for info. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Fri Jan 9 06:41:20 2004 From: hengist.podd at virgin.net (has) Date: Fri Jan 9 06:41:32 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: <94E34364-4232-11D8-B1A2-000A95686CD8@redivi.com> References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> <94E34364-4232-11D8-B1A2-000A95686CD8@redivi.com> Message-ID: Bob wrote: >>Do you happen to know of a sure way to get at terminology >>information? Script Editor always manages, but I seem to manage >>only in about 30-40% of the cases, and even then often with hacks. > >I've been pretty successful, this is what resfinder does in the >unreleased aeve: > 1) Look in the resource fork of the executable (or the >executable in the bundle) for 'aete' or 'aeut' > 2) Look in .rsrc files in the bundle for 'aete' or 'aeut' > 3) OSATerminology.GetAppTerminology(applicationPath) > 4) send the app 'ascr' 'gdte' and hope it responds Impressive... and scary. I can't believe it should be this hard to get the stupid thing. Hopefully Jack can find out more re. the OSA method. >One issue is that sometimes it will find more than one terminology, >so it tries to merge them. In at least one case I've seen an app >respond with a minimal aete one way, and a full aete another. Was that iTunes? (IBeen wondering how you're supposed to get its aete.) Ta, has -- http://freespace.virgin.net/hamish.sanderson/ From mjb at uma.pt Fri Jan 9 07:14:53 2004 From: mjb at uma.pt (Michael J. Barber) Date: Fri Jan 9 07:15:21 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: Message-ID: <6E903A98-429D-11D8-9B37-0050E4794D0F@uma.pt> On Thursday, Jan 8, 2004, at 16:52 Europe/Lisbon, has wrote: > Michael J. Barber wrote: > >> I'm not at all sure I that I understand the consequences of this >> fact, though. Specifically, what does this say about how Python >> should look as a substitute for AppleScript? Is the >> gensuitemodule-style approach of making an OO package that mimics the >> application dictionary just fundamentally misguided? > > It CAN be done this way: gensuitemodule does it, as does aeve. And > proxy objects/object models are not an uncommon idea: psyco does it, > Cocoa does it, plenty of others do it too. > > The question is: is this the most efficient way of doing it? In my > considered opinion, no. Because > what you really want to model in your own API is not the application > object model, but the various AEM reference forms. Because that's the > bit that really matters. The application's scriptable 'object model' > is simply a user interface, no different to a GUI dialog with buttons > and fields for users to click on as they wish. And the application > dictionary is merely the user documentation for this interface, along > with some mappings to convert from human-friendly names to AppleEvent > codes for those clients, such as AppleScript, who wish to use them. > Trying to read anything more into them can be done, but personally I > see it as just creating a lot of unnecessary complexity. Not to > mention the bone-juddering crunches that shifting paradigms without a > double de-clutch can cause...;) [3] > > OK, things are becoming clearer to me. I'm going to summarize briefly. We've got several pieces that work together. Of particular interest to us are AEM, OSA, and the so-called object model. The object model may be part of the OSA API, I'm still sort of unclear on that; regardless, it is something that is worth focusing on specifically, because it is what we'll normally deal with when we write a program depending on IAC. AEM has a relational nature, which masquerades as object oriented in AppleScript and most Pythonic approaches, due to the focus on the object model. The object model provides a convenient way for getting to the AEM. OSA provides ways for, e.g., scripting languages to interact with AEM. OSA and AEM are complementary, but distinct. There are then several issues: (1) The structure of the interface to AEM. (2) Making one or more convenient interfaces to the application "object model" for the programmer. An OO package is a common approach, but we should recognize that such an approach may not give a perfect fit to (1). (3) Making python into an OSA client, minimally for fetching the terminology needed in (2) and more ambitiously for making Python into a component language like AppleScript or JavascriptOSA. These issues interact, but are not identical. Treating them as the same could result in some unnecessarily strong coupling that leads to those "bone-juddering crunches." Does that seem approximately correct? Gah, I'm feeling TLA burnout... -- Michael From mitchchapman at earthlink.net Fri Jan 9 08:44:20 2004 From: mitchchapman at earthlink.net (Mitch Chapman) Date: Fri Jan 9 08:43:33 2004 Subject: [Pythonmac-SIG] PyObjC Templates In-Reply-To: <3DD61322-4296-11D8-B390-0003931CFE24@cistron.nl> References: <03BEC9D0-422A-11D8-8EDA-000A95C5A776@dial.pipex.com> <3DD61322-4296-11D8-B390-0003931CFE24@cistron.nl> Message-ID: On Jan 9, 2004, at 4:23 AM, Ronald Oussoren wrote: > On 8 jan 2004, at 23:28, Paul Sargent wrote: >> Am I going crazy or are the templates not in those packages? I was >> just interested to see if they were any use. Is it worth my time >> tracking these down? > > IIRC the official Package Manager database contains a 'PyObjC Extras' > package that contains at least the documentation and possibly also the > templates. > > The PyObjC sources definitively include the templates. However, these > templates are only usefull for Mac OS X 10.2, OSX 10.3 no longer uses > Project Builder but uses Xcode. We have 1 Xcode template in CVS. Granted they're not Xcode-Native, but I have successfully used the templates with Xcode. You just have to install the templates where Xcode is willing to look for them. If you pull PyObjC from CVS the templates can be found in .../ProjectBuilder Extras/Project Templates/. Create the folder ~/Library/Application Support/Apple/Developer Tools/Project Templates/Application under your login directory and copy all of the project template folders into it. (Or, to make the templates available to everyone on your system, copy them into /Library/Application Support/[etc.].) Then in Xcode select "File -> New Project..." and you should see e.g. "Cocoa-Python Application" in the list of project types. The only problem I've had so far was a temporarily un-buildable Cocoa-Python-Objc Application on my iBook. But I *think* that was because I got distracted and tried building just after removing the sole Objective-C module from my application support framework :) -- Mitch From Jack.Jansen at cwi.nl Fri Jan 9 10:06:22 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 9 10:06:16 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> Message-ID: <62F44DBB-42B5-11D8-AA42-000A958D1666@cwi.nl> On 9-jan-04, at 11:13, has wrote: > Well, I've followed AppleScript's approach, which is to do the > query-building thing, then cover it with syntactic sugar to make it > look and feel pleasant and familiar; eg: > > - AppleScript: > > a reference to first character of every paragraph of text of > document "ReadMe.txt" > > - Python: > > > app('TextEdit.app').documents['ReadMe.txt'].text.paragraphs.characters[ > 0] > > > Whereas the unsugared form would look like: > app('TextEdit.app').elems('document').byName('ReadMe.txt').prop('text') > .elems('paragraph').elems('character').byIndex(0) [>FLASH<] after years and years of struggling and failing to understand the AppleScript one simple example causes Jack's enlightenment. THANK YOU VERY MUCH!!!!!!! One question remains: are all these objects selectors? Are they all of the same Python class? -- 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 dethe.elza at blastradius.com Fri Jan 9 13:37:22 2004 From: dethe.elza at blastradius.com (Dethe Elza) Date: Fri Jan 9 13:37:26 2004 Subject: [Pythonmac-SIG] Re: Building 4Suite on OS X (Panther) Message-ID: Bob, thanks for the tips. I've finally gotten 4Suite working and discovered that I was wrong in thinking there was no Python DOM implementation which supported DOM Mutation Events (4DOM does). Life is good, and you rock. --Dethe "...our universities, I suggest, are not half-way out of the fifteenth century. [...] The three or four years' course of lectures, the bachelor who knows some, the master who knows most, the doctor who knows all, are ideas that have come down unimpaired from the Middle Ages. Nowadays no one should end his learning while he lives and these university degrees are preposterous. [...] Educationally we are still for all practical purposes in the coach and horse and galley stage." H. G. Wells From bob at redivi.com Fri Jan 9 13:43:47 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 9 13:41:34 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> <94E34364-4232-11D8-B1A2-000A95686CD8@redivi.com> Message-ID: On Jan 9, 2004, at 6:41 AM, has wrote: > Bob wrote: > >>> Do you happen to know of a sure way to get at terminology >>> information? Script Editor always manages, but I seem to manage only >>> in about 30-40% of the cases, and even then often with hacks. >> >> I've been pretty successful, this is what resfinder does in the >> unreleased aeve: >> 1) Look in the resource fork of the executable (or the executable in >> the bundle) for 'aete' or 'aeut' >> 2) Look in .rsrc files in the bundle for 'aete' or 'aeut' >> 3) OSATerminology.GetAppTerminology(applicationPath) >> 4) send the app 'ascr' 'gdte' and hope it responds > > Impressive... and scary. I can't believe it should be this hard to get > the stupid thing. Hopefully Jack can find out more re. the OSA method. > > >> One issue is that sometimes it will find more than one terminology, >> so it tries to merge them. In at least one case I've seen an app >> respond with a minimal aete one way, and a full aete another. > > Was that iTunes? (IBeen wondering how you're supposed to get its aete.) Off the top of my head, I'm pretty sure that iTunes is a case of #2 .. I don't believe it has multiple terminologies to merge, I think I've only seen that in 3rd party software. -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/20040109/31d5a50e/smime.bin From hengist.podd at virgin.net Fri Jan 9 11:43:37 2004 From: hengist.podd at virgin.net (has) Date: Fri Jan 9 14:30:10 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: <62F44DBB-42B5-11D8-AA42-000A958D1666@cwi.nl> References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> <62F44DBB-42B5-11D8-AA42-000A958D1666@cwi.nl> Message-ID: Jack Jansen wrote: >>a reference to first character of every paragraph of text of >>document "ReadMe.txt" >> >> app('TextEdit.app').documents['ReadMe.txt'].text.paragraphs.characters[0] >> >>app('TextEdit.app').elems('document').byName('ReadMe.txt').prop('text').elems('paragraph').elems('character').byIndex(0) > >[>FLASH<] > >after years and years of struggling and failing to understand the >AppleScript one simple example causes Jack's enlightenment. Cool. Now write this epiphany down and post it somewhere for everyone else to see. :) >One question remains: are all these objects selectors? Yep. (I've been calling them 'Refs', but 'selector' sounds better so maybe I'll change to that.) To summarise: - ref.prop('foo') returns an object specifying the 'foo' property of ref - ref.elems('bar') returns an object specifying all 'bar' elements of ref - all objects implement prop() and elem() methods - each 'all elements' selector provides additional methods allowing you to narrow the selection: byName(), byIndex(), byID(), byRange(), byTest() There's a few other methods that appear on some selectors - things like next() and previous() for specifying an element relative to another - but these are the main ones. >Are they all of the same Python class? No. (They're all descended from the same base class though.) Each method instantiates and returns something different: prop() returns a PropertyRef object that knows about properties and how to construct an AEDesc typeObjectSpecifier of formProperty, byName() returns an ElementByNameRef object, etc. has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Fri Jan 9 14:21:01 2004 From: hengist.podd at virgin.net (has) Date: Fri Jan 9 14:30:15 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: <6E903A98-429D-11D8-9B37-0050E4794D0F@uma.pt> References: <6E903A98-429D-11D8-9B37-0050E4794D0F@uma.pt> Message-ID: Michael J. Barber wrote: >OK, things are becoming clearer to me. I'm going to summarize briefly. > >We've got several pieces that work together. Of particular interest >to us are AEM, OSA, and the so-called object model. "application object model" >The object model may be part of the OSA API, [...] >I'm still sort of unclear on that; regardless, it is something that >is worth focusing on specifically, because it is what we'll normally >deal with when we write a program depending on IAC. To summarise: - Each application implements its own scriptable object model. (Which may or may not follow the structure of its actual Model layer - but this isn't something that users ever need to think about.) Essentially this is just another User Interface; peer to other application user interfaces such as GUI, CLI and Web-based. Just pushen ze buttons and watchen das blinkenlights. - AEM defines the structures used to specify an object, a property, an element or elements, and so on; as well as a bunch of structures for representing basic datatypes such as strings, numbers, lists, etc. - OSA is merely a mechanism for componentising your scripting language, for those that like to plug-n-play different languages into their environments (script editors, attachable apps), plus a couple of general calls for getting terminology resources. Does this help? >AEM has a relational nature, which masquerades as object oriented in >AppleScript and most Pythonic approaches, due to the focus on the >object model. Well, it _looks_ like OO, at least superficially. >The object model provides a convenient way for getting to the AEM. >OSA provides ways for, e.g., scripting languages to interact with >AEM. See summary above. >OSA and AEM are complementary, but distinct. Yes.(!) >There are then several issues: >(1) The structure of the interface to AEM. A pig-ugly bucket of loose parts. Very much Do-It-Yourself. Best hidden under a higher level interface. >(2) Making one or more convenient interfaces to the application >"object model" for the programmer. I think I get your meaning. To be a bit more precise: we write a module that connects to the AEM. This allows the scripter to manipulate an application's object model by calling the module's API. This is what I'm doing: appscript is a Python-specific implementation of a friendly, intelligent high-level API. The generic API I'm designing will provide a common pattern for developers on other languages to follow when implementing their own high-level AEM interfaces. BTW, I'm even wondering if it'd be worth doing an implementation of the generic API in C/C++/Obj-C. This'd reduce the amount of work needed to write a module for any language even further: basically one would just write a wrapper around this API, plus whatever syntactic sugar seems appropriate. Which is a lot more convenient than building directly atop the low-level AEM API, where each developer has to reimplement all the generic API logic themselves; hardly a good example of portable code reuse. > An OO package is a common approach, but we should recognize that >such an approach may not give a perfect fit to (1). That depends on what you mean by an 'OO package'. Both appscript and aeve are implemented using OOP, but their APIs are very different. Appscript creates 'selectors': objects that describe a path to one or more objects in the application object model. Aeve builds a proxy object model representing the structure of the application object model. Appscript fits perfectly with AEM because it simply presents what's already there, though at a higher-level. Aeve suffers a bit of impedance mismatch because it imposes an OO worldview on top of a relational one; but that's by choice, not necessity. >(3) Making python into an OSA client, minimally for fetching the >terminology needed in (2) Yep. >and more ambitiously for making Python into a component language >like AppleScript or JavascriptOSA. IMO the main advantage of this - at least in theory - is that it'll allow you to attach Python scripts to attachable applications. (Attachability is one of those terrific ideas that's currently much under-used and under-supported, but could really take off if PerlOSA and PythonOSA started bringing in lots of new users for it.) In practice, there may be problems with attachability from our POV, as so far the Cocoa frameworks only seem to support AppleScript. (Perhaps they forgot what the 'Open' part of OSA means?) Personally, I think full OSA support will only really become useful if we can persuade Apple to improve their frameworks or create our own GenericOSALanguage class and try to persuade application developers to use it in place of NSAppleScript. Though you'll still get some benefits, such as the ability to edit Python scripts from Script Editor, etc. I'd also mention that Philip Aker (who I know from my AppleScript days) is working on a generic OSA language component framework, based on the work he's done on a TclOSA component. Definitely something to explore before going ahead with a PythonOSA. BTW, I'll add a (4) here: designing and building a Python module/framework that'll make it easier for folk developing full-blown Mac apps to add scriptability. It's something at the back of my mind while working on appscript, as appscript will provide a good foundation for Python apps to interpret _incoming_ events in addition to generating outgoing ones as it can already do. Of course, there'll be a lot more to do on top of that, which is why I'm not going to think any further on it till stages 1 to 3 are complete. There may also be opportunities for cross-pollination between what we're doing and plans to improve OSS application scripting support by other parties; e.g. see the Shuttleworth Foundation's bounties page for 2004. So there's lots of interesting possibilities to explore - once we've nailed all the basic stuff down first, of course. >These issues interact, but are not identical. Yes. >Treating them as the same could result in some unnecessarily strong >coupling that leads to those "bone-juddering crunches." Agreed. My gut feeling on Cocoa's built-in scripting support is it already has excessively tight coupling between AEM, OSA, AppKit and AppleScript. And if there's one thing I've learned over the years (the hard way, what else?!;), it's to keep tasks small, simple, and well separated. (Of course Unix already taught us this thirty years ago... So sue me, I'm a slow learner.;) Dunno about you, but I think we're starting to make some damned good headway too, all thanks to this thread. Pats on back all round will be due at the end. >Gah, I'm feeling TLA burnout... I'm just feeling burnout. ;) HTH has -- http://freespace.virgin.net/hamish.sanderson/ From Jack.Jansen at cwi.nl Fri Jan 9 16:02:59 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 9 16:03:21 2004 Subject: [Pythonmac-SIG] Users and groups module In-Reply-To: <6DD7370C9452D31192A10008C75D07531DCF5192@RAPTOR> References: <6DD7370C9452D31192A10008C75D07531DCF5192@RAPTOR> Message-ID: <34C15D52-42E7-11D8-ABD4-000A27B19B96@cwi.nl> On 8-jan-04, at 19:22, Rick.Termath wrote: > I am working on a script to gather resource use etc on our ASIP OS9 > Servers, and I have been unable to find a module that can talk to the > users and groups. I am trying to gather information on student logins > to the servers, in users and groups a "last login" date is displayed > and I am trying to find a way to pull that information (if possible), > any help, tips, pointers or suggestions would be appreciated. If you can obtain the information with an AppleScript program you should be able to run gensuitemodule on the relevant application (or control panel, or whatever) and get a Python interface to it. If you cannot get the information in AppleScript you'd have to create a C module to interface to the relevant APIs, assuming there are such APIs. The former should be fairly simple, the latter is complicated. As always, your best bet for questions like this is to ask on the pythonmac-SIG. Even though you may be the first person to attempt this specific interface there'll usually be people who have helpful insights, etc. -- 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 Jack.Jansen at cwi.nl Fri Jan 9 16:58:30 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 9 16:58:55 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> <62F44DBB-42B5-11D8-AA42-000A958D1666@cwi.nl> Message-ID: On 9-jan-04, at 17:43, has wrote: > Jack Jansen wrote: > >>> a reference to first character of every paragraph of text of >>> document "ReadMe.txt" >>> >>> >>> app('TextEdit.app').documents['ReadMe.txt'].text.paragraphs.character >>> s[0] >>> >>> app('TextEdit.app').elems('document').byName('ReadMe.txt').prop('text >>> ').elems('paragraph').elems('character').byIndex(0) >> One question remains: are all these objects selectors? > > Yep. (I've been calling them 'Refs', but 'selector' sounds better so > maybe I'll change to that.) To summarise: I think selector is the apple term. At least, I don't know where I would have picked it up otherwise:-) > > - ref.prop('foo') returns an object specifying the 'foo' property of > ref > > - ref.elems('bar') returns an object specifying all 'bar' elements of > ref > > - all objects implement prop() and elem() methods > > - each 'all elements' selector provides additional methods allowing > you to narrow the selection: byName(), byIndex(), byID(), byRange(), > byTest() Okay, so far so good. And ClassRef and PropertyRef classes have a method __getattr__ that will do something similar to first trying elems(args) and then prop(args) for ClassRefs; something similar for __getitem__ being mapped to byName() for the relevant class, etc. Right? If I'm right so far then I would like to make one suggestion: rename elems() and prop() to something different, to forestall name clashes. I think I'd suggest _elements() and _property(). -- 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 euuwjww at terra.com Fri Jan 9 17:09:54 2004 From: euuwjww at terra.com (Janine Amos) Date: Fri Jan 9 17:12:36 2004 Subject: [Pythonmac-SIG] Re: GPWSR, almost followed after Message-ID: middleweight cognizant tuff embouchure matrimonial crisp tableaux lagrange allemand azimuthal profiteer rickety supercilious wallboard macarthur nyc sheen almagest propelling acquiesce -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040110/7fd06c5a/attachment-0001.html From bob at redivi.com Fri Jan 9 18:06:14 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 9 18:04:14 2004 Subject: [Pythonmac-SIG] ANN: SolarWolf 1.4 for OS X Message-ID: <6C5789FC-42F8-11D8-AA7D-000A95686CD8@redivi.com> I've packaged up Pete's latest version of SolarWolf ( http://pygame.org/shredwheat/solarwolf/ ) for OS X. It should work on 10.2 and 10.3 and should not have any external dependencies (even Python ;). Until the SolarWolf page is updated, you can get it here: http://undefined.org/python/SolarWolf-1.4.dmg (4.3mb) -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/20040109/1fdfaf9e/smime.bin From hengist.podd at virgin.net Fri Jan 9 19:22:34 2004 From: hengist.podd at virgin.net (has) Date: Fri Jan 9 19:29:51 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: <061706C8-4166-11D8-A551-000A27B19B96@cwi.nl> <8C3C85D1-4230-11D8-86A8-000A27B19B96@cwi.nl> <62F44DBB-42B5-11D8-AA42-000A958D1666@cwi.nl> Message-ID: Jack Jansen wrote: >>>One question remains: are all these objects selectors? >> >>Yep. (I've been calling them 'Refs', but 'selector' sounds better >>so maybe I'll change to that.) To summarise: > >I think selector is the apple term. You're maybe confusing 'object specifier', which is the name given to the structures that Apple Event Manager deals in, with 'selector', which is used in ObjC/Cocoa to refer to a method. Still, I think I like 'selector', because one of the problems with saying 'object specifier' is that some kinds of object specifiers (those of formRange or formTest) can refer to more than one application object, despite the name having a suggestively singular sound to it. That's why I chose to use 'Ref' in appscript; although I don't much like this either as it seems to suggest that a single Ref object represents an entire reference in itself whereas it actually represents only a single level of selection. Whereas any practical application object reference will consist of two or more Ref objects (the minimum for doing anything useful being the ApplicationRef plus a PropertyRef or some sort of element Ref). In comparison to these, 'selector' seems a reasonably neutral yet also fairly suggestive term, so may be worth adopting as our jargon of choice for describing the relevant appscript objects. IMHO, when it comes to measuring relative degrees of difficulty: product name > operational jargon > API design > implementation. Who'da thunk the coding was the easiest bit, eh?;) >At least, I don't know where I would have picked it up otherwise:-) >> >>- ref.prop('foo') returns an object specifying the 'foo' property of ref >> >>- ref.elems('bar') returns an object specifying all 'bar' elements of ref >> >>- all objects implement prop() and elem() methods >> >>- each 'all elements' selector provides additional methods allowing >>you to narrow the selection: byName(), byIndex(), byID(), >>byRange(), byTest() > >Okay, so far so good. And ClassRef and PropertyRef classes have a >method __getattr__ that will do something similar to first trying >elems(args) and then prop(args) for ClassRefs; To clarify, appscript's ScriptingInterface module classes and methods are basically my generic API design _after_ it's been sugared up with Python magic methods. There's no methods actually named elems(), prop(), byName(), byRange(), etc. as their code has been rearranged and stuck into __getattr__, __getitem__, __getslice__, etc. In terms of timeline, I actually started by designing the appscript API, and am now reverse engineering it to create the generic API specification [1]. As a result, the appscript API is much further on than generic API, which is why I haven't just published the full generic API spec and left you to digest it before continuing the discussion: the wretched thing simply ain't done yet! Now, showing examples in generic API form is good for showing what's actually going on. However, if you want to look at any operational code you'll have to look at appscript's ScriptingInterface module, which uses the same class structure as generic API but with heavily redesigned methods. Sorry I wasn't clearer in explaining what you'd be looking at. In future I'll label any code examples as either 'appscript' or 'generic API', and will indicate more clearly when I'm talking about generic API or appscript's specific, sugared-up, version. ... Anyway, this'd probably be a good time to take a short break: you for a chance to digest all that's been discussed thus far; me to collapse in a heap after an especially strenuous week's emailing! ;) So let's pick up again on Monday; meantime have a good weekend! has [1] Generic API, if I've not stated it before, is a sort of 'lowest common denominator' design specification that other developers can easily implement on other languages and then refactor to give it whatever appearance is most convenient for users there. -- http://freespace.virgin.net/hamish.sanderson/ From xbjsplqffom at china.com Fri Jan 9 06:04:25 2004 From: xbjsplqffom at china.com (Elvis) Date: Sat Jan 10 05:04:36 2004 Subject: [Pythonmac-SIG] Re: %RND_UC_CHAR[2-8], in a tolstoy Message-ID: berth focus businessman eavesdropper bonneville quixote doublet lucy freer though priam col aden humidify antenna bough entourage evaporate conclusion batch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040109/4c285d4d/attachment.html From yprwzd at india.com Fri Jan 9 23:55:48 2004 From: yprwzd at india.com (Mark Pereira) Date: Sat Jan 10 12:01:58 2004 Subject: [Pythonmac-SIG] Re: TGXFW, good - cognac! Message-ID: assess platte yield scimitar escadrille deoxyribose leaky blurb cf waveguide insurgent thoroughbred cryptography nsf ostensible clumsy coherent bat deoxyribonucleic above enchantress -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040110/0f4aada6/attachment.html From nazoi at canada.com Sat Jan 10 15:14:16 2004 From: nazoi at canada.com (Wray Jayne) Date: Sat Jan 10 15:43:28 2004 Subject: [Pythonmac-SIG] Re: EF, the more confusing Message-ID: cake walgreen mitochondria per pirate jerry schedule stale beheld rabbi coma millstone bedimming frowzy cattleman indistinguishable suit contrariwise blight sarah callisto pallid eben dingo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040110/5bc8b565/attachment.html From ldpbp at hongkong.com Sun Jan 11 06:23:16 2004 From: ldpbp at hongkong.com (Sweeney) Date: Sat Jan 10 18:20:07 2004 Subject: [Pythonmac-SIG] Re: QVPVBU, to this fagott Message-ID: cytoplasm upside bonfire giovanni phosphorylate sharpshoot earmark indissoluble patterson higgins talmud balboa newspapermen endorse archaism prolate bale onrushing credent airway four hilarious braggart renovate -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040111/c8ee40b2/attachment.html From qhhothmt at cnnic.net.cn Sat Jan 10 14:25:35 2004 From: qhhothmt at cnnic.net.cn (Rebecca) Date: Sun Jan 11 02:25:39 2004 Subject: [Pythonmac-SIG] Re: KTJCBRE, against the polonaise Message-ID: waldo headlight colony hong background simplicial curfew parrot manfred indiscretion graff detour penalty irvin assassinate baste bimini uruguay martinson actinolite dressmake frankel laze stokes inside combine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040110/4ed046b7/attachment.html From billb at mousa.demon.co.uk Sun Jan 11 09:21:56 2004 From: billb at mousa.demon.co.uk (Bill Bedford) Date: Sun Jan 11 09:22:03 2004 Subject: [Pythonmac-SIG] ZODB3.2 Message-ID: <20040111142156243777.GyazMail.billb@mousa.demon.co.uk> Has anyone tried to install ZODB 3.2? I get this error when I run test.py Traceback (most recent call last): File "/Users/billbedford/Library/OpenUp/ZODB3-3_2c1_0/ZODB3-3.2c1/test.py", line 803, in ? process_args() File "/Users/billbedford/Library/OpenUp/ZODB3-3_2c1_0/ZODB3-3.2c1/test.py", line 793, in process_args bad = main(module_filter, test_filter, libdir) File "/Users/billbedford/Library/OpenUp/ZODB3-3_2c1_0/ZODB3-3.2c1/test.py", line 594, in main files = find_tests(module_filter) File "/Users/billbedford/Library/OpenUp/ZODB3-3_2c1_0/ZODB3-3.2c1/test.py", line 442, in find_tests os.path.walk(pathinit.libdir, finder.visit, rx) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/posixpath.py", line 290, in walk walk(name, func, arg) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/posixpath.py", line 290, in walk walk(name, func, arg) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/posixpath.py", line 282, in walk func(arg, top, names) File "/Users/billbedford/Library/OpenUp/ZODB3-3_2c1_0/ZODB3-3.2c1/test.py", line 422, in visit __import__(pkg) File "/Users/billbedford/Library/OpenUp/ZODB3-3_2c1_0/ZODB3-3.2c1/build/lib.darwin-6.8-Power_Macintosh-2.3/BTrees/__init__.py", line 11, in ? import Interfaces File "/Users/billbedford/Library/OpenUp/ZODB3-3_2c1_0/ZODB3-3.2c1/build/lib.darwin-6.8-Power_Macintosh-2.3/BTrees/Interfaces.py", line 16, in ? from Interface import Interface ImportError: cannot import name Interface OS 10.2.8 python 2.3 Bill Bedford "Nothing is as important as model railways and even that isn't very important" -some wiseguy somewhere From hinsen at cnrs-orleans.fr Sun Jan 11 09:58:25 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Sun Jan 11 09:58:26 2004 Subject: [Pythonmac-SIG] Making icons Message-ID: <9B8BF8B0-4446-11D8-A785-000A95AB5F10@cnrs-orleans.fr> What do the experienced Mac developers recommended for making icons? I'd happiest with some tool that lets me convert from some standard graphics format to Mac icons, as I'd prefer to do the graphics work with a tool I know (Gimp). This isn't even off-topic as I need to make some icons for Python applets :-) Konrad. From bob at redivi.com Sun Jan 11 10:56:04 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 11 10:53:54 2004 Subject: [Pythonmac-SIG] Making icons In-Reply-To: <9B8BF8B0-4446-11D8-A785-000A95AB5F10@cnrs-orleans.fr> References: <9B8BF8B0-4446-11D8-A785-000A95AB5F10@cnrs-orleans.fr> Message-ID: On Jan 11, 2004, at 9:58 AM, Konrad Hinsen wrote: > What do the experienced Mac developers recommended for making icons? > I'd happiest with some tool that lets me convert from some standard > graphics format to Mac icons, as I'd prefer to do the graphics work > with a tool I know (Gimp). > > This isn't even off-topic as I need to make some icons for Python > applets :-) Save as tiff(s), drag into Icon Composer (an application that ships with Developer Tools or Xcode, whatever you happen to call 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/20040111/3d8ed1e5/smime.bin From bob at eyesopen.com Sun Jan 11 12:24:02 2004 From: bob at eyesopen.com (Bob Tolbert) Date: Sun Jan 11 12:23:45 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries Message-ID: Hi, I've been a bit of a lurker on this list for a while so I want to start by saying a big thank you to the all involved for making the Mac such a Python-friendly place. I'm posting here hoping that some of the more experienced Mac developers can maybe send me in the right direction, as I am currently at a loss. For a bit of background, my company ships a Python wrapper for a C++ toolkit. We've had versions for OS X as well as Windows and most major Unices for about a year now. Up til now, we've built the Python extension (bundle in Mac parlance) against a static library containing the C++ code. We are migrating to a shared library approach for the underlying C++ libraries to allow additional toolkits (that extend the base toolkit) to also be wrapped in Python. By the summer, we hope to ship all our toolkits with Python API's. All of the extension code is generated by SWIG (1.3.20) but I don't think that has much to do with my current problem. So, in switching to shared libraries, I've encountered loads of fun and platform-specific behavior on Linux and Win32 as well as OS X. I've got Linux and Win32 working and am now frustrated that my primary development platform still won't work. So here's the scenario. The following two work. 1. Build C++ libraries as static libraries then build Python extension as -bundle 2. Build C++ libraries as dynamic libraries and then build C++ apps that depend on them. The apps will run, loading the dynamic library at runtime. But what still fails to work is the combination: 3. Build C++ library as dynamic library then build Python extension dependent on it. So I have a python shadow/proxy class file foo.py that loads the actual python extension _foo.so that depends on the C++ library foo.dylib. I have have set DYLD_LIBRARY_PATH, etc. The behavior I see is that if I import foo, it imports _foo.so and then Python hangs, forever. I have to kill it from the commandline. So now that I've bored you with more details than I should have, I am really asking for some ideas of where to look for the straight scoop on the is whole dylib/so dichotomy in OS X. I am pretty sure I had an early prototype of this working under 10.2, but it seems Apple has changed some of the commandline switches for building dylibs in 10.3. First there is this whole issue of two-level namespaces and then there are all the command line switches concerning undefined symbols thanks for listening and for any clues, Bob Tolbert OpenEye Scientific Software, Inc. bob@eyesopen.com From bob at redivi.com Sun Jan 11 12:38:24 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 11 12:36:15 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: References: Message-ID: On Jan 11, 2004, at 12:24 PM, Bob Tolbert wrote: > So here's the scenario. The following two work. > > 1. Build C++ libraries as static libraries then build Python > extension as -bundle > 2. Build C++ libraries as dynamic libraries and then build C++ apps > that depend on them. The apps will run, loading the dynamic library at > runtime. > > But what still fails to work is the combination: > > 3. Build C++ library as dynamic library then build Python extension > dependent on it. So I have a python shadow/proxy class file foo.py > that loads the actual python extension _foo.so that depends on the C++ > library foo.dylib. I have have set DYLD_LIBRARY_PATH, etc. The > behavior I see is that if I import foo, it imports _foo.so and then > Python hangs, forever. I have to kill it from the commandline. This is probably something to do with the C++ runtime.. as a hunch, do you have any static initialization in your C++ dynamic library? If it works with DYLD_BIND_AT_LAUNCH, then that's probably the case. What's it doing in gdb when you break it? > So now that I've bored you with more details than I should have, I am > really asking for some ideas of where to look for the straight scoop > on the is whole dylib/so dichotomy in OS X. I am pretty sure I had an > early prototype of this working under 10.2, but it seems Apple has > changed some of the commandline switches for building dylibs in 10.3. > First there is this whole issue of two-level namespaces and then there > are all the command line switches concerning undefined symbols two-level namespaces have been around since 10.2 and -undefined dynamic_lookup is the only new linker flag in 10.3 that I'm aware of. You rarely ever want to use any command line switches related to namespaces or undefined symbols in shipping software. If you can't figure it out, please make a minimal example of this (minimal C++ dylib, minimal python SWIG wrapper, whatever build method you're using.. doesn't sound like you're using distutils) and one of us will try and look at 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/20040111/d4f5f5b1/smime.bin From israel at uandmedance.com Sun Jan 11 13:47:29 2004 From: israel at uandmedance.com (israel@uandmedance.com) Date: Sun Jan 11 13:47:18 2004 Subject: [Pythonmac-SIG] Making icons In-Reply-To: Message-ID: <9BD531BC-4466-11D8-9A4F-000393A47FF2@uandmedance.com> I use a combination of Viou, Icon Composer, Iconverter, and Pic2Icon. I've found that Icon Composer doesn't seem to work for making a simple icon you can stick on a folder. From what I can tell, it's useful for when you create a program and are accessing the icon resources from that program. On Sunday, Jan 11, 2004, at 07:56 US/Pacific, Bob Ippolito wrote: > > On Jan 11, 2004, at 9:58 AM, Konrad Hinsen wrote: > >> What do the experienced Mac developers recommended for making icons? >> I'd happiest with some tool that lets me convert from some standard >> graphics format to Mac icons, as I'd prefer to do the graphics work >> with a tool I know (Gimp). >> >> This isn't even off-topic as I need to make some icons for Python >> applets :-) > > Save as tiff(s), drag into Icon Composer (an application that ships > with Developer Tools or Xcode, whatever you happen to call it). > > -bob > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > ~Israel~ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1145 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040111/bdc9a97e/attachment.bin From hinsen at cnrs-orleans.fr Sun Jan 11 15:39:38 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Sun Jan 11 15:39:39 2004 Subject: [Pythonmac-SIG] Making icons In-Reply-To: References: <9B8BF8B0-4446-11D8-A785-000A95AB5F10@cnrs-orleans.fr> Message-ID: <46999B78-4476-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> On 11.01.2004, at 16:56, Bob Ippolito wrote: > Save as tiff(s), drag into Icon Composer (an application that ships > with Developer Tools or Xcode, whatever you happen to call it). > Thanks, that's exactly what I needed. BTW, it takes PNG as well, so it it rather straightforward to convert Linux icons. The icon name for Python applets (PythonApplet.icns) seems to be hardcoded somewhere, changing the name in Info.plist is not sufficient to make the Finder use some other icon. I guess I am starting to explore the dark sides of MacOS... Konrad. From bob at redivi.com Sun Jan 11 15:49:40 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 11 15:47:23 2004 Subject: [Pythonmac-SIG] Making icons In-Reply-To: <46999B78-4476-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> References: <9B8BF8B0-4446-11D8-A785-000A95AB5F10@cnrs-orleans.fr> <46999B78-4476-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> Message-ID: On Jan 11, 2004, at 3:39 PM, Konrad Hinsen wrote: > On 11.01.2004, at 16:56, Bob Ippolito wrote: > >> Save as tiff(s), drag into Icon Composer (an application that ships >> with Developer Tools or Xcode, whatever you happen to call it). >> > Thanks, that's exactly what I needed. BTW, it takes PNG as well, so it > it rather straightforward to convert Linux icons. From what I remember, it does a better job with transparency when you're using tiffs. Tiff is basically the native raster image format for OS X (at least in Cocoa). > The icon name for Python applets (PythonApplet.icns) seems to be > hardcoded somewhere, changing the name in Info.plist is not sufficient > to make the Finder use some other icon. I guess I am starting to > explore the dark sides of MacOS... Make a copy of the bundle after you change Info.plist or whatever.. Finder caches this, you're probably hitting cache. Are applets really what you want? Do they actually work? I think most people are using bundlebuilder (I have no experience with BuildApplet). -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/20040111/3482ba74/smime.bin From Jack.Jansen at cwi.nl Sun Jan 11 15:53:10 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Jan 11 15:53:16 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: References: Message-ID: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> On 11-jan-04, at 18:38, Bob Ippolito wrote: >> 3. Build C++ library as dynamic library then build Python extension >> dependent on it. So I have a python shadow/proxy class file foo.py >> that loads the actual python extension _foo.so that depends on the >> C++ library foo.dylib. I have have set DYLD_LIBRARY_PATH, etc. The >> behavior I see is that if I import foo, it imports _foo.so and then >> Python hangs, forever. I have to kill it from the commandline. > > This is probably something to do with the C++ runtime.. as a hunch, do > you have any static initialization in your C++ dynamic library? If it > works with DYLD_BIND_AT_LAUNCH, then that's probably the case. What's > it doing in gdb when you break it? If Bob is right (and I think he is) then you can probably fix this by using "g++" in stead of "ld" or "gcc" as the linker command for your Python extension. Although, Bob, I'm not sure about your DYLD_BIND_AT_LAUNCH suggestion. Is that also honored for plugins (as the Python extension modules are)? Bob Tolbert also wrote: > So now that I've bored you with more details than I should have, I am > really asking for some ideas of where to look for the straight scoop > on the is whole dylib/so dichotomy in OS X. You've definitely not bored us with the details! It's much better if people post as many details as they can possibly think of, even if 80% of them are insignificant the 20% that you don't have to go ask for makes life a whole lot easier! As to the dylib/so issue: that's my stupidity. Back when OSX came out I was under the impression (don't know where I got it) that both .dylib and .so were "legal" extensions for dynamic libraries on OSX. As .so was the standard on most unixen, and for some reason Python's configure seemed to pick that I never spent a second thought on it. I'm not sure what we'll do for 2.4. Either go to whatever is the standard on OSX (I haven't a clue whether there is a standard for plugins), or come up with one ourselves (.pysomethingorother). -- 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 hinsen at cnrs-orleans.fr Sun Jan 11 15:55:53 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Sun Jan 11 15:55:57 2004 Subject: [Pythonmac-SIG] Making icons In-Reply-To: References: <9B8BF8B0-4446-11D8-A785-000A95AB5F10@cnrs-orleans.fr> <46999B78-4476-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> Message-ID: <8B84FDDB-4478-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> On 11.01.2004, at 21:49, Bob Ippolito wrote: >> The icon name for Python applets (PythonApplet.icns) seems to be >> hardcoded somewhere, changing the name in Info.plist is not >> sufficient to make the Finder use some other icon. I guess I am >> starting to explore the dark sides of MacOS... > > Make a copy of the bundle after you change Info.plist or whatever.. > Finder caches this, you're probably hitting cache. Are applets really > what you want? Do they actually work? I think most people are using > bundlebuilder (I have no experience with BuildApplet). > It looked simpler, and good enough for my job. My applications are really trivial (Python-wise), though very convenient: small scripts that make Emacs and GIMP accessible as if they were proper applications. I can now put them into the dock and drag files into them :-) Bundlebuilder is my next exploration project. Konrad. From bob at redivi.com Sun Jan 11 16:18:45 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 11 16:16:34 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> Message-ID: On Jan 11, 2004, at 3:53 PM, Jack Jansen wrote: > > On 11-jan-04, at 18:38, Bob Ippolito wrote: > >>> 3. Build C++ library as dynamic library then build Python extension >>> dependent on it. So I have a python shadow/proxy class file foo.py >>> that loads the actual python extension _foo.so that depends on the >>> C++ library foo.dylib. I have have set DYLD_LIBRARY_PATH, etc. The >>> behavior I see is that if I import foo, it imports _foo.so and then >>> Python hangs, forever. I have to kill it from the commandline. >> >> This is probably something to do with the C++ runtime.. as a hunch, >> do you have any static initialization in your C++ dynamic library? >> If it works with DYLD_BIND_AT_LAUNCH, then that's probably the case. >> What's it doing in gdb when you break it? > > If Bob is right (and I think he is) then you can probably fix this by > using "g++" in stead of "ld" or "gcc" as the linker command for your > Python extension. > > Although, Bob, I'm not sure about your DYLD_BIND_AT_LAUNCH suggestion. > Is that also honored for plugins (as the Python extension modules > are)? That's probably the right solution Jack. DYLD_BIND_AT_LAUNCH is not something I've ever needed, so I don't know if it works for plugins. I believe have seen static initialization in C++ cause problems, but I usually solve these things pretty quickly and then completely forget how (post-traumatic stress syndrome? :) > Bob Tolbert also wrote: >> So now that I've bored you with more details than I should have, I am >> really asking for some ideas of where to look for the straight scoop >> on the is whole dylib/so dichotomy in OS X. > > You've definitely not bored us with the details! It's much better if > people post as many details as they can possibly think of, even if 80% > of them are insignificant the 20% that you don't have to go ask for > makes life a whole lot easier! > > As to the dylib/so issue: that's my stupidity. Back when OSX came out > I was under the impression (don't know where I got it) that both > .dylib and .so were "legal" extensions for dynamic libraries on OSX. > As .so was the standard on most unixen, and for some reason Python's > configure seemed to pick that I never spent a second thought on it. > > I'm not sure what we'll do for 2.4. Either go to whatever is the > standard on OSX (I haven't a clue whether there is a standard for > plugins), or come up with one ourselves (.pysomethingorother). Since we are using MH_BUNDLE object files I propose using .bundle. This does cause some confusion because the "standard for plugins" is to use the CFBundle APIs so .bundle is usually a (NeXT style) bundle with an MH_BUNDLE object file at "%(name)s.bundle/Contents/MacOS/%(name)s" -- however, I have seen "raw" .bundle files (MH_BUNDLE without the NeXT bundle) in Perl and Ruby, so we're safe. I'm all for changing the extension, it will prevent crazy people from trying to use 2.3.x or 2.2.x extensions with 2.4 ;) -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/20040111/daa8d1e4/smime.bin From vvoiuk at hongkong.com Sun Jan 11 04:47:20 2004 From: vvoiuk at hongkong.com (Connell Hans) Date: Sun Jan 11 16:55:44 2004 Subject: [Pythonmac-SIG] Re: PC, to call directly Message-ID: murray cowry hector nbc can't minefield osteopathic integrity tribe defendant atalanta afterward electro deoxyribose gage sunday myeloid logarithm eider blithe seamen bong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040111/d09b0f52/attachment.html From Jack.Jansen at cwi.nl Sun Jan 11 17:50:06 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Jan 11 17:50:23 2004 Subject: [Pythonmac-SIG] Making icons In-Reply-To: <46999B78-4476-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> References: <9B8BF8B0-4446-11D8-A785-000A95AB5F10@cnrs-orleans.fr> <46999B78-4476-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> Message-ID: <7FF81BD0-4488-11D8-B37C-000A27B19B96@cwi.nl> On 11-jan-04, at 21:39, Konrad Hinsen wrote: > The icon name for Python applets (PythonApplet.icns) seems to be > hardcoded somewhere, changing the name in Info.plist is not sufficient > to make the Finder use some other icon. I guess I am starting to > explore the dark sides of MacOS... The BuildApplet paradigm is that you override defaults (for .rsrc files on OS9, on OSX .icns and .plist have been added) by putting a file with the same basename beside your script. So, if your script is myapp.py and you drop it on BuildApplet it will look for a myapp.icns and use that if available. That's how it should work, at least, check the source code to make sure I actually implemented this:-) -- 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 hinsen at cnrs-orleans.fr Sun Jan 11 18:17:06 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Sun Jan 11 18:17:25 2004 Subject: [Pythonmac-SIG] Making icons In-Reply-To: <7FF81BD0-4488-11D8-B37C-000A27B19B96@cwi.nl> References: <9B8BF8B0-4446-11D8-A785-000A95AB5F10@cnrs-orleans.fr> <46999B78-4476-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> <7FF81BD0-4488-11D8-B37C-000A27B19B96@cwi.nl> Message-ID: <45CCED44-448C-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> On 11.01.2004, at 23:50, Jack Jansen wrote: > The BuildApplet paradigm is that you override defaults (for .rsrc > files on OS9, on OSX .icns and .plist have been added) by putting a > file with the same basename beside your script. > > So, if your script is myapp.py and you drop it on BuildApplet it will > look for a myapp.icns and use that if available. I didn't even know about BuildApplet, I just saved my script as an applet from the IDE. Anyway, my surprise is not so much about Python as about the Finder. I thought it would take the name for the icon from Info.plist. But Bob was right, it is sufficient to make a copy. Konrad. From bob at redivi.com Sun Jan 11 18:24:57 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 11 18:22:47 2004 Subject: [Pythonmac-SIG] Making icons In-Reply-To: <45CCED44-448C-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> References: <9B8BF8B0-4446-11D8-A785-000A95AB5F10@cnrs-orleans.fr> <46999B78-4476-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> <7FF81BD0-4488-11D8-B37C-000A27B19B96@cwi.nl> <45CCED44-448C-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> Message-ID: <5EDDC7D8-448D-11D8-9F26-000A95686CD8@redivi.com> On Jan 11, 2004, at 6:17 PM, Konrad Hinsen wrote: > On 11.01.2004, at 23:50, Jack Jansen wrote: > >> The BuildApplet paradigm is that you override defaults (for .rsrc >> files on OS9, on OSX .icns and .plist have been added) by putting a >> file with the same basename beside your script. >> >> So, if your script is myapp.py and you drop it on BuildApplet it will >> look for a myapp.icns and use that if available. > > I didn't even know about BuildApplet, I just saved my script as an > applet from the IDE. > > Anyway, my surprise is not so much about Python as about the Finder. I > thought it would take the name for the icon from Info.plist. But Bob > was right, it is sufficient to make a copy. It will probably take the new icon from Info.plist, eventually. It caches these things, so Finder isn't slow(er). Copying makes a new bundle that didn't exist before, so you don't have to worry about a cached icon. -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/20040111/0bd388e2/smime.bin From njriley at uiuc.edu Sun Jan 11 19:15:08 2004 From: njriley at uiuc.edu (Nicholas Riley) Date: Sun Jan 11 19:15:15 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> Message-ID: <20040112001508.GB52200@uiuc.edu> On Sun, Jan 11, 2004 at 09:53:10PM +0100, Jack Jansen wrote: > If Bob is right (and I think he is) then you can probably fix this by > using "g++" in stead of "ld" or "gcc" as the linker command for your > Python extension. Distutils doesn't properly support C++ until Python 2.3; for earlier versions you have to do various bizarre things to force it to link on various platforms. > As to the dylib/so issue: that's my stupidity. Back when OSX came out I > was under the impression (don't know where I got it) that both .dylib > and .so were "legal" extensions for dynamic libraries on OSX. As .so > was the standard on most unixen, and for some reason Python's configure > seemed to pick that I never spent a second thought on it. > > I'm not sure what we'll do for 2.4. Either go to whatever is the > standard on OSX (I haven't a clue whether there is a standard for > plugins), or come up with one ourselves (.pysomethingorother). You're not the only one to pick .so; Apache plugins in /usr/libexec/httpd also end with .so, and are also MH_BUNDLE format. Tcl uses MH_DYLIB and .dylib, which is bizarre; anyone know about any examples from other scripting languages? I think .bundle is likely to cause more confusion than not; something with Python in the name (akin to .pyd on Windows) seems like a much better idea, perhaps ".pyext" or ".pymod"? -- =Nicholas Riley | From njriley at uiuc.edu Sun Jan 11 19:24:04 2004 From: njriley at uiuc.edu (Nicholas Riley) Date: Sun Jan 11 19:24:07 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <20040112001508.GB52200@uiuc.edu> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> Message-ID: <20040112002403.GC52200@uiuc.edu> On Sun, Jan 11, 2004 at 06:15:08PM -0600, Nicholas Riley wrote: > I think .bundle is likely to cause more confusion than not; something > with Python in the name (akin to .pyd on Windows) seems like a much > better idea, perhaps ".pyext" or ".pymod"? As Bob Ippolito pointed out, Perl and Ruby use .bundle, but that doesn't mean we have to; the other advantage of picking our own extension is that we get to assign a nice icon to it :-) - and it's generally more user-friendly by showing what it is in the Finder and so forth. Note for example that some QuickTime extensions (which use the Component Manager, but that's rather irrelevant for the moment) end with the generic .component; others with .qtx. Apple recommends the more specific .qtx: That's the closest I could find to a precedent for this. -- =Nicholas Riley | From bob at redivi.com Sun Jan 11 19:37:01 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 11 19:34:46 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <20040112001508.GB52200@uiuc.edu> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> Message-ID: <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> On Jan 11, 2004, at 7:15 PM, Nicholas Riley wrote: > On Sun, Jan 11, 2004 at 09:53:10PM +0100, Jack Jansen wrote: >> As to the dylib/so issue: that's my stupidity. Back when OSX came out >> I >> was under the impression (don't know where I got it) that both .dylib >> and .so were "legal" extensions for dynamic libraries on OSX. As .so >> was the standard on most unixen, and for some reason Python's >> configure >> seemed to pick that I never spent a second thought on it. >> >> I'm not sure what we'll do for 2.4. Either go to whatever is the >> standard on OSX (I haven't a clue whether there is a standard for >> plugins), or come up with one ourselves (.pysomethingorother). > > You're not the only one to pick .so; Apache plugins in > /usr/libexec/httpd also end with .so, and are also MH_BUNDLE format. > > Tcl uses MH_DYLIB and .dylib, which is bizarre; anyone know about any > examples from other scripting languages? Yeah, I have no idea why they are using MH_DYLIB. (at least in 10.3) Perl - MH_BUNDLE - .bundle Ruby - MH_BUNDLE - .bundle TCL - MH_DYLIB - .dylib Python - MH_BUNDLE - .so ( yes all three of these happen, in stuff that comes with 10.3 no less ) Java - MH_BUNDLE - .jnilib Java - MH_DYLIB - .jnilib Java - MH_DYLIB - .dylib Apache - MH_BUNDLE - .so (these use the BINDATLOAD flag, so I'm guessing that yes, bundles can enforce that.. as per earlier conversation in this thread) > I think .bundle is likely to cause more confusion than not; something > with Python in the name (akin to .pyd on Windows) seems like a much > better idea, perhaps ".pyext" or ".pymod"? The only people that use something "non-standard" are the Java people.. Everyone else uses .bundle or .so. -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/20040111/3e52bc8e/smime.bin From oussoren at cistron.nl Mon Jan 12 03:24:36 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Mon Jan 12 03:24:38 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> Message-ID: On 12 jan 2004, at 1:37, Bob Ippolito wrote: >> I think .bundle is likely to cause more confusion than not; something >> with Python in the name (akin to .pyd on Windows) seems like a much >> better idea, perhaps ".pyext" or ".pymod"? > > The only people that use something "non-standard" are the Java > people.. Everyone else uses .bundle or .so. I agree with Nicholas on this, using .bundle as the extention for extention modules will very likely cause confusion because the term bundle is usually used for specially structured folders (app bundles and the like). What's wrong with using '.so' as the extention? Ronald From bob at redivi.com Mon Jan 12 03:50:52 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 12 03:48:37 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> Message-ID: <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> On Jan 12, 2004, at 3:24 AM, Ronald Oussoren wrote: > > On 12 jan 2004, at 1:37, Bob Ippolito wrote: >>> I think .bundle is likely to cause more confusion than not; something >>> with Python in the name (akin to .pyd on Windows) seems like a much >>> better idea, perhaps ".pyext" or ".pymod"? >> >> The only people that use something "non-standard" are the Java >> people.. Everyone else uses .bundle or .so. > > I agree with Nicholas on this, using .bundle as the extention for > extention modules will very likely cause confusion because the term > bundle is usually used for specially structured folders (app bundles > and the like). Well, it's pretty obvious they're not folders, so I wouldn't be confused. Just as a semi-but-not-really-serious idea: I wouldn't complain if they *were* folders (CFBundle-type-bundles) on the Mac. Think about it, we could embed the particular version of Python and OS compatibility matrix in the Info.plist, throw in some fun external data into Resources, put required dylibs/frameworks in Frameworks (and the Python runtime could jigger the appropriate dyld incantations to make them load properly), use a higher level plugin API then raw dyld, whatever. It's a metadata party, and everyone is invited. > What's wrong with using '.so' as the extention? .so probably implies MH_DYLIB? I don't really have a problem with .so. It's ".pyext" that I don't really like. -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/20040112/b84c388a/smime.bin From njriley at uiuc.edu Mon Jan 12 03:56:50 2004 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon Jan 12 03:56:59 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> Message-ID: <20040112085650.GB55645@uiuc.edu> On Mon, Jan 12, 2004 at 03:50:52AM -0500, Bob Ippolito wrote: > Well, it's pretty obvious they're not folders, so I wouldn't be > confused. Sure, but you're hardly typical. > Just as a semi-but-not-really-serious idea: I wouldn't complain if > they *were* folders (CFBundle-type-bundles) on the Mac. Think about > it, we could embed the particular version of Python and OS > compatibility matrix in the Info.plist, throw in some fun external data > into Resources, put required dylibs/frameworks in Frameworks (and the > Python runtime could jigger the appropriate dyld incantations to make > them load properly), use a higher level plugin API then raw dyld, > whatever. It's a metadata party, and everyone is invited. As an optional thing this sounds fine, but flat MH_BUNDLE containers should be supported for equivalence with every other Python platform. > >What's wrong with using '.so' as the extention? > > .so probably implies MH_DYLIB? I don't really have a problem with .so. > It's ".pyext" that I don't really like. .so doesn't seem to imply MH_DYLIB, especially given the example of Apache. There's no difference between dylibs and bundles under other OSes, "shared object" doesn't seem to me to connote one or the other. I don't have a huge problem with .so either, but I'd prefer something more specific like .pyext. Why are you against it? -- =Nicholas Riley | From bob at redivi.com Mon Jan 12 04:29:54 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 12 04:27:52 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <20040112085650.GB55645@uiuc.edu> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> <20040112085650.GB55645@uiuc.edu> Message-ID: On Jan 12, 2004, at 3:56 AM, Nicholas Riley wrote: > On Mon, Jan 12, 2004 at 03:50:52AM -0500, Bob Ippolito wrote: >> Well, it's pretty obvious they're not folders, so I wouldn't be >> confused. > > Sure, but you're hardly typical. Yeah, but most people have never seen a ".bundle" file or folder either way, so that's why I used myself as the example. >> Just as a semi-but-not-really-serious idea: I wouldn't complain if >> they *were* folders (CFBundle-type-bundles) on the Mac. Think about >> it, we could embed the particular version of Python and OS >> compatibility matrix in the Info.plist, throw in some fun external >> data >> into Resources, put required dylibs/frameworks in Frameworks (and the >> Python runtime could jigger the appropriate dyld incantations to make >> them load properly), use a higher level plugin API then raw dyld, >> whatever. It's a metadata party, and everyone is invited. > > As an optional thing this sounds fine, but flat MH_BUNDLE containers > should be supported for equivalence with every other Python platform. To further encourage people to built bundles by hand with the wrong tools or linker flags? ;) I suppose it's necessary to maintain the MH_BUNDLE aspect -- not because of "equivalence" -- but because some useful software programs insist on Not Using Distutils (subversion, and uh.. VTK maybe?). >>> What's wrong with using '.so' as the extention? >> >> .so probably implies MH_DYLIB? I don't really have a problem with >> .so. >> It's ".pyext" that I don't really like. > > .so doesn't seem to imply MH_DYLIB, especially given the example of > Apache. There's no difference between dylibs and bundles under other > OSes, "shared object" doesn't seem to me to connote one or the other. It implies MH_DYLIB to me because when you're porting software, more often than not, a ".so" on Linux is a ".dylib" in OS X, and even if it's ported as a ".framework" it's still MH_DYLIB. Maybe it's just me. Yes, I'm aware that other operating systems don't have separate header layouts for "dynamically linked libraries" and "plugins"... I'm just thinking statistically here, so that probably means I'm wrong. > I don't have a huge problem with .so either, but I'd prefer something > more specific like .pyext. Why are you against it? I think .pyext is more confusing (or at least less aesthetically pleasing) than .bundle for No Good Reason. I think .bundle would be ok, because that's what Perl and Ruby use. In other situations, .bundle is sometimes a plug-in bundle.. but in our case, Python extensions are plug-ins, so the difference is only technical. As far as I know, those are the only two other "Python equivalent" interpreters distributed with OS X.. so we're all alone here. I don't want to count TCL, and especially not Java, because it seems they're smoking something we're not with regard to MH_BUNDLE vs. MH_DYLIB and file name extension consistency. -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/20040112/da5a3827/smime.bin From oussoren at cistron.nl Mon Jan 12 05:08:33 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Mon Jan 12 05:08:41 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> <20040112085650.GB55645@uiuc.edu> Message-ID: <476F87E9-44E7-11D8-B390-0003931CFE24@cistron.nl> On 12 jan 2004, at 10:29, Bob Ippolito wrote: > > On Jan 12, 2004, at 3:56 AM, Nicholas Riley wrote: > >> On Mon, Jan 12, 2004 at 03:50:52AM -0500, Bob Ippolito wrote: >>> Well, it's pretty obvious they're not folders, so I wouldn't be >>> confused. >> >> Sure, but you're hardly typical. > > Yeah, but most people have never seen a ".bundle" file or folder > either way, so that's why I used myself as the example. > >>> Just as a semi-but-not-really-serious idea: I wouldn't complain if >>> they *were* folders (CFBundle-type-bundles) on the Mac. Think about >>> it, we could embed the particular version of Python and OS >>> compatibility matrix in the Info.plist, throw in some fun external >>> data >>> into Resources, put required dylibs/frameworks in Frameworks (and the >>> Python runtime could jigger the appropriate dyld incantations to make >>> them load properly), use a higher level plugin API then raw dyld, >>> whatever. It's a metadata party, and everyone is invited. >> >> As an optional thing this sounds fine, but flat MH_BUNDLE containers >> should be supported for equivalence with every other Python platform. > > To further encourage people to built bundles by hand with the wrong > tools or linker flags? ;) I suppose it's necessary to maintain the > MH_BUNDLE aspect -- not because of "equivalence" -- but because some > useful software programs insist on Not Using Distutils (subversion, > and uh.. VTK maybe?). I'm -1 on using plugin folders, although I'd have to reconsider if could get plugin folders into the standard distribution (not only for OSX). > >>>> What's wrong with using '.so' as the extention? >>> >>> .so probably implies MH_DYLIB? I don't really have a problem with >>> .so. >>> It's ".pyext" that I don't really like. >> >> .so doesn't seem to imply MH_DYLIB, especially given the example of >> Apache. There's no difference between dylibs and bundles under other >> OSes, "shared object" doesn't seem to me to connote one or the other. > > It implies MH_DYLIB to me because when you're porting software, more > often than not, a ".so" on Linux is a ".dylib" in OS X, and even if > it's ported as a ".framework" it's still MH_DYLIB. Maybe it's just > me. Yes, I'm aware that other operating systems don't have separate > header layouts for "dynamically linked libraries" and "plugins"... I'm > just thinking statistically here, so that probably means I'm wrong. > >> I don't have a huge problem with .so either, but I'd prefer something >> more specific like .pyext. Why are you against it? > > I think .pyext is more confusing (or at least less aesthetically > pleasing) than .bundle for No Good Reason. I think .bundle would be > ok, because that's what Perl and Ruby use. It's OK because Perl does it??? (Sorry couldn't resist). I have two problems with .bundle. First of all it suggests that the item is a bundle, which python extensions are not and furthermore the extension is too generic. IMHO at least some users will assume that python and ruby .bundle-files will be interchangeable. I'm +1 on using .pyext or some other python-specific suffix. > In other situations, .bundle is sometimes a plug-in bundle.. but in > our case, Python extensions are plug-ins, so the difference is only > technical. As far as I know, those are the only two other "Python > equivalent" interpreters distributed with OS X.. so we're all alone > here. I don't want to count TCL, and especially not Java, because it > seems they're smoking something we're not with regard to MH_BUNDLE vs. > MH_DYLIB and file name extension consistency. Java is very fashionable at the moment, so doing it the same as Java might be a good thing :-) Ronald From who2guess at xs4all.nl Mon Jan 12 05:13:01 2004 From: who2guess at xs4all.nl (W.H.Offenbach) Date: Mon Jan 12 05:13:05 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> <20040112085650.GB55645@uiuc.edu> Message-ID: On 12-jan-04, at 10:29, Bob Ippolito wrote: > On Jan 12, 2004, at 3:56 AM, Nicholas Riley wrote: >> On Mon, Jan 12, 2004 at 03:50:52AM -0500, Bob Ippolito wrote: >>> Well, it's pretty obvious they're not folders, so I wouldn't be >>> confused. >> Sure, but you're hardly typical. > > [... on and on ...] How about .theextensionthatstirredupalongdiscussion ;-) Seriously, let's look upon it from an Python evangelism point of view. Do we want it to look like all the other extensions or is there a reason to differ? Do we want it to explicitly refer to Python or not? Do we want it to explicitly refer to MacPython or not? Werner From bear at newworldkids.com Mon Jan 12 13:28:14 2004 From: bear at newworldkids.com (Tersina) Date: Mon Jan 12 05:35:47 2004 Subject: [Pythonmac-SIG] when? Message-ID: <9ss456$c59ifo981a3b802$-df1@ezp.7j6jk7.4ch> New OFFSHORE PHARMACY - Not a single medical question asked, guaranteed or it's free. We have the cheapest drugs w/ overnight delivery all over the world. Valium, Xanaxm, Soma, Zyban, Super V1agara, etc. Lowest cost anywhere in the world. 128-bit encrypted site which means maximum confidentiality & no tracing. Executives, Doctor's, & business people have been using our site for years & we are proud to present it to you. See what were all about today. http://offshorepharm1.nepzzz.com/m001p/index.php?id=m0014 This communication is privileged and contains confidential information intended only for the person(s) to whom it is addressed. Any unauthorized disclosure, copying, other distribution of this communication or taking any action on its contents is strictly prohibited. If you have received this message in error, please notify us immediately OR remove yourself from our list if there is no interest in regards to our products. http://www.nepzzz.com/m001p/byebye.html ndhd dejetugpchinigdj From gbopw at china.com Mon Jan 12 06:06:48 2004 From: gbopw at china.com (Henson) Date: Mon Jan 12 06:09:35 2004 Subject: [Pythonmac-SIG] Re: BJZCBHOJ, bowing and scraping Message-ID: cave elmer execrable bentham castanet noise snowstorm easygoing confute bacon bluish lagrange arterial -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040112/a56b7eab/attachment.html From mwh at python.net Mon Jan 12 07:42:21 2004 From: mwh at python.net (Michael Hudson) Date: Mon Jan 12 07:42:23 2004 Subject: [Pythonmac-SIG] Making icons In-Reply-To: <8B84FDDB-4478-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> (Konrad Hinsen's message of "Sun, 11 Jan 2004 21:55:53 +0100") References: <9B8BF8B0-4446-11D8-A785-000A95AB5F10@cnrs-orleans.fr> <46999B78-4476-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> <8B84FDDB-4478-11D8-B7DC-000A95AB5F10@cnrs-orleans.fr> Message-ID: <2m1xq5xrrm.fsf@starship.python.net> Konrad Hinsen writes: > It looked simpler, and good enough for my job. My applications are > really trivial (Python-wise), though very convenient: small scripts > that make Emacs and GIMP accessible as if they were proper > applications. Um, if you build emacs from CVS it *is* a proper application... (unless the FSF have finally /released/ a version with Carbon support). Cheers, mwh -- C is not clean -- the language has _many_ gotchas and traps, and although its semantics are _simple_ in some sense, it is not any cleaner than the assembly-language design it is based on. -- Erik Naggum, comp.lang.lisp From mjb at uma.pt Mon Jan 12 08:40:58 2004 From: mjb at uma.pt (Michael J. Barber) Date: Mon Jan 12 08:40:53 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: Message-ID: On Friday, Jan 9, 2004, at 19:21 Europe/Lisbon, has wrote: > To summarise: > [clarification of OSA, AEM, and application object model] > Does this help? > Yes, that (finally!) clears up the last of my terminology confusion nicely. I'm afraid that I'm struggling to unlearn some things that I've misunderstood for some time now. Thanks for being so patient. >> OSA and AEM are complementary, but distinct. > > Yes.(!) > This, more than anything else, seems to be the key point. >> (2) Making one or more convenient interfaces to the application >> "object model" for the programmer. > > I think I get your meaning. To be a bit more precise: we write a > module that connects to the AEM. This allows the scripter to > manipulate an application's object model by calling the module's API. > > This is what I'm doing: appscript is a Python-specific implementation > of a friendly, intelligent high-level API. The generic API I'm > designing will provide a common pattern for developers on other > languages to follow when implementing their own high-level AEM > interfaces. > Yes, that is exactly what I had in mind. Programmers ideally get an interface that hides all the icky stuff and lets them focus on getting the application to do what they want. And, of course, multiple interfaces are possible. See the following comment, also. > BTW, I'm even wondering if it'd be worth doing an implementation of > the generic API in C/C++/Obj-C. This'd reduce the amount of work > needed to write a module for any language even further: basically one > would just write a wrapper around this API, plus whatever syntactic > sugar seems appropriate. Which is a lot more convenient than building > directly atop the low-level AEM API, where each developer has to > reimplement all the generic API logic themselves; hardly a good > example of portable code reuse. > That seems like a good idea. However, maybe there's a simpler approach that gives the same benefits? In AppScripting, you've already got a Python implementation of your high-level API. Would it seem reasonable to leverage that work through a socket-based approach? That opens things up to essentially all languages fairly quickly, and still allows reimplementation in C if and when it becomes necessary. > Dunno about you, but I think we're starting to make some damned good > headway too, all thanks to this thread. Pats on back all round will be > due at the end. > I certainly feel like the issues are clearer than they were a week ago. The discussions of this topic that periodically recur on this list do seem to be showing gradual progress. Good interapplication scripting strikes me as a significant development, potentially even a "killer application," for whatever language gets it right first. -- Michael From Jack.Jansen at cwi.nl Mon Jan 12 08:50:25 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jan 12 08:50:04 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> <20040112085650.GB55645@uiuc.edu> Message-ID: <45DA434D-4506-11D8-84BD-000A958D1666@cwi.nl> On 12-jan-04, at 11:13, W.H.Offenbach wrote: > Seriously, let's look upon it from an Python evangelism point of view. > Do we want it to look like all the other extensions or is there a > reason to differ? > Do we want it to explicitly refer to Python or not? > Do we want it to explicitly refer to MacPython or not? Problem is: you can make a point for all 6 "yes" and "no" answers. Plus for quite a few more questions:-) Unless someone comes with a compelling argument to go one way or another, and not too many people disagree with that argument, I'll just leave it, and pick a whimsical solution when the time is there (read: we'll stick with .so in all probability:-). -- 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 dznjxwouydhiac at yahoo.ca Mon Jan 12 20:59:42 2004 From: dznjxwouydhiac at yahoo.ca (Joan) Date: Mon Jan 12 08:56:37 2004 Subject: [Pythonmac-SIG] Re: LCXMA, in the name Message-ID: individuate keyhole horticulture regale broach contemporaneous dabble germanic briton volcanic chaparral chat eagle mediocre coppery occlude deposit lyon muscovy zigzagging montrachet va awake dictionary bushy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040112/cf5d2fde/attachment.html From bob at tolbert.org Mon Jan 12 09:10:25 2004 From: bob at tolbert.org (Bob Tolbert) Date: Mon Jan 12 09:10:28 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <45DA434D-4506-11D8-84BD-000A958D1666@cwi.nl> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> <20040112085650.GB55645@uiuc.edu> <45DA434D-4506-11D8-84BD-000A958D1666@cwi.nl> Message-ID: <11720D88-4509-11D8-8B55-00039388DD5A@tolbert.org> On Jan 12, 2004, at 6:50 AM, Jack Jansen wrote: > > On 12-jan-04, at 11:13, W.H.Offenbach wrote: >> Seriously, let's look upon it from an Python evangelism point of view. >> Do we want it to look like all the other extensions or is there a >> reason to differ? >> Do we want it to explicitly refer to Python or not? >> Do we want it to explicitly refer to MacPython or not? > > Problem is: you can make a point for all 6 "yes" and "no" answers. > Plus for quite a few more questions:-) > > Unless someone comes with a compelling argument to go one way or > another, and not too many people disagree with that argument, I'll > just leave it, and pick a whimsical solution when the time is there > (read: we'll stick with .so in all probability:-). > -- well I had no idea I'd open up such a can of worms, but it does warm my heart a bit to hear that this is a grey area for more than just me. As for my original problem, I really appreciate all the comments and will try to build a simple case that fails so that I can demonstrate the behavior I see on the real extension. does any one have any recommendations for docs that might describe the whole OSX/Darwin linker/loader mess at the lowest level? Commercial or from Apple, doesn't matter, just hopefullly something better than the ld man page. And to reply to someone above, we do use g++ to link the extension. And I don't use distutils since when I started this project over a year ago, its support for C++ was marginal and support for multiple compilers and options was non-obvious and not documented. I build the python extensions in our tree using the same configure/make system that we use for everything else. Thanks Bob Robert W. Tolbert Ph.D. p. (505) 473-7385 OpenEye Scientific Software f. (505) 473-0833 3600 Cerrillos Road, Suite 1107 Santa Fe, NM 87507 From Jack.Jansen at cwi.nl Mon Jan 12 09:21:17 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jan 12 09:20:58 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <11720D88-4509-11D8-8B55-00039388DD5A@tolbert.org> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> <20040112085650.GB55645@uiuc.edu> <45DA434D-4506-11D8-84BD-000A958D1666@cwi.nl> <11720D88-4509-11D8-8B55-00039388DD5A@tolbert.org> Message-ID: <963009DA-450A-11D8-84BD-000A958D1666@cwi.nl> On 12-jan-04, at 15:10, Bob Tolbert wrote: > does any one have any recommendations for docs that might describe the > whole OSX/Darwin linker/loader mess at the lowest level? Commercial or > from Apple, doesn't matter, just hopefullly something better than the > ld man page. "Mach-O Runtime Architecture" from Apple, it's in the developer documentation that gets installed with the tools. "man 3 dyld" is part of that in manpage form, but only part of it. > And to reply to someone above, we do use g++ to link the extension. > And I don't use distutils since when I started this project over a > year ago, its support for C++ was marginal and support for multiple > compilers and options was non-obvious and not documented. I build the > python extensions in our tree using the same configure/make system > that we use for everything else. Hmm, I was really hoping g++ would be the answer. What you could also try for debugging is turning on the various environment variables mentioned in "man 1 dyld", they might make clear when exactly your import is hanging. -- 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 who2guess at xs4all.nl Mon Jan 12 10:02:38 2004 From: who2guess at xs4all.nl (W.H.Offenbach) Date: Mon Jan 12 10:02:47 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <45DA434D-4506-11D8-84BD-000A958D1666@cwi.nl> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> <20040112085650.GB55645@uiuc.edu> <45DA434D-4506-11D8-84BD-000A958D1666@cwi.nl> Message-ID: <5CE5B6FC-4510-11D8-AF40-000393894CEA@xs4all.nl> On 12-jan-04, at 14:50, Jack Jansen wrote: > On 12-jan-04, at 11:13, W.H.Offenbach wrote: >> Seriously, let's look upon it from an Python evangelism point of view. >> Do we want it to look like all the other extensions or is there a >> reason to differ? >> Do we want it to explicitly refer to Python or not? >> Do we want it to explicitly refer to MacPython or not? > > Problem is: you can make a point for all 6 "yes" and "no" answers. > Plus for quite a few more questions:-) > > Unless someone comes with a compelling argument to go one way or > another, and not too many people disagree with that argument, I'll > just leave it, and pick a whimsical solution when the time is there > (read: we'll stick with .so in all probability:-). I think we really should think about the message we are trying to convey here. Although .so seems reasonable, using it may lead to the plug-in incarnation of the .doc war we've seen between WP and Word. Using .pyso (or even .pysox on MacOS X) might be clearer... Just my $0.01, and that's less then E 0.01 these days ;-) Werner From pecora at anvil.nrl.navy.mil Mon Jan 12 13:10:31 2004 From: pecora at anvil.nrl.navy.mil (Louis M. Pecora) Date: Mon Jan 12 13:09:23 2004 Subject: [Pythonmac-SIG] Re: PC, to call directly In-Reply-To: References: Message-ID: >Our US Licensed Doctors will >Prescribes Your Medication For Free > >Medications Shipped Overnight To Your Do. >show Me more > > > > >initiate exhibitor marsh declaim design larsen amount mitt curiosity >cameraman enthusiasm refugee assure eclectic interpolant ulcer >holdover laredo shipwreck >blockade bini dubious simply borderline devastate sophia bid sin >clarinet garrett derek squeal shuddery corpsman peridotite >antigorite convenient harrow bellmen edict shrill document aphorism >clothesmen presumed impassable cowpea bryan checksummed inoculate >nanometer poisonous monomial complimentary democracy calm grassland Just what the hell is this crap/gibberish that's polluting this email list? -- Cheers, Lou Pecora -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040112/394f4045/attachment.html From hengist.podd at virgin.net Mon Jan 12 12:41:13 2004 From: hengist.podd at virgin.net (has) Date: Mon Jan 12 13:26:50 2004 Subject: [Pythonmac-SIG] Applescript In-Reply-To: References: Message-ID: Michael J. Barber wrote: >>>OSA and AEM are complementary, but distinct. >> >>Yes.(!) >> >This, more than anything else, seems to be the key point. It's certainly an important start. :) >>>(2) Making one or more convenient interfaces to the application >>>"object model" for the programmer. >> >>I think I get your meaning. To be a bit more precise: we write a >>module that connects to the AEM. This allows the scripter to >>manipulate an application's object model by calling the module's >>API. >> >>This is what I'm doing: appscript is a Python-specific >>implementation of a friendly, intelligent high-level API. The >>generic API I'm designing will provide a common pattern for >>developers on other languages to follow when implementing their own >>high-level AEM interfaces. >> >Yes, that is exactly what I had in mind. Programmers ideally get an >interface that hides all the icky stuff and lets them focus on >getting the application to do what they want. AEM-to- bridge developers get a solid template to work by. Scripters get an interface that provides them the full flexibility of AEM with superior ease-of-use for doing application control. And, as a bonus, application developers get a better idea of what's expected of them when adding scripting support to their products. >And, of course, multiple interfaces are possible. Yes, in that the brickwork is always the same, but the choice of finish (raw, painted, roughcast, or whatever) can be tailored to suit each particular market. >>BTW, I'm even wondering if it'd be worth doing an implementation of >>the generic API in C/C++/Obj-C. >[...] >That seems like a good idea. However, maybe there's a simpler >approach that gives the same benefits? In AppScripting, you've >already got a Python implementation of your high-level API. Yes, albeit with Python-specific sugar already applied. (Though it can always be returned to pristeen generic form.) > Would it seem reasonable to leverage that work through a >socket-based approach? That opens things up to essentially all >languages fairly quickly, and still allows reimplementation in C if >and when it becomes necessary. Couldn't answer this without a quick lesson in socket-based programming as it's something I'm not up on. >>Dunno about you, but I think we're starting to make some damned >>good headway too, all thanks to this thread. Pats on back all round >>will be due at the end. >> >I certainly feel like the issues are clearer than they were a week >ago. The discussions of this topic that periodically recur on this >list do seem to be showing gradual progress. Definitely. Though what'll be far more valuable is for Jack to write up and post his 'eureka' moment. (Jack: that's a Big Hint, btw!) A single moment of pure blinding revelation like that is worth more than a month of ordinary discussion, especially when we have to start communicating what we've learnt to the community at large. >Good interapplication scripting strikes me as a significant >development, potentially even a "killer application," for whatever >language gets it right first. Perhaps. Though please note I have no interest in playing favourites; having just escaped one appallingly partisan language, I've no intention of creating another. ;p Finally, realise that having a nice API for application scripting solves only part of the problem: the real task is educating users about it. There's a lot of entrenched mindset out there built almost entirely on misconception and mistrust, and beating that is going to take some doing. If Apple themselves can be persuaded to start promoting Mac IAC and AppleScript as the separate technologies they are, we could be laughing. OTOH, if Apple's marketing plans dictate they continue to sell the two as one ('AppleScript' being a far more powerful brand than an obscure bunch of cryptic TLAs, after all) then be prepared for an uphill slog. I'll sound out Chris Espinosa shortly to see which way they'll swing; we'll have a better idea of what it's going to take after then. Cheers, has p.s. I'm really starting to enjoy this. Wheeeeeeee!!!!!!!! -- http://freespace.virgin.net/hamish.sanderson/ From Chris.Barker at noaa.gov Mon Jan 12 13:20:58 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Jan 12 13:32:31 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <5CE5B6FC-4510-11D8-AF40-000393894CEA@xs4all.nl> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> <20040112085650.GB55645@uiuc.edu> <45DA434D-4506-11D8-84BD-000A958D1666@cwi.nl> <5CE5B6FC-4510-11D8-AF40-000393894CEA@xs4all.nl> Message-ID: <4002E58A.1000304@noaa.gov> FWIW, here is a quotation from: Mac OS- X for Unix Geeks (O'Reilly) Shared Libraries Versus Loadable Modules """ ... shared libraries and loadable modules are not the same on OS-X.... Mack-O shared libraries have the file type MH_DYLIB and .dylib suffix and can be linked with static linker flags. So, of you have a shared library named libcool.dylib, you can link to this library by specifying the -lcool flag. Although shared libraries cannot be loaded dynamically as modules, they can be loaded through the dyld API (see the manpage for dyld, the dynamic link editor). It is important to point out that shared libraries cannot be unloaded. Loadable modules, called bundles in OS-X, have the file type MH_BUNDLE. Most Unix-based software ports usually produce bundles with a .so extension, for the sake of consistancy across platforms. Although Apple recommends giving bundles a .bundle extension, it isn't mandatory. """ Frankly, I'm still confused, but I think that means that what we are making is a bundle, and if we want it native-ish, we call it *.bundle, and if we want it unix-ish we call it *.so, and if we want it Python-ish we call it *.pyd or something like that. Personally, I vote *.so, like linux, so I can use the same scripts to move them around. Why make up another extension? Mostly, I don't care however, I'll be using distutils anyway, and I assume it will do "the right thing"-- whatever that ends up being. -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 Jan 12 15:16:10 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 12 15:14:00 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] patching webbrowser.py for OS X In-Reply-To: References: Message-ID: <29BC9016-453C-11D8-97F6-000A95686CD8@redivi.com> On Jan 12, 2004, at 2:59 PM, Alex Martelli wrote: > > On Jan 12, 2004, at 8:45 PM, Brendan O'Connor wrote: > >> I was trying to use the webbrowser module with OS X's preinstalled >> python; I'm not very familiar with OS X, but I just patched >> webbrowser.py >> to use the very generic "open" command, which works for the simple >> webbrowser.open(url). >> >> I've heard that Fink or another port would be more complete; on the >> other >> hand, I'm using computers where I can't install software myself, so >> this >> is useful for me. >> >> Any thoughts or issues? > > As a brand-new user of Mac OS X, "open" appears to be the right > solution to me, picking up whatever settings one may have made for a > different browser than Safari, not requiring fink, etc, etc. However, > we should probably double-check on pythonmac-sig, where the REAL Mac > Pythonistas hang out... I don't think that this patch is necessary.. On my Mac OS X 10.3 machine (comes with Python 2.3.0), webbrowser.py uses Internet Config to launch the url (the 'ic' module). This is basically equivalent to the open command. It works like this: * Internet Config is an old MacOS API that's mapped to Launch Services which launches the URL with your preferred browser * open is a command line utility that uses the NSWorkspace Cocoa API which uses Launch Services to launch the URL with your preferred browser I don't think your patch fixes anything, it's launched by Launch Services either way.. at least on OS X 10.3. A patch doesn't do us any good against Python 2.2.0 on Mac OS 10.2 if its behavior is broken. Apple doesn't update Python between major releases. You should be able to install MacPython 2.3 in your home directory. Don't bother with Fink. -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/20040112/00c44b7d/smime.bin From skip at pobox.com Mon Jan 12 15:22:54 2004 From: skip at pobox.com (Skip Montanaro) Date: Mon Jan 12 15:23:03 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] patching webbrowser.py for OS X In-Reply-To: <29BC9016-453C-11D8-97F6-000A95686CD8@redivi.com> References: <29BC9016-453C-11D8-97F6-000A95686CD8@redivi.com> Message-ID: <16387.542.986999.429532@montanaro.dyndns.org> Bob> * Internet Config is an old MacOS API that's mapped to Launch Bob> Services which launches the URL with your preferred browser If Internet Config is an "old MacOS API" will it eventually disappear? Skip From bob at redivi.com Mon Jan 12 15:39:30 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 12 15:37:21 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] patching webbrowser.py for OS X In-Reply-To: <16387.542.986999.429532@montanaro.dyndns.org> References: <29BC9016-453C-11D8-97F6-000A95686CD8@redivi.com> <16387.542.986999.429532@montanaro.dyndns.org> Message-ID: <6BEA9533-453F-11D8-97F6-000A95686CD8@redivi.com> On Jan 12, 2004, at 3:22 PM, Skip Montanaro wrote: > Bob> * Internet Config is an old MacOS API that's mapped to Launch > Bob> Services which launches the URL with your preferred browser > > If Internet Config is an "old MacOS API" will it eventually disappear? In a few years, and if hell freezes over, maybe. It's recommended that new software uses System Configuration and Launch Services to replace Internet Config usage, but disabling Internet Config would break a whole lot of Carbon software. Python doesn't have an official wrapper for System Configuration (though I have one available), and the Launch Services wrapper is new for Python 2.4. -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/20040112/ce2201cc/smime.bin From humbert at semsek2.ham.nw.schule.de Mon Jan 12 15:41:38 2004 From: humbert at semsek2.ham.nw.schule.de (Dr. L. Humbert) Date: Mon Jan 12 15:41:59 2004 Subject: [Pythonmac-SIG] how to delete files which special characters on Mac OS 10.3 Message-ID: <200401122141.38158@abercorn.haspe.hagen.de> Hi, I have to write a Python-script to delete files on Mac OS 10.3. When I found out, that my cron-job updatedb stops at special filenames (for example) 'SIIHamm,G\xed\xb6\x86\xed\xbb\xa9chu.a.rtf' I wanted to delete those files with the finder (via trash), but I had no success. error -43 Ok, so I decided to open a terminal and tried rm -rf * in the directory, where those files "live". But -- it did'nt work. [ddi-balzac:~/MUELL/Dreck/1] hum% ls -l ls: SIIHamm,G?????chu.a.rtf: No such file or directory ls: SIIM??????engladbach,Kleinu.a.doc: No such file or directory Now I want to solve the problem via a python-script: Here it goes: >>> dels=os.listdir(".") >>> dels ['SIIHamm,G\xed\xb6\x86\xed\xbb\xa9chu.a.rtf', 'SIIM\xed\xb5\xb6\xed\xb2\xa8engladbach,Kleinu.a.doc'] >>> for i in dels: ... os.remove("./"+i) ... Traceback (most recent call last): File "", line 2, in ? OSError: [Errno 2] No such file or directory: './SIIHamm,G\xed\xb6\x86\xed\xbb\xa9chu.a.rtf' Whats going on here? If I look at those files in the finder, I see two symbols between G and c SIIHamm,G__chu.a.rtf How is it possible to delete those files from a python-script? L. Humbert -- Dr. L. Humbert http://semsek2.ham.nw.schule.de/Ausbildung/Fachseminare/ Studienseminar Hamm - Fachseminar Informatik Python 2.3.3 (#2, Jan 4 2004, 12:24:16) >>> print 'RGFzIGlzdCBlaW4gc2No9m5lciBUYWcgLi4u\n'.decode("base64") From artelse at mohr-i.nl Mon Jan 12 16:48:03 2004 From: artelse at mohr-i.nl (Arthur Elsenaar) Date: Mon Jan 12 16:48:29 2004 Subject: [Pythonmac-SIG] how to delete files which special characters on Mac OS 10.3 In-Reply-To: <200401122141.38158@abercorn.haspe.hagen.de> References: <200401122141.38158@abercorn.haspe.hagen.de> Message-ID: On Jan 12, 2004, at 21:41, Dr. L. Humbert wrote: > 'SIIHamm,G\xed\xb6\x86\xed\xbb\xa9chu.a.rtf' > I wanted to delete those files with the finder (via trash), > but I had no success. > error -43 > Ok, so I decided to open a terminal and tried > rm -rf * > in the directory, where those files "live". > But -- it did'nt work. I've exactly the same problem with some files containing 'illegal' characters in the file name. In my case most of these files are in the german language and contain umlauts. They just sit there and I can't delete them, I tried most of the ways you describe here, but to no afail. Mostly these files were saved by nicotine (pyslsk) on X11, a python peer-to-peer filesharing app. It clearly is a bug in OS X, but does anyone know how to get rid of files that are listed, but when you try deleting them don't exist? Thanks, Arthur. From berkowit at silcom.com Mon Jan 12 17:10:14 2004 From: berkowit at silcom.com (Paul Berkowitz) Date: Mon Jan 12 17:10:18 2004 Subject: [Pythonmac-SIG] how to delete files which special characters on Mac OS 10.3 In-Reply-To: Message-ID: On 1/12/04 1:48 PM, "Arthur Elsenaar" wrote: > > On Jan 12, 2004, at 21:41, Dr. L. Humbert wrote: > >> 'SIIHamm,G\xed\xb6\x86\xed\xbb\xa9chu.a.rtf' >> I wanted to delete those files with the finder (via trash), >> but I had no success. >> error -43 >> Ok, so I decided to open a terminal and tried >> rm -rf * >> in the directory, where those files "live". >> But -- it did'nt work. > > I've exactly the same problem with some files containing 'illegal' > characters in the file name. In my case most of these files are in the > german language and contain umlauts. They just sit there and I can't > delete them, I tried most of the ways you describe here, but to no > afail. > > Mostly these files were saved by nicotine (pyslsk) on X11, a python > peer-to-peer filesharing app. It clearly is a bug in OS X, but does > anyone know how to get rid of files that are listed, but when you try > deleting them don't exist? In AppleScript, the problem only arises when the startup disk name contains these accents, Otherwise accents are OK. It's a discrepancy between the file system, which uses decomposed Unicode diacritic characters only, and most European language's keyboards which use precomposed Unicode diacritic characters. Perhaps in Python the problem extends to other folders and files in the path, I don't know. It worth trying to change the name of your startup disk (maybe other disks too) so they contain no accents, then try again. Worst come to worst, do it in AppleScript ('alias' filePath' form). -- Paul Berkowitz From paul.sargent at dial.pipex.com Mon Jan 12 09:19:42 2004 From: paul.sargent at dial.pipex.com (Paul Sargent) Date: Mon Jan 12 18:05:44 2004 Subject: [Pythonmac-SIG] PyObjC Templates In-Reply-To: References: <03BEC9D0-422A-11D8-8EDA-000A95C5A776@dial.pipex.com> <3DD61322-4296-11D8-B390-0003931CFE24@cistron.nl> Message-ID: <5D615598-450A-11D8-A882-000A95C5A776@dial.pipex.com> On 9 Jan 2004, at 13:44, Mitch Chapman wrote: > On Jan 9, 2004, at 4:23 AM, Ronald Oussoren wrote: >> On 8 jan 2004, at 23:28, Paul Sargent wrote: >>> Am I going crazy or are the templates not in those packages? I was >>> just interested to see if they were any use. Is it worth my time >>> tracking these down? >> >> IIRC the official Package Manager database contains a 'PyObjC Extras' >> package that contains at least the documentation and possibly also >> the templates. Hmm, couldn't see them in there. >> The PyObjC sources definitively include the templates. However, these >> templates are only usefull for Mac OS X 10.2, OSX 10.3 no longer uses >> Project Builder but uses Xcode. We have 1 Xcode template in CVS. > > If you pull PyObjC from CVS the templates can be found in > .../ProjectBuilder Extras/Project Templates/. I'll grab the CVS and check them out. Thanks Paul -------------- 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/20040112/ead2416b/PGP.bin From oussoren at cistron.nl Tue Jan 13 01:13:30 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Tue Jan 13 01:13:34 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] patching webbrowser.py for OS X In-Reply-To: <29BC9016-453C-11D8-97F6-000A95686CD8@redivi.com> References: <29BC9016-453C-11D8-97F6-000A95686CD8@redivi.com> Message-ID: <9C108902-458F-11D8-B390-0003931CFE24@cistron.nl> On 12 jan 2004, at 21:16, Bob Ippolito wrote: > On Jan 12, 2004, at 2:59 PM, Alex Martelli wrote: > >> >> On Jan 12, 2004, at 8:45 PM, Brendan O'Connor wrote: >> >>> I was trying to use the webbrowser module with OS X's preinstalled >>> python; I'm not very familiar with OS X, but I just patched >>> webbrowser.py >>> to use the very generic "open" command, which works for the simple >>> webbrowser.open(url). >>> >>> I've heard that Fink or another port would be more complete; on the >>> other >>> hand, I'm using computers where I can't install software myself, so >>> this >>> is useful for me. >>> >>> Any thoughts or issues? >> >> As a brand-new user of Mac OS X, "open" appears to be the right >> solution to me, picking up whatever settings one may have made for a >> different browser than Safari, not requiring fink, etc, etc. >> However, we should probably double-check on pythonmac-sig, where the >> REAL Mac Pythonistas hang out... > > I don't think that this patch is necessary.. It might even be insecure, open will open more than just URLs (try 'open /bin/ls'). Ronald From bob at redivi.com Tue Jan 13 01:27:43 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 13 01:25:30 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] patching webbrowser.py for OS X In-Reply-To: <9C108902-458F-11D8-B390-0003931CFE24@cistron.nl> References: <29BC9016-453C-11D8-97F6-000A95686CD8@redivi.com> <9C108902-458F-11D8-B390-0003931CFE24@cistron.nl> Message-ID: <98742090-4591-11D8-8D71-000A95686CD8@redivi.com> On Jan 13, 2004, at 1:13 AM, Ronald Oussoren wrote: > On 12 jan 2004, at 21:16, Bob Ippolito wrote: > >> On Jan 12, 2004, at 2:59 PM, Alex Martelli wrote: >> >>> >>> On Jan 12, 2004, at 8:45 PM, Brendan O'Connor wrote: >>> >>>> I was trying to use the webbrowser module with OS X's preinstalled >>>> python; I'm not very familiar with OS X, but I just patched >>>> webbrowser.py >>>> to use the very generic "open" command, which works for the simple >>>> webbrowser.open(url). >>>> >>>> I've heard that Fink or another port would be more complete; on the >>>> other >>>> hand, I'm using computers where I can't install software myself, so >>>> this >>>> is useful for me. >>>> >>>> Any thoughts or issues? >>> >>> As a brand-new user of Mac OS X, "open" appears to be the right >>> solution to me, picking up whatever settings one may have made for a >>> different browser than Safari, not requiring fink, etc, etc. >>> However, we should probably double-check on pythonmac-sig, where the >>> REAL Mac Pythonistas hang out... >> >> I don't think that this patch is necessary.. > > It might even be insecure, open will open more than just URLs (try > 'open /bin/ls'). insecure? >>> from __future__ import audited_code File "", line 1 SyntaxError: future feature audited_code is not defined FWIW, ic.launchurl('file:///bin/ls') will do the same thing: open a Terminal.app window and execute /bin/ls. Safari will open a Finder window at "/bin" and select the "ls" executable. I'm not sure where the code is that handles unsafe URLs differently, but it's probably somewhere near WebCore.. probably not in Safari itself? I'd have to care, then I'd have to look :) -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/20040113/5660f28c/smime.bin From brendano at stanford.edu Tue Jan 13 04:00:15 2004 From: brendano at stanford.edu (Brendan O'Connor) Date: Tue Jan 13 04:00:29 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] patching webbrowser.py for OS X In-Reply-To: <29BC9016-453C-11D8-97F6-000A95686CD8@redivi.com> Message-ID: > I don't think that this patch is necessary.. On my Mac OS X 10.3 > machine (comes with Python 2.3.0), webbrowser.py uses Internet Config > to launch the url (the 'ic' module). This is basically equivalent to > the open command. It works like this: > * Internet Config is an old MacOS API that's mapped to Launch Services > which launches the URL with your preferred browser > * open is a command line utility that uses the NSWorkspace Cocoa API > which uses Launch Services to launch the URL with your preferred > browser > > I don't think your patch fixes anything, it's launched by Launch > Services either way.. at least on OS X 10.3. A patch doesn't do us any > good against Python 2.2.0 on Mac OS 10.2 if its behavior is broken. > Apple doesn't update Python between major releases. > > You should be able to install MacPython 2.3 in your home directory. > Don't bother with Fink. That's it, I'm on 10.2; I guess this is just a quick fix for that one version. Well, thanks all for the pointers. -Brendan From Jack.Jansen at cwi.nl Tue Jan 13 07:19:54 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jan 13 07:20:09 2004 Subject: [Pythonmac-SIG] Python C extensions that depend on dynamic libraries In-Reply-To: <4002E58A.1000304@noaa.gov> References: <2A2CE4A2-4478-11D8-B37C-000A27B19B96@cwi.nl> <20040112001508.GB52200@uiuc.edu> <6FBC55CC-4497-11D8-9F26-000A95686CD8@redivi.com> <6D73EE82-44DC-11D8-9F26-000A95686CD8@redivi.com> <20040112085650.GB55645@uiuc.edu> <45DA434D-4506-11D8-84BD-000A958D1666@cwi.nl> <5CE5B6FC-4510-11D8-AF40-000393894CEA@xs4all.nl> <4002E58A.1000304@noaa.gov> Message-ID: On 12-jan-04, at 19:20, Chris Barker wrote: > Loadable modules, called bundles in OS-X, have the file type > MH_BUNDLE. Most Unix-based software ports usually produce bundles with > a .so extension, for the sake of consistancy across platforms. > Although Apple recommends giving bundles a .bundle extension, it isn't > mandatory. I wouldn't be surprised if whoever wrote this article had a look at Python and Apache, and said "Hmm, so software ported over from unix uses .so":-) -- 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 john.weeks at insead.edu Tue Jan 13 16:39:04 2004 From: john.weeks at insead.edu (John Weeks) Date: Tue Jan 13 16:39:14 2004 Subject: [Pythonmac-SIG] AppScripting Safari Message-ID: I am experimenting with AppScripting and Safari and I have a question about how to translate the "do JavaScript" command into the form AppScripting expects. I have a AppleScript program that looks like this: property timeout_value : 60 tell application "Safari" activate try if not (exists document 1) then make new document at the beginning of documents end if set the URL of the front document to "http://lexis-nexis.com/" if my page_loaded(timeout_value) is false then error "Timed out" end try end tell on page_loaded(timeout_value) delay 2 repeat with i from 1 to the timeout_value tell application "Safari" if (do JavaScript "document.readyState" in document 1) is "complete" then return true else if i is the timeout_value then return false else delay 1 end if end tell end repeat return false end page_loaded Using AppScripting, I can get this far: from AppScripting import app, classes, enums, item safari = app('Safari.app') if not safari.windows[0].exists(): safari.documents.end.make(new=classes.document) safari.windows[0].document.URL.set('http://lexis-nexis.com') But then I am stumped. How to do I perform the do JavaScript? Thanks, John From john.weeks at insead.edu Tue Jan 13 16:43:44 2004 From: john.weeks at insead.edu (John Weeks) Date: Tue Jan 13 16:43:53 2004 Subject: [Pythonmac-SIG] AppScripting Documentation Message-ID: As I was trying to solve the problem with AppScripting and Safari, I tried to get the AppScripting doc function to work. Here is what I tried: import AppScripting fp = open("Safari.html", "w") fp.write(AppScripting.doc('Safari.app')) fp.close() This didn't work, though. I manually copied the doc directory from the AppScripting distribution into my site-packages folder; I downloaded the HTMLTemplate package. But I am getting an error. Here is the traceback. Any ideas what I am missing? File "test3.py", line 3, in ? fp.write(AppScripting.doc('Safari.app')) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site-packages/AppScripting/Main.py", line 137, in doc return DocGen.renderDoc(appPathOrName, aeteList, aeTable) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site-packages/AppScripting/Doc/DocGen.py", line 245, in renderDoc template = HTMLTemplate.Template(_xhtml) TypeError: Template() takes at least 2 arguments (1 given) Thanks, John From fwrutydv at india.com Tue Jan 13 07:10:31 2004 From: fwrutydv at india.com (Brantley Amie) Date: Tue Jan 13 19:18:04 2004 Subject: [Pythonmac-SIG] Re: HDOAXVF, in scarlet headbands Message-ID: chimera aphid argonaut beseech cardiff conjugal bilateral quaternary effluent spree sleep exaggerate pagoda boise godwit modal pliers sister sloven victorian bullyboy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040113/2de93ccd/attachment.html From lejwxgijymxt at tom.com Tue Jan 13 08:09:47 2004 From: lejwxgijymxt at tom.com (Mathews Clifford) Date: Tue Jan 13 20:17:15 2004 Subject: [Pythonmac-SIG] Re: JKP, the novels first Message-ID: confucianism tousle dramatic authoritative epidermic dollop bellyfull sulfite blimp southey servant worse marilyn and cry hot detriment patty attic lipstick denudation -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040113/3cc2f47a/attachment.html From john.weeks at insead.edu Wed Jan 14 07:00:18 2004 From: john.weeks at insead.edu (John Weeks) Date: Wed Jan 14 07:00:29 2004 Subject: [Pythonmac-SIG] aeve and Safari Message-ID: Trying to see how aeve handles the scripting of Safari and compare it to AppScripting, I am having problems figuring out how to call "do JavaScript" using aeve as well. I have a little program that works fine: import aeve saf = aeve.talkto('com.apple.safari') from aeve.Applications import Safari newdoc = saf.make(new=Safari.document) newdoc.URL = "http://web.lexis-nexis.com/" Looking at the aeve-generated dictionary for Safari, I tried to implement the AppleScript: set the load_status to (do JavaScript "document.readyState" in document 1) as: import aeve saf = aeve.talkto('com.apple.safari') from aeve.Applications import Safari newdoc = saf.make(new=Safari.document) newdoc.URL = "http://web.lexis-nexis.com/" load_status = newdoc.do_JavaScript("document.readyState") But I get the following error: File "test2.py", line 5, in ? newdoc.URL = "http://web.lexis-nexis.com/" File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/aeve/aetypes/aecomplex.py", line 246, in __set__ ObjectSpecifier.__set__(self, frominstance, tovalue) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/aeve/aetypes/aecomplex.py", line 127, in __set__ _from_instance=frominstance, File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/aeve/aetypes/aecomplex.py", line 468, in bound_event_method return self(inst, *args, **kwargs) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/aeve/aetypes/aecomplex.py", line 493, in __call__ raise aetools.Error, aetools.decodeerror(_reply, _arguments, _attributes) aeve.aetypes.aetools.Error: (1, u'NSReceiverEvaluationScriptError: 4', None) I also tried: import aeve saf = aeve.talkto('com.apple.safari') from aeve.Applications import Safari newdoc = saf.make(new=Safari.document) newdoc.URL = "http://web.lexis-nexis.com/" load_status = saf.do_JavaScript(in_=newdoc,_object='document.readyState') But I get the same error. Thanks for any help, John From bob at redivi.com Wed Jan 14 07:16:12 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 14 07:13:51 2004 Subject: [Pythonmac-SIG] aeve and Safari In-Reply-To: References: Message-ID: <715E3122-468B-11D8-9430-000A95686CD8@redivi.com> On Jan 14, 2004, at 7:00 AM, John Weeks wrote: > Trying to see how aeve handles the scripting of Safari and compare > it to AppScripting, I am having problems figuring out how to call > "do JavaScript" using aeve as well. > > I have a little program that works fine: > > import aeve > saf = aeve.talkto('com.apple.safari') > from aeve.Applications import Safari > newdoc = saf.make(new=Safari.document) > newdoc.URL = "http://web.lexis-nexis.com/" > > Looking at the aeve-generated dictionary for Safari, I tried to > implement the AppleScript: > > set the load_status to (do JavaScript "document.readyState" in > document 1) > > as: > > import aeve > saf = aeve.talkto('com.apple.safari') > from aeve.Applications import Safari > newdoc = saf.make(new=Safari.document) > newdoc.URL = "http://web.lexis-nexis.com/" > load_status = newdoc.do_JavaScript("document.readyState") Try this: import aeve saf = aeve.talkto('com.apple.safari') from aeve.Applications import Safari newdoc = saf.make(new=Safari.document) newdoc.URL = "http://web.lexis-nexis.com/" load_status = saf.do_JavaScript("document.readyState", in_=saf.documents[1]) -bob From hengist.podd at virgin.net Wed Jan 14 06:08:40 2004 From: hengist.podd at virgin.net (has) Date: Wed Jan 14 07:42:48 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG] AppScripting Safari Message-ID: John Weeks wrote: >I am experimenting with AppScripting and Safari and I have a question >about how to translate the "do JavaScript" command into the form >AppScripting expects. From the manual: ======= Notes on Identifier Mangling ======= Because aete resources do not specify C-style identifiers, appscript applies the following name mangling rules to convert AppleScript-style identifiers to Python-compatible format: - Characters a-z, A-Z, 0-9 and underscores are preserved. - Spaces and hyphens are replaced with underscores. - All other characters are converted to 0X00-style hexadecimal representations. - Names that match Python keywords or words reserved by appscript have an underscore appended. So in this case: do JavaScript "document.readyState" in document 1 becomes: safari.do_JavaScript('document.readyState', in_=safari.documents[0]) ------- Of course, the easiest thing is to use doc() to get the correct terms; which brings us to: >As I was trying to solve the problem with AppScripting and Safari, I >tried to get the AppScripting doc function to work. >[...] >But I am getting an error. > >TypeError: Template() takes at least 2 arguments (1 given) My bad: the HTMLTemplate API has changed since AppScripting 0.3.1 was released. You'll need to use HTMLTemplate 0.2.0 for now. Any other problems/questions, please fire away. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From tony at comsol.com Wed Jan 14 13:31:04 2004 From: tony at comsol.com (Tony Ching) Date: Wed Jan 14 13:31:14 2004 Subject: [Pythonmac-SIG] Do you want the FEMLAB Tour CD? Message-ID: <200401141831.i0EIGg5f028594@mail.comsol.se> Dear Colleague, I would like to offer you a free CD containing models and case studies that were presented during the worldwide FEMLAB Multiphysics Modeling Seminar Tour last year. The CD includes detailed documentation of 34 completely new finite element models, as well as the actual FEMLAB model files. Most of the models have not been published before. If you are interested in receiving the CD free of charge, please register at http://www.comsol.com/tourcd/ This offer will be valid as long as we still have CDs. FEMLAB is a powerful multiphysics modeling package using finite element analysis in 1D, 2D and 3D, and is fully integrated with MATLAB. It is used in research, product development and teaching, in such fields as: - Acoustics - Antennas - Bioscience - Bioengineering - Chemical reactions - Diffusion - Ecology - Electromagnetics - Environmental science - Fluid dynamics - Fuel cells - Geophysics - Heat transfer - Math/Applied PDEs - MEMS - Microwave engineering - Nanotechnology - Optics and photonics - Physics - Porous media flow - Quantum mechanics - Radio frequency components - Semiconductor devices - Structural mechanics - Transport phenomena - Wave propagation - Any combination of the above Best Regards, Tony Ching P.S. Feel free to forward this to a colleague. COMSOL, Inc. 310-689-7250 From pecora at anvil.nrl.navy.mil Wed Jan 14 13:38:24 2004 From: pecora at anvil.nrl.navy.mil (Louis M. Pecora) Date: Wed Jan 14 13:37:25 2004 Subject: [Pythonmac-SIG] Do you want the FEMLAB Tour CD? In-Reply-To: <200401141831.i0EIGg5f028594@mail.comsol.se> References: <200401141831.i0EIGg5f028594@mail.comsol.se> Message-ID: Hey, Tony, keep the spam out of this list. -- Cheers, Lou Pecora From paul at fxtech.com Wed Jan 14 13:48:08 2004 From: paul at fxtech.com (Paul Miller) Date: Wed Jan 14 13:48:23 2004 Subject: [Pythonmac-SIG] Looking for advice: supporting multiple embedded interpreters Message-ID: <6.0.1.1.2.20040114124029.056b7df0@mail.profoundeffects.com> Some background first - we have some software that embeds a Python interpreter into a host application. Scripts are loaded dynamically and used. But we want to support the ability to edit scripts while the app is running. This means we have to "unload" the script and cause a reload. Normal module reloading tricks don't work because if you try to reimport a script that imports another script, and if the nested script is changed, it might not be reloaded itself. Also, we have 2 parts of the software, each using Python for its own set of scripts. We don't want scripts loaded into each parts to "see" scripts loaded into the other part. Ideally, we would like multiple "instances" of a Python interpreter to manage this. So, for Python 2.2, I came up with a system that works. When we need a new self-contained Python interpreter, I use Py_NewInterpreter(), swap it in using PyThreadState_Swap, load my built in modules, and swap it back out. When I need to run some code in that interpreter, I swap it back in, load the module I need, call methods in it, and swap it back out. When I'm done with the interpreter, I swap it back in and call Py_EndInterpreter. When I want to force a reload of all the script code in a given interpreter, I just delete the interpreter, create a new one, and load the scripts into that one. This has worked flawlessly. And each "part" of my application can use a different interpreter without modules and globals in each one interfering with the other. Now, with Python 2.3, this code doesn't seem to work anymore. Someone told me it is likely because of the extensive rewrite of GUSI or whatnot. It is important to note that I'm NOT really doing any threading. I just was self-contained interpreters for the above reasons. What I am wondering is if there a reliable method in 2.3 that does what I need? From hengist.podd at virgin.net Wed Jan 14 11:50:23 2004 From: hengist.podd at virgin.net (has) Date: Wed Jan 14 14:07:50 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG] AppScripting Safari In-Reply-To: References: Message-ID: John Weeks wrote: >Thanks, that works great. > >One question so I understand better how to interpret the doc() output. >When I generate it for Safari, it says the following: > >ref.do_JavaScript() -- Applies a string of JavaScript code to a >document. > in_=document -- The document that the JavaScript should be >applied in. >result=None > >Yet, it seems that "ref" in this case should alway be the Safari >application and not, for example, the document (which gets specified by >the 'in_' parameter). Is that right? Should this read >app.do_JavaScript()? > >This is obviously not a big deal, I am just testing my understanding as >I learn more about these things. Looks like a bug in Safari's dictionary. Script Editor, etc. show the 'do JavaScript' command as: do JavaScript : Applies a string of JavaScript code to a document. do JavaScript reference -- the object for the command in document -- The document that the JavaScript should be applied in. But it really ought to look something like: do JavaScript : Applies a string of JavaScript code to a document. do JavaScript string/unicode text -- the JavaScript to execute in document -- The document that the JavaScript should be applied in. Typical clueless Cocoa app... grr. As for appscript's doc() command, it tries to be clever in presenting commands as you'd normally use them; as Python-style method calls upon the target object(s). So any time it sees a direct parameter whose type is 'reference' (or 'ObjectSpecifier', to give it its proper name), it shows ref.foo() instead of app.foo() and omits any separate mention of the direct parameter. (For example, look at how the open() command is presented, versus the exists() command.) I may have to change this behaviour back to 'dumb' form if this approach turns out to be no good. Really though I blame the inadequacies of the aete format (the sdef format that'll someday replace it is better, but still not perfect) for not providing more detailed, not to mention complete, information in the first place. Many thanks for bringing this to my attention. I've put it on the list of things to ask the next time I go all Spanish Inquisition-y on the responsible Apple engineers. Meantime, you may want to cross-reference any appscript-generated docs with Script Editor-generated ones to double-check for any such discrepancies. has -- http://freespace.virgin.net/hamish.sanderson/ From Jack.Jansen at cwi.nl Wed Jan 14 18:14:59 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Jan 14 18:15:32 2004 Subject: [Pythonmac-SIG] Handling bad dictionaries In-Reply-To: References: Message-ID: <7913838D-46E7-11D8-8DA0-000A27B19B96@cwi.nl> On 14-jan-04, at 17:50, has wrote: > > Looks like a bug in Safari's dictionary. Script Editor, etc. show the > 'do JavaScript' command as: > > do JavaScript : Applies a string of JavaScript code to a document. > do JavaScript reference -- the object for the command > in document -- The document that the JavaScript should be applied in. > > But it really ought to look something like: > > do JavaScript : Applies a string of JavaScript code to a document. > do JavaScript string/unicode text -- the JavaScript to execute > in document -- The document that the JavaScript should be applied in. > > Typical clueless Cocoa app... grr. Do AppScripting and aeve have a way to deal with this situation? With gensuitemodule it was easy: just hack the module after it was generated, but for the new interfaces that won't work. It would be nice if there was a file or module somewhere that could contain "edit instructions" for dictionaries known to be faulty. The easiest form is probably a file with instructions "if you read the dictionary of app X ignore entry Y" and "if you read the dictionary of app X please add entry Z" where Y is some identifier and Z is an actual entry in some intermediate form used by aeve/AppScripting. -- 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 paul at donovansbrain.co.uk Wed Jan 14 18:20:57 2004 From: paul at donovansbrain.co.uk (Paul Donovan) Date: Wed Jan 14 18:21:04 2004 Subject: [Pythonmac-SIG] Carbon.File and resolving aliases Message-ID: <4EF14640-46E8-11D8-9876-000393998ACA@donovansbrain.co.uk> I'm trying to work out how to deal with aliases in Python 2.3 on Panther. Searching the archives I came across the macfs module, but the documentation says to consider it obsolete for 2.3 and use Carbon.File instead. Where would I find documentation on that? The situation I'm trying to handle is very simple. I need to read a file in the user's home directory which is fairly likely to be an alias (it's the iTunes music library - people often put an alias to a shared library in /Users/Shared so that multiple users can share the same music library). My non-alias aware code is simply: file = os.path.expanduser('~/Music/iTunes/iTunes Music Library.xml') Any suggestions? Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2377 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040114/226982e8/smime.bin From tgmjr at china.com Tue Jan 13 21:18:19 2004 From: tgmjr at china.com (Blake Russel) Date: Wed Jan 14 20:18:27 2004 Subject: [Pythonmac-SIG] Re: MX, whats your address?' Message-ID: dormant occupant care tobacco chief alistair aerosol victim ursa annulling barr houston colloquium alton degas odyssey breakup ameslan colicky tray lousewort fateful round subsistent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040114/9240ad52/attachment.html From kprwbz at excite.com Thu Jan 15 13:37:30 2004 From: kprwbz at excite.com (Kerry Mcneil) Date: Thu Jan 15 02:43:40 2004 Subject: [Pythonmac-SIG] Improve your cup size NATURALLLY! Clinically verified! dbmxbwj mkr r i Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040115/7f8d47fb/attachment.html From bob at redivi.com Thu Jan 15 04:53:38 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 15 04:51:17 2004 Subject: [Pythonmac-SIG] Handling bad dictionaries In-Reply-To: <7913838D-46E7-11D8-8DA0-000A27B19B96@cwi.nl> References: <7913838D-46E7-11D8-8DA0-000A27B19B96@cwi.nl> Message-ID: On Jan 14, 2004, at 6:14 PM, Jack Jansen wrote: > On 14-jan-04, at 17:50, has wrote: > >> >> Looks like a bug in Safari's dictionary. Script Editor, etc. show the >> 'do JavaScript' command as: >> >> do JavaScript : Applies a string of JavaScript code to a document. >> do JavaScript reference -- the object for the command >> in document -- The document that the JavaScript should be applied >> in. >> >> But it really ought to look something like: >> >> do JavaScript : Applies a string of JavaScript code to a document. >> do JavaScript string/unicode text -- the JavaScript to execute >> in document -- The document that the JavaScript should be applied >> in. >> >> Typical clueless Cocoa app... grr. > > Do AppScripting and aeve have a way to deal with this situation? With > gensuitemodule it was easy: just hack the module after it was > generated, but for the new interfaces that won't work. > > It would be nice if there was a file or module somewhere that could > contain "edit instructions" for dictionaries known to be faulty. The > easiest form is probably a file with instructions "if you read the > dictionary of app X ignore entry Y" and "if you read the dictionary of > app X please add entry Z" where Y is some identifier and Z is an > actual entry in some intermediate form used by aeve/AppScripting. As far as aeve goes, you can modify the class and create whatever element/property descriptors you want after loading (but creating these is not particularly easy). I would imagine AppScripting has similar capabilities. A known database of faulty dictionaries is a good idea. I had this same "edit instructions" idea for bundlebuilder.. a plist should sit on the internet somewhere that describes packages that require special options, such as including a dylib or forcing a whole package to be included so __file__ data loading works. The dylib stuff is a solved problem with my macholib version of bundlebuilder (I should release these someday), but it still can't automagically include pygame because it needs a ttf file from the package. -bob From hengist.podd at virgin.net Thu Jan 15 06:02:40 2004 From: hengist.podd at virgin.net (has) Date: Thu Jan 15 06:31:56 2004 Subject: [Pythonmac-SIG] Re: Handling bad dictionaries In-Reply-To: <7913838D-46E7-11D8-8DA0-000A27B19B96@cwi.nl> References: <7913838D-46E7-11D8-8DA0-000A27B19B96@cwi.nl> Message-ID: Jack wrote: >>Looks like a bug in Safari's dictionary. Script Editor, etc. >>Typical clueless Cocoa app... grr. > >Do AppScripting and aeve have a way to deal with this situation? >With gensuitemodule it was easy: just hack the module after it was >generated, but for the new interfaces that won't work. Note this particular Safari terminology bug only affects appscript's doc() function, which is annoying but not fatal. There are some terminology bugs that'll prevent application control due to appscript's sanity-checking, but this isn't one of them. As far as terminology bugs go, the answer here is to fix the problem at source. The best solution is to get the application developer to sort it out themselves, but you can always hack the application's terminology resource yourself if you have to. So I don't see any need to muck up appscript and other IAC bridges with klunky adaptor mechanisms for this particular problem. Besides, there are plenty more serious application bugs which can't be hacked or adapted around - busted terminology is probably the least of our problems. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From Jack.Jansen at cwi.nl Thu Jan 15 07:02:04 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Jan 15 07:01:29 2004 Subject: [Pythonmac-SIG] Fwd: [MACTCL] [ANN] TclTkAqua 8.4.5b1 distributions available for testing Message-ID: People interested in Tkinter support may want to give the upcoming TclTkAqua beta a test drive, and report any problems back to Daniel and/or here. Begin forwarded message: > From: "Daniel A. Steffen" > Date: 13 januari 2004 23:36:01 GMT+01:00 > To: tcl-mac@lists.sourceforge.net > Subject: [MACTCL] [ANN] TclTkAqua 8.4.5b1 distributions available for > testing > > Dear All, > > I have made available a beta release of the upcoming Tcl/Tk Aqua 8.4.5 > BI, and would be grateful for help in testing that the various > components perform as expected (I have spent only very limited time on > testing). Everything is available under > http://tcltkaqua.sourceforge.net/8.4.5b1/ > more details below. > > Many components have been upgraded since 8.4.4.0, c.f. list below, and > I have added a number of additional ports & features, c.f. > http://tcltkaqua.sourceforge.net/8.4.5b1/CHANGES > http://tcltkaqua.sourceforge.net/8.4.5b1/README > for details. > > I have built the distribution both on Mac OS X 10.2 (Jaguar) and 10.3 > (Panther), but if no problems with the Jaguar release are reported by > Panther users, for the 8.4.5 final I plan to distribute only the > Jaguar release to reduce confusion (unless people think having the > Panther release would be useful?). > > The Jaguar and Panther disk images are available at > http://tcltkaqua.sourceforge.net/8.4.5b1/dmg/ > (the Panther images having a "-Panther" suffix) > > Individual tarballs of all the installer packages are also available: > http://tcltkaqua.sourceforge.net/8.4.5b1/pkg/ > http://tcltkaqua.sourceforge.net/8.4.5b1/Panther/pkg/ > > as are tarballs of the results of 'make install' of each project, to > e.g. allow easier access to binaries to non-MacOSX users > http://tcltkaqua.sourceforge.net/8.4.5b1/tar/ > http://tcltkaqua.sourceforge.net/8.4.5b1/Panther/tar/ > > in particular, note here the tarballs for tcl/tkX11 (standard unix > build in /usr/local), which are not available as Installer packages > http://tcltkaqua.sourceforge.net/8.4.5b1/tar/Tcl_X11-8.4.5.tar.gz > http://tcltkaqua.sourceforge.net/8.4.5b1/tar/Tk_X11-8.4.5.tar.gz > > as well as tarballs for the standalone Wish and for Wishkit, a tclkit > analogue (standalone Wish with all packages necessary to load starkits > embedded and auto_path adjusted), no installer package for these > either > http://tcltkaqua.sourceforge.net/8.4.5b1/tar/TclTkAquaStandalone > -8.4.5.tar.gz > http://tcltkaqua.sourceforge.net/8.4.5b1/tar/Wishkit.app-8.4.5.tar.gz > > the tclkit tarball is the only binary in the distro that will run on > 10.1-10.3, and should be identical (but more recently compiled) to the > binary on http://www.equi4.com/pub/tk/8.4.5/ > http://tcltkaqua.sourceforge.net/8.4.5b1/Panther/tar/tclkit-darwin- > ppc-8.4.5.tar.gz > > The sources used for most projects are CVS HEAD as of 2003-12-29 > 00:00:00 GMT, unless otherwise noted, c.f. > http://tcltkaqua.sourceforge.net/8.4.5b1/cvsTag.conf > for details, tarballs of the exact sources (before patching) used to > build the distribution are available: > http://tcltkaqua.sourceforge.net/8.4.5b1/src/ > as well as the patches used, as usual > http://tcltkaqua.sourceforge.net/8.4.5b1/patches/ > (I'm hoping to find some time soon to add all components to > darwinports based on these sources&patches, help appreciated...) > > The rest of the 8.4.5b1 directory contains the tools used to build the > distro, as usual, this is also in CVS tagged as 'release-8_4_5_0b1' > > I'm grateful for all reports of success/failure (if possible with > debugging of any problems, I have very limited time at the moment) or > any other constructive comments; and would also appreciate > proof-reading of README and other documents, in particular those in > http://tcltkaqua.sourceforge.net/8.4.5b1/Installer/ > and its subdirectories. > > One last point to note: on Panther, at present, the Tcl.pkg installer > will replace /usr/bin/tclsh8.4 installed by the system, what are > people's opinions on that, should we preserve the existing binary e.g. > by renaming it (to tclsh8.4.4?), or move our binary into > /usr/local/bin (noting well that this is not in the user's PATH by > default?). > > If no major problems are reported I'm planning to build and release > the final 8.4.5 BI on the weekend of the 24/25th. > > Cheers, > > Daniel > > -- > ** Daniel A. Steffen ** "And now for something completely > ** Dept. of Mathematics ** different" Monty Python > ** Macquarie University ** > ** NSW 2109 Australia ** > > > ---------------------------------------------------------------------- > The Tcl/Tk Aqua Batteries-Included distribution contains the following > projects: > > . Tcl/Tk 8.4.5 > . Thread 2.6 > . IncrTcl 3.3b1 > IWidgets 4.0.2 > . Tcllib, Tklib 1.5 > . BWidget 1.7 > Mclistbox 1.02 > TclX 8.4 > . TclVfs 1.3 > . Expect 5.39 > . TkTable 2.8 > . Vu 2.2 > TkImg 1.3 > TkHtml 2.0 > . Treectrl 1.0 > TclXML, TclDOM, TclXSLT 2.6 > . TclSOAP 1.6.7 > . tDOM 0.8.0 > Memchan 2.2 > Trf 2.1 > TrfCrypt 2.0p3 > . TLS 1.50 > . TclHttpd 3.4.3 > Tbcload, Compiler, Parser 1.4 > . Mk4Tcl, Oomk 2.4.9.2 > TcLex 1.2 > . Snack 2.2.3 > Tix 8.2 > + XOTcl 1.1.1 > . TclAE 2.0b14 > . QuickTimeTcl 3.1 > TclSpeech 2.0 > + TclResource 1.1 > + MacCarbonPrint 0.2 > . e4Graph 1.0a10 > . Tkcon 2.4 > + SWIG (tcl) 1.3.20 > . Launcher 1.0 > . Tclkit, SDX, Critcl, Wikit 8.4.5 > CritLib 2003/04/10 > > Packages with '+' have been added and packages with '.' have been > updated since the release of the 8.4.4.0 BI distribution. > ---------------------------------------------------------------------- > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Tcl-mac mailing list > Tcl-mac@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tcl-mac > -- 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: not available Type: text/enriched Size: 7411 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040115/5133306d/attachment.bin From berkowit at silcom.com Thu Jan 15 11:00:03 2004 From: berkowit at silcom.com (Paul Berkowitz) Date: Thu Jan 15 11:00:08 2004 Subject: [Pythonmac-SIG] Re: Handling bad dictionaries In-Reply-To: Message-ID: On 1/15/04 3:02 AM, "has" wrote: > Jack wrote: > >>> Looks like a bug in Safari's dictionary. Script Editor, etc. >>> Typical clueless Cocoa app... grr. >> >> Do AppScripting and aeve have a way to deal with this situation? >> With gensuitemodule it was easy: just hack the module after it was >> generated, but for the new interfaces that won't work. > > Note this particular Safari terminology bug only affects appscript's > doc() function, which is annoying but not fatal. There are some > terminology bugs that'll prevent application control due to > appscript's sanity-checking, but this isn't one of them. > > As far as terminology bugs go, the answer here is to fix the problem > at source. The best solution is to get the application developer to > sort it out themselves, but you can always hack the application's > terminology resource yourself if you have to. So I don't see any need > to muck up appscript and other IAC bridges with klunky adaptor > mechanisms for this particular problem. Besides, there are plenty > more serious application bugs which can't be hacked or adapted around > - busted terminology is probably the least of our problems. It almost only ever happens in cruddy Apple apps whose developers spent 30 minutes trying to learn AppleScript before slamming in their dictionaries. Somebody somewhere seems committed to fixing these bugs eventually, so if you report the bugs assiduously at bugreporter they do get fixed 18 months and two major OS releases later. ;-) -- Paul Berkowitz From Jack.Jansen at cwi.nl Thu Jan 15 15:09:12 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Jan 15 15:09:27 2004 Subject: [Pythonmac-SIG] No more releases of MacPython-OS9? Message-ID: [I'm cc-ing python-dev to get some feedback on this issue from a wider community too, let me know if the crowd there don't want this]. There is a serious problem with distributing future versions of MacPython-OS9. While the 2.3.3 installer has been sitting on my machine for the last three weeks I cannot distribute it due to licensing issues with Installer VISE from Mindvision. Mindvision's licensing scheme is a subscription-based model: you pay a yearly fee based on the number of copies you intend to distribute and whether you're a commercial/noncommercial operation. Built installers continue to work when you don't renew your subscription, but you cannot create new installers. For many years they have had a program whereby shareware and freeware developers could apply for a free license, and MacPython-OS9 installers have been created with Installer VISE for many many years. And, I must say, with great satisfaction on my side: even though MacPython installers have been very complex with 68K versus PowerPC, Classic versus Carbon execution model, inclusion of various optional bits and other issues all handled fairly easily. However, Mindvision has discontinued the free licensing program. And while there is some leeway for renewing existing freeware licenses apparently I should have applied for that before last october, when the previous license expired (apparently Mindvision thinks that people create installers every couple of days?). So now I'm looking at three choices: 1. Stop distributing MacPython-OS9. I was planning to continue the 2.3.X series for as long as I had access to compatible hardware, but as a community service (personally I couldn't be bothered with OS9 anymore:-). 2. Buy an Installer VISE license. If I read correctly this would cost $500 per year, probably for the next 2 years. This will only happen if someone else comes up with the money: I don't have it... 3. Switch to a different installer. Given the complexity of the MacPython distribution (even though it is a lot simpler nowadays, with only Carbon/PPC supported) I don't want to invest time in this. So: someone else will have to step in and create an installer. I'd like to hear what people think the best course of action is, especially from people who have a current interest in MacPython-OS9 (and/or are willing to donate time or money), -- 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 barry at python.org Thu Jan 15 15:18:30 2004 From: barry at python.org (Barry Warsaw) Date: Thu Jan 15 15:18:45 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] No more releases of MacPython-OS9? In-Reply-To: References: Message-ID: <1074197910.3167.75.camel@anthem> On Thu, 2004-01-15 at 15:09, Jack Jansen wrote: > 2. Buy an Installer VISE license. If I read > correctly this would cost $500 > per year, probably for the next 2 years. This will only happen if > someone else comes up with the money: I don't have it... If continuing the MacOS9 distro of Python 2.3.x is important enough to the Python community, then I think the PSF should pick up the cost of the license. Personally, I don't care about OS9 either myself. :) OTOH, I think it's perfectly reasonable to declare an EOL date for MacPython-OS9 now. -Barry From paul at fxtech.com Thu Jan 15 15:18:51 2004 From: paul at fxtech.com (Paul Miller) Date: Thu Jan 15 15:19:07 2004 Subject: [Pythonmac-SIG] No more releases of MacPython-OS9? In-Reply-To: References: Message-ID: <6.0.1.1.2.20040115141555.050ed148@mail.fxtech.com> >I'd like to hear what people think the best course of action is, >especially from people who have a current interest in MacPython-OS9 >(and/or are willing to donate time or money), We currently use MacPython on OS9 and OS X systems in one of our commercial effects packages, and appreciate the effort Jack and many others have contributed to making it happen. With that said, I believe fully that OS9 is a dead horse and we should encourage people to migrate to OS X and Mach-O as fast as possible. IMHO, any effort spent on OS9 is a waste of valuable resources. There are only so many hours in the day. I'd rather you have a beer on my behalf than spend any more time on beating the dead horse. From jordan at krushen.com Thu Jan 15 15:26:11 2004 From: jordan at krushen.com (Jordan Krushen) Date: Thu Jan 15 15:26:15 2004 Subject: [Pythonmac-SIG] Wiki Message-ID: <0EBFBC36-4799-11D8-88D6-000A958E9340@krushen.com> So it seems that some leet hacker has managed to own our wiki. I'm so scared. Anyway, I can show the diffs to the latest version, but I'm not sure how to revert the changes. Anyone know how to do that? Does it require a backup? J. From aahz at pythoncraft.com Thu Jan 15 16:27:02 2004 From: aahz at pythoncraft.com (Aahz) Date: Thu Jan 15 16:27:52 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] No more releases of MacPython-OS9? In-Reply-To: References: Message-ID: <20040115212700.GA7170@panix.com> On Thu, Jan 15, 2004, Jack Jansen wrote: > > 2. Buy an Installer VISE license. If I read > correctly this would cost $500 > per year, probably for the next 2 years. This will only happen if > someone else comes up with the money: I don't have it... Looks like 2.3 is the latest release currently available. There've been a lot of bugfixes since then. Do you have any download statistics for the OS9 version? (I.e. rough idea of how many people care.) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ A: No. Q: Is top-posting okay? From Jack.Jansen at cwi.nl Thu Jan 15 17:48:29 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Jan 15 17:48:33 2004 Subject: [Pythonmac-SIG] Carbon.File and resolving aliases In-Reply-To: <4EF14640-46E8-11D8-9876-000393998ACA@donovansbrain.co.uk> References: <4EF14640-46E8-11D8-9876-000393998ACA@donovansbrain.co.uk> Message-ID: On 15-jan-04, at 0:20, Paul Donovan wrote: > I'm trying to work out how to deal with aliases in Python 2.3 on > Panther. Searching the archives I came across the macfs module, but > the documentation says to consider it obsolete for 2.3 and use > Carbon.File instead. Where would I find documentation on that? > > The situation I'm trying to handle is very simple. I need to read a > file in the user's home directory which is fairly likely to be an > alias (it's the iTunes music library - people often put an alias to a > shared library in /Users/Shared so that multiple users can share the > same music library). > > My non-alias aware code is simply: > > file = os.path.expanduser('~/Music/iTunes/iTunes Music Library.xml') > > Any suggestions? It's not simple, if you want to cater for aliases in the middle (which I assume you do). A solution would be to split file into components, set result to the first component apply os.path.exists() to result, if it doesn't exist try replacing it with Carbon.File.ResolveAliasFile(result) and go back to the top. If os.path.exists() returns true you append the next component and start over. Continue until you're out of components. If you write the routine I'd be interested in adding it to the macostools module. -- 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 Jack.Jansen at cwi.nl Thu Jan 15 17:55:29 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Jan 15 17:55:33 2004 Subject: [Pythonmac-SIG] Wiki In-Reply-To: <0EBFBC36-4799-11D8-88D6-000A958E9340@krushen.com> References: <0EBFBC36-4799-11D8-88D6-000A958E9340@krushen.com> Message-ID: On 15-jan-04, at 21:26, Jordan Krushen wrote: > So it seems that some leet hacker has managed to own our wiki. I'm so > scared. > > Anyway, I can show the diffs to the latest version, but I'm not sure > how to revert the changes. Anyone know how to do that? Does it > require a backup? Just made an attempt, it seems, but the formatting is all gone. Bob probably knows best how to revert things, but he is off visiting A-Company-Whose-Name-Shall-Not-Be-Uttered-Even-In-These-Safe- Surroundings (to misparaphrase Gandalf). He should be back tomorrow. -- 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 rfinn at opnet.com Thu Jan 15 18:44:51 2004 From: rfinn at opnet.com (Russell Finn) Date: Thu Jan 15 18:45:42 2004 Subject: [Pythonmac-SIG] Wiki In-Reply-To: References: <0EBFBC36-4799-11D8-88D6-000A958E9340@krushen.com> Message-ID: On Jan 15, 2004, at 5:55 PM, Jack Jansen wrote: > On 15-jan-04, at 21:26, Jordan Krushen wrote: >> So it seems that some leet hacker has managed to own our wiki. I'm >> so scared. >> >> Anyway, I can show the diffs to the latest version, but I'm not sure >> how to revert the changes. Anyone know how to do that? Does it >> require a backup? > > Just made an attempt, it seems, but the formatting is all gone. Bob > probably knows best how to revert things, but he is off visiting > A-Company-Whose-Name-Shall-Not-Be-Uttered-Even-In-These-Safe- > Surroundings (to misparaphrase Gandalf). He should be back tomorrow. I think I got the formatting fixed -- there were some weird invisible characters that needed to be spaces. A moment's work in BBEdit. I'd asked Jack for "permission", but then I realized that's not the WikiWay(TM), so I just went ahead. Change it yourself if you don't like it. :-) Now I should get some real work done... -- Russell Finn -- Russell S. Finn Principal Software Engineer, Software Architecture and Design OPNET Technologies, Inc. Phone: +1-240-497-3000 / Fax: +1-240-497-3001 Web: ==================================================== Register for OPNET's Online Technology Workshops ==================================================== From Chris.Barker at noaa.gov Thu Jan 15 19:07:44 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Jan 15 19:07:54 2004 Subject: [Pythonmac-SIG] Can you send Apple events to Classic apps from an OS-X app? In-Reply-To: References: <0EBFBC36-4799-11D8-88D6-000A958E9340@krushen.com> Message-ID: <40072B50.1070104@noaa.gov> Hi all, The subject asks says it all. The long version: We're about to start developing a new app, and I'm pushing heavily for Python+wxPython as the tool of choice. One question that has come up is whether we need to make an OS-9 version of the app, which would make it pretty hard to use wxPython. Frankly, I think developing for OS-9 is a waste of time, but we have a bunch of existing apps that are OS-9 based, and this new app will need to talk to them. They can all run in Classic mode fine. Thus the question..will we be able to make a wxPython MacPython OS-X app that can communicate with OS-9 apps running under classic? Most important is to be able to send Apple events to the OS-9 apps, but we might want to be able to receive them as well. thanks, -Chris PS: before someone suggest PyObjC, probably 90% of our users want it on Windows, so if we're going to support the Mac at all, it needs to be relatively easy. Unix would be nice too, but again, only if it's easy. -- 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 thomas.grischott at kantisargans.ch Thu Jan 15 19:13:36 2004 From: thomas.grischott at kantisargans.ch (Thomas Grischott) Date: Thu Jan 15 19:13:30 2004 Subject: [Pythonmac-SIG] my first (and hopefully easy) tkinter question about a self-closing window Message-ID: today i removed an older macpython 2.3-installation from my powerbook g4 (mac os x 10.3.2) as discribed in . then i installed the macpython for panther additions. then i installed TclTkAqua-8.4.5-Panther.dmg and once again the macpython for panther additions (because i read somewhere to first install tcltk andi didn't know if the order matters). now my little problem is that my first "hello world"-program > from Tkinter import * > > root=Tk() > > w = Label(root, text="Hallo Welt") > w.pack() > > root.mainloop() works fine except that the root-window opens and immediately closes again. what am i doing wrong? thanks for helping! thomas --------------------------------------- thomas grischott fliederweg 9 ch-7000 chur +41 81 284 0906 schottilie@gmx.ch --------------------------------------- From info at plugeplay.it Thu Jan 15 19:53:31 2004 From: info at plugeplay.it (info@plugeplay.it) Date: Thu Jan 15 19:53:54 2004 Subject: [Pythonmac-SIG] a trojan is on your computer! Message-ID: <15516268610954.16888@plugeplay.it> hi, I am from Denmark and you'll don't believe me, but a trojan horse in on your pc. I've scanned the network-ports on the internet. (I know, that's illegal) And I have found your pc. Your pc is open on the internet for everybody! Because the smss.exe trojan is running on your system. Check this, open the task manager and try to stop that! You'll see, you can't stop this trojan. When you use win98/me you can't see the trojan!! On my system was this trojan, too! And I've found a tool to kill that bad thing. I hope that I've helped you! Sorry for my bad english! greets From njriley at uiuc.edu Thu Jan 15 21:29:50 2004 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu Jan 15 21:29:58 2004 Subject: [Pythonmac-SIG] Can you send Apple events to Classic apps from an OS-X app? In-Reply-To: <40072B50.1070104@noaa.gov> References: <0EBFBC36-4799-11D8-88D6-000A958E9340@krushen.com> <40072B50.1070104@noaa.gov> Message-ID: <20040116022950.GD91556@uiuc.edu> On Thu, Jan 15, 2004 at 04:07:44PM -0800, Chris Barker wrote: > We're about to start developing a new app, and I'm pushing heavily for > Python+wxPython as the tool of choice. One question that has come up is > whether we need to make an OS-9 version of the app, which would make it > pretty hard to use wxPython. Frankly, I think developing for OS-9 is a > waste of time, but we have a bunch of existing apps that are OS-9 based, > and this new app will need to talk to them. They can all run in Classic > mode fine. Thus the question..will we be able to make a wxPython > MacPython OS-X app that can communicate with OS-9 apps running under > classic? Most important is to be able to send Apple events to the OS-9 > apps, but we might want to be able to receive them as well. I thought there was a wxWindows port for OS 9, dunno about wxPython though. wxWindows applications tend to look very ugly on Mac OS X by default, so you may end up spending time fixing appearance related issues. wxWindows looks quite native on Windows, though, where I've done all my wxWindows/wxPython development to date). It is definitely possible to send Apple Events back and forth between Classic and native Mac OS X apps - this has worked since the blue box of Mac OS X Server 1.0 back in 1999. -- =Nicholas Riley | From Jack.Jansen at cwi.nl Fri Jan 16 05:10:02 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 16 05:09:22 2004 Subject: [Pythonmac-SIG] Testing spam filter Message-ID: <266103BA-480C-11D8-8BB4-000A958D1666@cwi.nl> Folks, I've enabled holding of spam and potential spam to the SIG. At least, I think I've done that, maybe I've blocked everything, or done something silly like that:-) This message is part one of a test (to check that non-spam gets through). Part two of the test (where I will, for the first time in my life, send a spam message myself:-) you should hopefully not see. Otherwise remember that it is a test:-) -- 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 Jack.Jansen at cwi.nl Fri Jan 16 05:11:03 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 16 05:10:21 2004 Subject: [Pythonmac-SIG] Fwd: 28, 765, 685 0rders filled & counting... 7 qjjoawdo Message-ID: <4A61107F-480C-11D8-8BB4-000A958D1666@cwi.nl> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: image.tiff Type: image/tiff Size: 654 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040116/3191ce58/image.tiff -------------- next part -------------- Skipped content of type multipart/alternative From Jack.Jansen at cwi.nl Fri Jan 16 05:12:59 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 16 05:12:19 2004 Subject: [Pythonmac-SIG] Testing spam filter In-Reply-To: <266103BA-480C-11D8-8BB4-000A958D1666@cwi.nl> References: <266103BA-480C-11D8-8BB4-000A958D1666@cwi.nl> Message-ID: <8FF21E8F-480C-11D8-8BB4-000A958D1666@cwi.nl> Apparently the filter doesn't work very well:-) I'll investigate, -- 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 mwh at python.net Fri Jan 16 06:12:44 2004 From: mwh at python.net (Michael Hudson) Date: Fri Jan 16 06:12:50 2004 Subject: [Pythonmac-SIG] Testing spam filter In-Reply-To: <8FF21E8F-480C-11D8-8BB4-000A958D1666@cwi.nl> (Jack Jansen's message of "Fri, 16 Jan 2004 11:12:59 +0100") References: <266103BA-480C-11D8-8BB4-000A958D1666@cwi.nl> <8FF21E8F-480C-11D8-8BB4-000A958D1666@cwi.nl> Message-ID: <2mk73srvtf.fsf@starship.python.net> Jack Jansen writes: > Apparently the filter doesn't work very well:-) Maybe it just likes you too much :-) I've certainly had pieces of spam for this list end up in my unsure folder, so it will do some good. Cheers, mwh -- A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- http://slashdot.org/comments.pl?sid=01/02/09/1815221&cid=52 (although I've seen it before) From Jack.Jansen at cwi.nl Fri Jan 16 07:37:10 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 16 07:36:43 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] No more releases of MacPython-OS9? In-Reply-To: <20040115212700.GA7170@panix.com> References: <20040115212700.GA7170@panix.com> Message-ID: On 15-jan-04, at 22:27, Aahz wrote: > On Thu, Jan 15, 2004, Jack Jansen wrote: >> >> 2. Buy an Installer VISE license. If I read >> correctly this would cost $500 >> per year, probably for the next 2 years. This will only happen if >> someone else comes up with the money: I don't have it... > > Looks like 2.3 is the latest release currently available. There've > been > a lot of bugfixes since then. Do you have any download statistics for > the OS9 version? (I.e. rough idea of how many people care.) I have now:-) I'm a bit surprised at the results: MacPython-OS9 is a *lot* more popular than I had thought.... Over the last few months I see about 6000 MacPython downloads per month from my site (I didn't check versiontracker and such, that'll be a couple hundred more, I guess). For december the breakdown is 2000 downloads for 10.2, 2000 downloads for 10.3 and 1700 downloads for OS9. The other 300 are various things like source and such. 10.2 downloads are slowly declining, 10.3 downloads increasing. But the fact that 30% of the MacPython users are still downloading the OS9 binary really surprises me... So it seems MacPython-OS9 does have a place, still... -- 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 hinsen at cnrs-orleans.fr Fri Jan 16 08:38:32 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Fri Jan 16 08:41:21 2004 Subject: [Pythonmac-SIG] my first (and hopefully easy) tkinter question about a self-closing window In-Reply-To: References: Message-ID: <200401161438.32973.hinsen@cnrs-orleans.fr> On Friday 16 January 2004 01:13, Thomas Grischott wrote: > works fine except that the root-window opens and immediately closes > again. > > what am i doing wrong? What are you doing? How are you trying to execute that script? Konrad. From tree at basistech.com Fri Jan 16 08:53:42 2004 From: tree at basistech.com (Tom Emerson) Date: Fri Jan 16 08:53:53 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] No more releases of MacPython-OS9? In-Reply-To: References: <20040115212700.GA7170@panix.com> Message-ID: <16391.60646.924678.704941@magrathea.basistech.com> Jack Jansen writes: > But the fact that 30% of the MacPython users are still downloading the > OS9 binary really surprises me... Have you considered sending mail to MindVision and asking them to donate a license to the PSF? No doubt they are being inundated with such requests, but it may be worth trying. Are you using InstallerVise on OS X as well (I build from the tarball)? If so I'd be willing to help migrate to the Apple Installer. Then you could tell MindVision that you would like to continuing distributing an installer built with InstallerVise only on Mac OS 9 and earlier, and ask if they'll donate the appropriate license. Who knows... perhaps they'll toss in the full deal. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From guido at python.org Fri Jan 16 10:20:28 2004 From: guido at python.org (Guido van Rossum) Date: Fri Jan 16 10:20:38 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] No more releases of MacPython-OS9? In-Reply-To: Your message of "Fri, 16 Jan 2004 13:37:10 +0100." References: <20040115212700.GA7170@panix.com> Message-ID: <200401161520.i0GFKS218572@c-24-5-183-134.client.comcast.net> > So it seems MacPython-OS9 does have a place, still... How about: if you manage to get one of its users to sign up as a PSF sponsor, the PSF will buy you an installer. (A better deal for the sponsor might be to buy you an installer directly, of course...) --Guido van Rossum (home page: http://www.python.org/~guido/) From aahz at pythoncraft.com Fri Jan 16 10:34:55 2004 From: aahz at pythoncraft.com (Aahz) Date: Fri Jan 16 10:35:05 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] No more releases of MacPython-OS9? In-Reply-To: References: <20040115212700.GA7170@panix.com> Message-ID: <20040116153455.GA1401@panix.com> On Fri, Jan 16, 2004, Jack Jansen wrote: > > I'm a bit surprised at the results: MacPython-OS9 is a *lot* more > popular than I had thought.... Over the last few months I see about > 6000 MacPython downloads per month from my site (I didn't check > versiontracker and such, that'll be a couple hundred more, I guess). > For december the breakdown is 2000 downloads for 10.2, 2000 downloads > for 10.3 and 1700 downloads for OS9. The other 300 are various things > like source and such. 10.2 downloads are slowly declining, 10.3 > downloads increasing. Then I think you should apply to the PSF for funds for the license (or ask the PSF to buy the license directly and send the software to you). Getting the license for one year should allow you to finish the 2.3 line. (While I appreciate what Guido is saying about finding a sponsor, I don't think we should hold your license pending that -- spending $500 to support several thousand people in the Python community is exactly what the PSF should doing IMO. At this point, I'd suggest that further discussion move to the psf-members list.) One thing you *could* do right now: post a message to c.l.py.a with a Subject: saying "Save OS9!", requesting donations to the PSF. ;-) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ A: No. Q: Is top-posting okay? From gandreas at delver.com Fri Jan 16 11:08:01 2004 From: gandreas at delver.com (Glenn Andreas) Date: Fri Jan 16 11:09:43 2004 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.5 - Cocoa based Python IDE Message-ID: After a long absense (mail problems, busy projects, holidays, etc...) I've _finally_ gotten to clean up and can release the latest version of PyOXIDE - and this time, the source is finally available! Since the last vesion, the start of "projects" (groups of related scripts) has been added, as well as a remote debugger (note that there are still a number of issues with it, including problems with breakpoints not always working, and not being able to set variables). There have also been some serious bugs fixed in the editor, a few features there (showing line numbers works with wrapped lines, show invisibles works, etc...) PyOXIDE 0.5 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.5 is now available on my idisk (as PyOXIDE_0.5.dmg): http://homepage.mac.com/gandreas/ If you want to build from source, you'll need to get PyOXIDE_Src_0.5.dmg, and IDEKit_0.1.0d1.dmg (also built XCode 1.1 on 10.3 but should build with ProjectBuilder on 10.2). 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. At some point in the not-too-distant future, both with be converted to XCode native projects (and thus require 10.3 to build from source). Retaining compatibility for 10.2, however, is an important goal. -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From hengist.podd at virgin.net Fri Jan 16 11:32:19 2004 From: hengist.podd at virgin.net (has) Date: Fri Jan 16 11:32:12 2004 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.5 - Cocoa based Python IDE Message-ID: Glenn Andreas wrote: >PyOXIDE 0.5 is now available on my idisk (as PyOXIDE_0.5.dmg): > http://homepage.mac.com/gandreas/ Quick heads-up for Glenn: just tried to download this, but the d/l link appears to be broken. :( has -- http://freespace.virgin.net/hamish.sanderson/ From gandreas at visi.com Fri Jan 16 12:19:56 2004 From: gandreas at visi.com (Glenn Andreas) Date: Fri Jan 16 12:20:21 2004 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.5 - Cocoa based Python IDE In-Reply-To: References: Message-ID: At 4:32 PM +0000 1/16/04, has wrote: >Glenn Andreas wrote: > >>PyOXIDE 0.5 is now available on my idisk (as PyOXIDE_0.5.dmg): >> http://homepage.mac.com/gandreas/ > >Quick heads-up for Glenn: just tried to download this, but the d/l >link appears to be broken. :( Try "go to other user's idisk public folder" in the finder and type in "gandreas" - then you can just finder-copy it... -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From gandreas at delver.com Fri Jan 16 12:46:30 2004 From: gandreas at delver.com (Glenn Andreas) Date: Fri Jan 16 12:47:54 2004 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.5 - Cocoa based Python IDE Message-ID: At 4:32 PM +0000 1/16/04, has wrote: >Glenn Andreas wrote: > >>PyOXIDE 0.5 is now available on my idisk (as PyOXIDE_0.5.dmg): >> http://homepage.mac.com/gandreas/ > >Quick heads-up for Glenn: just tried to download this, but the d/l >link appears to be broken. :( Try "go to other user's idisk public folder" in the finder and type in "gandreas" - then you can just finder-copy it... -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From rb4havoc at torvalds.cs.mtsu.edu Fri Jan 16 12:54:21 2004 From: rb4havoc at torvalds.cs.mtsu.edu (Robert B. Brown, IV) Date: Fri Jan 16 12:54:33 2004 Subject: [Pythonmac-SIG] Trouble running python Message-ID: <0398778E-484D-11D8-B98A-000393D5F6AA@torvalds.cs.mtsu.edu> I'm having trouble running python in terminal. Everytime I type python, it outputs: dyld: python Undefined symbols: _tgetent _tgetflag _tgetnum _tgetstr _tgoto _tputs Trace/BPT trap Can anyone help me solve this problem? From schottilie at gmx.ch Fri Jan 16 13:05:16 2004 From: schottilie at gmx.ch (thomas grischott) Date: Fri Jan 16 13:12:33 2004 Subject: [Pythonmac-SIG] my first (and hopefully easy) tkinter question Message-ID: <89B363DA-484E-11D8-AA01-000393DB40C8@gmx.ch> i write the script in the pythonIDE and then click in "run all". not only does the root-window disappear, but also pythonIDE quits immediately. (but saving the script as applet and then double-clicking it from the finder works well.) --------------------------------------- thomas grischott fliederweg 9 ch-7000 chur +41 81 284 0906 schottilie@gmx.ch --------------------------------------- From rowen at cesmail.net Fri Jan 16 13:23:01 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jan 16 13:23:07 2004 Subject: [Pythonmac-SIG] Re: my first (and hopefully easy) tkinter question References: <89B363DA-484E-11D8-AA01-000393DB40C8@gmx.ch> Message-ID: In article <89B363DA-484E-11D8-AA01-000393DB40C8@gmx.ch>, thomas grischott wrote: > i write the script in the pythonIDE and then click in "run all". not > only does the root-window disappear, but also pythonIDE quits > immediately. > (but saving the script as applet and then double-clicking it from the > finder works well.) PythonIDE is cannot be used to run Tkinter scripts. I believe it is also incompatible with other GUIs such as wxPython or Qt. You can edit your scripts using any editor you like (including Python IDE), but you'll have to run them from the terminal. You can also run them from within IDLE, but only if you do not run "mainloop" (since IDLE already uses Tkinter and runs mainloop). (There is apparently also some way to convert them to a double-clickable application, but I don't yet know it; in fact I'm about to post this as a question). -- Russell From hinsen at cnrs-orleans.fr Fri Jan 16 13:30:50 2004 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Fri Jan 16 13:33:03 2004 Subject: [Pythonmac-SIG] Re: my first (and hopefully easy) tkinter question In-Reply-To: References: <89B363DA-484E-11D8-AA01-000393DB40C8@gmx.ch> Message-ID: <200401161930.50019.hinsen@cnrs-orleans.fr> On Friday 16 January 2004 19:23, Russell E. Owen wrote: > You can edit your scripts using any editor you like (including Python > IDE), but you'll have to run them from the terminal. You can also run And use "pythonw" instead of "python". Konrad. From rowen at cesmail.net Fri Jan 16 13:48:18 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jan 16 13:50:38 2004 Subject: [Pythonmac-SIG] Re: Trouble running python References: <0398778E-484D-11D8-B98A-000393D5F6AA@torvalds.cs.mtsu.edu> Message-ID: In article <0398778E-484D-11D8-B98A-000393D5F6AA@torvalds.cs.mtsu.edu>, "Robert B. Brown, IV" wrote: > I'm having trouble running python in terminal. Everytime I type > python, it outputs: > > dyld: python Undefined symbols: > _tgetent > _tgetflag > _tgetnum > _tgetstr > _tgoto > _tputs > Trace/BPT trap > > Can anyone help me solve this problem? Perhaps somebody can get this off the bat, but I'd like to ask you for more information: - What version of MacOS X? - What verson of python; the one included with MacOS X? - Did you ever try to install a different python, and if so, are you sure who know which one you are running when you type "python" at the terminal? When in doubt, supply the whole path, e.g. /usr/bin/python (Apple's python) /usr/local/bin/python (default path for built-from-source python) /sw/???/python (rough idea of the path for fink installation) If you want the built in python and your environment may be messed up, then another interesting thing to try is to create a new user account (with NO environment mods), log into that and try it from there. -- Russell From rowen at cesmail.net Fri Jan 16 13:52:48 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jan 16 14:00:39 2004 Subject: [Pythonmac-SIG] Question: why two PythonLaunchers? Message-ID: I have MacOS X 10.3.2 and have installed the Panther MacPython extras. In /Applications/MacPython I find two files named PythonLauncher. One is an alias to /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/Python Launcher.app. The other is an application. Any idea what to do? The things I've thought of are: - Leave things alone (I don't actually use the launcher anyway) - Delete one (obvious, but I have no idea which one to save) - Reinstall the MacPython extras from scratch -- Russell From rowen at cesmail.net Fri Jan 16 14:03:53 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jan 16 14:10:40 2004 Subject: [Pythonmac-SIG] How to build a double-clickable application Message-ID: Can anyone point me to documentation on how to build a double-clickable application from a Python package? Ease of use, installation and robustness are far more important than size, so if possible I would like the package to be 100% self-contained. My package uses Tkinter (and thus framework Tcl/Tk). I could go either way on relying on Panther's framework MacPython. I see advantages either way. Any help would be appreciated. I may have missed something, but didn't find anything in the installed MacPython docs or the on-line FAQ. -- Russell P.S. at risk of asking a really dumb question...is there some way to search the archives for this mailing list? I only can see how to view subject lists and such one month at a time. From schottilie at gmx.ch Fri Jan 16 14:20:41 2004 From: schottilie at gmx.ch (thomas grischott) Date: Fri Jan 16 14:22:38 2004 Subject: [Pythonmac-SIG] Re: my first (and hopefully easy) tkinter question Message-ID: <12B5E7C5-4859-11D8-A8C7-000393DB40C8@gmx.ch> thanks, russel and konrad! --------------------------------------- thomas grischott fliederweg 9 ch-7000 chur +41 81 284 0906 schottilie@gmx.ch --------------------------------------- From jordan at krushen.com Fri Jan 16 15:50:56 2004 From: jordan at krushen.com (Jordan Krushen) Date: Fri Jan 16 15:51:11 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] Re: No more releases of MacPython-OS9? In-Reply-To: References: <20040115212700.GA7170@panix.com> Message-ID: On 16-Jan-04, at 10:43 AM, Russell E. Owen wrote: > In any case, I'd be willing to contact VISE about a possible exception > to their licensing. Or perhaps we could work up a petition if you think > it might help. I don't think bullying a software company into giving you free software is the way to go, here. I'd ask all the potential petition-signers to donate $10 each to the PSF, instead. ;) J. From speno at isc.upenn.edu Fri Jan 16 15:57:30 2004 From: speno at isc.upenn.edu (John P Speno) Date: Fri Jan 16 15:59:11 2004 Subject: [Pythonmac-SIG] How to build a double-clickable application In-Reply-To: References: Message-ID: <20040116205730.GA2092@isc.upenn.edu> On Fri, Jan 16, 2004 at 11:03:53AM -0800, Russell E. Owen wrote: > Can anyone point me to documentation on how to build a double-clickable > application from a Python package? > This can be very easy to build using bundlebuilder.py. First create your app building script like so: ### makeapplication.py from bundlebuilder import buildapp buildapp( name='ApplicationName.app', # what to build mainprogram='main.py', # your app's main() argv_emulation=1, # drag&dropped filenames show up in sys.argv iconfile='myapp.icns', # file containing your app's icons standalone=1, # make this app self contained. includeModules=[], # list of additional Modules to force in includePackages=[], # list of additional Packages to force in ) ### end of makeapplication.py Then do this: % python makeapplication.py build Which should create a build/ApplicationName.app bundle, which make even work, but probably needs a little help. There will most likely be a few warnings, which can probably be safely ignored. There may be additional modules and libraries to include that buildapp couldn't determine. For example, you may need to copy Tcl.Framework and Tk.Framework into build/ApplicationName.app/Contents/Frameworks. I use those from the standalone Aqua Tcl/TK package (i.e. the Wish.app/Contents/Frameworks/*). Maybe this could get added to the wiki. I'll do that if folks think so. Hope that helps. -- Speno's Pythonic Avocado http://www.pycs.net/users/0000231 From barry at python.org Fri Jan 16 16:03:08 2004 From: barry at python.org (Barry Warsaw) Date: Fri Jan 16 16:06:18 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] Re: No more releases of MacPython-OS9? In-Reply-To: References: <20040115212700.GA7170@panix.com> Message-ID: <1074286988.3167.257.camel@anthem> On Fri, 2004-01-16 at 15:50, Jordan Krushen wrote: > I don't think bullying a software company into giving you free software > is the way to go, here. I'd ask all the potential petition-signers to > donate $10 each to the PSF, instead. ;) I hope the PSF will just pony up the dough. It's not that much and it clearly helps the Python community. I'd also hope that such goodwill would inspire lots of MacPython users to donate what they can to the PSF to show their appreciation! -Barry From Jack.Jansen at cwi.nl Fri Jan 16 16:27:32 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 16 16:27:43 2004 Subject: [Pythonmac-SIG] Trouble running python In-Reply-To: <0398778E-484D-11D8-B98A-000393D5F6AA@torvalds.cs.mtsu.edu> References: <0398778E-484D-11D8-B98A-000393D5F6AA@torvalds.cs.mtsu.edu> Message-ID: On 16-jan-04, at 18:54, Robert B. Brown, IV wrote: > I'm having trouble running python in terminal. Everytime I type > python, it outputs: > > dyld: python Undefined symbols: > _tgetent > _tgetflag > _tgetnum > _tgetstr > _tgoto > _tputs > Trace/BPT trap Strange... - Which version of MacOSX? - Which version of Python, and how did you install it (apple-installed, MacPython, fink, built and installed it yourself, etc)? - Was Python initially built (or installed) for a previous version of MacOSX? -- 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 Jack.Jansen at cwi.nl Fri Jan 16 16:28:47 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 16 16:28:52 2004 Subject: [Pythonmac-SIG] my first (and hopefully easy) tkinter question In-Reply-To: <89B363DA-484E-11D8-AA01-000393DB40C8@gmx.ch> References: <89B363DA-484E-11D8-AA01-000393DB40C8@gmx.ch> Message-ID: On 16-jan-04, at 19:05, thomas grischott wrote: > i write the script in the pythonIDE and then click in "run all". not > only does the root-window disappear, but also pythonIDE quits > immediately. > (but saving the script as applet and then double-clicking it from the > finder works well.) Tkinter programs cannot be run from the IDE. This is covered in the FAQ (question 3.6 right now, but this may change in the future as the FAQ is a wiki). -- 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 Jack.Jansen at cwi.nl Fri Jan 16 16:32:33 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 16 16:32:59 2004 Subject: [Pythonmac-SIG] Question: why two PythonLaunchers? In-Reply-To: References: Message-ID: <7F2F9122-486B-11D8-B171-000A27B19B96@cwi.nl> On 16-jan-04, at 19:52, Russell E. Owen wrote: > I have MacOS X 10.3.2 and have installed the Panther MacPython extras. > > In /Applications/MacPython I find two files named PythonLauncher. One > is > an alias to > /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python > Launcher.app. The other is an application. Any idea what to do? The > things I've thought of are: > - Leave things alone (I don't actually use the launcher anyway) > - Delete one (obvious, but I have no idea which one to save) > - Reinstall the MacPython extras from scratch Interesting... What has probably happened is that you installed the Panther MacPython Extra's over an existing Jaguar MacPython installation. As PythonLauncher is included with 10.3 I don't install a new copy with the extras installer, I just put in a symlink to the apple-installed PythonLauncher. I call this symlink "PythonLauncher". Should I call it "PythonLauncher.app" in stead? The good news it that it doesn't really matter which one you remove, but I would suggest the application, as it'll save you a couple of KB on disk. -- 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 at zope.com Fri Jan 16 16:46:44 2004 From: jeremy at zope.com (Jeremy Hylton) Date: Fri Jan 16 16:53:07 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] Re: No more releases of MacPython-OS9? In-Reply-To: <1074286988.3167.257.camel@anthem> References: <20040115212700.GA7170@panix.com> <1074286988.3167.257.camel@anthem> Message-ID: <1074289603.24983.38.camel@localhost.localdomain> On Fri, 2004-01-16 at 16:03, Barry Warsaw wrote: > On Fri, 2004-01-16 at 15:50, Jordan Krushen wrote: > > > I don't think bullying a software company into giving you free software > > is the way to go, here. I'd ask all the potential petition-signers to > > donate $10 each to the PSF, instead. ;) > > I hope the PSF will just pony up the dough. It's not that much and it > clearly helps the Python community. I'd also hope that such goodwill > would inspire lots of MacPython users to donate what they can to the PSF > to show their appreciation! Sounds like the right arrangement to me. Jeremy From rowen at cesmail.net Fri Jan 16 18:15:16 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jan 16 18:15:34 2004 Subject: [Pythonmac-SIG] Re: Question: why two PythonLaunchers? References: <7F2F9122-486B-11D8-B171-000A27B19B96@cwi.nl> Message-ID: In article <7F2F9122-486B-11D8-B171-000A27B19B96@cwi.nl>, Jack Jansen wrote: > On 16-jan-04, at 19:52, Russell E. Owen wrote: > > > I have MacOS X 10.3.2 and have installed the Panther MacPython extras. > > > > In /Applications/MacPython I find two files named PythonLauncher. One > > is > > an alias to > > /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ > > Python > > Launcher.app. The other is an application. Any idea what to do? The > > things I've thought of are: > > - Leave things alone (I don't actually use the launcher anyway) > > - Delete one (obvious, but I have no idea which one to save) > > - Reinstall the MacPython extras from scratch > > Interesting... > > What has probably happened is that you installed the Panther MacPython > Extra's over an existing Jaguar MacPython installation. > > As PythonLauncher is included with 10.3 I don't install a new copy with > the extras installer, I just put in a symlink to the apple-installed > PythonLauncher. I call this symlink "PythonLauncher". Should I call it > "PythonLauncher.app" in stead? > > The good news it that it doesn't really matter which one you remove, > but I would suggest the application, as it'll save you a couple of KB > on disk. Thank you! I thought my sequence was: - Upgrade to Panther with archive and install - Discard my old MacPython - Install the Panther MacPython but perhaps I forgot to ditch the Jaguar MacPython first. In any case, I threw out the app and am happy. -- Russell From paul.sargent at dsl.pipex.com Thu Jan 15 07:56:17 2004 From: paul.sargent at dsl.pipex.com (Paul Sargent) Date: Fri Jan 16 18:45:52 2004 Subject: [Pythonmac-SIG] Mac-Python Vs Apple Python history Message-ID: <35509C5A-475A-11D8-A361-000A95C5A776@dsl.pipex.com> Hi all, I'm trying to get my head around some bits and pieces to do with how python has developed on the Mac platform. This is to help dealing with old tutorials and other documents which describe how to do things on an older installation and haven't been updated for 10.3 (which is what I'm running) Now as I understand it (and from here on out, please correct me if I've got it wrong, that way I can check see if my understanding is correct) Apple didn't ship Python until 10.2. When they did this, they missed out some bits (headers, or dynamic libraries or something?) which meant that their installation was limited in what it could do (extra modules couldn't be installed?) Therefore, on 10.2, despite there being a python installation in /System/Library/Frameworks/Python.framework/Versions/2.2, Mac-Python for 10.2 consists of a full python installation which is installed into /Library/Frameworks/Python.framework/Versions/2.3. Net result was that two versions of python were installed on a 10.2 machine. Correct so far? How was the system told which version of python should be used? Now with 10.3, Apple included the missing bits(?). Therefore Mac-Python was able to just add things on without problems. This makes the Mac-Python for 10.3 install mainly consist of the package manager and basic modules. Net result, on a 10.3 machine only one version of python is installed and that's in /System/Library/Frameworks/...etc.... Therefore, as someone trying to learn on 10.3, whenever I see documents talking about files in /Library/Frameworks I should substitute /System/Library/Frameworks. Right? Of course, Mac-Python modules such as Numeric, or PyObjC are not system components so paths to those on both systems are /Library/Python. Is my understanding anywhere close to reality? Are we likely to need to go back to the 10.2 scheme in the future when newer versions of python appear? Thanks Paul -------------- 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/20040115/a1d8d9f8/PGP.bin From bob at redivi.com Fri Jan 16 19:07:13 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 16 19:05:00 2004 Subject: [Pythonmac-SIG] Mac-Python Vs Apple Python history In-Reply-To: <35509C5A-475A-11D8-A361-000A95C5A776@dsl.pipex.com> References: <35509C5A-475A-11D8-A361-000A95C5A776@dsl.pipex.com> Message-ID: <1A53BC38-4881-11D8-B110-000A95686CD8@redivi.com> On Jan 15, 2004, at 7:56 AM, Paul Sargent wrote: > I'm trying to get my head around some bits and pieces to do with how > python has developed on the Mac platform. This is to help dealing with > old tutorials and other documents which describe how to do things on > an older installation and haven't been updated for 10.3 (which is what > I'm running) > > Now as I understand it (and from here on out, please correct me if > I've got it wrong, that way I can check see if my understanding is > correct) Apple didn't ship Python until 10.2. When they did this, they > missed out some bits (headers, or dynamic libraries or something?) > which meant that their installation was limited in what it could do > (extra modules couldn't be installed?) Therefore, on 10.2, despite > there being a python installation in > /System/Library/Frameworks/Python.framework/Versions/2.2, Mac-Python > for 10.2 consists of a full python installation which is installed > into /Library/Frameworks/Python.framework/Versions/2.3. Python 2.2.0 was included with Mac OS X 10.2, it was not a framework build (standard --prefix=/usr build) and was not available as a dynamic library. It did not include all of the Mac extensions to get at Carbon stuff. Python 2.2.0 on the Mac had several bugs, especially one that meant that you can only use one "extension.so" per Python session, regardless of the path of "extension.so". It shipped with a distutils configuration that prevented it from building extension modules properly by default, and probably some other things that I've forgotten. > Net result was that two versions of python were installed on a 10.2 > machine. Not by default, of course, but any serious Python developer should have had two versions of Python on their machine. > Correct so far? How was the system told which version of python should > be used? "the system"? I'm not sure what you mean. The user would typically choose a default version of Python by changing their PATH. > Now with 10.3, Apple included the missing bits(?). Therefore > Mac-Python was able to just add things on without problems. This makes > the Mac-Python for 10.3 install mainly consist of the package manager > and basic modules. 10.3 includes a framework build of Python 2.3.0 with all the modules that should have been included. It is missing the GUI tools, so there is an add-ons package that installs these tools (Python IDE, PackageManager, etc.). > Net result, on a 10.3 machine only one version of python is installed > and that's in /System/Library/Frameworks/...etc.... Typically. > Therefore, as someone trying to learn on 10.3, whenever I see > documents talking about files in /Library/Frameworks I should > substitute /System/Library/Frameworks. Right? It depends on what the documents are talking about. If it says /Library/Frameworks/Tk.framework for example, which does not come with Mac OS X, then no substitution should be done. > Of course, Mac-Python modules such as Numeric, or PyObjC are not > system components so paths to those on both systems are > /Library/Python. well.. on a Mac OS X 10.3 version of Python 2.3, it is /Library/Python/2.3. On a properly built MacPython 2.3 it is /Library/Python/2.3/site-packages. > Is my understanding anywhere close to reality? Are we likely to need > to go back to the 10.2 scheme in the future when newer versions of > python appear? It's not really clear what you mean by 10.2 scheme.. but if you want to run a version of Python newer than the one currently on your computer, then yeah, you'll have to install one separately and change your PATH.. among other things. -bob From bob at redivi.com Fri Jan 16 19:27:18 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 16 19:24:58 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] Re: No more releases of MacPython-OS9? In-Reply-To: References: <20040115212700.GA7170@panix.com> Message-ID: On Jan 16, 2004, at 1:43 PM, Russell E. Owen wrote: > In article , > Jack Jansen wrote: > >> I'm a bit surprised at the results: MacPython-OS9 is a *lot* more >> popular than I had thought.... Over the last few months I see about >> 6000 MacPython downloads per month from my site (I didn't check >> versiontracker and such, that'll be a couple hundred more, I guess)... > > This may not only be people using MacOS 9. Having a carbon version of > MacPython running on MacOS X makes a certain amount of sense. The main > one being that drag-and-drop applets having an actual console window. > I've not had the nerve to ask my users to open the system console to > see > results. > > Also, I doubt any significant # of users are affected by this, > but....Carbon MacPython made it trivial to get to the file creation > date, and I ended up using it for processing some files. I'm sure it > can > be obtained in framework MacPython, but so far haven't figured out how. > > Due to these issues, I still use carbon MacPython for a fair # of my > file conversion scripts, although most of my work is done using > framework MacPython. You should speak up about things like this -- it's totally possible to develop a Framework Python BuildApplet that redirects stdin/stdout to a window. File a feature request and/or make some noise in pythonmac-sig. -bob From speno at isc.upenn.edu Fri Jan 16 20:51:48 2004 From: speno at isc.upenn.edu (John P Speno) Date: Fri Jan 16 20:51:52 2004 Subject: [Pythonmac-SIG] How to build a double-clickable application In-Reply-To: <20040116205730.GA2092@isc.upenn.edu> References: <20040116205730.GA2092@isc.upenn.edu> Message-ID: <20040117015148.GA2640@isc.upenn.edu> On Fri, Jan 16, 2004 at 03:57:30PM -0500, John P Speno wrote: > > [deletia: using buildapp] > > Maybe this could get added to the wiki. I'll do that if folks think so. I've added a slightly expanded version of my answer to the FAQ here: http://www.pythonmac.org/wiki/FAQ#head-904cbb109f2d4b78652f2f19fd6633adf65eb08a If it's bad advice, the next editor can fix it. :-) -- Speno's Pythonic Avocado http://www.pycs.net/users/0000231 From bob at redivi.com Fri Jan 16 21:14:12 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 16 21:11:48 2004 Subject: [Pythonmac-SIG] How to build a double-clickable application In-Reply-To: <20040117015148.GA2640@isc.upenn.edu> References: <20040116205730.GA2092@isc.upenn.edu> <20040117015148.GA2640@isc.upenn.edu> Message-ID: On Jan 16, 2004, at 8:51 PM, John P Speno wrote: > On Fri, Jan 16, 2004 at 03:57:30PM -0500, John P Speno wrote: >> >> [deletia: using buildapp] >> >> Maybe this could get added to the wiki. I'll do that if folks think >> so. > > I've added a slightly expanded version of my answer to the FAQ here: > > http://www.pythonmac.org/wiki/FAQ#head > -904cbb109f2d4b78652f2f19fd6633adf65eb08a > > If it's bad advice, the next editor can fix it. :-) Could you break this out into a separate WikiNode (i.e. BundleBuilder or BundleBuilderTutorial) and link to it from the FAQ? Also, please change the "copy frameworks to Contents/Frameworks" stuff. You can actually tell bundlebuilder to include frameworks or dylibs, either with the --lib=FILE command line option or by something like this: buildapp( .... libs=['/Library/Frameworks/Tk.framework', '/Library/Frameworks/Tcl.framework'] .... ) Additionally, it would be nice if --standalone, --semi-standalone, and --link were mentioned.. especially the fact that --standalone is not worth using for Apple's MacPython 2.3.0 (included with OS X 10.3) because the bundles are not backwards compatible with OS X 10.2. -bob From chris at fonnesbeck.org Fri Jan 16 22:33:39 2004 From: chris at fonnesbeck.org (Christopher Fonnesbeck) Date: Fri Jan 16 22:33:46 2004 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.5 - Cocoa based Python IDE Message-ID: When attempting to build PyOXIDE (and after building IDEKit) I get missing file warnings for: ExternalPython.prefPane TargetKind.prefPane that apparently were supposed to have been built by IDEKit. However, IDEKit built without error and had neither file in the build directory. Thanks for any advice, -- Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g ) Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia From mark.asbach at post.rwth-aachen.de Sat Jan 17 05:59:36 2004 From: mark.asbach at post.rwth-aachen.de (Mark Asbach) Date: Sat Jan 17 06:05:18 2004 Subject: [Pythonmac-SIG] Mac-Python Vs Apple Python history In-Reply-To: <1A53BC38-4881-11D8-B110-000A95686CD8@redivi.com> References: <35509C5A-475A-11D8-A361-000A95C5A776@dsl.pipex.com> <1A53BC38-4881-11D8-B110-000A95686CD8@redivi.com> Message-ID: <3D34247C-48DC-11D8-A5C5-000393449862@post.rwth-aachen.de> Hi Pythonians, > 10.3 includes a framework build of Python 2.3.0 with all the modules > that should have been included. It is missing the GUI tools, so there > is an add-ons package that installs these tools (Python IDE, > PackageManager, etc.). Hm. With 10.3 I'm missing a library - but it might be, that I don't understand the framework build thing. I'm wondering, if I need to build a unixy version of python myself, if I want to embed the interpreter into my own projects. At least, my autoconf scripts fail to detect an embeddable python install on Panter, while they were working well on Jaguar with a custom python install (no -frameworkinstall). "locate libpython" returns nothing, so I'd state, it's not a complete install not only regarding the tkinter issue. In addition to your original question, Paul, I'd be glad if we could collect a list of the default installation parts (headers, binaries, interpreter library and modules) for OS 9, Jaguar, Panther and the default UNIX install. This would help refining my python autoconf scripts as well ... Yours, Mark From bob at redivi.com Sat Jan 17 06:22:30 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 17 06:20:06 2004 Subject: [Pythonmac-SIG] ProcessSerialNumber? Message-ID: <706195C6-48DF-11D8-84EF-000A95686CD8@redivi.com> Are any of the PSN APIs available from Python? It doesn't seem like any of them are *directly* available, in the standard library anyways, but what about indirectly (PyObjC maybe)? I'm working on Apple Event stuff again, and it's useful for me to be able to iterate over running processes and such. -bob From bob at redivi.com Sat Jan 17 06:26:55 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 17 06:24:30 2004 Subject: [Pythonmac-SIG] Mac-Python Vs Apple Python history In-Reply-To: <3D34247C-48DC-11D8-A5C5-000393449862@post.rwth-aachen.de> References: <35509C5A-475A-11D8-A361-000A95C5A776@dsl.pipex.com> <1A53BC38-4881-11D8-B110-000A95686CD8@redivi.com> <3D34247C-48DC-11D8-A5C5-000393449862@post.rwth-aachen.de> Message-ID: <0E6FE352-48E0-11D8-84EF-000A95686CD8@redivi.com> On Jan 17, 2004, at 5:59 AM, Mark Asbach wrote: >> 10.3 includes a framework build of Python 2.3.0 with all the modules >> that should have been included. It is missing the GUI tools, so >> there is an add-ons package that installs these tools (Python IDE, >> PackageManager, etc.). > > Hm. With 10.3 I'm missing a library - but it might be, that I don't > understand the framework build thing. I'm wondering, if I need to > build a unixy version of python myself, if I want to embed the > interpreter into my own projects. At least, my autoconf scripts fail > to detect an embeddable python install on Panter, while they were > working well on Jaguar with a custom python install (no > -frameworkinstall). > > "locate libpython" returns nothing, so I'd state, it's not a complete > install not only regarding the tkinter issue. > > In addition to your original question, Paul, I'd be glad if we could > collect a list of the default installation parts (headers, binaries, > interpreter library and modules) for OS 9, Jaguar, Panther and the > default UNIX install. This would help refining my python autoconf > scripts as well ... Your autoconf scripts are not detecting it because it's not a (standard) dylib, it's a framework. The simplest way to detect a Python framework is to see if this passes: cc foo.c -framework Python where foo.c can be just "int main(int argc, char **argv) {}" Note the difference in linker command (-framework Python as opposed to -lpython). -bob From mwh at python.net Sat Jan 17 10:22:09 2004 From: mwh at python.net (Michael Hudson) Date: Sat Jan 17 10:22:12 2004 Subject: [Pythonmac-SIG] Trouble running python In-Reply-To: <0398778E-484D-11D8-B98A-000393D5F6AA@torvalds.cs.mtsu.edu> (Robert B. Brown, IV's message of "Fri, 16 Jan 2004 11:54:21 -0600") References: <0398778E-484D-11D8-B98A-000393D5F6AA@torvalds.cs.mtsu.edu> Message-ID: <2md69isiqm.fsf@starship.python.net> "Robert B. Brown, IV" writes: > I'm having trouble running python in terminal. Everytime I type > python, it outputs: > > dyld: python Undefined symbols: > _tgetent > _tgetflag > _tgetnum > _tgetstr > _tgoto > _tputs > Trace/BPT trap > > Can anyone help me solve this problem? I'm guessing you have a version of Python that was compiled on 10.1 with the curses module statically linked in (or something like that). Ignoring the matter of how you got such a beast, I suggest finding a less eccentric build... Cheers, mwh -- (Of course SML does have its weaknesses, but by comparison, a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god.) -- Thant Tessman From gandreas at delver.com Sat Jan 17 10:32:36 2004 From: gandreas at delver.com (Glenn Andreas) Date: Sat Jan 17 10:33:04 2004 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.5 - Cocoa based Python IDE In-Reply-To: References: Message-ID: At 10:33 PM -0500 1/16/04, Christopher Fonnesbeck wrote: >When attempting to build PyOXIDE (and after building IDEKit) I get >missing file warnings for: > >ExternalPython.prefPane >TargetKind.prefPane > >that apparently were supposed to have been built by IDEKit. However, >IDEKit built without error and had neither file in the build >directory. > >Thanks for any advice, Those should, unless XCode ate them, be subtargets of PyOXIDE, since those are preference panels specific to it (and not part of IDEKit) -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From kevin at macosx.com Sat Jan 17 13:17:45 2004 From: kevin at macosx.com (kevin) Date: Sat Jan 17 13:18:34 2004 Subject: [Pythonmac-SIG] setenv PATH & plist xml file settings In-Reply-To: Message-ID: <72DCB098-4919-11D8-A6B3-003065555ABC@macosx.com> Hi folks! Here is something that should go on the wiki faq! I am on jaguar using MacPython Python 2.3 (#2, Jul 30 2003, 11:45:28) [GCC 3.1 20020420 (prerelease)] and apple's half-python. i have made all my: ~/Library/init/tcsh files aliases.mine completions.mine environment.mine path rc.mine and added some directories to the standard path in my ~/Library/init/tcsh/path like so setenv PATH "/Users/kevin:/Users/kevin/bin:/Users/kevin/scripts:${PATH}" which means that i no longer have to type the full path in the shell, but i still have trouble importing. Wasn't there a plist file that had to be created? What was this for again? And wasn't there a template floating around out there with the xml to plug in so that you didn't even need to touch that plist editor ? cheers, kevin From paul.sargent at dsl.pipex.com Sat Jan 17 03:48:51 2004 From: paul.sargent at dsl.pipex.com (Paul Sargent) Date: Sat Jan 17 14:52:25 2004 Subject: [Pythonmac-SIG] Mac-Python Vs Apple Python history In-Reply-To: <1A53BC38-4881-11D8-B110-000A95686CD8@redivi.com> References: <35509C5A-475A-11D8-A361-000A95C5A776@dsl.pipex.com> <1A53BC38-4881-11D8-B110-000A95686CD8@redivi.com> Message-ID: On 17 Jan 2004, at 00:07, Bob Ippolito wrote: > > On Jan 15, 2004, at 7:56 AM, Paul Sargent wrote: > >> Correct so far? How was the system told which version of python >> should be used? > > "the system"? I'm not sure what you mean. The user would typically > choose a default version of Python by changing their PATH. What I meant, in a loose way, was "when a user typed 'python' at the prompt, how was it decided which version to use?". You've answered that. >> Is my understanding anywhere close to reality? Are we likely to need >> to go back to the 10.2 scheme in the future when newer versions of >> python appear? > > It's not really clear what you mean by 10.2 scheme.. but if you want > to run a version of Python newer than the one currently on your > computer, then yeah, you'll have to install one separately and change > your PATH.. among other things. OK, you pretty much got what I meant. Thanks Bob, That makes thing a bit clearer. -------------- 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/20040117/248d370e/PGP.bin From kranki2 at earthlink.net Sat Jan 17 16:58:02 2004 From: kranki2 at earthlink.net (Robert White) Date: Sat Jan 17 16:58:09 2004 Subject: [Pythonmac-SIG] Embedding Python in 10.3 Panther apps Message-ID: <38E2A37E-4938-11D8-893F-000A95A94FC8@earthlink.net> I just spent a bunch of time investigating this for the darwinports version of xchat2 on MacOSX 10.3 Panther. I posted the things that I found out in the wiki faq yesterday. If you have any further questions, I would be more than happy to try to answer them if I can. It took me a while to figure it out since I had never worked with darwinports, autoconf, automake, or libtools before. Once, I figured it out however, the answers were pretty easy. I have sent a request to Apple to update libtool to support the -u and -framework options, but doubt that they will. Anyway, I know a little more now than two months ago. Bob From speno at isc.upenn.edu Sat Jan 17 19:20:27 2004 From: speno at isc.upenn.edu (John P Speno) Date: Sat Jan 17 19:20:30 2004 Subject: [Pythonmac-SIG] setenv PATH & plist xml file settings In-Reply-To: <72DCB098-4919-11D8-A6B3-003065555ABC@macosx.com> References: <72DCB098-4919-11D8-A6B3-003065555ABC@macosx.com> Message-ID: <20040118002026.GA4264@isc.upenn.edu> On Sat, Jan 17, 2004 at 01:17:45PM -0500, kevin wrote: > importing. Wasn't there a plist file that had to be created? What was > this for again? Do you mean your ~/.MacOSX/environment.plist file? This file can set enviornment variables for you when you log into the MacOS X windowmanager. Any application you run which needs them will see those variables you set there. Setting variables in your dotfiles, e.g. .cshrc, only affects things you start from the Terminal. > And wasn't there a template floating around out there > with the xml to plug in so that you didn't even need to touch that > plist editor ? Dunno. I use /usr/bin/vim instead of the plist editor. Here's an example of the file: CVS_RSH ssh Take care. From beesley at wanadoo.fr Sun Jan 18 09:57:10 2004 From: beesley at wanadoo.fr (Kenneth Beesley) Date: Sun Jan 18 09:57:16 2004 Subject: [Pythonmac-SIG] Beginner: Best Python GUI for Arabic, etc. Message-ID: <978173C8-49C6-11D8-A2BA-000393454058@wanadoo.fr> Beginner questions: Best Python GUI for Arabic, general Unicode I/O I've just started experimenting with MacPython and am interested ultimately in creating GUI apps that allow the input and rendering of Arabic script (and Unicode in general). I have OS X 10.3.2 and so MacPython 2.3. I just installed the IDE and package manager from the MacPython page. At work I may also be using Python on Linux in the near future. If I understand correctly, the use of PyObjC will result in platform-specific applications for Mac, which is probably not ideal for me. I see that wxPython and Tkinter are also available on the Mac (any others?) Question: Are there other options for developing cross-platform GUIs with MacPython, perhaps pyQt or PyGTK+ v.2.X ??? I don't think that pyQt runs at all on Macs yet (some problem with libraries), but PyGTK+ v.2.X might be interesting. Any advice you could offer would be much appreciated. Ken Beesley ken.beesley@xrce.xerox.com beesley@wanadoo.fr From bob at redivi.com Sun Jan 18 10:18:44 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 18 10:16:17 2004 Subject: [Pythonmac-SIG] Beginner: Best Python GUI for Arabic, etc. In-Reply-To: <978173C8-49C6-11D8-A2BA-000393454058@wanadoo.fr> References: <978173C8-49C6-11D8-A2BA-000393454058@wanadoo.fr> Message-ID: <9AE8F0C4-49C9-11D8-84EF-000A95686CD8@redivi.com> On Jan 18, 2004, at 9:57 AM, Kenneth Beesley wrote: > Beginner questions: Best Python GUI for Arabic, general Unicode I/O > > I've just started experimenting with MacPython and am interested > ultimately > in creating GUI apps that allow the input and rendering of Arabic > script (and > Unicode in general). > > I have OS X 10.3.2 and so MacPython 2.3. I just installed the IDE and > package manager from the MacPython page. > > At work I may also be using Python on Linux in the near future. > > If I understand correctly, the use of PyObjC will result in > platform-specific > applications for Mac, which is probably not ideal for me. I see that > wxPython and Tkinter are also available on the Mac (any others?) > > Question: Are there other options for developing cross-platform GUIs > with > MacPython, perhaps pyQt or PyGTK+ v.2.X ??? I don't think that pyQt > runs at all on Macs yet (some problem with libraries), but PyGTK+ v.2.X > might be interesting. PyObjC will actually work, the others may or may not ;) The actual PyObjC code will be mostly portable to GNUStep (I think Ronald is pretty close to getting GNUStep AppKit support going), which means you will be portable to Linux but not (yet) Win32. You will need to build the interfaces twice, unless converted with some tool (dunno how well that works), or you use Renaissance on both platforms (can't use Apple's Interface Builder, which would be a shame). Tkinter is a bust from what I hear, YMMV, but I wouldn't even bother. wxPython probably has too many bugs and runs too slowly on the Mac at the moment.. but that is improving pretty fast so I might be wrong (which would be awesome) pyQt runs on all Macs operated by people who know what they're doing and that read the instructions properly.. but it's too buggy and slow to bother with right now. I don't know how fast it's improving, but it sticks you with the GPL. PyGTK+ v2.x is only going to run on X11, which is hard to setup (basically you need to install fink, because nobody really does X11 with any other Python right now). Supposedly fltk is portable to the mac, and has a Python binding, but I don't know anyone has even tried it. -- Personally, I would write the application in PyObjC, because it provides for VERY rapid development -- especially for your type of application (since unicode and arabic stuff probably Just Work). Just keep all the "guts" of your program in regular portable Python and port the GUI later if you have to. -bob From wtbridgman at radix.net Sun Jan 18 11:25:41 2004 From: wtbridgman at radix.net (W.T. Bridgman) Date: Sun Jan 18 11:25:15 2004 Subject: [Pythonmac-SIG] Python solution to monitor your internet connection? Message-ID: I know of a few commercial/shareware packages that can monitor your machine for apps that try to 'phone home' when you're online, but does anyone know of any open source (preferably Python) solutions for this? If not, can anyone point me to somewhere that I might find out what I need to write such an app that can monitor my internet connection? I'm specifically interested in monitoring OS X applications. Do the python internet modules have sufficient access to the internet API to do this? Thanks, Tom From bob at redivi.com Sun Jan 18 12:21:56 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 18 12:19:34 2004 Subject: [Pythonmac-SIG] Python solution to monitor your internet connection? In-Reply-To: References: Message-ID: On Jan 18, 2004, at 11:25 AM, W.T. Bridgman wrote: > I know of a few commercial/shareware packages that can monitor your > machine for apps that try to 'phone home' when you're online, but does > anyone know of any open source (preferably Python) solutions for this? > > If not, can anyone point me to somewhere that I might find out what I > need to write such an app that can monitor my internet connection? > I'm specifically interested in monitoring OS X applications. Do the > python internet modules have sufficient access to the internet API to > do this? You pretty much have to write the bulk of such a thing in C, since you have to intercept calls to C functions from other processes. There's a few ways to do it, I'm not sure which way Little Snitch uses, but it's definitely not even close to possible from Python (this year). -bob From kevino at tulane.edu Sun Jan 18 14:54:14 2004 From: kevino at tulane.edu (Kevin Ollivier) Date: Sun Jan 18 14:55:47 2004 Subject: [Pythonmac-SIG] Beginner: Best Python GUI for Arabic, etc. In-Reply-To: <9AE8F0C4-49C9-11D8-84EF-000A95686CD8@redivi.com> References: <978173C8-49C6-11D8-A2BA-000393454058@wanadoo.fr> <9AE8F0C4-49C9-11D8-84EF-000A95686CD8@redivi.com> Message-ID: <17C49D5A-49F0-11D8-B16D-000393CB1C86@tulane.edu> Hi, On Jan 18, 2004, at 7:18 AM, Bob Ippolito wrote: [snip] > wxPython probably has too many bugs and runs too slowly on the Mac at > the moment.. but that is improving pretty fast so I might be wrong > (which would be awesome) There should be a wxPython 2.5.1 release in the very near future (1-2 weeks max, maybe even sometime next week) and from my testing on Panther there have been major improvements. It still uses 5-9% CPU time on idle, but maxes out at about 20% as opposed to the 50% max Bob measured previously (yes, that's when using wxSTC). Load times range in the 4-6 second range, depending on what else you've got going on. Most of my testing was on an 800Mhz iMac, but it seemed even faster on my 1Ghz PowerBook. =) And we're not done yet. =) In the very near future, Classic support is getting separated so that we can maximize the Carbon port using Carbon Events, etc. This should bring down the idle CPU time down even further as we delegate more of the idle event handling to Apple's Window Manager. We're also going to implement HIView for Jaguar+. As for Unicode support, there's still a few issues to be worked out, the main one being that Mac APIs use short-wchar-t (2 bytes) while wxMac expects the 4-byte implementation. The result is that we get clipped text. This shouldn't be difficult to resolve, however (implement --fshort-wchar in configure and maybe set a define), and once I get out the latest release of wxMozilla I'll take a look into making this work. However, while wxPython 2.5 is probably more stable than its 2.4 counterpart, this is all very new so unless you're adventurous and have patience for dealing with the little quirks that arise, it might be best as Bob suggested to prototype the app in PyObjC, and then come back to wxPython when you need to really make your app cross-platform. Either that, or start writing your code on Linux or Windows using wxPython then move it over to Mac later. I would also agree that wxPython is a better choice than Tkinter and pyQT/pyGTK for Mac, but then again I'm a bit biased. ;-) Thanks, Kevin From kranki2 at earthlink.net Mon Jan 19 20:58:14 2004 From: kranki2 at earthlink.net (Robert White) Date: Mon Jan 19 20:58:27 2004 Subject: [Pythonmac-SIG] Compiling Applications under 10.3 Panther which embed Python Message-ID: <1BD0AEF4-4AEC-11D8-82E0-000A95A94FC8@earthlink.net> Apparently, I do not understand how to update the FAQ, because my changes did not seem to appear there. So, here is basically what I thought that I had entered. Since I did not understand anything about embedding Python and autoconf/automake/libtoolize/libtool, this took me about 2 months to figure out. So, I hope that it helps you. Also, this does NOT apply to any MacOSX release other than 10.3! Please enter it in the FAQ for me if you find it appropriate. Thanks. If you are working with MacOSX 10.3 and Python (which is builtin as a Framework), then you need to understand how to access the appropriate link parameters for the Python Framework. The following bash excerpt will return the appropriate C include directories: "PY_INC=`$pythonpath -c 'import distutils.sysconfig; print distutils.sysconfig.get_config_vars("INCLUDEPY")[0];'`" The following programming returns the link parameters into a variable for Bash: "PY_SHARE=`$pythonpath -c 'import distutils.sysconfig; print distutils.sysconfig.get_config_vars("LINKFORSHARED")[0];'"` Under 10.3 this returns: "-u __dummy -u _PyMac_Error -framework System -framework Python " If you are compiling your own application, this works great. However, if you decide to use the tools autoconf/automake/libtool, you are in for a surprise, because libtool not only does not recognize -u or -framework, it ignores them. So, you don't get any link errors (at least with the application, xchat2) and the link succeeds when it should have failed. For the link to be successful in the autoconf/automake/libtool system, you need to preface each option and its parameter with "-Xcompiler" such as: "-Xcompiler -u -Xcompiler __dummy -Xcompiler -u -Xcompiler _PyMac_Error -Xcompiler -framework -Xcompiler System -Xcompiler -framework -Xcompiler Python " From bob at redivi.com Mon Jan 19 21:41:40 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 19 21:39:14 2004 Subject: [Pythonmac-SIG] Compiling Applications under 10.3 Panther which embed Python In-Reply-To: <1BD0AEF4-4AEC-11D8-82E0-000A95A94FC8@earthlink.net> References: <1BD0AEF4-4AEC-11D8-82E0-000A95A94FC8@earthlink.net> Message-ID: <2D388FD5-4AF2-11D8-A4CC-000A95686CD8@redivi.com> On Jan 19, 2004, at 8:58 PM, Robert White wrote: > Apparently, I do not understand how to update the FAQ, because my > changes did not seem to appear there. So, here is basically what I > thought that I had entered. Since I did not understand anything about > embedding Python and autoconf/automake/libtoolize/libtool, this took > me about 2 months to figure out. So, I hope that it helps you. Also, > this does NOT apply to any MacOSX release other than 10.3! Please > enter it in the FAQ for me if you find it appropriate. Thanks. > > > If you are working with MacOSX 10.3 and Python (which is builtin as a > Framework), then you need to understand how to access the appropriate > link parameters for the Python Framework. > > The following bash excerpt will return the appropriate C include > directories: > > "PY_INC=`$pythonpath -c 'import distutils.sysconfig; print > distutils.sysconfig.get_config_vars("INCLUDEPY")[0];'`" > > > The following programming returns the link parameters into a variable > for Bash: > > "PY_SHARE=`$pythonpath -c 'import distutils.sysconfig; print > distutils.sysconfig.get_config_vars("LINKFORSHARED")[0];'"` > > Under 10.3 this returns: > > "-u __dummy -u _PyMac_Error -framework System -framework Python " > > If you are compiling your own application, this works great. However, > if you decide to use the tools autoconf/automake/libtool, you are in > for a surprise, because libtool not only does not recognize -u or > -framework, it ignores them. So, you don't get any link errors (at > least with the application, xchat2) and the link succeeds when it > should have failed. > > For the link to be successful in the autoconf/automake/libtool system, > you need to preface each option and its parameter with "-Xcompiler" > such as: > > "-Xcompiler -u -Xcompiler __dummy -Xcompiler -u -Xcompiler > _PyMac_Error -Xcompiler -framework -Xcompiler System -Xcompiler > -framework -Xcompiler Python " I think these should be -Xlinker actually, have you tried that? These are linker flags. What you've written here isn't really specific to OS X 10.3 in any way, this procedure should work with on any platform with any Python. That's why Python keeps config/Makefile around, so software builds can be automated. Can you try entering it into the FAQ again? Maybe someone clobbered it by accident; there were 5 edits to the FAQ on Friday. -bob From gshao1 at san.rr.com Mon Jan 19 23:12:07 2004 From: gshao1 at san.rr.com (Gary Shao) Date: Mon Jan 19 23:12:20 2004 Subject: [Pythonmac-SIG] Re: Best Python GUI for Arabic, etc. In-Reply-To: References: Message-ID: <400CAA97.7000500@san.rr.com> Hi, Thanks Kevin for the update on wxPython. I've only recently tried running an existing wxPython script that works fine on Linux and Windows machines on a Mac OS X box. I quite quickly observed some of the visual irregularities mentioned when people talk about the status of wxPython on the Mac. The most readily apparent problems were rounded buttons that were surrounded by white rectangles and tab headers that had poor spacing when compared to what appeared on Linux and Windows. Another problem that showed up on the Mac version was the GetValue method of a wxTextCtrl object not returning the correct value unless the user manually changed the value (for instance simply backspacing over one letter of the default value shown and typing the same letter back in). When I looked through the wxPython site, I could find no mention of known problems with the Mac implementation. This meant there was no way to know whether any problems I found were already known and whether they were already fixed for later releases, planned for being worked on, or would continue in later versions until someone addressed them. I'm interested in writing Python applications that are truly cross-platform, and would appreciate having some pointers on where the status of specific Mac issues can be found. Thanks again. --Gary > There should be a wxPython 2.5.1 release in the very near future (1-2 > weeks max, maybe even sometime next week) and from my testing on > Panther there have been major improvements. It still uses 5-9% CPU > time on idle, but maxes out at about 20% as opposed to the 50% max Bob > measured previously (yes, that's when using wxSTC). Load times range > in the 4-6 second range, depending on what else you've got going on. > Most of my testing was on an 800Mhz iMac, but it seemed even faster on > my 1Ghz PowerBook. =) > > And we're not done yet. =) In the very near future, Classic support is > getting separated so that we can maximize the Carbon port using Carbon > Events, etc. This should bring down the idle CPU time down even > further as we delegate more of the idle event handling to Apple's > Window Manager. We're also going to implement HIView for Jaguar+. > > As for Unicode support, there's still a few issues to be worked out, > the main one being that Mac APIs use short-wchar-t (2 bytes) while > wxMac expects the 4-byte implementation. The result is that we get > clipped text. This shouldn't be difficult to resolve, however > (implement --fshort-wchar in configure and maybe set a define), and > once I get out the latest release of wxMozilla I'll take a look into > making this work. > > However, while wxPython 2.5 is probably more stable than its 2.4 > counterpart, this is all very new so unless you're adventurous and > have patience for dealing with the little quirks that arise, it might > be best as Bob suggested to prototype the app in PyObjC, and then come > back to wxPython when you need to really make your app cross-platform. > Either that, or start writing your code on Linux or Windows using > wxPython then move it over to Mac later. I would also agree that > wxPython is a better choice than Tkinter and pyQT/pyGTK for Mac, but > then again I'm a bit biased. ;-) > > Thanks, > > Kevin > > > From kevino at tulane.edu Tue Jan 20 02:33:53 2004 From: kevino at tulane.edu (Kevin Ollivier) Date: Tue Jan 20 02:35:22 2004 Subject: [Pythonmac-SIG] Re: Best Python GUI for Arabic, etc. In-Reply-To: <400CAA97.7000500@san.rr.com> References: <400CAA97.7000500@san.rr.com> Message-ID: Hi Gary, There is a page for OS X/Mac issues but it is a bit hidden. To get there, you go to the wxPython Wiki, select "Other Docs", then "wxPythonOSX issues". Here's the link: http://wiki.wxpython.org/index.cgi/wxPythonOSX_20Issues The buttons issue has been resolved. As for the other issues, I'll try to take a look at them and see what can be done, but if you could go ahead and post a note to the wiki page it would be very helpful. One thing to note too, is that some of the issues (i.e. header tab spacing) may be a result of wxMac trying to adhere to Apple's Human Interface Guidelines. It's important to Mac users that applications follow those guidelines, so wxMac does try to follow them, even if it may cause some visual differences between the Mac version and those for Windows/Linux. (If the spacing is off and it is not following the guidelines, however, then that most certainly needs to be fixed.) Thanks, Kevin On Jan 19, 2004, at 8:12 PM, Gary Shao wrote: > Hi, > > Thanks Kevin for the update on wxPython. I've only recently tried > running an existing wxPython > script that works fine on Linux and Windows machines on a Mac OS X > box. I quite quickly > observed some of the visual irregularities mentioned when people talk > about the status of > wxPython on the Mac. The most readily apparent problems were rounded > buttons that were > surrounded by white rectangles and tab headers that had poor spacing > when compared to > what appeared on Linux and Windows. Another problem that showed up on > the Mac version > was the GetValue method of a wxTextCtrl object not returning the > correct value unless > the user manually changed the value (for instance simply backspacing > over one letter of the > default value shown and typing the same letter back in). > > When I looked through the wxPython site, I could find no mention of > known problems with the > Mac implementation. This meant there was no way to know whether any > problems I found > were already known and whether they were already fixed for later > releases, planned for being > worked on, or would continue in later versions until someone addressed > them. I'm interested in > writing Python applications that are truly cross-platform, and would > appreciate having some > pointers on where the status of specific Mac issues can be found. > Thanks again. > > --Gary > >> There should be a wxPython 2.5.1 release in the very near future (1-2 >> weeks max, maybe even sometime next week) and from my testing on >> Panther there have been major improvements. It still uses 5-9% CPU >> time on idle, but maxes out at about 20% as opposed to the 50% max >> Bob measured previously (yes, that's when using wxSTC). Load times >> range in the 4-6 second range, depending on what else you've got >> going on. Most of my testing was on an 800Mhz iMac, but it seemed >> even faster on my 1Ghz PowerBook. =) >> >> And we're not done yet. =) In the very near future, Classic support >> is getting separated so that we can maximize the Carbon port using >> Carbon Events, etc. This should bring down the idle CPU time down >> even further as we delegate more of the idle event handling to >> Apple's Window Manager. We're also going to implement HIView for >> Jaguar+. >> >> As for Unicode support, there's still a few issues to be worked out, >> the main one being that Mac APIs use short-wchar-t (2 bytes) while >> wxMac expects the 4-byte implementation. The result is that we get >> clipped text. This shouldn't be difficult to resolve, however >> (implement --fshort-wchar in configure and maybe set a define), and >> once I get out the latest release of wxMozilla I'll take a look into >> making this work. >> >> However, while wxPython 2.5 is probably more stable than its 2.4 >> counterpart, this is all very new so unless you're adventurous and >> have patience for dealing with the little quirks that arise, it might >> be best as Bob suggested to prototype the app in PyObjC, and then >> come back to wxPython when you need to really make your app >> cross-platform. Either that, or start writing your code on Linux or >> Windows using wxPython then move it over to Mac later. I would also >> agree that wxPython is a better choice than Tkinter and pyQT/pyGTK >> for Mac, but then again I'm a bit biased. ;-) >> >> Thanks, >> >> Kevin >> >> >> > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Jack.Jansen at cwi.nl Tue Jan 20 07:34:22 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jan 20 07:33:20 2004 Subject: [Pythonmac-SIG] Python solution to monitor your internet connection? In-Reply-To: References: Message-ID: On 18-jan-04, at 18:21, Bob Ippolito wrote: > > On Jan 18, 2004, at 11:25 AM, W.T. Bridgman wrote: > >> I know of a few commercial/shareware packages that can monitor your >> machine for apps that try to 'phone home' when you're online, but >> does anyone know of any open source (preferably Python) solutions for >> this? >> >> If not, can anyone point me to somewhere that I might find out what I >> need to write such an app that can monitor my internet connection? >> I'm specifically interested in monitoring OS X applications. Do the >> python internet modules have sufficient access to the internet API to >> do this? > > You pretty much have to write the bulk of such a thing in C, since you > have to intercept calls to C functions from other processes. I don't think you have to be *that* gross. The ipfirewall device (see man 4 firewall) can probably be used to make all packets be given to your code for inspection. But still I don't think I'd want to do this in Python because of the overhead. -- 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 Tue Jan 20 08:07:51 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 20 08:05:21 2004 Subject: [Pythonmac-SIG] Python solution to monitor your internet connection? In-Reply-To: References: Message-ID: On Jan 20, 2004, at 7:34 AM, Jack Jansen wrote: > > On 18-jan-04, at 18:21, Bob Ippolito wrote: > >> >> On Jan 18, 2004, at 11:25 AM, W.T. Bridgman wrote: >> >>> I know of a few commercial/shareware packages that can monitor your >>> machine for apps that try to 'phone home' when you're online, but >>> does anyone know of any open source (preferably Python) solutions >>> for this? >>> >>> If not, can anyone point me to somewhere that I might find out what >>> I need to write such an app that can monitor my internet connection? >>> I'm specifically interested in monitoring OS X applications. Do >>> the python internet modules have sufficient access to the internet >>> API to do this? >> >> You pretty much have to write the bulk of such a thing in C, since >> you have to intercept calls to C functions from other processes. > > I don't think you have to be *that* gross. The ipfirewall device (see > man 4 firewall) can probably be used to make all packets be given to > your code for inspection. But still I don't think I'd want to do this > in Python because of the overhead. It's extremely important to know the pid the packet came from in this sort of application, so that interface won't cut it. Little Snitch uses a kext. (kextstat output -- little snitch isn't even active at the moment, I guess it stays resident) 86 0 0x2fa51000 0xe000 0xd000 at.obdev.KUC (1.1.1) <10> (the startup item is probably a replicant of what is in the pref pane..) /Library/StartupItems/LittleSnitch/Resources/ODKUControl.kext /Library/PreferencePanes/Little Snitch.prefPane/Contents/Resources/ODKUControl.kext -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/20040120/390dc38b/smime.bin From mwh at python.net Tue Jan 20 09:21:00 2004 From: mwh at python.net (Michael Hudson) Date: Tue Jan 20 09:21:05 2004 Subject: [Pythonmac-SIG] uninstalled debugging framework build? Message-ID: <2mbroyog4z.fsf@starship.python.net> Is there any easy way to get a Python.app containing a debugging build of Python that isn't installed in such a way as to obscure the optimized build I have installed? I had a quick peek, but it didn't look easy. Cheers, mwh -- This song is for anyone ... fuck it. Shut up and listen. -- Eminem, "The Way I Am" From Jack.Jansen at cwi.nl Tue Jan 20 10:06:29 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jan 20 10:05:27 2004 Subject: [Pythonmac-SIG] uninstalled debugging framework build? In-Reply-To: <2mbroyog4z.fsf@starship.python.net> References: <2mbroyog4z.fsf@starship.python.net> Message-ID: <39C5ABDE-4B5A-11D8-9B7E-000A958D1666@cwi.nl> On 20-jan-04, at 15:21, Michael Hudson wrote: > Is there any easy way to get a Python.app containing a debugging build > of Python that isn't installed in such a way as to obscure the > optimized build I have installed? I had a quick peek, but it didn't > look easy. After configuring, try editing the Makefile and changing PYTHONFRAMEWORK and PYTHONFRAMEWORKDIR to something like "DbgPython" and "DbgPython.framework". Then edit Mac/OSX/Makefile too so it doesn't overwrite /usr/local/bin/python* and /Applications/MacPython-2.3/*. I would be interested in hearing whether this actually works:-) -- 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 Tue Jan 20 10:20:31 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 20 10:18:03 2004 Subject: [Pythonmac-SIG] uninstalled debugging framework build? In-Reply-To: <39C5ABDE-4B5A-11D8-9B7E-000A958D1666@cwi.nl> References: <2mbroyog4z.fsf@starship.python.net> <39C5ABDE-4B5A-11D8-9B7E-000A958D1666@cwi.nl> Message-ID: <2FC57391-4B5C-11D8-AC58-000A95686CD8@redivi.com> On Jan 20, 2004, at 10:06 AM, Jack Jansen wrote: > > On 20-jan-04, at 15:21, Michael Hudson wrote: > >> Is there any easy way to get a Python.app containing a debugging build >> of Python that isn't installed in such a way as to obscure the >> optimized build I have installed? I had a quick peek, but it didn't >> look easy. > > After configuring, try editing the Makefile and changing > PYTHONFRAMEWORK and PYTHONFRAMEWORKDIR to something like "DbgPython" > and "DbgPython.framework". Then edit Mac/OSX/Makefile too so it > doesn't overwrite /usr/local/bin/python* and > /Applications/MacPython-2.3/*. > > I would be interested in hearing whether this actually works:-) Me too, I want to make a stackless distribution of this sort -- when it's ready :) -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/20040120/c32130fa/smime.bin From mwh at python.net Tue Jan 20 10:22:40 2004 From: mwh at python.net (Michael Hudson) Date: Tue Jan 20 10:22:43 2004 Subject: [Pythonmac-SIG] uninstalled debugging framework build? In-Reply-To: <39C5ABDE-4B5A-11D8-9B7E-000A958D1666@cwi.nl> (Jack Jansen's message of "Tue, 20 Jan 2004 16:06:29 +0100") References: <2mbroyog4z.fsf@starship.python.net> <39C5ABDE-4B5A-11D8-9B7E-000A958D1666@cwi.nl> Message-ID: <2m3caaoda7.fsf@starship.python.net> Jack Jansen writes: > On 20-jan-04, at 15:21, Michael Hudson wrote: > >> Is there any easy way to get a Python.app containing a debugging build >> of Python that isn't installed in such a way as to obscure the >> optimized build I have installed? I had a quick peek, but it didn't >> look easy. > > After configuring, try editing the Makefile and changing > PYTHONFRAMEWORK and PYTHONFRAMEWORKDIR to something like "DbgPython" > and "DbgPython.framework". Then edit Mac/OSX/Makefile too so it > doesn't overwrite /usr/local/bin/python* and > /Applications/MacPython-2.3/*. An instant problem: I always build in a subdirectory of the source directory, but Mac/OSX/Makefile is always accessed from the source directory itself. > I would be interested in hearing whether this actually works:-) Gee, nice to know I'm on solid ground :-) Cheers, mwh -- /* I'd just like to take this moment to point out that C has all the expressive power of two dixie cups and a string. */ -- Jamie Zawinski from the xkeycaps source From robin at reportlab.com Tue Jan 20 11:29:34 2004 From: robin at reportlab.com (Robin Becker) Date: Tue Jan 20 11:31:20 2004 Subject: [Pythonmac-SIG] tools help Message-ID: The client has been supplied with a completely self contained dylib containing a frozen python + application framework. We tested locally with OS 10.2 that it can do the right thing as a shared object. The client reports complete success on some 10.3 machines and mysterious crashes on others. The suggestion is that on some machines that a shared library is missing or different. Is there an easy way to detect which dependencies are still open in my dylib? I tried using nm -fu to get a feel for the outstanding things and see libz/libpthread as possibles. There is an ldd for linux, but is there an equivalent for darwin/panther? -- Robin Becker From njriley at uiuc.edu Tue Jan 20 11:37:57 2004 From: njriley at uiuc.edu (Nicholas Riley) Date: Tue Jan 20 11:38:02 2004 Subject: [Pythonmac-SIG] tools help In-Reply-To: References: Message-ID: <20040120163757.GA40236@uiuc.edu> On Tue, Jan 20, 2004 at 04:29:34PM +0000, Robin Becker wrote: > There is an ldd for linux, but is there an equivalent for > darwin/panther? otool -L -- =Nicholas Riley | From kranki2 at earthlink.net Tue Jan 20 13:31:54 2004 From: kranki2 at earthlink.net (Robert White) Date: Tue Jan 20 13:32:01 2004 Subject: [Pythonmac-SIG] Fwd: Compiling Applications under 10.3 Panther which embed Python Message-ID: Begin forwarded message: > From: Robert White > Date: January 19, 2004 8:58:14 PM EST > To: pythonmac-sig@python.org > Subject: Compiling Applications under 10.3 Panther which embed Python > > Apparently, I do not understand how to update the FAQ, because my > changes did not seem to appear there. So, here is basically what I > thought that I had entered. Since I did not understand anything about > embedding Python and autoconf/automake/libtoolize/libtool, this took > me about 2 months to figure out. So, I hope that it helps you. Also, > this does NOT apply to any MacOSX release other than 10.3! Please > enter it in the FAQ for me if you find it appropriate. Thanks. > > > If you are working with MacOSX 10.3 and Python (which is builtin as a > Framework), then you need to understand how to access the appropriate > link parameters for the Python Framework. > > The following bash excerpt will return the appropriate C include > directories: > > "PY_INC=`$pythonpath -c 'import distutils.sysconfig; print > distutils.sysconfig.get_config_vars("INCLUDEPY")[0];'`" > > > The following programming returns the link parameters into a variable > for Bash: > > "PY_SHARE=`$pythonpath -c 'import distutils.sysconfig; print > distutils.sysconfig.get_config_vars("LINKFORSHARED")[0];'"` > > Under 10.3 this returns: > > "-u __dummy -u _PyMac_Error -framework System -framework Python " > > If you are compiling your own application, this works great. However, > if you decide to use the tools autoconf/automake/libtool, you are in > for a surprise, because libtool not only does not recognize -u or > -framework, it ignores them. So, you don't get any link errors (at > least with the application, xchat2) and the link succeeds when it > should have failed. > > For the link to be successful in the autoconf/automake/libtool system, > you need to preface each option and its parameter with "-Xcompiler" > such as: > > "-Xcompiler -u -Xcompiler __dummy -Xcompiler -u -Xcompiler > _PyMac_Error -Xcompiler -framework -Xcompiler System -Xcompiler > -framework -Xcompiler Python " > You might want to use the -Xlinker flag if the -Xcompiler flag does not work for your application. For xchat2, -Xlinker did not work, but -Xcompiler did. I try to add this again. Why -Xlinker did not work above was not something that I could figure out. The libtool mode was to link which I would have thought -Xlinker should have been used, but it did not work and I tried it first. I tried to cut and paste the above into the faq again. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2743 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040120/26fb1b89/attachment.bin From Philip.Kalmus at nera.com Tue Jan 20 10:58:59 2004 From: Philip.Kalmus at nera.com (Kalmus, Philip) Date: Tue Jan 20 16:22:48 2004 Subject: [Pythonmac-SIG] xgrid and numeric/numarray Message-ID: <3CE9059DA7571D479A129D83ABB8FFB8E7777C@exchangeldn.nera.com> Hi, does anyone know if it is possible / how to run Numeric or Numarray programs on Apple's new Xgrid? Philip _____________________________________________________________ This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation. _____________________________________________________________ From Jack.Jansen at cwi.nl Tue Jan 20 16:26:44 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jan 20 16:26:59 2004 Subject: [Pythonmac-SIG] uninstalled debugging framework build? In-Reply-To: <2m3caaoda7.fsf@starship.python.net> References: <2mbroyog4z.fsf@starship.python.net> <39C5ABDE-4B5A-11D8-9B7E-000A958D1666@cwi.nl> <2m3caaoda7.fsf@starship.python.net> Message-ID: <589AF6A4-4B8F-11D8-99A8-000A27B19B96@cwi.nl> On 20-jan-04, at 16:22, Michael Hudson wrote: >> After configuring, try editing the Makefile and changing >> PYTHONFRAMEWORK and PYTHONFRAMEWORKDIR to something like "DbgPython" >> and "DbgPython.framework". Then edit Mac/OSX/Makefile too so it >> doesn't overwrite /usr/local/bin/python* and >> /Applications/MacPython-2.3/*. > > An instant problem: I always build in a subdirectory of the source > directory, but Mac/OSX/Makefile is always accessed from the source > directory itself. You can also edit the builddir Makefile only, and pass some extra arguments to the recursive "make -f $(srcdir)/Mac/OSX/Makefile" calls in the installframeworkapps and installframeworkunixtools calls. What exactly you'd need to pass to the recursive make you'd have to figure out yourself, though (i.e. I'm too lazy to think it up for you:-) -- 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 Tue Jan 20 16:38:25 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 20 16:35:54 2004 Subject: [Pythonmac-SIG] xgrid and numeric/numarray In-Reply-To: <3CE9059DA7571D479A129D83ABB8FFB8E7777C@exchangeldn.nera.com> References: <3CE9059DA7571D479A129D83ABB8FFB8E7777C@exchangeldn.nera.com> Message-ID: On Jan 20, 2004, at 10:58 AM, Kalmus, Philip wrote: > Hi, does anyone know if it is possible / how to run Numeric or > Numarray programs on Apple's new Xgrid? > Philip Sure, I think that Xgrid will run whatever you want it to run.. My understanding of it is that it can start up command line apps on remote machines and collect their output. -bob From Philip.Kalmus at nera.com Tue Jan 20 17:14:26 2004 From: Philip.Kalmus at nera.com (Kalmus, Philip) Date: Tue Jan 20 17:14:36 2004 Subject: [Pythonmac-SIG] xgrid and numeric/numarray Message-ID: <3CE9059DA7571D479A129D83ABB8FFB8E77782@exchangeldn.nera.com> thanks Bob, that makes a lot of sense Philip -----Original Message----- From: Bob Ippolito [mailto:bob@redivi.com] Sent: Tue 1/20/2004 9:38 PM To: Kalmus, Philip Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] xgrid and numeric/numarray On Jan 20, 2004, at 10:58 AM, Kalmus, Philip wrote: > Hi, does anyone know if it is possible / how to run Numeric or > Numarray programs on Apple's new Xgrid? > Philip Sure, I think that Xgrid will run whatever you want it to run.. My understanding of it is that it can start up command line apps on remote machines and collect their output. -bob _____________________________________________________________ This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation. _____________________________________________________________ From mwh at python.net Wed Jan 21 05:32:07 2004 From: mwh at python.net (Michael Hudson) Date: Wed Jan 21 05:32:10 2004 Subject: [Pythonmac-SIG] uninstalled debugging framework build? In-Reply-To: <589AF6A4-4B8F-11D8-99A8-000A27B19B96@cwi.nl> (Jack Jansen's message of "Tue, 20 Jan 2004 22:26:44 +0100") References: <2mbroyog4z.fsf@starship.python.net> <39C5ABDE-4B5A-11D8-9B7E-000A958D1666@cwi.nl> <2m3caaoda7.fsf@starship.python.net> <589AF6A4-4B8F-11D8-99A8-000A27B19B96@cwi.nl> Message-ID: <2msmi9mw2g.fsf@starship.python.net> Jack Jansen writes: > On 20-jan-04, at 16:22, Michael Hudson wrote: >>> After configuring, try editing the Makefile and changing >>> PYTHONFRAMEWORK and PYTHONFRAMEWORKDIR to something like "DbgPython" >>> and "DbgPython.framework". Then edit Mac/OSX/Makefile too so it >>> doesn't overwrite /usr/local/bin/python* and >>> /Applications/MacPython-2.3/*. >> >> An instant problem: I always build in a subdirectory of the source >> directory, but Mac/OSX/Makefile is always accessed from the source >> directory itself. > > You can also edit the builddir Makefile only, and pass some extra > arguments to the recursive "make -f $(srcdir)/Mac/OSX/Makefile" calls > in the installframeworkapps and installframeworkunixtools calls. What > exactly you'd need to pass to the recursive make you'd have to figure > out yourself, though (i.e. I'm too lazy to think it up for you:-) It would seem that just not doing the frameworkinstallunixtools and frameworkinstallapps would do, i.e. just running "make frameworkinstallframework" from the build dir (I hacked the generated makefile to remove the frameworkinstallunixtools dependency from the frameworkinstall target and forgot about frameworkinstallapps, so I've stomped on my /Applications/MacPython-2.3 folder... oh well). Haven't actually gotten to the problem I want to debug yet :-/ need to build PyObjC and pygame against the debug Python first... Cheers, mwh -- I believe C++ instills fear in programmers, fear that the interaction of some details causes unpredictable results. -- Erik Naggum, comp.lang.lisp From paul at donovansbrain.co.uk Wed Jan 21 16:29:44 2004 From: paul at donovansbrain.co.uk (Paul Donovan) Date: Wed Jan 21 16:29:51 2004 Subject: [Pythonmac-SIG] Carbon.File and resolving aliases In-Reply-To: References: <4EF14640-46E8-11D8-9876-000393998ACA@donovansbrain.co.uk> Message-ID: On 15 Jan 2004, at 22:48, Jack Jansen wrote: > If you write the routine I'd be interested in adding it to the > macostools module. > Ok, it took a while (not a lot of spare time), but I've got something I'm fairly happy with. I've not been doing either Python or Mac programming for very long, so it might not be the best, but here it is: import Carbon.File import os.path import string def ResolveFinderAliases(path): """Returns a version of the supplied path with all Finder aliases converted to their real locations """ if path is "": return path # We need to keep testing a full path until all the aliases have # been removed finished = 0 while not finished: comps = string.split(path,'/') for i,c in enumerate(comps): if c == '': comps[i] = '/' result = "" for i, comp in enumerate(comps): # Add the next component of the path result = os.path.join(result,comp) # Check for an alias fss = Carbon.File.FSSpec(result) fss, isFolder, aliased = Carbon.File.ResolveAliasFile(fss,0) if aliased: # Get where the alias points to fsr = Carbon.File.FSRef(fss) path = fsr.FSRefMakePath() for j in range(i+1,len(comps)): path = os.path.join(path,comps[j]) # Start the process again - the target of this alias # might have an alias further up the path. break elif i == len(comps)-1: # Reached the last component without finding # an alias - finished. finished = 1 return result One flaw I am aware of is that handling of errors from the Carbon.File functions is non-existent. Cheers, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2377 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040121/e052f3b7/smime.bin From drewmccormack at mac.com Thu Jan 22 05:45:50 2004 From: drewmccormack at mac.com (Drew McCormack) Date: Thu Jan 22 05:47:44 2004 Subject: [Pythonmac-SIG] xgrid and numeric/numarray In-Reply-To: <3CE9059DA7571D479A129D83ABB8FFB8E7777C@exchangeldn.nera.com> References: <3CE9059DA7571D479A129D83ABB8FFB8E7777C@exchangeldn.nera.com> Message-ID: <24D8ECB4-4CC8-11D8-84EA-003065BD3BD8@mac.com> I think the trick is to use the 'Create Custom Plugin' option in the Xgrid client. Whenever Xgrid schedules a job on the controller machine, it copies the executable you enter (eg /bin/sh or your python binary) from the client submitting the job, to the controller, and then on to the agent that runs the job. This is important to know --- it does not run the executable installed on the agent, but actually copies it from the client. The 'Create Custom Plugin' option allows you to create a plugin via the GUI which can do things like copy a directory of files (in addition to your executable) from the client to the agent. These could be input files, for example, dynamic libraries or plugins...anything your program needs to run. My guess is, your best chance is to copy your Numpy module by entering its directory path. It will then be copied, along with the python executable, to a temporary directory on the agent machine, and run as user 'nobody'. Haven't tried this, but I assume that is the way to go. Cheers, Drew McCormack On Jan 20, 2004, at 4:58 PM, Kalmus, Philip wrote: > Hi, does anyone know if it is possible / how to run Numeric or > Numarray programs on Apple's new Xgrid? > Philip > > > _____________________________________________________________ > > This e-mail and any attachments may be confidential or legally > privileged. If you received this message in error or are not the > intended recipient, you should destroy the e-mail message and any > attachments or copies, and you are prohibited from retaining, > distributing, disclosing or using any information contained herein. > Please inform us of the erroneous delivery by return e-mail. > > > Thank you for your cooperation. > > _____________________________________________________________ > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From frederik at pandora.be Thu Jan 22 09:39:58 2004 From: frederik at pandora.be (Frederik De Bleser) Date: Thu Jan 22 09:40:24 2004 Subject: [Pythonmac-SIG] NSBundle: attribute loading? Message-ID: Hi, I wanted to add some additional options to the save panel in PyObjC. I discovered that I should use setAccessoryView_ on a NSSavePanel. The TextEdit sources show how to do that: you load an NSBundle, and then set a certain box to the accessorryView of the save panel. The file's owner of the NIB is changed to my own subclass of NSDocument, and I added two additionational outlets: pageCount (an NSTextField) and pageCountAccessory (an NSBox). The problem I have is that NSBundle.loadNibNamed_owner_ doesn't seem to set the attributes I defined on the file's owner ("self"). Therefore, I'm not able to access any of the outlets. Here's the code. Python gives an error the moment I try to access self.pageCount ("object has no attribute pageCount") def saveMultipleDocumentsAsPDF_(self): savePanel = NSSavePanel.savePanel() if not NSBundle.loadNibNamed_owner_("PageCounterAccessory", self): NSLog("Error -- could not load PageCounterAccessory.") self.pageCount.setIntValue_(1) savePanel.setAccessoryView_(self.pageCountAccessory) Any help on how this problem might be solved is appreciated. Regards, Frederik De Bleser From drewmccormack at mac.com Thu Jan 22 13:25:36 2004 From: drewmccormack at mac.com (Drew McCormack) Date: Thu Jan 22 13:25:44 2004 Subject: [Pythonmac-SIG] xgrid and numeric/numarray In-Reply-To: <40100920.4070207@noaa.gov> References: <3CE9059DA7571D479A129D83ABB8FFB8E7777C@exchangeldn.nera.com> <24D8ECB4-4CC8-11D8-84EA-003065BD3BD8@mac.com> <40100920.4070207@noaa.gov> Message-ID: <5F433CC7-4D08-11D8-B126-0003937B5C28@mac.com> On Jan 22, 2004, at 6:32 PM, Chris Barker wrote: > > > Drew McCormack wrote: >> Whenever Xgrid schedules a job on the controller machine, it copies >> the executable you enter (eg /bin/sh or your python binary) from the >> client submitting the job, to the controller, and then on to the >> agent that runs the job. Actually, I think I may have exaggerated in my first post. The executable does get copied by Xgrid, but you can run things already installed on the agent machine, as long as you remember that you will be running as user 'nobody'. Permissions have to be right. In practice, the best option is probably to run /bin/sh as the executable, which will be copied across, and start up your python from inside that, using the installation already on the agent machine. > > Yuck! this sounds substantially less sophisticated than Mosix (or open > mosix), for instance. Too bad. Sure, it ain't an advanced grid engine. Things like Globus are much more sophisticated, but you try to get them working ;-) I think if Apple can get Xgrid stable, it will be a very useful thing, not because it is advanced, but because it is simple. It is the iMovie of the grid world. I get the feeling Apple may build Xgrid into future versions of OS X, and hopefully provide APIs in Cocoa. That would make it very easy for any app to share the work load with other idle macs. I think it is a cool idea. Eventually the distinction between each mac may largely disappear. You will just buy a piece of one very big mac ;-) >> These could be input files, for example, dynamic libraries or >> plugins...anything your program needs to run. > > It sounds like you mioght have to copy your whole darn Python > environment! Well, I think I may have exaggerated there, but there is an upside to copying the environment: you have complete control over your run, with no compatibility surprises. Drew Trade Strategist Stock market strategy design software http://www.trade-strategist.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2821 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040122/65b7a37a/attachment.bin From rowen at cesmail.net Thu Jan 22 16:24:34 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Thu Jan 22 16:24:58 2004 Subject: [Pythonmac-SIG] bundlebuilder questions Message-ID: I've been trying to use bundlebuilder to create a double-clickable app from my Tkinter program. It's getting very close (thanks to a helpful posting from John P Speno) but I have run into a few problems that I'm hoping somebody can help me with. I've included the build files and other details at the very end, for those who want details. The problems are: 1) My main module Main.py tries to automatically load modules via the __import__ function. Most of these modules are expected to be in the same directory as Main.py. This fails in the double-clickable app because the build process moves Main.py elsewhere. I suspect that the buildapp arg "executable" is intended to help with this problem, but I have not figured out how to get it to work. I also had a shot at rewriting my Main.py, but that looks messy because __import__ does not handle submodule names (e.g. "A.B"). 2) My application relies on some sound files (.wav files) being contained in package TUI.Sounds (i.e. in directory TUI/Sounds, where TUI is in a directory on the PYTHONPATH). Unfortunately, I've not found any good way of including those files. I can supply the command-line argument --file-SRC:DST for each file in turn, but: - I cannot get the files to end up in the right location. They ought to end up in TUI/Sounds within TUI.app/Contents/Resources/Modules.zip, but I have not found any source specification that puts the files inside Modules.zip - (minor) It seems that each file name has to be specified individually. Is there any way to use wildcards (other than writing a script that finds all the files, generates a suitable shell script and then runs that)? 3) I've tried to work around (2) by adding the sound files to the suitable location in TUI.app/Contents/Resources/Modules.zip, but this breaks the resulting application. It's as if the file is not really a standard zip file, because even the slightest change totally breaks the app -- it acts as if it can no longer see *anything* in the .zip file. And two minor things: 4) Is there some way to avoid the use of a shell script? I would prefer to have one python script do everything, but I've not figured out how to specify suitable args to buildapp that correspond to the command-line arguments. The command-line args are well documented in the source code, but I find the docs for the buildapp args quite confusing. 5) Also, as a final note, the package "os" is not found. I fixed this by explicitly including it with buildapp argument "includeModules", but I am puzzled why a standard package is not found. -- Russell The file MakeMacTUI.py is: from bundlebuilder import buildapp import TUI.Version appName = "TUI " + TUI.Version.VersionStr.split()[0] + ".app" buildapp( name=appName, # application name builddir = ".", # dir for application mainprogram='/Users/rowen/PythonRO/TUI/Main.py', # your app's main() argv_emulation=False, # drag&dropped filenames show up in sys.argv? # iconfile='myapp.icns', # file containing your app's icons standalone=True, # make this app self contained. includeModules=["os"], # list of additional Modules to force in includePackages=[], # list of additional Packages to force in ) This is executed from a shell script maintui.sh: #!/bin/sh pythonw MakeMacTUI.py \ --lib="/Library/Frameworks/Tcl.framework" \ --lib="/Library/Frameworks/Tk.framework" \ build The basic organization of my code is as follows: PythonRO (a directory on the PYTHONPATH) TUI (a package) __init__.py (of course) Main.py (my main file) other modules and subpackages, some of which Main.py tries to import using __import__(name) From rowen at cesmail.net Thu Jan 22 17:14:32 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Thu Jan 22 17:14:53 2004 Subject: [Pythonmac-SIG] more bundlebuilder problems Message-ID: I just posted a message about bundlebuilder problems, but have found two more... Is there some way to get all modules in a package loaded? Much of my code is auto-loaded, so bundlebuilder does not realize it needs to be added. We're talking a *lot" of modules, so listing them individually is something of a nightmare, though obviously I can code a script to make it happen if necessary. I've tried just importing the package itself (in Main.py or by listing it in the includePackages argument to bundlebuilder) but neither of those works. The only module in each such package that is transferred is __init__.py. (And if I can't get those modules loaded as part of the build, then presumably the packages they rely on will also not be loaded.) Is there some way to get bundlebuilder to not zip the modules? I've discovered I can unzip Modules.zip into Resources and that works, but it'll mean a more complex script (right now I'm doing it by hand). The reason I need this is some of my code is auto-loaded using a directory walk, and that fails if the code is in a zip file. -- Russell From wtbridgman at radix.net Thu Jan 22 17:41:10 2004 From: wtbridgman at radix.net (W.T. Bridgman) Date: Thu Jan 22 17:40:31 2004 Subject: [Pythonmac-SIG] Python solution to monitor your internet connection? In-Reply-To: Message-ID: <132BD7F4-4D2C-11D8-B296-0050E485FC7A@radix.net> Bob, Then could I assume that you regard 'LittleSnitch' as a worthwhile program for such a task? Tom On Tuesday, January 20, 2004, at 08:07 AM, Bob Ippolito wrote: > On Jan 20, 2004, at 7:34 AM, Jack Jansen wrote: >> I don't think you have to be *that* gross. The ipfirewall device (see >> man 4 firewall) can probably be used to make all packets be given to >> your code for inspection. But still I don't think I'd want to do this >> in Python because of the overhead. > > It's extremely important to know the pid the packet came from in this > sort of application, so that interface won't cut it. Little Snitch > uses a kext. > > (kextstat output -- little snitch isn't even active at the moment, I > guess it stays resident) > 86 0 0x2fa51000 0xe000 0xd000 at.obdev.KUC (1.1.1) <10> > > (the startup item is probably a replicant of what is in the pref > pane..) > /Library/StartupItems/LittleSnitch/Resources/ODKUControl.kext > /Library/PreferencePanes/Little > Snitch.prefPane/Contents/Resources/ODKUControl.kext > > > -bob > From bob at redivi.com Thu Jan 22 19:23:56 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 22 19:21:25 2004 Subject: [Pythonmac-SIG] Python solution to monitor your internet connection? In-Reply-To: <132BD7F4-4D2C-11D8-B296-0050E485FC7A@radix.net> References: <132BD7F4-4D2C-11D8-B296-0050E485FC7A@radix.net> Message-ID: <6E7E252B-4D3A-11D8-B133-000A95686CD8@redivi.com> Well I only downloaded it to see how it worked (pick it apart ;) .. I don't personally use a whole lot of software that tries to spy on me, but I have friends who do (thanks, Macromedia!) and they say that it works just fine. Technically, I would certainly recommend it. It seems to work as advertised, easy to use, etc. Personally, I would like to see an open source version (for study, not to prevent obdev from making money), but I'm not interested enough to write it. -bob On Jan 22, 2004, at 5:41 PM, W.T. Bridgman wrote: > Then could I assume that you regard 'LittleSnitch' as a worthwhile > program for such a task? > > On Tuesday, January 20, 2004, at 08:07 AM, Bob Ippolito wrote: >> On Jan 20, 2004, at 7:34 AM, Jack Jansen wrote: >>> I don't think you have to be *that* gross. The ipfirewall device >>> (see man 4 firewall) can probably be used to make all packets be >>> given to your code for inspection. But still I don't think I'd want >>> to do this in Python because of the overhead. >> >> It's extremely important to know the pid the packet came from in this >> sort of application, so that interface won't cut it. Little Snitch >> uses a kext. >> >> (kextstat output -- little snitch isn't even active at the moment, I >> guess it stays resident) >> 86 0 0x2fa51000 0xe000 0xd000 at.obdev.KUC (1.1.1) <10> >> >> (the startup item is probably a replicant of what is in the pref >> pane..) >> /Library/StartupItems/LittleSnitch/Resources/ODKUControl.kext >> /Library/PreferencePanes/Little >> Snitch.prefPane/Contents/Resources/ODKUControl.kext From kevin at macosx.com Thu Jan 22 22:30:57 2004 From: kevin at macosx.com (kevin) Date: Thu Jan 22 22:31:48 2004 Subject: [Pythonmac-SIG] libpython2.3.a: No such file or directory In-Reply-To: Message-ID: <8EBBC137-4D54-11D8-91DD-003065555ABC@macosx.com> I am trying to compile something (not python, but something called pycmix, a front end for cmix, a music synthesis language) and i though that i would be bold and try to do it myself and pointed the makefile at Jack's build pythonw2.3, but am getting the following error about a library. Anyone have any ideas about why this is missing and what i could maybe do to remedy this.... It is starting to look like i need yet another version of python... I though that jack's python was a framework build and had all the stuff that apple's was missing...... I am on Jag latest python from Jack..... cheers, kevin [d-199-206-240:RTcmix/insts.base/MIX] kevin% make PYMIX c++ -o PYMIX MIX.o /usr/local/src/RTcmix/sys/cmix.o /usr/local/src/RTcmix/rtstuff/profile.o \ /usr/local/src/RTcmix/Minc/py.o -framework CoreAudio /usr/local/src/RTcmix/lib/genlib.a `python /usr/local/src/RTcmix/Python/print_libpython.py` c++: /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/ libpython2.3.a: No such file or directory make: *** [PYMIX] Error 1 From bob at redivi.com Thu Jan 22 22:42:37 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 22 22:40:02 2004 Subject: [Pythonmac-SIG] libpython2.3.a: No such file or directory In-Reply-To: <8EBBC137-4D54-11D8-91DD-003065555ABC@macosx.com> References: <8EBBC137-4D54-11D8-91DD-003065555ABC@macosx.com> Message-ID: <3005681B-4D56-11D8-B72E-000A95686CD8@redivi.com> On Jan 22, 2004, at 10:30 PM, kevin wrote: > I am trying to compile something (not python, but something called > pycmix, a front end for cmix, a music synthesis language) and i though > that i would be bold and try to do it myself and pointed the makefile > at Jack's build pythonw2.3, but am getting the following error about a > library. Anyone have any ideas about why this is missing and what i > could maybe do to remedy this.... It is starting to look like i need > yet another version of python... I though that jack's python was a > framework build and had all the stuff that apple's was missing...... > > I am on Jag latest python from Jack..... Apparently pycmix has a broken build script. It should be using -framework Python instead of trying to link to a static library directly. You should take this up with them, they're obviously not using the canonical way to build python extensions (distutils), so the fix needs to happen in their custom build phase for the python extension -- hopefully by replacing it altogether with a distutils based solution :) -bob From list-matt at reprocessed.org Fri Jan 23 05:16:49 2004 From: list-matt at reprocessed.org (Matt Patterson) Date: Fri Jan 23 05:16:56 2004 Subject: [Pythonmac-SIG] Python bindings for DB XML Message-ID: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> Hello, I'm trying to build the Python bindings for Sleepycat's DB XML and I've gotten to the point where I need a pybsddb compiled against BDB 4.2.52 rather than 4.1.25, and I've come entirely unstuck at this point. Can anyone enlighten me? I've got a home-built Framework Python 2.3.3 on 10.3.2. Thanks, Matt -- Matt Patterson | Typographer | http://www.emdash.co.uk/ | http://reprocessed.org/ From bob at redivi.com Fri Jan 23 08:27:15 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 23 08:24:40 2004 Subject: [Pythonmac-SIG] Python bindings for DB XML In-Reply-To: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> References: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> Message-ID: On Jan 23, 2004, at 5:16 AM, Matt Patterson wrote: > I'm trying to build the Python bindings for Sleepycat's DB XML and > I've gotten to the point where I need a pybsddb compiled against BDB > 4.2.52 rather than 4.1.25, and I've come entirely unstuck at this > point. Can anyone enlighten me? > > I've got a home-built Framework Python 2.3.3 on 10.3.2. I'm pretty confused as to what your problem actually is? http://pybsddb.sf.net/ is where you would download the source for a newer pybsddb, and http://www.sleepycat.com/ is where you would do the same for BerkeleyDB. -bob Oh, by the way, getting "unstuck" means that you don't a problem :) From Harri.Hakula at arabianranta.com Fri Jan 23 14:21:28 2004 From: Harri.Hakula at arabianranta.com (Harri Hakula) Date: Fri Jan 23 14:21:12 2004 Subject: [Pythonmac-SIG] Python bindings for DB XML In-Reply-To: References: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> Message-ID: <57EC4388-4DD9-11D8-AD82-0050E4601908@arabianranta.com> DB XML python examples start with the following lines: # As of Python 2.3, there is a built-in module for Berkeley DB, # called bsddb. The next uncommented line assumes that module is being used. # If you are using your own bsddb3 module, use this line: # from bsddb3.db import * from bsddb.db import * from dbxml import * I simply compiled the pybsddb from the source and installed it as bsddb3. It is understandable why Apple left it out from their distribution. Cheers, Harri Hakula On Jan 23, 2004, at 15:27, Bob Ippolito wrote: > On Jan 23, 2004, at 5:16 AM, Matt Patterson wrote: > >> I'm trying to build the Python bindings for Sleepycat's DB XML and >> I've gotten to the point where I need a pybsddb compiled against BDB >> 4.2.52 rather than 4.1.25, and I've come entirely unstuck at this >> point. Can anyone enlighten me? >> >> I've got a home-built Framework Python 2.3.3 on 10.3.2. > > I'm pretty confused as to what your problem actually is? > http://pybsddb.sf.net/ is where you would download the source for a > newer pybsddb, and http://www.sleepycat.com/ is where you would do the > same for BerkeleyDB. > > -bob > > Oh, by the way, getting "unstuck" means that you don't a problem :) > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From rowen at cesmail.net Fri Jan 23 15:49:34 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jan 23 15:49:51 2004 Subject: [Pythonmac-SIG] bundlebuilder bug? Message-ID: I just submitted this to sourceforge, but thought I'd see if anybody had any suggested workarounds. I'm also unclear if I should be reporting a 2nd bug as well. The bundlebuilder command-line argument --lib is supposed to be able to include frameworks in the resulting Mac application package. Unfortunately, the aliases in the resulting framework copy are all broken. For an example of this, use --lib to include Tcl.framework and then look through the framework in the resulting application package. Frameworks normally have quite a few handy aliases (such as .../Versions/Current) and all the aliases I tried were broken. I'm not entirely sure if this actually breaks anything. The one app I've managed to build with standalone=True and use of --lib to include the Tk and Tcl frameworks runs fine on my Mac (which has Python, Tcl and Tk frameworks installed) but fails with "True undefined" on another Mac running Jaguar that I happened to have handy. This 2nd problem may be a separate bug or user error on my part. I'm not yet sure. -- Russell P.S. I finally got my extra files properly installed by adding to the bundlebuilder script such that it: - unpacks Modules.zip - copies the two packages in question (overwriting the incomplete versions that were already installed; I plan to try excluding them and leaving Modules.zip alone). The results work on my machine but break on a Jaguar machine is noted above with True undefined -- as if it's running the python on that machine instead of the framework python that's in the application package. From oussoren at cistron.nl Fri Jan 23 16:43:42 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Fri Jan 23 16:43:49 2004 Subject: [Pythonmac-SIG] bundlebuilder bug? In-Reply-To: References: Message-ID: <364DC072-4DED-11D8-B390-0003931CFE24@cistron.nl> On 23 jan 2004, at 21:49, Russell E. Owen wrote: > > > P.S. I finally got my extra files properly installed by adding to the > bundlebuilder script such that it: > - unpacks Modules.zip > - copies the two packages in question (overwriting the incomplete > versions that were already installed; I plan to try excluding them and > leaving Modules.zip alone). Does adding '--package=myFooPackage' to the buildapp commandline help? This seems to require a standalone/semi-standalone build. Ronald From bob at redivi.com Fri Jan 23 16:59:58 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 23 16:57:32 2004 Subject: [Pythonmac-SIG] bundlebuilder bug? In-Reply-To: References: Message-ID: <7CA5094E-4DEF-11D8-824A-000A95686CD8@redivi.com> On Jan 23, 2004, at 3:49 PM, Russell E. Owen wrote: > I just submitted this to sourceforge, but thought I'd see if anybody > had > any suggested workarounds. I'm also unclear if I should be reporting a > 2nd bug as well. Next time it'd be cool to get a URL for it in the bug tracker, only Jack gets email notifications about this stuff, and it's sort of a pain to dig around in sourceforge's bug tracker. > The bundlebuilder command-line argument --lib is supposed to be able to > include frameworks in the resulting Mac application package. > Unfortunately, the aliases in the resulting framework copy are all > broken. > > For an example of this, use --lib to include Tcl.framework and then > look > through the framework in the resulting application package. Frameworks > normally have quite a few handy aliases (such as .../Versions/Current) > and all the aliases I tried were broken. > > I'm not entirely sure if this actually breaks anything. The one app > I've > managed to build with standalone=True and use of --lib to include the > Tk > and Tcl frameworks runs fine on my Mac (which has Python, Tcl and Tk > frameworks installed) but fails with "True undefined" on another Mac > running Jaguar that I happened to have handy. These symbolic links are never used by the runtime as far as I know. I think they're mostly for humans and compilers -- unless maybe something goes wrong during the link (dyld fallback environment variables or something). > This 2nd problem may be a separate bug or user error on my part. I'm > not > yet sure. Not sure, there really isn't enough information to go on. If you are running 10.3 on your machine, all bets are off.. --standalone will not produce a 10.2 compatible app bundle, --semi-standalone *probably* won't either because you have to set up a compile time environment explicitly make things 10.2 deployable (and have the SDKs installed), Python.framework itself certainly is not (compiled by Apple), and none of the modules in PackageManager (both Jack's and mine) are necessarily 10.2 deployable and are likely to have dyld issues anyway because the Python.framework paths are different. Short answer: if you want your Python apps to run on Jaguar, you need to make them on Jaguar. > P.S. I finally got my extra files properly installed by adding to the > bundlebuilder script such that it: > - unpacks Modules.zip > - copies the two packages in question (overwriting the incomplete > versions that were already installed; I plan to try excluding them and > leaving Modules.zip alone). > The results work on my machine but break on a Jaguar machine is noted > above with True undefined -- as if it's running the python on that > machine instead of the framework python that's in the application > package. If you exclude a module/package (so it won't go in Modules.zip), and then include it (either as a resource or a module, it doesn't really matter) then this problem should be solved. No need to modify the code for bundlebuilder. That said, I have personally modified a copy of bundlebuilder that fixes the aforementioned symlink bug, and adds a slew of additional features with regard to embedding modules and frameworks (it actually scans your extensions and automatically locates any dylibs/frameworks they depend on.. rewrites all of their headers and chunks them into the app bundle). I'll clean this up and release it someday if people bug me about it on a semi-regular basis :) -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/20040123/80995d2e/smime.bin From rowen at cesmail.net Fri Jan 23 19:52:47 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jan 23 19:52:54 2004 Subject: [Pythonmac-SIG] Re: bundlebuilder bug? References: <7CA5094E-4DEF-11D8-824A-000A95686CD8@redivi.com> Message-ID: In article <7CA5094E-4DEF-11D8-824A-000A95686CD8@redivi.com>, Bob Ippolito wrote: > On Jan 23, 2004, at 3:49 PM, Russell E. Owen wrote: > > > I just submitted this to sourceforge, but thought I'd see if anybody > > had > > any suggested workarounds. I'm also unclear if I should be reporting a > > 2nd bug as well. > > Next time it'd be cool to get a URL for it in the bug tracker, only > Jack gets email notifications about this stuff, and it's sort of a pain > to dig around in sourceforge's bug tracker. Sorry about that. I'll try to remember for next time. > > The bundlebuilder command-line argument --lib is supposed to be able to > > include frameworks in the resulting Mac application package. > > Unfortunately, the aliases in the resulting framework copy are all > > broken.... I suspect you're right, since things now seem to be running OK. I went on to say my app was failing in Jaguar and you pointed out this was normal. I figured out a way to test my standalone app on my Panther machine (temporarily move the stuff in /Library/Frameworks) and it works fine (except for another problem I'm about to post about). So I simply documented the Jaguar problem and went on. ... > > P.S. I finally got my extra files properly installed by adding to the > > bundlebuilder script such that it: > > - unpacks Modules.zip > > - copies the two packages in question (overwriting the incomplete > > versions that were already installed; I plan to try excluding them and > > leaving Modules.zip alone). > > The results work on my machine but break on a Jaguar machine is noted > > above with True undefined -- as if it's running the python on that > > machine instead of the framework python that's in the application > > package. > > If you exclude a module/package (so it won't go in Modules.zip), and > then include it (either as a resource or a module, it doesn't really > matter) then this problem should be solved. No need to modify the code > for bundlebuilder. Yes, I tried this and found that it greatly increased the # of modules that had to be explicitly listed for inclusion. The only way I found of dealing with that was iteratively including the modules I got errors for, running the program and repeating as new module errors were reported. After a few rounds of this I gave up and went back to my old system of unpacking Modules.zip. > That said, I have personally modified a copy of bundlebuilder that > fixes the aforementioned symlink bug, and adds a slew of additional > features with regard to embedding modules and frameworks (it actually > scans your extensions and automatically locates any dylibs/frameworks > they depend on.. rewrites all of their headers and chunks them into the > app bundle). I'll clean this up and release it someday if people bug > me about it on a semi-regular basis :) That sounds wonderful. Thanks for all your help! -- Russell From rowen at cesmail.net Fri Jan 23 19:53:45 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jan 23 20:00:42 2004 Subject: [Pythonmac-SIG] Re: bundlebuilder bug? References: <364DC072-4DED-11D8-B390-0003931CFE24@cistron.nl> Message-ID: In article <364DC072-4DED-11D8-B390-0003931CFE24@cistron.nl>, Ronald Oussoren wrote: > On 23 jan 2004, at 21:49, Russell E. Owen wrote: > > > > > > > P.S. I finally got my extra files properly installed by adding to the > > bundlebuilder script such that it: > > - unpacks Modules.zip > > - copies the two packages in question (overwriting the incomplete > > versions that were already installed; I plan to try excluding them and > > leaving Modules.zip alone). > > Does adding '--package=myFooPackage' to the buildapp commandline help? > This seems to require a standalone/semi-standalone build. Unfortunately not. I tried it and found that only a few files in the associated packages were loaded. -- Russell From rowen at cesmail.net Fri Jan 23 20:06:20 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jan 23 20:06:25 2004 Subject: [Pythonmac-SIG] can't delete Tkinter apps built with bundlebuilder Message-ID: I finally go bundlebuilder working (thanks for all the help). Sigh. Quite a struggle. I plan to post some docs on what I learned when I get some time. Unfortunately, I'm still in the learning stage... The Tkinter apps I produce, once executed, cannot be deleted until the Mac is rebooted (simply logging out and logging back in again does NOT suffice). The Finder's error message is: The operation cannot be completed because the item "Python" is in use. I thought I was quitting and cleaning up properly, but perhaps not. The app does use a few threads (though I'm pretty sure I've seen the problem before any of them are launched, since all are assoc. with networking and I can see the problem even if I never connect to anything). Any hints on what to look for or useful tricks for working around this problem would be appreciated. -- Russell P.S. this is MacOS X 10.3.2. I'm not sure what other details to post now. I may try to build a smaller version of the app to try to isolate the problem. From list-matt at reprocessed.org Sat Jan 24 05:44:32 2004 From: list-matt at reprocessed.org (Matt Patterson) Date: Sat Jan 24 05:44:39 2004 Subject: [Pythonmac-SIG] Python bindings for DB XML In-Reply-To: References: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> Message-ID: <4B2AD036-4E5A-11D8-AA47-000393CBB978@reprocessed.org> On 23 Jan 2004, at 13:27, Bob Ippolito wrote: > On Jan 23, 2004, at 5:16 AM, Matt Patterson wrote: > >> I'm trying to build the Python bindings for Sleepycat's DB XML and >> I've gotten to the point where I need a pybsddb compiled against BDB >> 4.2.52 rather than 4.1.25, > > I'm pretty confused as to what your problem actually is? > http://pybsddb.sf.net/ is where you would download the source for a > newer pybsddb, and http://www.sleepycat.com/ is where you would do the > same for BerkeleyDB. I have the latest pybsddb, and the latest BerkeleyDB. Berkeley DB has been built and installed in /usr/local/ as per the BDB instructions. python setup.py build runs fine, and finds my /usr/local/ Berkeley DB install When I run python test.py I get: Fatal Python error: Interpreter not initialized (version mismatch?) And that is where I come unstuck. > Oh, by the way, getting "unstuck" means that you don't a problem :) Unstuck like a glued-together something becoming spontaneously unglued... Thanks, Matt -- Matt Patterson | Typographer | http://www.emdash.co.uk/ | http://reprocessed.org/ From bob at redivi.com Sat Jan 24 12:32:02 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 24 12:29:30 2004 Subject: [Pythonmac-SIG] Python bindings for DB XML In-Reply-To: <4B2AD036-4E5A-11D8-AA47-000393CBB978@reprocessed.org> References: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> <4B2AD036-4E5A-11D8-AA47-000393CBB978@reprocessed.org> Message-ID: <389C43B8-4E93-11D8-BCF3-000A95686CD8@redivi.com> On Jan 24, 2004, at 5:44 AM, Matt Patterson wrote: > > On 23 Jan 2004, at 13:27, Bob Ippolito wrote: > >> On Jan 23, 2004, at 5:16 AM, Matt Patterson wrote: >> >>> I'm trying to build the Python bindings for Sleepycat's DB XML and >>> I've gotten to the point where I need a pybsddb compiled against BDB >>> 4.2.52 rather than 4.1.25, >> >> I'm pretty confused as to what your problem actually is? >> http://pybsddb.sf.net/ is where you would download the source for a >> newer pybsddb, and http://www.sleepycat.com/ is where you would do >> the same for BerkeleyDB. > > I have the latest pybsddb, and the latest BerkeleyDB. Berkeley DB has > been built and installed in /usr/local/ as per the BDB instructions. > > python setup.py build runs fine, and finds my /usr/local/ Berkeley DB > install > > When I run python test.py I get: > > Fatal Python error: Interpreter not initialized (version mismatch?) > > And that is where I come unstuck. > >> Oh, by the way, getting "unstuck" means that you don't a problem :) > > Unstuck like a glued-together something becoming spontaneously > unglued... You have multiple versions of Python installed.. you compiled the bsddb module (or something it is using) with a different version of Python than what you're testing it with. -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/20040124/19a6f3cc/smime.bin From Jack.Jansen at cwi.nl Sun Jan 25 15:26:13 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Jan 25 15:26:23 2004 Subject: [Pythonmac-SIG] bundlebuilder bug? In-Reply-To: <7CA5094E-4DEF-11D8-824A-000A95686CD8@redivi.com> References: <7CA5094E-4DEF-11D8-824A-000A95686CD8@redivi.com> Message-ID: On 23-jan-04, at 22:59, Bob Ippolito wrote: > That said, I have personally modified a copy of bundlebuilder that > fixes the aforementioned symlink bug, and adds a slew of additional > features with regard to embedding modules and frameworks (it actually > scans your extensions and automatically locates any dylibs/frameworks > they depend on.. rewrites all of their headers and chunks them into > the app bundle). I'll clean this up and release it someday if people > bug me about it on a semi-regular basis :) Consider yourself bugged:-) And, as usual, you would do me a great favor if you could separate the two items (the bug fix for the symlinking and the added functionality of automatically scanning your extensions) and post them as two separate tracker items... -- 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 heafnerj at ctc.net Sun Jan 25 16:04:49 2004 From: heafnerj at ctc.net (Joe Heafner) Date: Sun Jan 25 16:05:01 2004 Subject: [Pythonmac-SIG] BROWSER env var won't work under Panther In-Reply-To: References: <7CA5094E-4DEF-11D8-824A-000A95686CD8@redivi.com> Message-ID: <1D0C182D-4F7A-11D8-9F9F-000A95CD1A36@ctc.net> Hello. I have installed Fink's Python23 and have built VPython successfully. Under Jaguar, I could set the env variable BROWSER=open and that allowed me to access help from inside IDLE. This isn't working under Panther. How can I get docs to come up when pressing F1 from inside IDLE under Panther? Cheers, Joe Heafner -- Astronomy/Physics Instructor (by some definitions) From njriley at uiuc.edu Sun Jan 25 17:36:21 2004 From: njriley at uiuc.edu (Nicholas Riley) Date: Sun Jan 25 17:36:28 2004 Subject: [Pythonmac-SIG] BROWSER env var won't work under Panther In-Reply-To: <1D0C182D-4F7A-11D8-9F9F-000A95CD1A36@ctc.net> References: <7CA5094E-4DEF-11D8-824A-000A95686CD8@redivi.com> <1D0C182D-4F7A-11D8-9F9F-000A95CD1A36@ctc.net> Message-ID: <20040125223621.GA2890@uiuc.edu> On Sun, Jan 25, 2004 at 04:04:49PM -0500, Joe Heafner wrote: > Hello. > > I have installed Fink's Python23 and have built VPython successfully. > Under Jaguar, I could set the env variable BROWSER=open and that > allowed me to access help from inside IDLE. This isn't working under > Panther. How can I get docs to come up when pressing F1 from inside > IDLE under Panther? This is a bug in IDLE: def python_docs(self, event=None): if sys.platform.count('win') or sys.platform.count('nt'): os.startfile(self.help_url) return "break" else: webbrowser.open(self.help_url) return "break" >>> import sys; sys.platform 'darwin' You can see what's happening. :) I wonder if something like: if hasattr(os, 'startfile'): os.startfile(self.help_url) else: webbrowser.open(self.help_url) would work. But even this shouldn't be necessary. I'm a bit confused as to why the webbrowser module isn't used on Windows - it is supposed to work on Python 2.0 and later. -- =Nicholas Riley | From list-matt at reprocessed.org Mon Jan 26 06:55:33 2004 From: list-matt at reprocessed.org (Matt Patterson) Date: Mon Jan 26 06:55:37 2004 Subject: [Pythonmac-SIG] Python bindings for DB XML In-Reply-To: <389C43B8-4E93-11D8-BCF3-000A95686CD8@redivi.com> References: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> <4B2AD036-4E5A-11D8-AA47-000393CBB978@reprocessed.org> <389C43B8-4E93-11D8-BCF3-000A95686CD8@redivi.com> Message-ID: <8C0EA43C-4FF6-11D8-AA47-000393CBB978@reprocessed.org> On 24 Jan 2004, at 17:32, Bob Ippolito wrote: > You have multiple versions of Python installed.. you compiled the > bsddb module (or something it is using) with a different version of > Python than what you're testing it with. Ah, yes. I was, in fact, just being a total dimwit. I had built my lovely new Python, and thought that my path was correctly ordered. When I checked this by looking at the version of Python I still thought that 10.3 shipped with Python 2.2, and I saw 2.3 and thought that I was running my /usr/local/bin python 2.3.3... I don't imagine I'll have any problems now that's resolved... Thanks for bearing with me! Best, Matt From Chris.Barker at noaa.gov Mon Jan 26 12:17:31 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Jan 26 12:20:26 2004 Subject: [Pythonmac-SIG] Python bindings for DB XML In-Reply-To: <8C0EA43C-4FF6-11D8-AA47-000393CBB978@reprocessed.org> References: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> <4B2AD036-4E5A-11D8-AA47-000393CBB978@reprocessed.org> <389C43B8-4E93-11D8-BCF3-000A95686CD8@redivi.com> <8C0EA43C-4FF6-11D8-AA47-000393CBB978@reprocessed.org> Message-ID: <40154BAB.1020108@noaa.gov> Matt Patterson wrote: > and thought that my path was correctly ordered. When > I checked this by looking at the version of Python I still thought that > 10.3 shipped with Python 2.2, and I saw 2.3 and thought that I was > running my /usr/local/bin python 2.3.3... > > I don't imagine I'll have any problems now that's resolved... We need to start a little eduction campain here. I've seen advice given here that getting your PATH in the right order is the way to deal with multiple versions of python. That's really a Bad Idea for a number of reasons: - While for the moment, for Python's sake, you may want to have /usr/local/bin searched before /usr/bin, it may be that for other applications, you'd want it the other way around. - When you install the third version of Python, what are you going to do then? - what if Apple has tools that put "#!/usr/bin/env python" at the top, and expect to find the python in /usr/bin. I know, they shouldn't do that , but RedHat did it for years, and I think they still do. -- There are various ways that the PATH can get set, they might not all be the same. -- The solution I propose is that you put: #!/usr/bin/env pythonX.X At the top of your file. Where X.X is the version of Python you want (python2.2, python2.3, etc.) This way that script will always give you the Python that it was written and tested with, and you can have any number of pythons on your PATH without having to define a "default" one. I've been doing this on LInux for years, and it works great. As a bonus, if you distribute your scripts (or even look at your own in a year or two), it's very clear what version they were developed on. I know Jack said that PythonLauncher would respect the #! line, so this should work for scripts launched from either the finder or a command line. I've only used a command line at the moment...does this work? As a community, we really need to make sure that there is a way to have multiple versions of python coexisting peacefully. The #! line is one good way to do it. Frankly, I have no idea how to make this work on Windows, but that's not this group's problem! By the way, what does BuildApplet and/or BundleBuilder -semistandalone do to handle this? Another note. I Always do: python2.3 setup.py build when building an extension, rather than just "python", for all the same reasons. -Chris From oussoren at cistron.nl Mon Jan 26 10:52:50 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Mon Jan 26 12:32:14 2004 Subject: [Pythonmac-SIG] bundlebuilder bug? In-Reply-To: References: <7CA5094E-4DEF-11D8-824A-000A95686CD8@redivi.com> Message-ID: On 25 jan 2004, at 21:26, Jack Jansen wrote: > > On 23-jan-04, at 22:59, Bob Ippolito wrote: >> That said, I have personally modified a copy of bundlebuilder that >> fixes the aforementioned symlink bug, and adds a slew of additional >> features with regard to embedding modules and frameworks (it actually >> scans your extensions and automatically locates any dylibs/frameworks >> they depend on.. rewrites all of their headers and chunks them into >> the app bundle). I'll clean this up and release it someday if people >> bug me about it on a semi-regular basis :) > > Consider yourself bugged:-) > > And, as usual, you would do me a great favor if you could separate the > two items (the bug fix for the symlinking and the added functionality > of automatically scanning your extensions) and post them as two > separate tracker items... I have a main.m lying around for use in .app bundles. I was hoping to use this for further speeding up launching PyObjC applications (that didn't help). An executable is at least cleaner than the current bootstrap procedure, and makes it possible to create working .app bundles on Mac OS X 10.1. Ronald From bob at redivi.com Mon Jan 26 12:42:55 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 26 12:40:16 2004 Subject: [Pythonmac-SIG] Python bindings for DB XML In-Reply-To: <40154BAB.1020108@noaa.gov> References: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> <4B2AD036-4E5A-11D8-AA47-000393CBB978@reprocessed.org> <389C43B8-4E93-11D8-BCF3-000A95686CD8@redivi.com> <8C0EA43C-4FF6-11D8-AA47-000393CBB978@reprocessed.org> <40154BAB.1020108@noaa.gov> Message-ID: <12C780EB-5027-11D8-97A6-000A95686CD8@redivi.com> On Jan 26, 2004, at 12:17 PM, Chris Barker wrote: > Matt Patterson wrote: >> and thought that my path was correctly ordered. When >> I checked this by looking at the version of Python I still thought >> that 10.3 shipped with Python 2.2, and I saw 2.3 and thought that I >> was running my /usr/local/bin python 2.3.3... >> I don't imagine I'll have any problems now that's resolved... > > We need to start a little eduction campain here. I've seen advice > given here that getting your PATH in the right order is the way to > deal with multiple versions of python. That's really a Bad Idea for a > number of reasons: > > - While for the moment, for Python's sake, you may want to have > /usr/local/bin searched before /usr/bin, it may be that for other > applications, you'd want it the other way around. > > - When you install the third version of Python, what are you going to > do then? > > - what if Apple has tools that put "#!/usr/bin/env python" at the top, > and expect to find the python in /usr/bin. I know, they shouldn't do > that , but RedHat did it for years, and I think they still do. > > -- There are various ways that the PATH can get set, they might not > all be the same. > > -- The solution I propose is that you put: > > #!/usr/bin/env pythonX.X > > At the top of your file. Where X.X is the version of Python you want > (python2.2, python2.3, etc.) This way that script will always give you > the Python that it was written and tested with, and you can have any > number of pythons on your PATH without having to define a "default" > one. I've been doing this on LInux for years, and it works great. As a > bonus, if you distribute your scripts (or even look at your own in a > year or two), it's very clear what version they were developed on. > > I know Jack said that PythonLauncher would respect the #! line, so > this should work for scripts launched from either the finder or a > command line. I've only used a command line at the moment...does this > work? > > As a community, we really need to make sure that there is a way to > have multiple versions of python coexisting peacefully. The #! line is > one good way to do it. Frankly, I have no idea how to make this work > on Windows, but that's not this group's problem! > > By the way, what does BuildApplet and/or BundleBuilder -semistandalone > do to handle this? > > Another note. I Always do: > > python2.3 setup.py build > > when building an extension, rather than just "python", for all the > same reasons. I agree with you, to a small extent, but this pythonX.X business that you propose only matters to OS X 10.2 users. On 10.2, any way you slice it, /usr/local/bin isn't in the default path anyways (if I remember correctly), so the PATH thing is generally reasonable (especially because Apple didn't use Python at all on 10.2.x). In any case, there's one tiny little problem with what you propose: It doesn't do a damn thing for 10.3 users. - can't accommodate for minor versions (f.ex Apple Python 2.3.0 and your own Python 2.3.3) - can't accommodate build parameters debug build vs normal build - can't accommodate "distribution mechanism" (fink vs vendor vs user Python) People who are getting version mismatch problems are on 10.3, not 10.2. If you compiled an extension with Apple Python 2.2.0 on OS X 10.2, there's almost no way that you could accidentally load it from Python 2.3.x, and vice versa. That is certainly not true if you have a user installation of Python on OS X 10.3. -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/20040126/44645f7d/smime.bin From altis at semi-retired.com Mon Jan 26 13:00:26 2004 From: altis at semi-retired.com (Kevin Altis) Date: Mon Jan 26 12:57:47 2004 Subject: [Pythonmac-SIG] Announce: OSCON 2004 (Python 12) call for participation - proposal deadline February 9th! Message-ID: I realize many of you will have already seen this announcement on c.l.py, but the deadline is fast approaching and I would like to get some proposals this year that highlight Python on the Mac. If you have questions, respond directly to me, there is no need to post back to the list. ka --- Kevin Altis altis@semi-retired.com ------------------------------------------------------------ 2004 O'Reilly Open Source Convention Call for Participation: Opening the Future: Discover, Develop, Deliver http://conferences.oreillynet.com/os2004/ The O'Reilly Open Source Convention (OSCON) will be held July 26-30, 2004 at the Portland Marriott Downtown in Portland, OR. Proposals Submission Information--Deadline: February 9, 2004 http://conferences.oreillynet.com/cs/os2004/create/e_sess Sebastopol, CA--"There is an upheaval in the open source landscape, particularly Linux, and the corporate landscape is changing too," observes Tim O'Reilly, founder and CEO of O'Reilly & Associates. Economic pressures and legal battles have combined to push open source topics to the front burner as companies, institutions, and governments of every size make technology decisions. O'Reilly, long a vocal open source advocate, brings together open source influencers, early adopters, technology activists, developers, and business leaders to evaluate and debate the evolving open source landscape at OSCON, the annual O'Reilly Open Source Convention. The 2004 O'Reilly Open Source Convention, to be held in Portland, OR from July 26-30, is now accepting proposals delving into topics that matter most to the entire open source community, which includes new--and perhaps unexpected--players. "OSCON provides an analysis of what's happening now and what may come--what will affect the future landscape. This convention brings together projects in a way that other conferences don't. We're able to cover a broad range of topics in a deep, coherent way," says OSCON program chair Nathan Torkington. "It's not just about trimming costs at large companies, it's about collaborating and innovating our way into the next big thing. This convention is like a radar. It's a mix of what you'll be doing as soon as you get back to your desk and what you'll be doing differently in six months." The keynote speakers for the next OSCON exemplify the event's wide-ranging mix: Freeman, George, and Esther Dyson, presenting a joint keynote address; Robert Lefkowitz, who was one of OSCON 2003's most thought-provoking speakers; Milton Ngan of Weta Digital, the company that created the digital effects for "The Lord of the Rings" films; and Tim O'Reilly. Other influential open source leaders will come to OSCON to accept the first Open Source Awards, produced by the Open Source Institute (OSI) and ZDNet (winners will be announced in stages during the winter and spring of 2004). Proposals Submission Information--Deadline: February 9, 2004 http://conferences.oreillynet.com/cs/os2004/create/e_sess Individuals and companies interested in making session or tutorial presentations, or participating in panel discussions, are invited to submit proposals. Presentations by marketing staff or with a marketing focus will not be accepted; neither will submissions made by anyone other than the proposed speaker. Session presentations are 45 or 90 minutes long, and tutorials are either a half-day (three hours) or a full day (six hours). The theme for OSCON 2004 is "Opening the Future: Discover, Develop, Deliver." Proposals for sessions that help attendees discover new open source projects, develop new relationships, or deliver value to their employers and coworkers are especially welcome. Proposals that are not related to the theme are also encouraged, such as case studies showing how open source software solved thorny problems or replaced expensive closed source software, best practices for a tool or system, new features or modules, and fundamental skills. The tracks and conferences running in parallel at the convention include: Linux - Management, security, administration, configuration - Desktop, server farm, back office, personal productivity tools, development PHP Conference 4 - Unix, Windows, Apache, and beyond - New developments, security, case studies, large-scale applications development, best practices The Python 12 Conference - Python and Zope - Using the latest modules, software engineering, case studies Perl Conference 8 - Perl 5, Perl 6, Parrot, mod_perl - Useful modules, software development tips, developing for Parrot and Perl 6 MySQL and PostgreSQL - Configuration, migration, data warehousing, tuning - Clustering and replication, fallover, backups - Efficient client-side processing and query design Apache httpd, Java, and XML projects - Apache web server: 2.0, modules, configuration, performance tuning, security - Apache XML projects: Xerces, Xalan, Cocoon, FOP, SOAP, XML-RPC, XML Security - Apache and Open Source Java projects: Jakarta, Jserv, Avalon, Geronimo XML - XML Schemas, Transformations, Software, Services, and Standards - New standards, best practices, web services, IP issues around standards and schemas Applications - System administration tools, servers, back office utilities - GUI systems, user applications, productivity tools Ruby - Introductions to aspects of Ruby for people unfamiliar with the language - Power user talks for experienced Ruby programmers OSCON is the one place open source practitioners of every stripe can gather to learn useful skills, discover what's new, and "cross-fertilize" projects. Concludes Tim O'Reilly, "OSCON is for anyone interested in open source. It's the one event that brings together leaders of all the major open source projects not only with the hacker community but also with commercial software developers, business leaders, analysts, and even opponents of open source." From Chris.Barker at noaa.gov Mon Jan 26 14:27:36 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Jan 26 14:30:31 2004 Subject: [Pythonmac-SIG] Python bindings for DB XML In-Reply-To: <12C780EB-5027-11D8-97A6-000A95686CD8@redivi.com> References: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> <4B2AD036-4E5A-11D8-AA47-000393CBB978@reprocessed.org> <389C43B8-4E93-11D8-BCF3-000A95686CD8@redivi.com> <8C0EA43C-4FF6-11D8-AA47-000393CBB978@reprocessed.org> <40154BAB.1020108@noaa.gov> <12C780EB-5027-11D8-97A6-000A95686CD8@redivi.com> Message-ID: <40156A28.2010507@noaa.gov> Bob Ippolito wrote: > On Jan 26, 2004, at 12:17 PM, Chris Barker wrote: >> #!/usr/bin/env pythonX.X >> >> At the top of your file. Where X.X is the version of Python you want >> (python2.2, python2.3, etc.) > I agree with you, to a small extent, but this pythonX.X business that > you propose only matters to OS X 10.2 users. On 10.2, any way you slice > it, /usr/local/bin isn't in the default path anyways In theory, /usr/local/bin will never have vendor installed software, but I'm not so sure that I ALWAYS want a "local" version of a given program to be the default. > (if I remember > correctly), so the PATH thing is generally reasonable (especially > because Apple didn't use Python at all on 10.2.x). I'm really looking to the future here. no python version less than 10.2 has ever been an issue on OS-X. IF you look at the Redhat story, however, they built some tools on Python 1.5, and saw no reason to upgrade for quite few years (until RedHat 8, with Python2.2). If RedHat had just had the brains to put #!/usr/bin/python1.5 in their files there never would have been a problem. Instead, all of us RedHat users have to do it, which I think we should anyway. Apple may very well decide to keep using Python 2.3 when Python 3.5 is out. We have no way of predicting that, and we should not count on them doing anything in particular. > In any case, there's one tiny little problem with what you propose: It > doesn't do a damn thing for 10.3 users. It might when 2.4 (or whatever) comes out. > - can't accommodate for minor versions (f.ex Apple Python 2.3.0 and > your own Python 2.3.3) I suppose you could put python2.3.3 on your #! line. In theory, this shouldn't be neccesary, as minor versions are supposed to be compataible. If only Apple would eiother upgrade Pythonl, or rrelease the source to their extensions so we could upgrade it (they haven't doen that have they?) I would argue that Apple should do what RedHat should have done: put an explicit path to the python they want in their scripts that use python, including a minor version number. As they distribute both the python version and all the scripts that use it, they could do that, and it would solve a whole slew of problems. Of course, we have no control over what apple does so we'll just have to live with what they come up with. I don't have 10.3 installed yet...what do they put in theie #! lines? > - can't accommodate build parameters debug build vs normal build I'd say don't put a debug build on your path at all...you should only use that if you know you want it, i.e. use an explicit path > - can't accommodate "distribution mechanism" (fink vs vendor vs user > Python) This can be accomidated with an explicit path as well. As I think about it, perhaps OS-X is uniform enough that you could just use explicit paths all the time. On Linux, all the distros (and individual installations) are different enough that you're much better off using: #!/usr/bin/env, and letting the system find the executable for you. That may not be the case on OS-X > People who are getting version mismatch problems are on 10.3, not 10.2. > If you compiled an extension with Apple Python 2.2.0 on OS X 10.2, > there's almost no way that you could accidentally load it from Python > 2.3.x, and vice versa. That is certainly not true if you have a user > installation of Python on OS X 10.3. This entangling of different 2.3 pythons is way beyond me to comprehend. There really should be a way to get the right libraries once you get the right executable. It's certainly beyond the users realm to figure this out for each python program written. I don't think this is a problem on Linux, but then I'm not sure I've ever tried it either. Bob, do you have any other suggestions? -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 Jan 26 15:27:45 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 26 15:25:10 2004 Subject: [Pythonmac-SIG] Python bindings for DB XML In-Reply-To: <40156A28.2010507@noaa.gov> References: <41B944B8-4D8D-11D8-AA47-000393CBB978@reprocessed.org> <4B2AD036-4E5A-11D8-AA47-000393CBB978@reprocessed.org> <389C43B8-4E93-11D8-BCF3-000A95686CD8@redivi.com> <8C0EA43C-4FF6-11D8-AA47-000393CBB978@reprocessed.org> <40154BAB.1020108@noaa.gov> <12C780EB-5027-11D8-97A6-000A95686CD8@redivi.com> <40156A28.2010507@noaa.gov> Message-ID: <19BC63A8-503E-11D8-97A6-000A95686CD8@redivi.com> On Jan 26, 2004, at 2:27 PM, Chris Barker wrote: > Bob Ippolito wrote: >> On Jan 26, 2004, at 12:17 PM, Chris Barker wrote: >>> #!/usr/bin/env pythonX.X >>> >>> At the top of your file. Where X.X is the version of Python you want >>> (python2.2, python2.3, etc.) > >> I agree with you, to a small extent, but this pythonX.X business that >> you propose only matters to OS X 10.2 users. On 10.2, any way you >> slice it, /usr/local/bin isn't in the default path anyways > > In theory, /usr/local/bin will never have vendor installed software, > but I'm not so sure that I ALWAYS want a "local" version of a given > program to be the default. More often than not, you do. I would use shell aliases to point to /usr/bin if I wanted to (I don't have any yet). >> (if I remember correctly), so the PATH thing is generally reasonable >> (especially because Apple didn't use Python at all on 10.2.x). > > I'm really looking to the future here. no python version less than > 10.2 has ever been an issue on OS-X. IF you look at the Redhat story, > however, they built some tools on Python 1.5, and saw no reason to > upgrade for quite few years (until RedHat 8, with Python2.2). If > RedHat had just had the brains to put #!/usr/bin/python1.5 in their > files there never would have been a problem. Instead, all of us RedHat > users have to do it, which I think we should anyway. Yeah, I had that problem too. > Apple may very well decide to keep using Python 2.3 when Python 3.5 is > out. We have no way of predicting that, and we should not count on > them doing anything in particular. I'm not too worried about that. >> In any case, there's one tiny little problem with what you propose: >> It doesn't do a damn thing for 10.3 users. > > It might when 2.4 (or whatever) comes out. > >> - can't accommodate for minor versions (f.ex Apple Python 2.3.0 >> and your own Python 2.3.3) > > I suppose you could put python2.3.3 on your #! line. In theory, this > shouldn't be neccesary, as minor versions are supposed to be > compataible. If only Apple would eiother upgrade Pythonl, or rrelease > the source to their extensions so we could upgrade it (they haven't > doen that have they?) The python installation process doesn't use the minor version for install names. > I would argue that Apple should do what RedHat should have done: put > an explicit path to the python they want in their scripts that use > python, including a minor version number. As they distribute both the > python version and all the scripts that use it, they could do that, > and it would solve a whole slew of problems. Of course, we have no > control over what apple does so we'll just have to live with what they > come up with. I don't have 10.3 installed yet...what do they put in > theie #! lines? Apple uses /usr/bin/python - I don't see any reason to complain about that. In any case, there is only ONE Apple-written Python script on an OS X 10.3 system: /usr/libexec/fax/coverpage.py. Though a few other CoreGraphics-using scripts are in /Developer/Examples/Quartz/Python/ if you have Xcode installed. >> - can't accommodate build parameters debug build vs normal build > > I'd say don't put a debug build on your path at all...you should only > use that if you know you want it, i.e. use an explicit path Well, sure. I'll agree with that. >> - can't accommodate "distribution mechanism" (fink vs vendor vs >> user Python) > > This can be accomidated with an explicit path as well. As I think > about it, perhaps OS-X is uniform enough that you could just use > explicit paths all the time. On Linux, all the distros (and individual > installations) are different enough that you're much better off using: > > #!/usr/bin/env, and letting the system find the executable for you. > > That may not be the case on OS-X I think /usr/bin/env is going to universally find fink if you have their shell script running.. I'm pretty sure /sw/bin goes before /usr/local/bin and wherever else. I dunno, there's arguments to be made either way. #!/usr/bin/env is certainly not the right solution if you depend on non-standard extensions. >> People who are getting version mismatch problems are on 10.3, not >> 10.2. If you compiled an extension with Apple Python 2.2.0 on OS X >> 10.2, there's almost no way that you could accidentally load it from >> Python 2.3.x, and vice versa. That is certainly not true if you have >> a user installation of Python on OS X 10.3. > > This entangling of different 2.3 pythons is way beyond me to > comprehend. There really should be a way to get the right libraries > once you get the right executable. It's certainly beyond the users > realm to figure this out for each python program written. I don't > think this is a problem on Linux, but then I'm not sure I've ever > tried it either. > > Bob, do you have any other suggestions? The entangling of different 2.3 pythons is really all people have a problem with right now.. so far I've seen people have problems with: Apple Python 2.3 vs Fink Python (or fink libraries/compliers in general) Apple Python 2.3 vs Jaguar Python 2.3 ("oops, I meant to get the panther addons", vestige from 10.2, or didn't know better) Apple Python 2.3 vs User-Built 2.3.x (2.3.x fixes a bug that I need fixed, "I'm a python-dev'er") I think the biggest problem is that /Library/Python/2.3/ (or the user equiv) is used by any framework built Python 2.3.x. Bundles built for one are NOT going to necessarily be compatible with another (by default, they will most certainly NOT be compatible, because the load command in their mach-o header will point to the wrong framework). This problem in particular might be "solvable" by using -bundle_loader $PYTHON_EXECUTABLE instead of -framework Python when building bundles -- because in that case all you have to worry about is if their APIs are compatible not if they were built against the same build. I am not entirely sure if this works though, because the linker might not like the fact that all the required symbols are actually coming from dylibs, not the executable itself. I will have to try 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/20040126/05812d01/smime-0001.bin From listmail at gearyweb.com Tue Jan 27 00:29:48 2004 From: listmail at gearyweb.com (michael geary) Date: Tue Jan 27 00:29:32 2004 Subject: [Pythonmac-SIG] mod_python on Panther? Message-ID: Has anyone done this? The Apple version of Panther doesn't seem to have a file that mod_python wanted: libpython2.3.a. I found a version of this file in my /usr/local/src/panther2.3 directory, and when I copied that to my Apple Python directory and did ranlib on it, the compile/install of mod_python seemed to go fine. However, I now get: Fatal Python error: Interpreter not initialized (version mismatch?) in my Apache error log when I try to run a .py file over my webserver. I'm compiling a source version of 2.3 to my /usr/local root to see if that will do anything. Any ideas or tips? Thanks, michael From peter.maas at mplusr.de Tue Jan 27 03:10:05 2004 From: peter.maas at mplusr.de (Peter Maas) Date: Tue Jan 27 03:10:22 2004 Subject: [Pythonmac-SIG] PackageManager tarfile MacOS9 Message-ID: <40161CDD.5040906@mplusr.de> Hi, I'm a Mac newbie but have some experience with Python (Win32, Linux). I tried to create a Tkinter app with Python 2.3-MacOS9. As Python-2.3 no longer includes Tkinter I tried to install it with the Package- Manager. But I got an import error telling that module tarfile doesn't work for MacOS9. Has anybody an advice how to proceed? Should I use Python 2.2-MacOS9? Thanks for your help. Mit freundlichen Gruessen, Peter Maas -- ------------------------------------------------------------------- Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24 Tel +49-241-93878-0 Fax +49-241-93878-20 eMail peter.maas@mplusr.de ------------------------------------------------------------------- From gstein at lyra.org Tue Jan 27 03:27:11 2004 From: gstein at lyra.org (gstein@lyra.org) Date: Tue Jan 27 03:20:43 2004 Subject: [Pythonmac-SIG] received your email Message-ID: <200401270827.i0R8RBlj027166@nebula.lyra.org> Hi, [ Re: Re[4]: very cool photo PRIVATE ] I have received your email, but it may take a while to respond. I'm really sorry to have to hook up this auto-responder, as it is so impersonal. However, I get a lot of email every day and find it very difficult to keep up with it. Please be patient while I try to get to your message. Please feel free to resend your message if you think I've missed it. I'll always respond to personal email first. If your email is regarding some of the software that I work on (if you have questions, comments, suggestions, etc), then please resend it to the appropriate mailing list: mod_dav WebDAV ViewCVS Subversion edna Thank you! Cheers, -g -- Greg Stein, http://www.lyra.org/ From Jack.Jansen at cwi.nl Tue Jan 27 07:33:01 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jan 27 07:32:46 2004 Subject: [Pythonmac-SIG] PackageManager tarfile MacOS9 In-Reply-To: <40161CDD.5040906@mplusr.de> References: <40161CDD.5040906@mplusr.de> Message-ID: On 27-jan-04, at 9:10, Peter Maas wrote: > I'm a Mac newbie but have some experience with Python (Win32, Linux). > I tried to create a Tkinter app with Python 2.3-MacOS9. As Python-2.3 > no longer includes Tkinter I tried to install it with the Package- > Manager. But I got an import error telling that module tarfile doesn't > work for MacOS9. Has anybody an advice how to proceed? Should I use > Python 2.2-MacOS9? Thanks for your help. It was a valiant attempt of you to try Package Manager with MacPython-OS9, but it won't work. First of all, Tcl/Tk was never ported to the Carbon model, and MacPython-OS9 2.3 is Carbon-only, so Tkinter will never work in MacPython-OS9 2.3. If you really need Tkinter, you have to get MacPython 2.2.3 and use it only in the Classic execution mode. Second, Package Manager doesn't work on OS9, it is OSX-only. Part of the problem is the tarfile module, but there are more problems. None that can't be solved, but noone did the work. And if you got it to work there wouldn't be any package database to download from. -- 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 garbanzito at mac.com Tue Jan 27 13:58:48 2004 From: garbanzito at mac.com (steve harley) Date: Tue Jan 27 13:58:56 2004 Subject: [Pythonmac-SIG] advanced newbie questions Message-ID: i'm learning Python, evaluating it for replacing a workflow that is now half in Visual FoxPro, half in UserLand Frontier (running in Virtual PC & Classic respectively under Mac OS X 10.3.2).. given that i find both of those environments very fluid and powerful, but dislike having to use VPC and Classic, Python looks very promising.. it has a coding feel much like Frontier, though i miss coding in an outliner; has anyone found a way to do this for Python, which is so obviously suited? since the Frontier part of this workflow heavily exercises the AE capabilities of publishing apps, i was curious to see how Python stacked up.. i read through the recent thread on abstracting the AE functionality, and a few other threads, and got the impression that there are multiple paths, and all are essentially in beta.. by the way, coming from strong familiarity with Mac scripting, that thread really helped me grasp the richness of Python, as it touched on several under-the-hood aspects that intro texts ignore anyhow, AppScript looked like the easiest transition from Frontier's object model, so i got the latest version and installed it.. i immediately found a dependency on launchservices.py, so i installed the latest SourceForge version now i'm stuck just instantiating an application object.. test.py contains: import AppScripting as AS Finder = AS.app ("Finder") and gives this error when i run it: % pythonw test.py Traceback (most recent call last): File "test.py", line 2, in ? Finder = AS.app ("Finder") File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/AppScripting/Main.py", line 141, in app targetDesc, aeteList, aeTable = _prepareApp(appPathOrName) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/AppScripting/Main.py", line 122, in _prepareApp appPath = _fullPathToApp(appPathOrName) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/AppScripting/Main.py", line 18, in _fullPathToApp return LaunchServices.FindApplicationPath(name=appPathOrName) AttributeError: 'module' object has no attribute 'FindApplicationPath' seeing a path problem, i tried "/Applications/Finder.app" and got a somewhat similar error: % pythonw test.py Traceback (most recent call last): File "test.py", line 2, in ? Finder = AS.app ("/Applications/Finder.app") File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/AppScripting/Main.py", line 141, in app targetDesc, aeteList, aeTable = _prepareApp(appPathOrName) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/AppScripting/Main.py", line 123, in _prepareApp targetDesc = AEInterface.establishConnection(appPath) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/AppScripting/AEInterface.py", line 81, in establishConnection targetDesc = _makeAEAddressDesc(appPath) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/AppScripting/AEInterface.py", line 32, in _makeAEAddressDesc return _makeAddressDescByAppSig(appPath) # TO DO: other ways of creating AEAddressDescs File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/AppScripting/AEInterface.py", line 37, in _makeAddressDescByAppSig sig = LS.GetInfoForPath(appPath, LS.LSRequestedInfo.kLSRequestTypeCreator)['creator'] AttributeError: 'module' object has no attribute 'GetInfoForPath' in both cases it looks like the problem is in a LaunchServices call.. can someone tell me what's going wrong here? should i be using some kind of package management tool? assuming i can get past this i have some other questions: i see some people have trouble getting the dictionary from iTunes.. is AppScript able to do this? if not which AE package should i use? (i'm using a small iTunes-related project as an evaluation tool) i need some practical advice for persistent storage needs.. unfortunately my workflow depends heavily on both relational and object paradigms (SQL in Visual FoxPro, object databases in Frontier; both *highly* integrated) for relational purposes, easiest for me would be SQL back end; bearing in mind i'm used to completely integrated, inline SQL, with little fiddling or setup required, are there any gotchas or strong positives (from the Python on Mac OS X perspective) for MySQL or Postgres? is there some other approach which would let me do complex joins and many-to-many relations? for object storage, i get the impression there are various "object serialization" approaches.. since i'd probably eventually use PyObjC to build interfaces, i'd also consider a Cocoa-based approach.. from either the pure Python or Cocoa sides, is there one that stands out? what are the performance considerations? (most of my objects are probably smaller than 10KB) for either of these storage needs, are there good abstraction libraries so that i could switch storage types later if needed? thanks very much From bob at redivi.com Tue Jan 27 14:46:42 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 27 14:44:03 2004 Subject: [Pythonmac-SIG] advanced newbie questions In-Reply-To: References: Message-ID: <882F8381-5101-11D8-9EDD-000A95686CD8@redivi.com> On Jan 27, 2004, at 1:58 PM, steve harley wrote: > i'm learning Python, evaluating it for replacing a workflow that is > now half in Visual FoxPro, half in UserLand Frontier (running in > Virtual PC & Classic respectively under Mac OS X 10.3.2).. given that > i find both of those environments very fluid and powerful, but dislike > having to use VPC and Classic, Python looks very promising.. it has a > coding feel much like Frontier, though i miss coding in an outliner; > has anyone found a way to do this for Python, which is so obviously > suited? We don't have an outliner. I've never used one (and I'm not willing to install Classic :) so if you could explain what an outliner does, how it works, and what you like most about it.. maybe we can incorporate that sort of thing into a future IDE for MacPython. > since the Frontier part of this workflow heavily exercises the AE > capabilities of publishing apps, i was curious to see how Python > stacked up.. i read through the recent thread on abstracting the AE > functionality, and a few other threads, and got the impression that > there are multiple paths, and all are essentially in beta.. by the > way, coming from strong familiarity with Mac scripting, that thread > really helped me grasp the richness of Python, as it touched on > several under-the-hood aspects that intro texts ignore They're not even beta quality, don't try anything complicated yet. Or at least, if you do, don't spend too much time trying to make it work - because it probably won't :) > anyhow, AppScript looked like the easiest transition from Frontier's > object model, so i got the latest version and installed it.. i > immediately found a dependency on launchservices.py, so i installed > the latest SourceForge version The LaunchServices that AppScripting depends on is actually mine, not the newer standard one. You can get that from http://undefined.org/python/#LaunchServices Your best bet is just to wait until AppScripting is fixed, or wait for the new version of aeve. > i see some people have trouble getting the dictionary from iTunes.. is > AppScript able to do this? if not which AE package should i use? (i'm > using a small iTunes-related project as an evaluation tool) AppScripting is not able to do this, due to a bug in the way it tries to get the OSA terminology. aeve does not have this problem, but it has a different suite of bugs. I'm working on a new version of aeve that encompasses all of AppScripting's features and then some, but don't hold your breath waiting for it, it's probably another few weeks out. > i need some practical advice for persistent storage needs.. > unfortunately my workflow depends heavily on both relational and > object paradigms (SQL in Visual FoxPro, object databases in Frontier; > both *highly* integrated) > > for relational purposes, easiest for me would be SQL back end; bearing > in mind i'm used to completely integrated, inline SQL, with little > fiddling or setup required, are there any gotchas or strong positives > (from the Python on Mac OS X perspective) for MySQL or Postgres? is > there some other approach which would let me do complex joins and > many-to-many relations? Don't use MySQL, use PostgreSQL. PostgreSQL has a better license, supports more SQL, and the Python interface actually works properly. MySQL loses on all three counts there. There are other SQL databases that run in-process and have Python interfaces that might be of interest (but I can't think of their names), ZODB is a really good transactional versioned object database, and Metakit is sort of a hybrid between relational and object database. > for object storage, i get the impression there are various "object > serialization" approaches.. since i'd probably eventually use PyObjC > to build interfaces, i'd also consider a Cocoa-based approach.. from > either the pure Python or Cocoa sides, is there one that stands out? > what are the performance considerations? (most of my objects are > probably smaller than 10KB) Object serialization is a problem if you're mixing PyObjC and Python classes.. you have to decide one way or the other as to which kind of objects you're going to serialize. In the only-python route you can use regular 'ol pickle and possibly shelve or something more advanced like ZODB.. otherwise you're using plists with the Cocoa classes. It's probably even possible to add pickle integration to the plist stuff, by having Python objects support the coding protocols -- or add __reduce__ functionality to Cocoa classes to allow them to be pickled. I don't think either of these has been looked into, though. > for either of these storage needs, are there good abstraction > libraries so that i could switch storage types later if needed? Relational databases in Python all use the DB-API spec, so switching can be as simple as changing the module and connect string. There are higher level things you can shim on top, such as PEAK, but you probably don't need them. Learn Python first, then worry about the big frameworks that make it easier for large applications :) The best way to do it is to figure out what you need to do first, before getting mixed up in relational vs object vs hybrid databases and picking a particular product to do it with. SQL certainly feels like a kludge after a while with ZODB or MetaKit, because you can eschew the whole ORM layer (object-relational mapping) and Just Use Objects. Python is a terse enough language to write queries yourself, working with the native object structures, and can even be faster than SQL (if a query doesn't lend itself to a relational representation, or if you're smarter than the SQL database's optimizer). -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/20040127/c87dae9f/smime.bin From njriley at uiuc.edu Tue Jan 27 15:49:18 2004 From: njriley at uiuc.edu (Nicholas Riley) Date: Tue Jan 27 15:49:27 2004 Subject: [Pythonmac-SIG] advanced newbie questions In-Reply-To: References: Message-ID: <20040127204918.GA24268@uiuc.edu> On Tue, Jan 27, 2004 at 11:58:48AM -0700, steve harley wrote: > i'm learning Python, evaluating it for replacing a workflow that is now > half in Visual FoxPro, half in UserLand Frontier (running in Virtual PC > & Classic respectively under Mac OS X 10.3.2).. given that i find both > of those environments very fluid and powerful, but dislike having to > use VPC and Classic, Python looks very promising.. it has a coding feel > much like Frontier, though i miss coding in an outliner; has anyone > found a way to do this for Python, which is so obviously suited? I wish. There are a few editors based on Scintilla which provide code folding, but it's nothing like Frontier's outline-based editing. I really miss Frontier, but at least on the Mac, current versions of Frontier/Radio are buggy and poorly maintained (if at all). I've moved off it, mainly to Python. A few years ago, around Python 1.5.2/2.0, I wrote an application which was half in Python, using ZODB and Tkinter, and half in Radio (back when it was free), using XML-RPC for communication. The main reason for this was that I couldn't find a scriptable outliner for Python half as good as Radio's. Unfortunately, nothing has changed since then. > for relational purposes, easiest for me would be SQL back end; bearing > in mind i'm used to completely integrated, inline SQL, with little > fiddling or setup required, are there any gotchas or strong positives > (from the Python on Mac OS X perspective) for MySQL or Postgres? is > there some other approach which would let me do complex joins and > many-to-many relations? Two Python apps I'm currently maintaining use Metakit and MS SQL Server for data storage. Obviously the latter is not a good choice for the Mac - I am using ADODBAPI on Windows, in fact :). Python has a standard, easy-to-use database API; I hope the multitude of bugs in ADODAPI I've found aren't shared by the interfaces to PostgreSQL. (MySQL is a bad choice overall, especially with the recent licensing changes). Metakit is a relational-ish database with the ease of construction of an object database. It doesn't really lend itself to the hierarchical design you'd find in Frontier's ODB, but it's good for small to medium size data sets (since it uses memory mapping for speed) and has a great Python binding on which I've done some work. > for object storage, i get the impression there are various "object > serialization" approaches.. since i'd probably eventually use PyObjC to > build interfaces, i'd also consider a Cocoa-based approach.. from > either the pure Python or Cocoa sides, is there one that stands out? > what are the performance considerations? (most of my objects are > probably smaller than 10KB) If you choose to go with ZODB, be careful. ZODB's paradigm is much closer to Frontier's ODB: it's extremely hierarchical and doesn't really like to make arbitrary connections, unlike true object-oriented databases (e.g. ObjectStore). But by storing objects rather than a limited set of data types - I like to think of Frontier's ODB as what the Mac Resource Manager would be like if it became a database - it's not so hard to corrupt your data store in subtle and confusing ways. Just don't expect it to handle indexing well. > for either of these storage needs, are there good abstraction libraries > so that i could switch storage types later if needed? There are a few, but I haven't found any higher-level database abstraction layers in Python robust enough to use. You might also consider Squeak Smalltalk (www.squeak.org). I learned Frontier before Smalltalk, and Smalltalk environments are the closest I've found to the immersive development experience of Frontier. GLORP (www.glorp.org) is an object-relational persistence layer which I used in a much more primitive version, and it looks pretty decent now despite the version number. GLORP works with Oracle and PostgreSQL. -- =Nicholas Riley | From Chris.Barker at noaa.gov Tue Jan 27 16:07:48 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Jan 27 16:07:59 2004 Subject: [Pythonmac-SIG] advanced newbie questions In-Reply-To: References: Message-ID: <4016D324.2060503@noaa.gov> steve harley wrote: > though i miss coding in an outliner; has anyone found a way to do this for Python, which is so obviously suited? Check out Leo: http://leo.sourceforge.net/ It uses Tkinter, so I'm not sure how well it runs on OS-X at the moment. Sorry, I'm not much use with your other questions. -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 peter.maas at mplusr.de Wed Jan 28 04:31:19 2004 From: peter.maas at mplusr.de (Peter Maas) Date: Wed Jan 28 04:31:38 2004 Subject: [Pythonmac-SIG] PackageManager tarfile MacOS9 In-Reply-To: References: <40161CDD.5040906@mplusr.de> Message-ID: <40178167.3030205@mplusr.de> Jack Jansen wrote: > First of all, Tcl/Tk was never ported to the Carbon model, and > MacPython-OS9 2.3 is Carbon-only, so Tkinter will never work in > MacPython-OS9 2.3. Is there any GUI library that works on Win32 and Mac and is compatible with MacPython-OS9 2.3? Im afraid the answer is no. > If you really need Tkinter, you have to get MacPython 2.2.3 and use it > only in the Classic execution mode. So a MacOS9-Python-2.2 app for wouldn't run as smooth on MacOSX as a MacOS9-Python-2.3 app, right? Mit freundlichen Gruessen, Peter Maas -- ------------------------------------------------------------------- Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24 Tel +49-241-93878-0 Fax +49-241-93878-20 eMail peter.maas@mplusr.de ------------------------------------------------------------------- From mjb at uma.pt Wed Jan 28 05:31:09 2004 From: mjb at uma.pt (Michael J. Barber) Date: Wed Jan 28 05:31:05 2004 Subject: [Pythonmac-SIG] advanced newbie questions In-Reply-To: Message-ID: <1682EF88-517D-11D8-96AC-0050E4794D0F@uma.pt> On Tuesday, Jan 27, 2004, at 18:58 Europe/Lisbon, steve harley wrote: > promising.. it has a coding feel much like Frontier, though i miss > coding in an outliner; has anyone found a way to do this for Python, > which is so obviously suited? > There are a few possibilities worth considering. However, I've never used Frontier, so I can't make any direct comparisons. Not actually an outliner, but jEdit has decent line folding. I used it for Python programming for a while, and the folding was quite nice. As I understand it, both vim and emacs do folding as well, but I've little or no experience using folding with either of them. OmniOutliner is scriptable enough that you could probably get it to serve. I've toyed with the idea, but not much more than that. Converting an outline into a Python program in a text file would be dead simple. Chris Barker mentioned Leo. In principle, Leo is just the sort of thing you're looking for. Last time I tried it, though, I was pretty unhappy with it -- it was jarringly different from other apps, and had a variety of interface bugs. That was more the fault of AquaTk than of Leo itself. Both AquaTk and Leo have improved since then, so I should probably try it again. Since you currently use a mix of a Windows app in VPC and a classic app running in Mac OS X, you're clearly a lot more tolerant of interface inconsistencies than I am, so maybe it wouldn't be a problem. Definitely worth a try. From Jack.Jansen at cwi.nl Wed Jan 28 06:50:35 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Jan 28 06:51:32 2004 Subject: [Pythonmac-SIG] PackageManager tarfile MacOS9 In-Reply-To: <40178167.3030205@mplusr.de> References: <40161CDD.5040906@mplusr.de> <40178167.3030205@mplusr.de> Message-ID: <2F5CBE9D-5188-11D8-A4CD-000A958D1666@cwi.nl> On 28-jan-04, at 10:31, Peter Maas wrote: > Jack Jansen wrote: >> First of all, Tcl/Tk was never ported to the Carbon model, and >> MacPython-OS9 2.3 is Carbon-only, so Tkinter will never work in > > MacPython-OS9 2.3. > > Is there any GUI library that works on Win32 and Mac and is compatible > with MacPython-OS9 2.3? Im afraid the answer is no. Some work was done on porting wxPython to MacPython-OS9, but I haven't heard anything about it for a long time. So, there's a good chance that the developers lost interest... >> If you really need Tkinter, you have to get MacPython 2.2.3 and use >> it only in the Classic execution mode. > > So a MacOS9-Python-2.2 app for wouldn't run as smooth on MacOSX as a > MacOS9-Python-2.3 app, right? Tkinter does not run smoothly on MacOS9. A couple of years ago, when Scriptics started, Mac development of Tcl/Tk was basically halted, and Tcl/Tk got worse and worse on MacOS9. So don't expect a miracle from Tkinter on MacOS9. But your script will run reasonably smoothly on MacOSX, with MacPython 2.3. Tcl/Tk on OSX is in a pretty good shape, still not perfect but definitely usable and continuing to improve. -- 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 Chris.Barker at noaa.gov Wed Jan 28 12:54:57 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Jan 28 12:55:05 2004 Subject: [Pythonmac-SIG] PackageManager tarfile MacOS9 In-Reply-To: <2F5CBE9D-5188-11D8-A4CD-000A958D1666@cwi.nl> References: <40161CDD.5040906@mplusr.de> <40178167.3030205@mplusr.de> <2F5CBE9D-5188-11D8-A4CD-000A958D1666@cwi.nl> Message-ID: <4017F771.8000903@noaa.gov> Jack Jansen wrote: > Some work was done on porting wxPython to MacPython-OS9, but I haven't > heard anything about it for a long time. So, there's a good chance that > the developers lost interest... Probably true. Robin Dunn got some funding to get wxPython working on OS-X, and that's what got it really usable. There is no such funding for OS-9. However, C++ wxWindows still works pretty well on OS-9, so it shouldn't be all that much work to get wxPython working there too. Someone has to do it, however, and frankly, it's a dead end. I can't see why anyone would want to put a lot of work into a project that is pretty much guaranteed not to be used in a few years. It would probably be less work to convert whatever you're doing to OS-X, and you'd get a lot of other benefits as well. -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 grobinson at transpose.com Wed Jan 28 15:12:51 2004 From: grobinson at transpose.com (Gary Robinson) Date: Wed Jan 28 15:12:50 2004 Subject: [Pythonmac-SIG] Installing pychecker Message-ID: I've been doing quite a bit of python coding under OS X, but I'm still pretty unsophisticated about a lot of the "under the covers" stuff about installers, etc. So to aid in my understanding, I am asking this question here rather than just kluging up some sort of solution for myself. I ran sudo python setup.py install and the setup script did a bunch of stuff and terminated normally. now, the pychecker instructions say: > To use PyChecker, pass options and the python source files (or packages) you > want to check on the command line: > > pychecker file1.py file2.py ... > > pychecker and pychecker.bat will only exist if pychecker has been installed. > To install, do: python setup.py install Now, I have done the install. But if I type into the Terminal: pychecker somefile.py I get an error because it can't find pychecker. So, I did some searching. I found that there is a pychecker at the following location: /System/Library/Frameworks/Python.framework/Versions/2.3/bin/pychecker and this pychecker does do what pychecker is supposed to do. But, I can't just type "pychecker" in on the command line as the instructions say I should be able to do after installing it. If I do "echo $PATH" the directory containing pychecker is not on the list. So of course, that's why pychecker isn't found. But... 1) Why do the instructions say I'll be able to run it from the command line after running setup.py, if in fact, after running an apparently successful install on OS X, you can't do so? Is it because under OS X pytchecker ends up in an obscure "frameworks" directory whereas on other OS's it ends up in a directory that's already on the PATH? 2) What is the standard thing to do? Should I add that directory to my PATH? Or should I add a hard link called "pychecker" from another directory that IS in my PATH? Or is there some other, obvious, standard way of handling it that a sophisticated user is supposed to understand? Thanks in advance for any help! --Gary -- Putting http://wecanstopspam.org in your email helps it pass through overzealous spam filters. Gary Robinson CEO Transpose, LLC grobinson@transpose.com 207-942-3463 Company: http://www.transpose.com Blog: http://www.garyrobinson.net From bob at redivi.com Wed Jan 28 15:29:54 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 28 15:27:13 2004 Subject: [Pythonmac-SIG] Installing pychecker In-Reply-To: References: Message-ID: On Jan 28, 2004, at 3:12 PM, Gary Robinson wrote: > I've been doing quite a bit of python coding under OS X, but I'm still > pretty unsophisticated about a lot of the "under the covers" stuff > about > installers, etc. So to aid in my understanding, I am asking this > question > here rather than just kluging up some sort of solution for myself. > > I ran > > sudo python setup.py install > > > and the setup script did a bunch of stuff and terminated normally. > > now, the pychecker instructions say: > >> To use PyChecker, pass options and the python source files (or >> packages) you >> want to check on the command line: >> >> pychecker file1.py file2.py ... >> >> pychecker and pychecker.bat will only exist if pychecker has been >> installed. >> To install, do: python setup.py install > > Now, I have done the install. But if I type into the Terminal: > > pychecker somefile.py > > I get an error because it can't find pychecker. > > So, I did some searching. I found that there is a pychecker at the > following > location: > > /System/Library/Frameworks/Python.framework/Versions/2.3/bin/pychecker > > and this pychecker does do what pychecker is supposed to do. > > But, I can't just type "pychecker" in on the command line as the > instructions say I should be able to do after installing it. > > If I do "echo $PATH" the directory containing pychecker is not on the > list. > So of course, that's why pychecker isn't found. But... > > 1) Why do the instructions say I'll be able to run it from the command > line > after running setup.py, if in fact, after running an apparently > successful > install on OS X, you can't do so? Is it because under OS X pytchecker > ends > up in an obscure "frameworks" directory whereas on other OS's it ends > up in > a directory that's already on the PATH? The documentation has no idea that your scripts directory is so far away from your PATH, it surely wasn't written for framework build OS X users. > 2) What is the standard thing to do? Should I add that directory to my > PATH? > Or should I add a hard link called "pychecker" from another directory > that > IS in my PATH? Or is there some other, obvious, standard way of > handling it > that a sophisticated user is supposed to understand? Add it to you PATH, make a symlink, or use "python setup.py install --install-scripts=/usr/local/bin" .. there's no standard way to do it, I'm not sure this has even been discussed yet (recently?). I've actually been thinking about changing the --install-scripts parameter to /usr/local/bin for my PackageManager repository. -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/20040128/6371e129/smime.bin From Chris.Barker at noaa.gov Wed Jan 28 15:59:59 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Jan 28 16:00:10 2004 Subject: [Pythonmac-SIG] Installing pychecker In-Reply-To: References: Message-ID: <401822CF.7000407@noaa.gov> Bob Ippolito wrote: >> 2) What is the standard thing to do? Should I add that directory to my >> PATH? >> Or should I add a hard link called "pychecker" from another directory >> that > Add it to you PATH, Don't add it to your PATH, that's jsut not the "unix way". If you do that, eventually you'll have an absurdly lonbg PATH from all sorts of stuff. make a symlink, Very good idea, this is the standard approach. Don't make a hard link. With a sym link, you can upgrade pychecker and the symlink will point to the new one, not the old one, as a hard link will do. or use "python setup.py install > --install-scripts=/usr/local/bin" If this works, it's a good option > I'm not sure this has even been discussed yet (recently?). I've > actually been thinking about changing the --install-scripts parameter to > /usr/local/bin for my PackageManager repository. I think that's a great idea. Interestingly enough, on Linux, the pychecker setup.py installs the script in usr/local/bin. Someone who understands distutils could probably fix this on OS-X very easily. -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 Jan 28 16:14:31 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 28 16:35:42 2004 Subject: [Pythonmac-SIG] Installing pychecker In-Reply-To: <401822CF.7000407@noaa.gov> References: <401822CF.7000407@noaa.gov> Message-ID: On Jan 28, 2004, at 3:59 PM, Chris Barker wrote: > Bob Ippolito wrote: >>> 2) What is the standard thing to do? Should I add that directory to >>> my PATH? >>> Or should I add a hard link called "pychecker" from another >>> directory that > >> Add it to you PATH, > > Don't add it to your PATH, that's jsut not the "unix way". If you do > that, eventually you'll have an absurdly lonbg PATH from all sorts of > stuff. Either you have an absurdly long PATH, or an absurdly cluttered /usr/local/bin. In any case, I personally use the PATH option because if it's not Python, it's already in my path elsewhere.. It's just easier, since I don't have to specify distutils arguments or make symlinks. > make a symlink, > > Very good idea, this is the standard approach. Don't make a hard link. > With a sym link, you can upgrade pychecker and the symlink will point > to the new one, not the old one, as a hard link will do. > > or use "python setup.py install >> --install-scripts=/usr/local/bin" > > If this works, it's a good option It should, haven't tried it. It's there, according to "python setup.py --help install". >> I'm not sure this has even been discussed yet (recently?). I've >> actually been thinking about changing the --install-scripts parameter >> to /usr/local/bin for my PackageManager repository. > > I think that's a great idea. > > Interestingly enough, on Linux, the pychecker setup.py installs the > script in usr/local/bin. Someone who understands distutils could > probably fix this on OS-X very easily. On every (POSIX?) platform, distutils installs scripts to a default path of $PREFIX/bin -- in order to get lib and such in the right place on OS X, $PREFIX is inside the framework. AFAIK, there is no code in distutils that has any idea that it's working with this sort of build. -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/20040128/9c5b8b67/smime.bin From Jack.Jansen at cwi.nl Wed Jan 28 17:30:55 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Jan 28 17:31:05 2004 Subject: [Pythonmac-SIG] Installing pychecker In-Reply-To: References: <401822CF.7000407@noaa.gov> Message-ID: I added an FAQ entry on the distutils-installed script problems. -- 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 garbanzito at mac.com Thu Jan 29 01:21:09 2004 From: garbanzito at mac.com (steve harley) Date: Thu Jan 29 01:21:16 2004 Subject: [Pythonmac-SIG] advanced newbie questions In-Reply-To: <882F8381-5101-11D8-9EDD-000A95686CD8@redivi.com> References: <882F8381-5101-11D8-9EDD-000A95686CD8@redivi.com> Message-ID: <54499140-5223-11D8-AF5A-000393C5ED50@mac.com> On 27 Jan 2004, at 12:46 PM, Bob Ippolito wrote: > We don't have an outliner. I've never used one (and I'm not willing > to install Classic :) so if you could explain what an outliner does, > how it works, and what you like most about it.. maybe we can > incorporate that sort of thing into a future IDE for MacPython. many IDEs already use outlining concepts at a high level.. what i miss most, though, is the block-level folding and reorganizing of code.. outlining is of course also widely used outside of programming.. if you want a hands on experience with a very sweet outliner UI, download the OmniOutliner demo.. imagine what it would be like if it were oriented to coding -- syntax-coloring, commenting commands, debugging tools, etc.. (in response to Michael Barber's suggestion, i looked at scripting OmniOutliner to support Python code.. it's feasible, but i doubt it would integrate tightly enough to be worth the effort) if you want more on outliners in general on Mac OS X, here's a good article: you'll see a comment by me below the article which describes what i think are Frontier's advantages.. Python seems a natural for outlining because, like Frontier, there's a precise semantic meaning for indentation, and also like Fronter, one could merge coding with object browsing thanks to Chris Barker, i would say Leo has some of what i'm talking about: i got it running, and it's impressive -- very rich outlining experience, and has syntax coloring ... though it doesn't seem to want to treat outline nodes as code -- just the "body" under each node -- too bad! it's intriguing, but tk is very primitive Aqua, it's missing way too many UI bells and whistles like command-key, drag & drop, wheel scrolling, window switching, etc.. with a real Mac OS X interface, Leo could be amazing in trying to figure out what Leo was trying to do for me, i came across this article which opened up the subject a lot more broadly: > The LaunchServices that AppScripting depends on is actually mine, not > the newer standard one. You can get that from > http://undefined.org/python/#LaunchServices cool, this will at least let me experiment a bit, and encourage me to decouple my code from whatever i use for Apple Events > Don't use MySQL, use PostgreSQL. PostgreSQL has a better license, > supports more SQL, and the Python interface actually works properly. > MySQL loses on all three counts there. what i didn't know yet was the Python part -- thanks > The best way to do it is to figure out what you need to do first, > before getting mixed up in relational vs object vs hybrid databases > and picking a particular product to do it with. SQL certainly feels > like a kludge after a while with ZODB or MetaKit, well, i'm converting a workflow that uses each paradigm separately, and i'm looking for the shortest route, since i have to justify it all to a client.. i'd love to learn something better than SQL, but there are rafts of complex queries in my existing code i'd rather not rewrite.. this feedback is leading me toward using Postgres for the relational side, and ZODB or MetaKit for the rest (though i'll get my head around pickle just to see if it might work), perhaps dropping the SQL later thanks to everyone for their helpful comments.. plenty to chew on! From Chris.Barker at noaa.gov Thu Jan 29 12:29:25 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Jan 29 12:29:36 2004 Subject: [Pythonmac-SIG] advanced newbie questions In-Reply-To: <54499140-5223-11D8-AF5A-000393C5ED50@mac.com> References: <882F8381-5101-11D8-9EDD-000A95686CD8@redivi.com> <54499140-5223-11D8-AF5A-000393C5ED50@mac.com> Message-ID: <401942F5.9070309@noaa.gov> steve harley wrote: > thanks to Chris Barker, i would say Leo has some of what i'm talking > about: > > > it's intriguing, but tk is very primitive Aqua, it's missing > way too many UI bells and whistles like command-key, drag & drop, wheel > scrolling, window switching, etc.. with a real Mac OS X interface, Leo > could be amazing From what I understand, Edward Ream is re-working Leo to be more GUI-independent, the first step being writing a wxPython GUI for it. That should improve things a lot, and if he realy does make it GUI independent, maybe someone would write a Cocoa GUI for it, and that could take it the final step to "Real Mac App" -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 gandreas at delver.com Thu Jan 29 23:37:07 2004 From: gandreas at delver.com (Glenn Andreas) Date: Thu Jan 29 23:37:24 2004 Subject: [Pythonmac-SIG] advanced newbie questions In-Reply-To: <20040127204918.GA24268@uiuc.edu> References: <20040127204918.GA24268@uiuc.edu> Message-ID: At 2:49 PM -0600 1/27/04, Nicholas Riley wrote: >On Tue, Jan 27, 2004 at 11:58:48AM -0700, steve harley wrote: >, though i miss coding in an outliner; has anyone > > found a way to do this for Python, which is so obviously suited? > >I wish. There are a few editors based on Scintilla which provide code >folding, but it's nothing like Frontier's outline-based editing. If by "outline-based editing" you mean you can do things like "fold" lines based on indentation, then the next version of PyOXIDE will support this (it's not perfect, since it's based _entirely_ on the indentation of the file, and not on any language based information, but it's at least a step). If that's not what you mean, then, well, it won't. -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From keithn at 2xtreme.net Fri Jan 30 21:25:04 2004 From: keithn at 2xtreme.net (Keith Nemitz) Date: Fri Jan 30 21:25:10 2004 Subject: [Pythonmac-SIG] string index bug? Message-ID: This one's so unbelievable, I'd rather be ridiculed for not understanding TFM than let a potential bug slip. I'm running macPython 2.3 on Panther. Drop into python from Terminal. Type >>>print "food"[-3:-1] oo >>>print "food"[-3:0] (results in an empty line) huh? I mean does everyone use[-3:] instead and 0 is taboo? I'm used to the Icon programming language where "food"[-3:0] returns --> ood Keith Nemitz From bob at redivi.com Fri Jan 30 22:16:21 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 30 22:13:35 2004 Subject: [Pythonmac-SIG] string index bug? In-Reply-To: References: Message-ID: On Jan 30, 2004, at 9:25 PM, Keith Nemitz wrote: > This one's so unbelievable, I'd rather be ridiculed for not > understanding TFM than let a potential bug slip. I'm running macPython > 2.3 on Panther. > > Drop into python from Terminal. Type > > >>>print "food"[-3:-1] > oo > > >>>print "food"[-3:0] > > (results in an empty line) > > > huh? I mean does everyone use[-3:] instead and 0 is taboo? I'm used to > the Icon programming language where "food"[-3:0] returns --> ood "food"[-3:] is equivalent to "food"[-3:None] (that is, literally, how it works out internally) "food"[-3:0] is just backwards :) If anything, it should give you "oof", but that's too confusing. -bob From dkwolfe at pacbell.net Fri Jan 30 23:35:50 2004 From: dkwolfe at pacbell.net (Dan Wolfe) Date: Fri Jan 30 23:36:01 2004 Subject: [Pythonmac-SIG] string index bug? In-Reply-To: References: Message-ID: In python, indexes are defined by [index] or [startIndex:endIndex], and NOT [startIndex:count] and are zero based. The use of negative indexes means count from the end. If the parameter is missing (like [:2] [2:]), it means start from the beginning or continue to the end depending on the location. If both are missing it's gives you a copy.. Thus given the the string "food" >>> "food"[:-1] 'foo' >>> "food"[-3:] 'ood' >>> "food"[-3:-1] 'oo' >>> "food"[0] 'f' >>> "food"[0:-3] 'f' >>> "food"[-3:0] '' In the last case, the start index is AFTER to the end index, so logically it returns a empty string. And missing values are... >>> a = "food" >>> b= a[:] >>> b 'food' The same logic also applies to lists and tuples... here's an example using a list.. >>> a = [0,1,2,3] >>> a[0] 0 >>> a[3] 3 >>> a[-1] 3 >>> a[-3] 1 >>> a[1:3] [1, 2] >>> a[-2:-1] [2] >>> a[-3:-1] [1, 2] Hope this helps... - dan On Jan 30, 2004, at 6:25 PM, Keith Nemitz wrote: This one's so unbelievable, I'd rather be ridiculed for not understanding TFM than let a potential bug slip. I'm running macPython 2.3 on Panther. Drop into python from Terminal. Type >>>print "food"[-3:-1] oo >>>print "food"[-3:0] (results in an empty line) huh? I mean does everyone use[-3:] instead and 0 is taboo? I'm used to the Icon programming language where "food"[-3:0] returns --> ood Keith Nemitz _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From keithn at 2xtreme.net Sat Jan 31 13:57:20 2004 From: keithn at 2xtreme.net (Keith Nemitz) Date: Sat Jan 31 13:57:26 2004 Subject: [Pythonmac-SIG] (no subject) Message-ID: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> >> >> >> huh? I mean does everyone use[-3:] instead and 0 is taboo? I'm used >> to the Icon programming language where "food"[-3:0] returns --> ood > > "food"[-3:] is equivalent to "food"[-3:None] (that is, literally, how > it works out internally) > > "food"[-3:0] is just backwards :) If anything, it should give you > "oof", but that's too confusing. > > -bob > Thank you. I knew there had to be a reason. If you think about lists as ring buffers, however, then "food"[-3:0]-->"ood" makes plenty of sense and can be very useful. My case that started this whole thread had to do with iterating from negative to positive, returning larger substrings on each iteration. It broke with the zero index. So I had to special case it. sigh, I wonder if adding this 'concept' to python (indexing lists as ring buffers) would break any existing code... Heck while I'm at it, changing the language, might as well add nested comments, and (my personal favorite) record names, implemented like this: record tuple of enums ::= ( [,enum]*) enum ::= [= ] ...such that the keyword 'record' turns the strings into module and/or class scoped indexes. Isn't it fun to dream? Keith Nemitz From bob at redivi.com Sat Jan 31 14:14:23 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 31 14:11:35 2004 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> Message-ID: On Jan 31, 2004, at 1:57 PM, Keith Nemitz wrote: >>> huh? I mean does everyone use[-3:] instead and 0 is taboo? I'm used >>> to the Icon programming language where "food"[-3:0] returns --> ood >> >> "food"[-3:] is equivalent to "food"[-3:None] (that is, literally, how >> it works out internally) >> >> "food"[-3:0] is just backwards :) If anything, it should give you >> "oof", but that's too confusing. >> > Thank you. I knew there had to be a reason. If you think about lists > as ring buffers, however, then "food"[-3:0]-->"ood" makes plenty of > sense and can be very useful. My case that started this whole thread > had to do with iterating from negative to positive, returning larger > substrings on each iteration. It broke with the zero index. So I had > to special case it. They aren't ring buffers, they're arrays.. the fact you can use negative indexes is a convenience really.. if you notice, you can do "food"[1:100000] and you will still get "ood". You get clipped at the boundaries when slicing. > sigh, I wonder if adding this 'concept' to python (indexing lists as > ring buffers) would break any existing code... Yes, I'm sure it would.. you could make a subclass of str (or list, or whatever) or a proxy object to address things as a ring buffer though. > Heck while I'm at it, changing the language, might as well add nested > comments, and (my personal favorite) record names, implemented like > this: Nested comments? > record > tuple of enums ::= ( [,enum]*) > enum ::= [= ] > > ...such that the keyword 'record' turns the strings into module and/or > class scoped indexes. You don't need language support for this, definitely not a keyword. -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/20040131/a4b41e50/smime.bin From keithn at 2xtreme.net Sat Jan 31 14:43:44 2004 From: keithn at 2xtreme.net (Keith Nemitz) Date: Sat Jan 31 14:44:01 2004 Subject: [Pythonmac-SIG] Re: string bug? In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> Message-ID: > > Nested comments? > {{ comment {{ nested comment }} }} very handy although {{ }} might not work in python. not sure if {} is used for anything but assigning empty dictionaries. > You don't need language support for this, definitely not a keyword. > am glad to hear python is keyword shy. Icon was featured to death. Keith From bob at redivi.com Sat Jan 31 15:01:21 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 31 14:58:31 2004 Subject: [Pythonmac-SIG] Re: string bug? In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> Message-ID: <3DDC256E-5428-11D8-B571-000A95686CD8@redivi.com> On Jan 31, 2004, at 2:43 PM, Keith Nemitz wrote: >> Nested comments? > > {{ comment {{ nested comment }} }} > > very handy > > although {{ }} might not work in python. not sure if {} is used for > anything but assigning empty dictionaries. But uh.. why? What would it be handy for? What's wrong with using strings for comments? class MyClass: """ This is a big comment """ You could nest different kinds of comments, I guess, but I don't see how that would ever be useful. class MyClass: """ # this is a comment in a comment """ -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/20040131/2e2f8601/smime.bin From keithn at 2xtreme.net Sat Jan 31 15:13:53 2004 From: keithn at 2xtreme.net (Keith Nemitz) Date: Sat Jan 31 15:13:57 2004 Subject: [Pythonmac-SIG] Re: string bug? In-Reply-To: <3DDC256E-5428-11D8-B571-000A95686CD8@redivi.com> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <3DDC256E-5428-11D8-B571-000A95686CD8@redivi.com> Message-ID: On Jan 31, 2004, at 12:01 PM, Bob Ippolito wrote: > > You could nest different kinds of comments, I guess, but I don't see > how that would ever be useful. > I think of it as vitally useful. I'm always wanting to comment out a chunk of code and then comment out a bigger chunk later. And using comment strings is like using a screwdriver to open a paint can. Sure it works.... but doesn't that screw up the auto-documentation feature of python? {{ bigger chunk {{ chunk of code }} of code }} Keith From bob at redivi.com Sat Jan 31 15:37:13 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 31 15:34:22 2004 Subject: [Pythonmac-SIG] Re: string bug? In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <3DDC256E-5428-11D8-B571-000A95686CD8@redivi.com> Message-ID: <4042AACC-542D-11D8-B571-000A95686CD8@redivi.com> On Jan 31, 2004, at 3:13 PM, Keith Nemitz wrote: > > On Jan 31, 2004, at 12:01 PM, Bob Ippolito wrote: > >> >> You could nest different kinds of comments, I guess, but I don't see >> how that would ever be useful. >> > > I think of it as vitally useful. I'm always wanting to comment out a > chunk of code and then comment out a bigger chunk later. And using > comment strings is like using a screwdriver to open a paint can. Sure > it works.... but doesn't that screw up the auto-documentation feature > of python? > > {{ > bigger > chunk > > {{ > chunk > of > code > }} > > of > code > }} # # bigger chunk # # # # chunk of code # # # # # # # # of code # or... if 0: bigger chunk if 0: chunk of code of code Obviously, you would want your editor to support you with the first one.. the second one is easy enough to do by hand. -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/20040131/a8412731/smime.bin