From moehl at akaflieg.extern.tu-berlin.de Fri Aug 1 00:35:34 2003 From: moehl at akaflieg.extern.tu-berlin.de (Torsten Sadowski) Date: Thu Jul 31 17:37:24 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? Message-ID: If someone has a working vtk with python I would appreciate some binaries. Torsten From Jack.Jansen at cwi.nl Fri Aug 1 01:17:32 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Jul 31 18:17:41 2003 Subject: [Pythonmac-SIG] For your eyes only: MacPython-OS9 2.3 installer Message-ID: Folks, the MacPython-OS9 2.3 installer is finished too. Please give it a try, at , or any of the other combinations of full/active/src and .bin/.hqx. Source will come later. For this one I would like positive feedback too, as so few people seem to be using MacPython-OS9 anymore. I will wait for at least one positive response for each of installation on OS9 and OSX before I announce 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 zen at shangri-la.dropbear.id.au Fri Aug 1 10:23:08 2003 From: zen at shangri-la.dropbear.id.au (Stuart Bishop) Date: Thu Jul 31 19:23:33 2003 Subject: [Pythonmac-SIG] PackageManager / Python 2.3.x - 2.4 ideas In-Reply-To: <51B62EFFBC83D6118ADA00096BB030A102CC2D94@usamcms7.mc.usa.xerox.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, August 1, 2003, at 12:21 AM, Schollnick, Benjamin wrote: >> Package Manager should be a responsive application, either by using >> nonblocking methods to speak with spawned processes. Threading sucks >> in python, let's not try and use it too much. > > I admit, I haven't used threading too much.... > > But, are any steps being taken in the Python Development circles to > resolve the "Threading Sucks" issues? 'Threading Sucks' isn't a development issue - it is an education issue. If someone has a problem with threading, the first step would be to better articulate their issues. It isn't going to be fixed if people don't think it is broken. Whenever I've used threads, I've really liked the Python implementation :-) - -- Stuart Bishop http://shangri-la.dropbear.id.au/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQE/KaTgh8iUz1x5geARAtpeAJ99xYdI4J9yk1G4lLLHHzsxnrD3AACg/ovK I3jy8AW+0Ir41MnLpQ9U5FQ= =/K2r -----END PGP SIGNATURE----- From bob at redivi.com Fri Aug 1 01:31:41 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 00:31:47 2003 Subject: [Pythonmac-SIG] Additional binary packages for Python2.3rc1 on 10.2.6 In-Reply-To: <78AC6A9A-BD7C-11D7-9428-000A95686CD8@redivi.com> Message-ID: <0C388CB9-C3D9-11D7-853A-000A95686CD8@redivi.com> On Wednesday, Jul 23, 2003, at 22:13 America/New_York, Bob Ippolito wrote: > I've setup a repository for several packages that I use that aren't in > jack's list yet, or weren't compiled correctly for the non-fink user. > > The Package Manager URL is: > http://undefined.org/python/pimp/darwin-6.6-Power_Macintosh.plist > > I couldn't find what jack has been using to build binary packages, so > I wrote one that makes it easy. It's at: > http://undefined.org/python/makepimp.py I've updated both the script (totally different now) and the package repository. The current contents are: aeve 0.0.2 mxBase 2.0.4 PIL 1.1.4 (includes jpeg and freetype support, Jack's doesn't have freetype as far as I can tell) pyOpenSSL 0.5.1 ctypes 0.6.2 pycrypto 1.9a6 Twisted 1.0.7alpha2 From bob at redivi.com Fri Aug 1 01:32:34 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 00:32:41 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: Message-ID: <2C5132B0-C3D9-11D7-853A-000A95686CD8@redivi.com> On Thursday, Jul 31, 2003, at 17:35 America/New_York, Torsten Sadowski wrote: > If someone has a working vtk with python I would appreciate some > binaries. I tried compiling it, and it took forever, but it looked like it worked. However, I don't know how to use it from python.. so I don't know how to test it. If you could point me to some examples/docs I'll take a look and see what I can do for you. -bob From bob at redivi.com Fri Aug 1 02:41:53 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 01:41:59 2003 Subject: [Pythonmac-SIG] Additional binary packages for Python2.3rc1 on 10.2.6 In-Reply-To: <0C388CB9-C3D9-11D7-853A-000A95686CD8@redivi.com> Message-ID: On Friday, Aug 1, 2003, at 00:31 America/New_York, Bob Ippolito wrote: > > On Wednesday, Jul 23, 2003, at 22:13 America/New_York, Bob Ippolito > wrote: > >> I've setup a repository for several packages that I use that aren't >> in jack's list yet, or weren't compiled correctly for the non-fink >> user. >> >> The Package Manager URL is: >> http://undefined.org/python/pimp/darwin-6.6-Power_Macintosh.plist >> >> I couldn't find what jack has been using to build binary packages, so >> I wrote one that makes it easy. It's at: >> http://undefined.org/python/makepimp.py > > I've updated both the script (totally different now) and the package > repository. The current contents are: > > aeve 0.0.2 > mxBase 2.0.4 > PIL 1.1.4 (includes jpeg and freetype support, Jack's doesn't have > freetype as far as I can tell) > pyOpenSSL 0.5.1 > ctypes 0.6.2 > pycrypto 1.9a6 > Twisted 1.0.7alpha2 Note that I'm not really doing much testing on any of this, but I added some more packages: pyOpenGL 2.0.1.05 (Andrew Straw's version that supports multitexturing, I took the liberty to up the build by to 05) numarray 0.6.1 ZODB3 3.2b2 Pyro 3.3beta pygame 1.5.6 (with a separate package for SDL*, smpeg) -bob From kevino at tulane.edu Fri Aug 1 01:50:49 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Fri Aug 1 03:53:46 2003 Subject: [Pythonmac-SIG] PackageManager / Python 2.3.x - 2.4 ideas In-Reply-To: Message-ID: On Wednesday, July 30, 2003, at 03:25 PM, Jack Jansen wrote: > While I agree we need it I think it isn't a PackMan problem. There are > numerous > other packages that want this (bgen, for instance). This could be the > subject of a > separate PEP. > >> Not have separate plist files for each distutils.util.get_platform() >> -- this is only semi-useful for binary OS X packages, and not useful >> at all for other operating systems. > > This one I disagree with, and I disagree with it strongly. The central > philosophy of PackMan > is accountability (in other words: the scapegoat). We may need to > structure things differently, with major/minor OS release in the > filename and within the database entries a list of micro releases that > are known to work, but we definitely need the functionality. Sorry, missed this comment earlier. ;-) This makes sense if we imagine a scapegoat for all packages for a particular platform (and for now this is acceptable because PPM is still new and we need to get people using it first), but I think we want to move towards developers maintaining PPM records for their own packages, and in that case they would want to write one file with multiple platform installs. > Binary packages are the reason for PackMan's existence, source > releases are a service to the developer community. They already have > PyPI. > >> Package Manager should be organized categorically, like PyPI. (i.e. >> they should be heavily integrated). > > Yes, I think we do, indeed. On the other hand I want the database to > remain manageable in size, both for the user and for the maintainer. > The PyPI database has already become unmanageable:-) I think a simple set of top-level categories will do. (i.e. the top categories at the Vault of Parnassas) But eventually I think the only feasible way of maintaining the database is to allow package developers to update their own records via the web. PPM will need to scale because if people can't find most of the modules they're looking for in it, it won't really be used. Of course, I also think a nice search function is in order, but that won't have to be dealt with in the immediate future. >> All of Package Manager's functionality should really be in platform >> independent "designed" modules (meaning they don't have to support >> other platforms yet, just designed with that intent). > > It's all there. Untested, but it's there. > >> Package Manager should be a responsive application, either by using >> nonblocking methods to speak with spawned processes. Threading sucks >> in python, let's not try and use it too much. > > I agree with the responsive bit, not with the threading bit. I think > switching to MVC should make threading a lot easier. Only the log > remains a problem (but not a very big one, on unix). I've already got wxPackageManager using threading to run the install script. =) My personal opinion on this is that if we run into problems, we'll find another way to solve the problem without threads. Personally, I've been using threads in my own wxPython app for quite some time and have had no problems with them. Thanks, Kevin From lanceboyle at myrealbox.com Fri Aug 1 02:25:05 2003 From: lanceboyle at myrealbox.com (Lance Boyle) Date: Fri Aug 1 04:24:55 2003 Subject: [Pythonmac-SIG] Can I move the MacPython-2.3 folder? Message-ID: Can I move the MacPython-2.3 folder out of the Applications folder without breaking anything? Jerry From Jack.Jansen at cwi.nl Fri Aug 1 12:13:10 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 05:10:53 2003 Subject: [Pythonmac-SIG] For your eyes only: MacPython-OS9 2.3 installer In-Reply-To: <16169.54025.901301.201103@montanaro.dyndns.org> Message-ID: <5F330620-C400-11D7-93AF-0030655234CE@cwi.nl> On Friday, Aug 1, 2003, at 04:40 Europe/Amsterdam, Skip Montanaro wrote: > I'm not sure how useful my feedback will be, since I've never really > used > MacPython in an OS9 environment. I ran the installer on my Mac OS X > 10.2.6 > system after running the Classic startup app. From inside an > interpreter > window I ran > > from test import regrtest > regrtest.main() > > One test crashed (test_logging) and one failed (test_socket). I then > tried > each individually. I won't bore you with all the details. The > failure from > test_logging is typical: > [...] > File "Macintosh HD:Users:skip:Desktop:MacPython > OS9:MacPython-OS9 2.3:Lib:SocketServer.py", line 341, in server_bind > self.socket.bind(self.server_address) > File "", line 1, in bind > gaierror: (4, 'getaddrinfo failed') I remember having seen a report of this before, but I can't find it right now. I'm 99% convinced that this is a problem with your setup, and I think it happens because there is no reverse DNS mapping for your IP address. Unless other people are seeing this too I'm tempted to let this slip through, and see what we can do for 2.3.1. Could you file a bug report, please? -- 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 Aug 1 12:14:51 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 05:12:31 2003 Subject: [Pythonmac-SIG] Can I move the MacPython-2.3 folder? In-Reply-To: Message-ID: <9B5A27F0-C400-11D7-93AF-0030655234CE@cwi.nl> On Friday, Aug 1, 2003, at 10:25 Europe/Amsterdam, Lance Boyle wrote: > Can I move the MacPython-2.3 folder out of the Applications folder > without breaking anything? I think you can, i.e. please report if something breaks:-) Things will break in the future, though: in one of the PackMan threads we discuss installing documentation and sample code into /Applications/MacPython-2.3/Extras. -- 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 Benjamin.Schollnick at usa.xerox.com Fri Aug 1 09:56:39 2003 From: Benjamin.Schollnick at usa.xerox.com (Schollnick, Benjamin) Date: Fri Aug 1 08:56:48 2003 Subject: [Pythonmac-SIG] PackageManager / Python 2.3.x - 2.4 ideas Message-ID: <51B62EFFBC83D6118ADA00096BB030A102CC2DA4@usamcms7.mc.usa.xerox.com> > Threading sucks > >> in python, let's not try and use it too much. > > > > I admit, I haven't used threading too much.... > > > > But, are any steps being taken in the Python Development circles to > > resolve the "Threading Sucks" issues? > > 'Threading Sucks' isn't a development issue - it is an education > issue. If someone has a problem with threading, the first step > would be to better articulate their issues. It isn't going to > be fixed if people don't think it is broken. Whenever I've used > threads, I've really liked the Python implementation :-) I mostly agree... as I indicated, I had a learning curve, but my threading generally works fine... (I've only had to thread two apps / libraries. And that was a while ago....) I was really attempting to see what he thought "Sucks" about the Threading model.... To see if I agreed, or might be able to help... - Ben From Jack.Jansen at cwi.nl Fri Aug 1 15:59:44 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 08:57:27 2003 Subject: [Pythonmac-SIG] Anyone interested in 10.1 support? Message-ID: <05F998BE-C420-11D7-BE84-0030655234CE@cwi.nl> I just tried to build MacPython for 10.1, and it doesn't work due to one bug: the #! lines in applets don't work. This was discussed here half a year ago, but I had conveniently forgotten:-). If there is anyone here interested enough to fix this: please check out bug . I don't have enough interest in 10.1 to put much work into this, but I am definitely willing to help if someone wants to do the hard work. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Benjamin.Schollnick at usa.xerox.com Fri Aug 1 10:02:23 2003 From: Benjamin.Schollnick at usa.xerox.com (Schollnick, Benjamin) Date: Fri Aug 1 09:04:47 2003 Subject: [Pythonmac-SIG] Can I move the MacPython-2.3 folder? Message-ID: <51B62EFFBC83D6118ADA00096BB030A102CC2DA5@usamcms7.mc.usa.xerox.com> > Things will break in the future, though: in one of the > PackMan threads > we discuss installing > documentation and sample code into /Applications/MacPython-2.3/Extras. Why hard code the directory? You can find out where python is running simply by getting the directory path... or if you insist on hard coding.... "./Extras" would work.... As long as in the python directory... IMHO, Anything that has a absolute path will eventually break... Or run into a problem... For example, remember Apple's issues with the Itunes v3.00 release, where it accidently "deleted" entire hard drives due to absolute path issues? - Benjamin From mwh at python.net Fri Aug 1 15:07:34 2003 From: mwh at python.net (Michael Hudson) Date: Fri Aug 1 09:07:40 2003 Subject: [Pythonmac-SIG] PackageManager / Python 2.3.x - 2.4 ideas In-Reply-To: <51B62EFFBC83D6118ADA00096BB030A102CC2DA4@usamcms7.mc.usa.xerox.com> ("Schollnick, Benjamin"'s message of "Fri, 01 Aug 2003 08:56:39 -0400") References: <51B62EFFBC83D6118ADA00096BB030A102CC2DA4@usamcms7.mc.usa.xerox.com> Message-ID: <2m8yqdsezt.fsf@starship.python.net> "Schollnick, Benjamin" writes: >> Threading sucks >> >> in python, let's not try and use it too much. >> > >> > I admit, I haven't used threading too much.... >> > >> > But, are any steps being taken in the Python Development circles to >> > resolve the "Threading Sucks" issues? >> >> 'Threading Sucks' isn't a development issue - it is an education >> issue. If someone has a problem with threading, the first step >> would be to better articulate their issues. It isn't going to >> be fixed if people don't think it is broken. Whenever I've used >> threads, I've really liked the Python implementation :-) > > I mostly agree... as I indicated, I had a learning curve, but my > threading generally works fine... > > (I've only had to thread two apps / libraries. And that was a while > ago....) > > I was really attempting to see what he thought "Sucks" about the Threading > model.... To see if I agreed, or might be able to help... AIUI, the "threading sucks" viewpoint has more-or-less nothing to do with Python. Some of the reasons I mistrust threading are explained very well in http://www.advogato.org/person/graydon/diary.html?start=103 In general, concurrency seems to be hard. I didn't think this was news :-) Cheers, mwh -- In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it. -- Tim Peters, 16 Sep 93 From Benjamin.Schollnick at usa.xerox.com Fri Aug 1 10:26:02 2003 From: Benjamin.Schollnick at usa.xerox.com (Schollnick, Benjamin) Date: Fri Aug 1 09:26:15 2003 Subject: [Pythonmac-SIG] PackageManager / Python 2.3.x - 2.4 ideas Message-ID: <51B62EFFBC83D6118ADA00096BB030A102CC2DA6@usamcms7.mc.usa.xerox.com> > > I mostly agree... as I indicated, I had a learning curve, but my > > threading generally works fine... > > > > (I've only had to thread two apps / libraries. And that was a while > > ago....) > > > > I was really attempting to see what he thought "Sucks" > about the Threading > > model.... To see if I agreed, or might be able to help... > > AIUI, the "threading sucks" viewpoint has more-or-less nothing to do > with Python. Some of the reasons I mistrust threading are explained > very well in > > http://www.advogato.org/person/graydon/diary.html?start=103 > > In general, concurrency seems to be hard. I didn't think this was > news :-) This is a little too general... Concurrency does require a good examination of what is happening, and the project flow... But what I found worked in multiple cases, was reducing the issue, until I had the "actions" being handled by a object. Thus I would create multiple objects, and pass them into the threads for servicing. Once the thread finished, I would retrieve the data from the object, destroy the object, and continue on... Yes, this model does not work every where... But often, when working in a OOP model, I keep coming back to a similiar model... Threading in a non-OOP environment is harder... When I rewrote parts of Stathost, and made it into a multithreaded application, to speed it up... I had to basically graft a OOP manager on top of the system for the threading... But it was not difficult.. - Benjamin From Jack.Jansen at cwi.nl Fri Aug 1 17:10:37 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 10:08:20 2003 Subject: [Pythonmac-SIG] Can I move the MacPython-2.3 folder? In-Reply-To: <51B62EFFBC83D6118ADA00096BB030A102CC2DA5@usamcms7.mc.usa.xerox.com> Message-ID: On Friday, Aug 1, 2003, at 15:02 Europe/Amsterdam, Schollnick, Benjamin wrote: > >> Things will break in the future, though: in one of the >> PackMan threads >> we discuss installing >> documentation and sample code into /Applications/MacPython-2.3/Extras. > > Why hard code the directory? > > You can find out where python is running simply by getting the > directory > path... > or if you insist on hard coding.... This may be doable if you are running Package Manager (either standalone or through PythonIDE), because sys.argv[0] may have the information. It will fail if you run pimp.py from the command line, though. I'll see what I can do. At the very least I'll make packages that install into Extras dependent on a pseudo-package that tests whether we can find the correct place to install. Hmm, coming to think of it: the same is true for the IDLE installer, which currently installs into /Applications/MacPython-2.3 unconditionally. -- 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 Aug 1 18:07:31 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 11:05:15 2003 Subject: [Pythonmac-SIG] Additions to the PackMan database Message-ID: Folks, I added two things to the packman database: - a pseudopackage that tests that you haven't moved /Applications/MacPython-2.3. IDLE depends on it, so you can't install it to the wrong place inadvertently. Actually finding where your MacPython-2.3 folder had moved turned out to be non-trivial, so I'm punting on that for now. - a package PyObjC_Extras which puts the PyObjC documentation and examples into your Extras folder. Let me know if you like this scheme, and also let me know which other packages have interesting bits in the source that should be treated similarly (and, preferably, tell me which bits too:-). -- 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 brownr at ucalgary.ca Fri Aug 1 11:06:46 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 1 12:07:26 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: Message-ID: <26DCCBAE-C43A-11D7-8E5A-000A959032C4@ucalgary.ca> Hi -- I'm the visualization guy at our lab and our platform is Python-VTK on OSX. I've got full working binaries (include Patented and Parallel) for Python 2.2 and today's project is building VTK 4.2.2 for Python 2.3. VTK Mac OSX support has come a long way. Last time I built it worked first time! I'll let you know as soon as I have the Python 2.3 binaries working. I'm also interested in building a package out of them (see my message to the list after this one). I assume you're interested in the 2.3 binaries? On Thursday, July 31, 2003, at 03:35 PM, Torsten Sadowski wrote: > If someone has a working vtk with python I would appreciate some > binaries. > > Torsten > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From brownr at ucalgary.ca Fri Aug 1 11:13:57 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 1 12:14:42 2003 Subject: [Pythonmac-SIG] Building Packages for PackageManager Message-ID: <277A29D0-C43B-11D7-8E5A-000A959032C4@ucalgary.ca> First, congratulations to Jack and everyone else on the new version of MacPython! Building Python always worked very well on the Mac, but the installer and PackageManager is a big step forward! I'm interested in creating a VTK package (among other things) for use with PackageManager. Is there any documentation on creating packages? _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From moehl at akaflieg.extern.tu-berlin.de Fri Aug 1 20:04:48 2003 From: moehl at akaflieg.extern.tu-berlin.de (Torsten Sadowski) Date: Fri Aug 1 13:06:42 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <26DCCBAE-C43A-11D7-8E5A-000A959032C4@ucalgary.ca> Message-ID: Great news, I would also be interested in the things you did to make it work, because - the carbon version did not build because of a problem between the tk and the carbon framework - the python test failed because the wrapper libraries were not linked together. Torsten On Fri, 1 Aug 2003, Robb Brown wrote: > Hi -- I'm the visualization guy at our lab and our platform is > Python-VTK on OSX. I've got full working binaries (include Patented > and Parallel) for Python 2.2 and today's project is building VTK 4.2.2 > for Python 2.3. VTK Mac OSX support has come a long way. Last time I > built it worked first time! > > I'll let you know as soon as I have the Python 2.3 binaries working. > I'm also interested in building a package out of them (see my message > to the list after this one). I assume you're interested in the 2.3 > binaries? > > > On Thursday, July 31, 2003, at 03:35 PM, Torsten Sadowski wrote: > > > If someone has a working vtk with python I would appreciate some > > binaries. > > > > Torsten > > > > > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > > _____________________________ > Robb Brown > Seaman Family MR Center > Calgary, AB > > > From brownr at ucalgary.ca Fri Aug 1 12:08:21 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 1 13:09:00 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <16170.37373.292636.327582@montanaro.dyndns.org> Message-ID: What version of gcc are you using? What version of the Tk framework? I'm just starting my new VTK build. Last time I compiled it was gcc 3.1 and AquaTk 8.4.1. When I tried to upgrade to a newer Tk (8.4.2) without rebuilding VTK it crashed with a function prototype error. Obviously some reasonably major work was done to AquaTk between those two minor releases. I'll try building with the newest version, but you might want to try going back to 8.4.1. On Friday, August 1, 2003, at 10:14 AM, Skip Montanaro wrote: > Robb, > > I tried building VTK 4.2 yesterday w/ Python 2.3. If failed building > vtkTkWidgetsInit.o with a boatload of syntax errors: > > Building object file vtkTkWidgetsInit.o... > In file included from > /Users/skip/src/VTK-4.2.2/Rendering/vtkTkWidgetsInit.cxx:1 > 9: > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h:339: > type specifier omitted for parameter `CONST84' > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h:339: > parse error before `char' > In file included from > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h > :1576, > from > /Users/skip/src/VTK-4.2.2/Rendering/vtkTkWidgetsInit.cxx:1 > 9: > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:145: > type specifier omitted for parameter `CONST84' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:145: > parse error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:237: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:327: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:330: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:412: > type specifier omitted for parameter `CONST84' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:412: > parse error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:479: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:482: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:484: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:487: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:489: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:491: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:494: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:496: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:499: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:501: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:504: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:516: > type specifier omitted for parameter `CONST84' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:516: > parse error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:960: > type specifier omitted for parameter `CONST84' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:960: > parse error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:986: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1014: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1015: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1039: > type specifier omitted for parameter `CONST84' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1039: > parse error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1061: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1062: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1063: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1064: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1065: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1066: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1067: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1068: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1069: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1070: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1071: > syntax error before `char' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1074: > type specifier omitted for parameter `CONST84' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1074: > parse error before `char' > make[3]: *** [vtkTkWidgetsInit.o] Error 1 > make[2]: *** [default_target] Error 2 > make[1]: *** [default_target_Rendering] Error 2 > make: *** [default_target] Error 2 > > Got any suggestions? > > Thanks, > > -- > Skip Montanaro > Got gigs? http://www.musi-cal.com/ > Got spam? http://spambayes.sf.net/ > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From bob at redivi.com Fri Aug 1 11:18:56 2003 From: bob at redivi.com (bob@redivi.com) Date: Fri Aug 1 13:19:48 2003 Subject: [Pythonmac-SIG] Can I move the MacPython-2.3 folder? In-Reply-To: <51B62EFFBC83D6118ADA00096BB030A102CC2DA5@usamcms7.mc.usa.xerox.com> References: <51B62EFFBC83D6118ADA00096BB030A102CC2DA5@usamcms7.mc.usa.xerox.com> Message-ID: <20030801171856.GA25842@redivi.com> On Fri, Aug 01, 2003 at 09:02:23AM -0400, Schollnick, Benjamin wrote: > > > Things will break in the future, though: in one of the > > PackMan threads > > we discuss installing > > documentation and sample code into /Applications/MacPython-2.3/Extras. > > Why hard code the directory? > > You can find out where python is running simply by getting the directory > path... > or if you insist on hard coding.... > > "./Extras" would work.... As long as in the python directory... > > IMHO, Anything that has a absolute path will eventually break... Or run into > a problem... > > For example, remember Apple's issues with the Itunes v3.00 release, where it > accidently "deleted" entire hard drives due to absolute path issues? Python isn't there, python is in /Library/Frameworks/..../. Python has no idea where MacPython-2.3 is. The only way to keep track of it would be to keep an alias inside the Python.framework, and even that would only work if they kept it on the same volume. -bob From moehl at akaflieg.extern.tu-berlin.de Fri Aug 1 20:19:18 2003 From: moehl at akaflieg.extern.tu-berlin.de (Torsten Sadowski) Date: Fri Aug 1 13:21:11 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: Message-ID: Though I'm not Skip I had the same errors with the release tarball. The nightly build and cvs led (for carbon) to: In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:165, from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21, from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from /Volumes/Temp/Download/vtk/VTK.1/Rendering/vtkCarbonRenderWindowInteractor.h:30, from /Volumes/Temp/Download/vtk/osx1/Rendering/vtkCarbonRenderWindowInteractorPython.cxx:7: /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h: In function `long double scalbl(long double, long int)': /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1896: ` scalb' undeclared (first use this function) /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1896: (Each undeclared identifier is reported only once for each function it appears in.) make[3]: *** [vtkCarbonRenderWindowInteractorPython.o] Error 1 make[2]: *** [default_target] Error 2 make[1]: *** [default_target_Rendering] Error 2 make: *** [default_target] Error 2 When I said I want a cocoa build everything compiled. A short test (BlackBox.py) gave undefined symbols: Traceback (most recent call last): File "vtk/test/BlackBox.py", line 1, in ? from vtk.util import vtkMethodParser File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/vtk_python/vtk/__init__.py", line 28, in ? from filtering import * File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/vtk_python/vtk/filtering.py", line 7, in ? from libvtkFilteringPython import * ImportError: Failure linking new module: : dyld: /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/Python Undefined symbols: _PyArg_VTKParseTuple _PyVTKClass_Check _PyVTKClass_New _PyVTKClass_vtkCollectionNew _PyVTKClass_vtkDataObjectNew _PyVTKClass_vtkImplicitFunctionNew _PyVTKClass_vtkLocatorNew _PyVTKClass_vtkObjectNew _PyVTKClass_vtkPointLocatorNew _PyVTKClass_vtkScalarsToColorsNew _PyVTKClass_vtkSourceNew __Z19vtkPythonCheckArrayP7_objectiPfi __Z19vtkPythonCheckArrayP7_objectiPi I use Apples gcc 3.1 and tk version 8.4.2. I could live without the tk-stuff, I'm more in wxPython. Torsten On Fri, 1 Aug 2003, Robb Brown wrote: > What version of gcc are you using? What version of the Tk framework? > I'm just starting my new VTK build. Last time I compiled it was gcc > 3.1 and AquaTk 8.4.1. When I tried to upgrade to a newer Tk (8.4.2) > without rebuilding VTK it crashed with a function prototype error. > Obviously some reasonably major work was done to AquaTk between those > two minor releases. I'll try building with the newest version, but you > might want to try going back to 8.4.1. > > > On Friday, August 1, 2003, at 10:14 AM, Skip Montanaro wrote: > > > Robb, > > > > I tried building VTK 4.2 yesterday w/ Python 2.3. If failed building > > vtkTkWidgetsInit.o with a boatload of syntax errors: > > > > Building object file vtkTkWidgetsInit.o... > > In file included from > > /Users/skip/src/VTK-4.2.2/Rendering/vtkTkWidgetsInit.cxx:1 > > 9: > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h:339: > > type specifier omitted for parameter `CONST84' > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h:339: > > parse error before `char' > > In file included from > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h > > :1576, > > from > > /Users/skip/src/VTK-4.2.2/Rendering/vtkTkWidgetsInit.cxx:1 > > 9: > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:145: > > type specifier omitted for parameter `CONST84' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:145: > > parse error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:237: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:327: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:330: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:412: > > type specifier omitted for parameter `CONST84' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:412: > > parse error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:479: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:482: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:484: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:487: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:489: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:491: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:494: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:496: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:499: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:501: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:504: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:516: > > type specifier omitted for parameter `CONST84' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:516: > > parse error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:960: > > type specifier omitted for parameter `CONST84' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:960: > > parse error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:986: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1014: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1015: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1039: > > type specifier omitted for parameter `CONST84' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1039: > > parse error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1061: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1062: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1063: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1064: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1065: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1066: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1067: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1068: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1069: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1070: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1071: > > syntax error before `char' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1074: > > type specifier omitted for parameter `CONST84' > > > > /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1074: > > parse error before `char' > > make[3]: *** [vtkTkWidgetsInit.o] Error 1 > > make[2]: *** [default_target] Error 2 > > make[1]: *** [default_target_Rendering] Error 2 > > make: *** [default_target] Error 2 > > > > Got any suggestions? > > > > Thanks, > > > > -- > > Skip Montanaro > > Got gigs? http://www.musi-cal.com/ > > Got spam? http://spambayes.sf.net/ > > > > > _____________________________ > Robb Brown > Seaman Family MR Center > Calgary, AB > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From bob at redivi.com Fri Aug 1 11:22:57 2003 From: bob at redivi.com (bob@redivi.com) Date: Fri Aug 1 13:23:48 2003 Subject: [Pythonmac-SIG] Building Packages for PackageManager In-Reply-To: <277A29D0-C43B-11D7-8E5A-000A959032C4@ucalgary.ca> References: <277A29D0-C43B-11D7-8E5A-000A959032C4@ucalgary.ca> Message-ID: <20030801172257.GB25842@redivi.com> On Fri, Aug 01, 2003 at 10:13:57AM -0600, Robb Brown wrote: > First, congratulations to Jack and everyone else on the new version of > MacPython! Building Python always worked very well on the Mac, but the > installer and PackageManager is a big step forward! > > I'm interested in creating a VTK package (among other things) for use > with PackageManager. Is there any documentation on creating packages? Not really, if it uses distutils it's rather easy (take a look at http://undefined.org/python/makepimp.py) otherwise you currently have to do it by hand. -bob From bob at redivi.com Fri Aug 1 11:27:06 2003 From: bob at redivi.com (bob@redivi.com) Date: Fri Aug 1 13:27:57 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: References: <26DCCBAE-C43A-11D7-8E5A-000A959032C4@ucalgary.ca> Message-ID: <20030801172706.GC25842@redivi.com> On Fri, Aug 01, 2003 at 07:04:48PM +0200, Torsten Sadowski wrote: > Great news, > > I would also be interested in the things you did to make it work, because > - the carbon version did not build because of a problem between the tk and > the carbon framework > - the python test failed because the wrapper libraries were not linked > together. That's what it look like to me. It looks like their Python wrappers are currently expecting -flat_namespace -undefined suppress and a specific import order.. but Python is not linking the .so's that way. The best way to do this would be to fix the VTK build process so that it links hte dependent libraries together and doesn't mess up. That's really NOT the way to do extension->extension dependencies in Python, though. -bob From brownr at ucalgary.ca Fri Aug 1 12:47:40 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 1 13:48:20 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <16170.40699.333720.621865@montanaro.dyndns.org> Message-ID: <3F212D54-C448-11D7-8E5A-000A959032C4@ucalgary.ca> Have a look in your /Library/Frameworks and see if there's a Tcl.framework and Tk.framework there. If not (or maybe even if there is) try downloading http://prdownloads.sourceforge.net/tcl/TclTkAqua-8.4.1- Jaguar.dmg?download This is a dmg file that should mount itself. There's a standard mac Package inside you can double click to install. You have to have an admin password. I'm about half way through building VTK now, but haven't gotten to the Tcl/Tk stuff yet so I don't know if this works or not. On Friday, August 1, 2003, at 11:10 AM, Skip Montanaro wrote: > > Robb> What version of gcc are you using? What version of the Tk > Robb> framework? > > Whatever comes with OS X 10.2.6 plus whatever developer kit I have > loaded. > Gcc tells me it's version 3.1 20020420. I don't know how to determine > Tk > version other than what's embedded in the path or the header files: > > #define TK_MAJOR_VERSION 8 > #define TK_MINOR_VERSION 4 > #define TK_VERSION "8.4" > #define TK_PATCH_LEVEL "8.4.1" > > I don't know if it's Aqua or not. "aqua" doesn't appear in the Tk > header > files. > > Robb> I'm just starting my new VTK build. Last time I compiled it > was > Robb> gcc 3.1 and AquaTk 8.4.1. When I tried to upgrade to a > newer Tk > Robb> (8.4.2) without rebuilding VTK it crashed with a function > Robb> prototype error. Obviously some reasonably major work was > done to > Robb> AquaTk between those two minor releases. I'll try building > with > Robb> the newest version, but you might want to try going back to > 8.4.1. > > It appears I have 8.4.1, but I can't tell if it's AquaTk or not. > > Thx, > > Skip > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From brownr at ucalgary.ca Fri Aug 1 12:50:54 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 1 13:51:39 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: Message-ID: I haven't ever built with the cocoa bindings... last time I tried (a while ago) it didn't work. Might be worth a look. I have found you often have to explicitly tell CMake that various X libraries and header files are not found so that it doesn't start confusing the Cocoa/Aqua frameworks with X versions of things. I also found that I couldn't trust VTK to install things in Python -- I had to manually add things to the site-packages folder. On Friday, August 1, 2003, at 11:19 AM, Torsten Sadowski wrote: > Though I'm not Skip I had the same errors with the release tarball. The > nightly build and cvs led (for carbon) to: > > In file included from > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/CarbonCore.h:165, > from > /System/Library/Frameworks/CoreServices.framework/Headers/ > CoreServices.h:21, > from > /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, > from > /Volumes/Temp/Download/vtk/VTK.1/Rendering/ > vtkCarbonRenderWindowInteractor.h:30, > from > /Volumes/Temp/Download/vtk/osx1/Rendering/ > vtkCarbonRenderWindowInteractorPython.cxx:7: > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h: > In > function `long double scalbl(long double, long int)': > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h:1896: > ` > scalb' undeclared (first use this function) > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h:1896: > (Each > undeclared identifier is reported only once for each function it > appears > in.) > make[3]: *** [vtkCarbonRenderWindowInteractorPython.o] Error 1 > make[2]: *** [default_target] Error 2 > make[1]: *** [default_target_Rendering] Error 2 > make: *** [default_target] Error 2 > > When I said I want a cocoa build everything compiled. > > A short test (BlackBox.py) gave undefined symbols: > > Traceback (most recent call last): > File "vtk/test/BlackBox.py", line 1, in ? > from vtk.util import vtkMethodParser > File > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- > packages/vtk_python/vtk/__init__.py", > line 28, in ? > from filtering import * > File > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- > packages/vtk_python/vtk/filtering.py", > line 7, in ? > from libvtkFilteringPython import * > ImportError: Failure linking new module: : dyld: > /Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python.app/Contents/MacOS/Python > Undefined symbols: > _PyArg_VTKParseTuple > _PyVTKClass_Check > _PyVTKClass_New > _PyVTKClass_vtkCollectionNew > _PyVTKClass_vtkDataObjectNew > _PyVTKClass_vtkImplicitFunctionNew > _PyVTKClass_vtkLocatorNew > _PyVTKClass_vtkObjectNew > _PyVTKClass_vtkPointLocatorNew > _PyVTKClass_vtkScalarsToColorsNew > _PyVTKClass_vtkSourceNew > __Z19vtkPythonCheckArrayP7_objectiPfi > __Z19vtkPythonCheckArrayP7_objectiPi > > I use Apples gcc 3.1 and tk version 8.4.2. I could live without the > tk-stuff, I'm more in wxPython. > > Torsten > > On Fri, 1 Aug 2003, Robb Brown wrote: > >> What version of gcc are you using? What version of the Tk framework? >> I'm just starting my new VTK build. Last time I compiled it was gcc >> 3.1 and AquaTk 8.4.1. When I tried to upgrade to a newer Tk (8.4.2) >> without rebuilding VTK it crashed with a function prototype error. >> Obviously some reasonably major work was done to AquaTk between those >> two minor releases. I'll try building with the newest version, but >> you >> might want to try going back to 8.4.1. >> >> >> On Friday, August 1, 2003, at 10:14 AM, Skip Montanaro wrote: >> >>> Robb, >>> >>> I tried building VTK 4.2 yesterday w/ Python 2.3. If failed building >>> vtkTkWidgetsInit.o with a boatload of syntax errors: >>> >>> Building object file vtkTkWidgetsInit.o... >>> In file included from >>> /Users/skip/src/VTK-4.2.2/Rendering/vtkTkWidgetsInit.cxx:1 >>> 9: >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h:339: >>> type specifier omitted for parameter `CONST84' >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h:339: >>> parse error before `char' >>> In file included from >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h >>> :1576, >>> from >>> /Users/skip/src/VTK-4.2.2/Rendering/vtkTkWidgetsInit.cxx:1 >>> 9: >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:145: >>> type specifier omitted for parameter `CONST84' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:145: >>> parse error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:237: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:327: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:330: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:412: >>> type specifier omitted for parameter `CONST84' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:412: >>> parse error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:479: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:482: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:484: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:487: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:489: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:491: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:494: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:496: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:499: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:501: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:504: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:516: >>> type specifier omitted for parameter `CONST84' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:516: >>> parse error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:960: >>> type specifier omitted for parameter `CONST84' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:960: >>> parse error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:986: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1014: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1015: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1039: >>> type specifier omitted for parameter `CONST84' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1039: >>> parse error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1061: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1062: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1063: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1064: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1065: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1066: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1067: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1068: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1069: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1070: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1071: >>> syntax error before `char' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1074: >>> type specifier omitted for parameter `CONST84' >>> >>> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkDecls.h:1074: >>> parse error before `char' >>> make[3]: *** [vtkTkWidgetsInit.o] Error 1 >>> make[2]: *** [default_target] Error 2 >>> make[1]: *** [default_target_Rendering] Error 2 >>> make: *** [default_target] Error 2 >>> >>> Got any suggestions? >>> >>> Thanks, >>> >>> -- >>> Skip Montanaro >>> Got gigs? http://www.musi-cal.com/ >>> Got spam? http://spambayes.sf.net/ >>> >>> >> _____________________________ >> Robb Brown >> Seaman Family MR Center >> Calgary, AB >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From brownr at ucalgary.ca Fri Aug 1 12:54:03 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 1 13:54:41 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <20030801172706.GC25842@redivi.com> Message-ID: <2355C67B-C449-11D7-8E5A-000A959032C4@ucalgary.ca> Uh oh. Did this change from Python 2.2 to 2.3? Last I checked VTK DOES use -flat_namespace (at least for Carbon). The VTK wrapping code is probably on it's way out, to be replaced by Cable (eventually) so I doubt anyone is too interested in fixing it. Maybe Cocoa VTK does this smarter and that's why it works for Torsten? On Friday, August 1, 2003, at 11:27 AM, bob@redivi.com wrote: > On Fri, Aug 01, 2003 at 07:04:48PM +0200, Torsten Sadowski wrote: >> Great news, >> >> I would also be interested in the things you did to make it work, >> because >> - the carbon version did not build because of a problem between the >> tk and >> the carbon framework >> - the python test failed because the wrapper libraries were not linked >> together. > > That's what it look like to me. It looks like their Python wrappers > are currently expecting -flat_namespace -undefined suppress and a > specific import order.. but Python is not linking the .so's that way. > > The best way to do this would be to fix the VTK build process so that > it links hte dependent libraries together and doesn't mess up. That's > really NOT the way to do extension->extension dependencies in Python, > though. > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From brownr at ucalgary.ca Fri Aug 1 13:10:23 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 1 14:11:01 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <2355C67B-C449-11D7-8E5A-000A959032C4@ucalgary.ca> Message-ID: <6B75BEFA-C44B-11D7-8E5A-000A959032C4@ucalgary.ca> Okay, I can confirm that, my VTK builds (Skip, probably a problem with your Tk libraries), but it doesn't import. Looks like you're right Bob. I'm building the Cocoa version of VTK now, but I'm not too optimistic. On Friday, August 1, 2003, at 11:54 AM, Robb Brown wrote: > Uh oh. Did this change from Python 2.2 to 2.3? Last I checked VTK > DOES use -flat_namespace (at least for Carbon). The VTK wrapping code > is probably on it's way out, to be replaced by Cable (eventually) so I > doubt anyone is too interested in fixing it. Maybe Cocoa VTK does > this smarter and that's why it works for Torsten? > > > On Friday, August 1, 2003, at 11:27 AM, bob@redivi.com wrote: > >> On Fri, Aug 01, 2003 at 07:04:48PM +0200, Torsten Sadowski wrote: >>> Great news, >>> >>> I would also be interested in the things you did to make it work, >>> because >>> - the carbon version did not build because of a problem between the >>> tk and >>> the carbon framework >>> - the python test failed because the wrapper libraries were not >>> linked >>> together. >> >> That's what it look like to me. It looks like their Python wrappers >> are currently expecting -flat_namespace -undefined suppress and a >> specific import order.. but Python is not linking the .so's that way. >> >> The best way to do this would be to fix the VTK build process so that >> it links hte dependent libraries together and doesn't mess up. >> That's really NOT the way to do extension->extension dependencies in >> Python, though. >> >> -bob >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > _____________________________ > Robb Brown > Seaman Family MR Center > Calgary, AB > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From list at mchsi.com Fri Aug 1 15:11:13 2003 From: list at mchsi.com (Andrew Hartung) Date: Fri Aug 1 15:11:22 2003 Subject: [Pythonmac-SIG] pygame In-Reply-To: <2C5132B0-C3D9-11D7-853A-000A95686CD8@redivi.com> Message-ID: Is it possible to compile pygame from source with a fink installed SDL? Can I use a fink python 2.3 too, or am I asking for trouble and should go with MacPython? Thank you, Andrew Hartung From bob at redivi.com Fri Aug 1 16:23:24 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 15:23:32 2003 Subject: [Pythonmac-SIG] pygame In-Reply-To: Message-ID: <9EC63EF0-C455-11D7-853A-000A95686CD8@redivi.com> On Friday, Aug 1, 2003, at 15:11 America/New_York, Andrew Hartung wrote: > Is it possible to compile pygame from source with a fink installed > SDL? Can I use a fink python 2.3 too, or am I asking for trouble and > should go with MacPython? You're asking for trouble, don't do that. -bob From brownr at ucalgary.ca Fri Aug 1 15:20:38 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 1 16:21:17 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <20030801172706.GC25842@redivi.com> Message-ID: <9D500C30-C45D-11D7-8E5A-000A959032C4@ucalgary.ca> What's the recommended way of doing this? If I understand correctly, we need to get rid of the -flat_namespace. Doing this requires that we link some of the VTK Python modules with each other (eg. libvtkRenderingPython.so needs to be linked with libvtkCommonPython.so). This happens on other platforms but VTK avoids this for the Mac. Must have been a workaround in the early days when nobody could get ANYTHING to compile without flat namespaces in Apple's gcc. So how do you link against a .so? -l doesn't find them. If we can figure this out I think it's relatively easy to modify VTK's cmake files to reflect the change. Thanks for any help, Robb On Friday, August 1, 2003, at 11:27 AM, bob@redivi.com wrote: > On Fri, Aug 01, 2003 at 07:04:48PM +0200, Torsten Sadowski wrote: >> Great news, >> >> I would also be interested in the things you did to make it work, >> because >> - the carbon version did not build because of a problem between the >> tk and >> the carbon framework >> - the python test failed because the wrapper libraries were not linked >> together. > > That's what it look like to me. It looks like their Python wrappers > are currently expecting -flat_namespace -undefined suppress and a > specific import order.. but Python is not linking the .so's that way. > > The best way to do this would be to fix the VTK build process so that > it links hte dependent libraries together and doesn't mess up. That's > really NOT the way to do extension->extension dependencies in Python, > though. > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From bob at redivi.com Fri Aug 1 17:27:54 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 16:28:02 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <9D500C30-C45D-11D7-8E5A-000A959032C4@ucalgary.ca> Message-ID: There's three ways that I know of to do it: (1) Inject Mach-O loader commands into the .so's that have dependencies directly after compilation (something like install_name_tool but more dangerous, I could write one of these using the "potool" code I have) (2) Trick the linker by whatever means.. i.e. not using -l, or renaming to lib*.dylib then editing the Mach-O loaders with install_name_tool after the fact. (3) Fix VTK to use the recommended Python way for inter-extension dependencies, like the way that numarray does it. Basically what you do is use Python to import the module containing the things you depend on. That module has a way of giving you various pointers to C functions, and you setup a jump table based upon that. See: http://stsdas.stsci.edu/numarray/Doc/node37.html On Friday, Aug 1, 2003, at 16:20 America/New_York, Robb Brown wrote: > What's the recommended way of doing this? If I understand correctly, > we need to get rid of the -flat_namespace. Doing this requires that > we link some of the VTK Python modules with each other (eg. > libvtkRenderingPython.so needs to be linked with > libvtkCommonPython.so). This happens on other platforms but VTK > avoids this for the Mac. Must have been a workaround in the early > days when nobody could get ANYTHING to compile without flat namespaces > in Apple's gcc. > > So how do you link against a .so? -l doesn't find them. If we can > figure this out I think it's relatively easy to modify VTK's cmake > files to reflect the change. > > Thanks for any help, > > Robb > > > On Friday, August 1, 2003, at 11:27 AM, bob@redivi.com wrote: > >> On Fri, Aug 01, 2003 at 07:04:48PM +0200, Torsten Sadowski wrote: >>> Great news, >>> >>> I would also be interested in the things you did to make it work, >>> because >>> - the carbon version did not build because of a problem between the >>> tk and >>> the carbon framework >>> - the python test failed because the wrapper libraries were not >>> linked >>> together. >> >> That's what it look like to me. It looks like their Python wrappers >> are currently expecting -flat_namespace -undefined suppress and a >> specific import order.. but Python is not linking the .so's that way. >> >> The best way to do this would be to fix the VTK build process so that >> it links hte dependent libraries together and doesn't mess up. >> That's really NOT the way to do extension->extension dependencies in >> Python, though. >> >> -bob >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > _____________________________ > Robb Brown > Seaman Family MR Center > Calgary, AB > From brownr at ucalgary.ca Fri Aug 1 15:56:12 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 1 16:56:53 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: Message-ID: <95AA4B22-C462-11D7-8E5A-000A959032C4@ucalgary.ca> Hm. Sounds like (3) is the right way... but it involves modifying VTK's auto-wrapper. (1) sounds like maybe a quick fix? Is (1) something that would be fairly easy for you try? For (3), how hard is it to write something similar to import_libnumarray()? I assume we'd have to do this for each VTK module and then insert the relevant calls. Can we automatically create the tables as part of the wrapping process (that way the average VTK developer wouldn't have to do anything differently)? On Friday, August 1, 2003, at 02:27 PM, Bob Ippolito wrote: > There's three ways that I know of to do it: > (1) Inject Mach-O loader commands into the .so's that have > dependencies directly after compilation (something like > install_name_tool but more dangerous, I could write one of these using > the "potool" code I have) > (2) Trick the linker by whatever means.. i.e. not using -l, or > renaming to lib*.dylib then editing the Mach-O loaders with > install_name_tool after the fact. > (3) Fix VTK to use the recommended Python way for inter-extension > dependencies, like the way that numarray does it. Basically what you > do is use Python to import the module containing the things you depend > on. That module has a way of giving you various pointers to C > functions, and you setup a jump table based upon that. See: > http://stsdas.stsci.edu/numarray/Doc/node37.html > > On Friday, Aug 1, 2003, at 16:20 America/New_York, Robb Brown wrote: > >> What's the recommended way of doing this? If I understand correctly, >> we need to get rid of the -flat_namespace. Doing this requires that >> we link some of the VTK Python modules with each other (eg. >> libvtkRenderingPython.so needs to be linked with >> libvtkCommonPython.so). This happens on other platforms but VTK >> avoids this for the Mac. Must have been a workaround in the early >> days when nobody could get ANYTHING to compile without flat >> namespaces in Apple's gcc. >> >> So how do you link against a .so? -l doesn't find them. If we can >> figure this out I think it's relatively easy to modify VTK's cmake >> files to reflect the change. >> >> Thanks for any help, >> >> Robb >> >> >> On Friday, August 1, 2003, at 11:27 AM, bob@redivi.com wrote: >> >>> On Fri, Aug 01, 2003 at 07:04:48PM +0200, Torsten Sadowski wrote: >>>> Great news, >>>> >>>> I would also be interested in the things you did to make it work, >>>> because >>>> - the carbon version did not build because of a problem between the >>>> tk and >>>> the carbon framework >>>> - the python test failed because the wrapper libraries were not >>>> linked >>>> together. >>> >>> That's what it look like to me. It looks like their Python wrappers >>> are currently expecting -flat_namespace -undefined suppress and a >>> specific import order.. but Python is not linking the .so's that >>> way. >>> >>> The best way to do this would be to fix the VTK build process so >>> that it links hte dependent libraries together and doesn't mess up. >>> That's really NOT the way to do extension->extension dependencies in >>> Python, though. >>> >>> -bob >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >>> >> _____________________________ >> Robb Brown >> Seaman Family MR Center >> Calgary, AB >> > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From skip at pobox.com Fri Aug 1 17:03:53 2003 From: skip at pobox.com (Skip Montanaro) Date: Fri Aug 1 17:04:10 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <6B75BEFA-C44B-11D7-8E5A-000A959032C4@ucalgary.ca> References: <2355C67B-C449-11D7-8E5A-000A959032C4@ucalgary.ca> <6B75BEFA-C44B-11D7-8E5A-000A959032C4@ucalgary.ca> Message-ID: <16170.54713.45994.109328@montanaro.dyndns.org> Robb> Okay, I can confirm that, my VTK builds (Skip, probably a problem Robb> with your Tk libraries), but it doesn't import.... No luck. I installed the Aqua thing you pointed me to, but /Library/Frameworks/Tk.framework still contains a symlink called libtkstub8.4g.a, so I suspect I had that all along. I still get the same errors trying to build vtkTkWidgetsInit.o. Skip From bob at redivi.com Fri Aug 1 18:10:06 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 17:10:14 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <95AA4B22-C462-11D7-8E5A-000A959032C4@ucalgary.ca> Message-ID: <86B7C93E-C464-11D7-853A-000A95686CD8@redivi.com> On Friday, Aug 1, 2003, at 16:56 America/New_York, Robb Brown wrote: > Hm. Sounds like (3) is the right way... but it involves modifying > VTK's auto-wrapper. (1) sounds like maybe a quick fix? > > Is (1) something that would be fairly easy for you try? Fairly easy, I'll try and look into it this weekend. However, someone needs to hook me up with some example code for VTK cause I have no idea what it's supposed to do and how I'm supposed to use it :) > For (3), how hard is it to write something similar to > import_libnumarray()? I assume we'd have to do this for each VTK > module and then insert the relevant calls. Can we automatically > create the tables as part of the wrapping process (that way the > average VTK developer wouldn't have to do anything differently)? We'd have to do it through the wrapping process, to keep our sanity. I don't know how their wrapper works, it seems awfully complicated (all this cmake, etc.) and by virtue of it taking what seemed like hours to compile on my 1ghz pbg4 I can't imagine this would be fun (for me) to do. > > > On Friday, August 1, 2003, at 02:27 PM, Bob Ippolito wrote: > >> There's three ways that I know of to do it: >> (1) Inject Mach-O loader commands into the .so's that have >> dependencies directly after compilation (something like >> install_name_tool but more dangerous, I could write one of these >> using the "potool" code I have) >> (2) Trick the linker by whatever means.. i.e. not using -l, or >> renaming to lib*.dylib then editing the Mach-O loaders with >> install_name_tool after the fact. >> (3) Fix VTK to use the recommended Python way for inter-extension >> dependencies, like the way that numarray does it. Basically what you >> do is use Python to import the module containing the things you >> depend on. That module has a way of giving you various pointers to C >> functions, and you setup a jump table based upon that. See: >> http://stsdas.stsci.edu/numarray/Doc/node37.html >> >> On Friday, Aug 1, 2003, at 16:20 America/New_York, Robb Brown wrote: >> >>> What's the recommended way of doing this? If I understand >>> correctly, we need to get rid of the -flat_namespace. Doing this >>> requires that we link some of the VTK Python modules with each other >>> (eg. libvtkRenderingPython.so needs to be linked with >>> libvtkCommonPython.so). This happens on other platforms but VTK >>> avoids this for the Mac. Must have been a workaround in the early >>> days when nobody could get ANYTHING to compile without flat >>> namespaces in Apple's gcc. >>> >>> So how do you link against a .so? -l doesn't find them. If we can >>> figure this out I think it's relatively easy to modify VTK's cmake >>> files to reflect the change. >>> >>> Thanks for any help, >>> >>> Robb >>> >>> >>> On Friday, August 1, 2003, at 11:27 AM, bob@redivi.com wrote: >>> >>>> On Fri, Aug 01, 2003 at 07:04:48PM +0200, Torsten Sadowski wrote: >>>>> Great news, >>>>> >>>>> I would also be interested in the things you did to make it work, >>>>> because >>>>> - the carbon version did not build because of a problem between >>>>> the tk and >>>>> the carbon framework >>>>> - the python test failed because the wrapper libraries were not >>>>> linked >>>>> together. >>>> >>>> That's what it look like to me. It looks like their Python >>>> wrappers are currently expecting -flat_namespace -undefined >>>> suppress and a specific import order.. but Python is not linking >>>> the .so's that >>> way. >>>> >>>> The best way to do this would be to fix the VTK build process so >>>> that it links hte dependent libraries together and doesn't mess up. >>>> That's really NOT the way to do extension->extension dependencies >>>> in Python, though. >>>> >>>> -bob >>>> >>>> _______________________________________________ >>>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>> >>>> >>> _____________________________ >>> Robb Brown >>> Seaman Family MR Center >>> Calgary, AB >>> >> >> > _____________________________ > Robb Brown > Seaman Family MR Center > Calgary, AB > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen at cwi.nl Sat Aug 2 00:39:58 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 17:40:07 2003 Subject: [Pythonmac-SIG] Building Packages for PackageManager In-Reply-To: <277A29D0-C43B-11D7-8E5A-000A959032C4@ucalgary.ca> Message-ID: On vrijdag, aug 1, 2003, at 18:13 Europe/Amsterdam, Robb Brown wrote: > First, congratulations to Jack and everyone else on the new version of > MacPython! Building Python always worked very well on the Mac, but > the installer and PackageManager is a big step forward! > > I'm interested in creating a VTK package (among other things) for use > with PackageManager. Is there any documentation on creating packages? Not yet, but let's start with some! Here's what I would do: - Grab the existing database, clear out all packages except one source package. PyObjC or Numeric are fairly run-of-the-mill source packages. You'll find the URL of the standard database via . - Fill in your own name and description at the top of the database. - Edit that source package to point to the source package you want to build, and change name, version, etc. - For now, comment out the md5sum field of the package. - Add an include to the main database (see the experimental database for details). This will allow you to depend on packages in there, especially the psuedo-packages like AppleDeveloperTools. - Run Package Manager or pimp with your database, and try to download and build from source. - If the download worked: run md5sum on the downloaded tarball in /tmp, and fill in the md5sum field. - If the build needs more than "python setup.py install": see the way PIL is built for how to do a pre-build step. - If the source doesn't build out of the box you have to fix it and create your own modified source distribution. - Once building from source worked you start on the binary package. Go to the unpacked directory in /tmp and type "python setup.py bdist_dumb". You binary distribution ends up in the dist directory. Calculate the md5sum and upload to your webserver. - Edit the database, duplicate the record for the source distribution. Change type to binary, change the URL, the md5sum and probably the description slightly. Take the dependency on AppleDeveloperTools (and maybe more) out of your dependencies. - Zap whatever building the source distribution installed into site-packages. Try to install from binary. - Zap again, and try a per-user source install. If it doesn't work: set the SystemWideOnly flag in the database record. - Zap again (it's now in ~/Library/Python/2.3/site-packages/) and try a per-user binary install. Again, if it doesn't work set the SystemWideOnly flag in the database record. When this is all done send an angry mail to the SIG telling me which steps I missed or didn't explain correctly:-) Once you have a skeleton database you could also use Bob's makepimp tool to create new database entries. -- - 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 Sat Aug 2 00:41:25 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 17:41:31 2003 Subject: [Pythonmac-SIG] Anyone interested in 10.1 support? In-Reply-To: Message-ID: On vrijdag, aug 1, 2003, at 18:31 Europe/Amsterdam, Pascal Oberndoerfer wrote: > Jack Jansen at Jack.Jansen@cwi.nl: > >> I just tried to build MacPython for 10.1, and it doesn't work due to >> one >> bug: the #! lines in applets don't work. This was discussed here half >> a year ago, but I had conveniently forgotten:-). > > So if I don't care for applets I can safely build MacPython for 10.1 > from > source? Yes. You want to apply though, otherwise the MacOS module won't compile. -- - 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 p.oberndoerfer at urheberrecht.org Fri Aug 1 19:31:05 2003 From: p.oberndoerfer at urheberrecht.org (Pascal Oberndoerfer) Date: Fri Aug 1 17:42:02 2003 Subject: [Pythonmac-SIG] Anyone interested in 10.1 support? In-Reply-To: <05F998BE-C420-11D7-BE84-0030655234CE@cwi.nl> Message-ID: Jack Jansen at Jack.Jansen@cwi.nl: > I just tried to build MacPython for 10.1, and it doesn't work due to one > bug: the #! lines in applets don't work. This was discussed here half > a year ago, but I had conveniently forgotten:-). So if I don't care for applets I can safely build MacPython for 10.1 from source? Pascal From loredo at astro.cornell.edu Fri Aug 1 13:36:59 2003 From: loredo at astro.cornell.edu (Tom Loredo) Date: Fri Aug 1 17:42:04 2003 Subject: [Pythonmac-SIG] For your eyes only: MacPython-OS9 2.3 installer Message-ID: <200308011636.h71Gaxt20677@laplace.astro.cornell.edu> Hi Jack- I'm about to head out of town for a business trip, but I thought I'd give the installers a quick try before I left. I tried both the OS9 and OSX installers on a G4 QuickSilver, the OS9 while booted into 9.2.2, and the OSX one booted into 10.2.6. Unfortunately I can only offer limited feedback because most of my python computing is running cross-platform scripts with no GUIs that work at my office computer (Solaris) and on the Mac at home. So I am not exercising the Mac GUI stuff (except via the IDE) and I only minimally use the macfs module. The OS9 installer ran fine, and the interpreter and IDE both appear to work as before for the most part. Many of my scripts do numerical stuff and rely on my own extensions, but unfortunately I could not build my extensions because I am still using CW5 (the patch that let 2.2 work with CW5 does not succeed with 2.3, but it only gives a few errors and I think I may just need updated headers; no time to look into it now). I did successfully run some scripts that use PIL, and also successfully imported Numeric and verified basic stuff works. I didn't run the test suite yet---it slipped my mind! I'll try it before I leave. Two slight peculiarities: To successfully "import Image" I had to add the PIL directory to my Python path (i.e., PIL.pth appears not to work as it does on my Solaris box); I think I've always had to do this but 2.2 was long enough ago that I don't remember for sure. Also, when I start the IDE, it does not automatically open an interpreter window as it did before. I like having it there and find it a nuisance to have to open it manually; I couldn't find a way to change this default behavior with the preferences. The OS X installer also ran without a hitch, and again ran basic numeric scripts fine. I also verified that it didn't affect the Apple python installation. I wish I could offer you more thorough testing, but time constraints prevent this. Hopefully this small extra "datum" will be useful anyway. -Tom Loredo From mbagai at arslegal.com Fri Aug 1 15:49:03 2003 From: mbagai at arslegal.com (Morten Bagai) Date: Fri Aug 1 17:49:59 2003 Subject: [Pythonmac-SIG] Package suggestions Message-ID: Hi there, I'm fairly new to Python and to this group as well. I've got the latest MacPython OS X running, and I must say it is looking pretty awesome. I really like the idea of the PackageManager as well, and wanted to suggest a few packages I'd like to see in there. I hope this is the right forum for it. Here goes: 1. python-mysql For whatever reason - maybe just newbie confusion - I've had trouble getting this to work with previous versions of Unix Python I had installed through fink and the built-in version 2. pyXML It would just be really sweet to have all those XML tools install just like that :) Unfortunately, I've got a ways to go before I'd be able to embark on creating packages myself, so I am hoping someone here is able to pick up the gauntlet. Thanks! Morten From Jack.Jansen at cwi.nl Sat Aug 2 00:50:54 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 17:51:00 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <2355C67B-C449-11D7-8E5A-000A959032C4@ucalgary.ca> Message-ID: <399C2F2A-C46A-11D7-A5E7-000A27B19B96@cwi.nl> On vrijdag, aug 1, 2003, at 19:54 Europe/Amsterdam, Robb Brown wrote: > Uh oh. Did this change from Python 2.2 to 2.3? Last I checked VTK > DOES use -flat_namespace (at least for Carbon). Yes, it changed. And I would have dearly liked to change it for 2.2.1, but vtk used it, so I couldn't in the name of backward compatibility:-( The flat namespace is a hole big enough to drive a truck through: *any* global symbol used by *any* module will be satisfied by a symbol with the same name from anything that was by chance loaded previously. This will lead to spectacular crashes, that will miraculously disappear when you try to debug them in isolation:-) Does vtk run on windows? If it does it must have a way around the trick of using symbols exported by something imported earlier. There are various possibilities: a common shared library used to communicate between the modules, a cobject with pointers exported from module A imported by module B, a poor mans version of the latter using a string with a magic name (Numeric does 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 Jack.Jansen at cwi.nl Sat Aug 2 00:58:27 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 17:58:36 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: Message-ID: <47ADDA21-C46B-11D7-A5E7-000A27B19B96@cwi.nl> On vrijdag, aug 1, 2003, at 22:27 Europe/Amsterdam, Bob Ippolito wrote: > There's three ways that I know of to do it: > (1) Inject Mach-O loader commands into the .so's that have > dependencies directly after compilation (something like > install_name_tool but more dangerous, I could write one of these using > the "potool" code I have) > (2) Trick the linker by whatever means.. i.e. not using -l, or > renaming to lib*.dylib then editing the Mach-O loaders with > install_name_tool after the fact. I think neither of these two will work. For one, Python extensions are bundles (Mach-O bundles, not MacOSX bundles), not dynamic libraries. If you want to use linker magic I would suggest building the modules *except their init routines* into .dylibs, linking them against each other as needed, and putting the init routines (linked against their .dylib) in the .so bundles. But you may still need to fiddle DYLD_LIBRARY_PATH at runtime:-( > (3) Fix VTK to use the recommended Python way for inter-extension > dependencies, like the way that numarray does it. Basically what you > do is use Python to import the module containing the things you depend > on. That module has a way of giving you various pointers to C > functions, and you setup a jump table based upon that. See: > http://stsdas.stsci.edu/numarray/Doc/node37.html That's really the way to go, assuming numarray uses cobjects in stead of the string hack that was used in Numeric. -- - 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 list at mchsi.com Fri Aug 1 18:04:57 2003 From: list at mchsi.com (Andrew Hartung) Date: Fri Aug 1 18:05:03 2003 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <9EC63EF0-C455-11D7-853A-000A95686CD8@redivi.com> Message-ID: <2FFF4522-C46C-11D7-87DC-00306583718C@mchsi.com> Ok, I installed MacPython; can I make the PackageManager recognize programs I've installed via fink, like readline? fink has its own SDL packages, should I stay away from them and use the ones from Bob(thanks for pygame BTW)? Thank you, Andrew Hartung From brownr at ucalgary.ca Fri Aug 1 17:12:28 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 1 18:13:11 2003 Subject: [Pythonmac-SIG] Has anyone running vtk+python on OSX? In-Reply-To: <399C2F2A-C46A-11D7-A5E7-000A27B19B96@cwi.nl> Message-ID: <3D47EB72-C46D-11D7-8E5A-000A959032C4@ucalgary.ca> I noticed the problem back when 2.3 first appeared in CVS... I'm kicking myself for not bugging the VTK guys to make it work then. VTK does run on Windows. I wonder if we can use their Windows tricks. Maybe they've all broken too though. Unfortunately it sounds like all those would require some major tinkering with VTK (which has to be done eventually). I wonder if VTK is planning to move over to Cable wrapping, and when. Also, this would be a lot easier if somebody who knows the guts of VTK building and wrapping would help out. I posted a message to the VTK mailing list, but it's been absolutely dead today. Thanks for the info about packages, by the way. I'm going on vacation for a week so I won't have the chance to play, but I'll give it a try when I get back. If things go well, I'll write a tutorial! On Friday, August 1, 2003, at 03:50 PM, Jack Jansen wrote: > > On vrijdag, aug 1, 2003, at 19:54 Europe/Amsterdam, Robb Brown wrote: > >> Uh oh. Did this change from Python 2.2 to 2.3? Last I checked VTK >> DOES use -flat_namespace (at least for Carbon). > > Yes, it changed. And I would have dearly liked to change it for 2.2.1, > but vtk used it, so I couldn't in the name of backward > compatibility:-( The flat namespace is a hole big enough to drive a > truck through: *any* global symbol used by *any* module will be > satisfied by a symbol with the same name from anything that was by > chance loaded previously. This will lead to spectacular crashes, that > will miraculously disappear when you try to debug them in isolation:-) > > Does vtk run on windows? If it does it must have a way around the > trick of using symbols exported by something imported earlier. There > are various possibilities: a common shared library used to communicate > between the modules, a cobject with pointers exported from module A > imported by module B, a poor mans version of the latter using a string > with a magic name (Numeric does 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 - > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From bob at redivi.com Fri Aug 1 19:14:25 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 18:14:34 2003 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <2FFF4522-C46C-11D7-87DC-00306583718C@mchsi.com> Message-ID: <828D2CB2-C46D-11D7-853A-000A95686CD8@redivi.com> On Friday, Aug 1, 2003, at 18:04 America/New_York, Andrew Hartung wrote: > Ok, I installed MacPython; can I make the PackageManager recognize > programs I've installed via fink, like readline? fink has its own SDL > packages, should I stay away from them and use the ones from > Bob(thanks for pygame BTW)? Fink and MacPython are mutually exclusive.. Nothing from one should touch anything from the other for now. I have no plans whatsoever for making anything compatible with already-installed fink stuff, because I don't have fink installed and I don't want to force anyone to install fink. -bob From bob at redivi.com Fri Aug 1 19:17:18 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 18:17:28 2003 Subject: [Pythonmac-SIG] Building Packages for PackageManager In-Reply-To: Message-ID: On Friday, Aug 1, 2003, at 17:39 America/New_York, Jack Jansen wrote: > > On vrijdag, aug 1, 2003, at 18:13 Europe/Amsterdam, Robb Brown wrote: > >> First, congratulations to Jack and everyone else on the new version >> of MacPython! Building Python always worked very well on the Mac, >> but the installer and PackageManager is a big step forward! >> >> I'm interested in creating a VTK package (among other things) for use >> with PackageManager. Is there any documentation on creating >> packages? > > Not yet, but let's start with some! > > Here's what I would do: > - Grab the existing database, clear out all packages except one source > package. PyObjC or Numeric are fairly run-of-the-mill source packages. > You'll find the URL of the standard database via > . > - Fill in your own name and description at the top of the database. > - Edit that source package to point to the source package you want to > build, and change name, version, etc. > - For now, comment out the md5sum field of the package. > - Add an include to the main database (see the experimental database > for details). This will allow you to depend on packages in there, > especially the psuedo-packages like AppleDeveloperTools. > - Run Package Manager or pimp with your database, and try to download > and build from source. > - If the download worked: run md5sum on the downloaded tarball in > /tmp, and fill in the md5sum field. > - If the build needs more than "python setup.py install": see the way > PIL is built for how to do a pre-build step. > - If the source doesn't build out of the box you have to fix it and > create your own modified source distribution. > - Once building from source worked you start on the binary package. Go > to the unpacked directory in /tmp and type "python setup.py > bdist_dumb". You binary distribution ends up in the dist directory. > Calculate the md5sum and upload to your webserver. > - Edit the database, duplicate the record for the source distribution. > Change type to binary, change the URL, the md5sum and probably the > description slightly. Take the dependency on AppleDeveloperTools (and > maybe more) out of your dependencies. > - Zap whatever building the source distribution installed into > site-packages. Try to install from binary. > - Zap again, and try a per-user source install. If it doesn't work: > set the SystemWideOnly flag in the database record. > - Zap again (it's now in ~/Library/Python/2.3/site-packages/) and try > a per-user binary install. Again, if it doesn't work set the > SystemWideOnly flag in the database record. > > When this is all done send an angry mail to the SIG telling me which > steps I missed or didn't explain correctly:-) Once you have a skeleton > database you could also use Bob's makepimp tool to create new database > entries. So this is what you've been doing for every package?! Wow. What I do is download a package, chdir to its folder, make sure it builds (if I don't know this already), type makepimp, edit the plist if I need to, and then makepimp sync to upload the new plist ;) I'll have makepimp create a skeleton database and stuff sometime soon. VTK is significantly more complicated because it has stuff all over the place, I don't even think it has a setup.py. -bob From Jack.Jansen at cwi.nl Sat Aug 2 01:17:28 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 18:17:35 2003 Subject: [Pythonmac-SIG] Should we do a press release? Message-ID: Folks, should we create a press release for MacPython 2.3? Does anyone have any experience with writing one? I don't think we can re-use the general Python 2.3 press release, although we can probably borrow from it, but I think we'd need to focus on the mac community. Also, we'd need to get a fairly decent list of places to send it, otherwise it isn't worth the trouble. Does anyone have a list of Mac publications? -- - 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 Sat Aug 2 01:25:32 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 18:25:40 2003 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <2FFF4522-C46C-11D7-87DC-00306583718C@mchsi.com> Message-ID: <109956EE-C46F-11D7-A5E7-000A27B19B96@cwi.nl> On zaterdag, aug 2, 2003, at 00:04 Europe/Amsterdam, Andrew Hartung wrote: > Ok, I installed MacPython; can I make the PackageManager recognize > programs I've installed via fink, like readline? fink has its own SDL > packages, should I stay away from them and use the ones from > Bob(thanks for pygame BTW)? fink Python and MacPython are blissfully unaware of each other. And that is a good thing too: if one would try to use a dynamic module built for the other things can go very wrong. I keep forgetting which direction goes wrong (framework Python using module for static Python or the other way around), but one of the directions fails without a reasonable error message. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen at cwi.nl Sat Aug 2 01:28:24 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 18:28:32 2003 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <828D2CB2-C46D-11D7-853A-000A95686CD8@redivi.com> Message-ID: <7693DE64-C46F-11D7-A5E7-000A27B19B96@cwi.nl> On zaterdag, aug 2, 2003, at 00:14 Europe/Amsterdam, Bob Ippolito wrote: > > On Friday, Aug 1, 2003, at 18:04 America/New_York, Andrew Hartung > wrote: > >> Ok, I installed MacPython; can I make the PackageManager recognize >> programs I've installed via fink, like readline? fink has its own SDL >> packages, should I stay away from them and use the ones from >> Bob(thanks for pygame BTW)? > > Fink and MacPython are mutually exclusive.. Nothing from one should > touch anything from the other for now. Do you really mean "mutually exclusive", as in: if you install the one don't install the other? Or do you mean what I, in the other reply, called "blissfully unaware": different install locations, different pythonpaths, 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 Sat Aug 2 01:44:08 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 18:44:14 2003 Subject: [Pythonmac-SIG] PackageManager philosophy In-Reply-To: Message-ID: Changing the subject on this, because it is important. On zaterdag, aug 2, 2003, at 00:17 Europe/Amsterdam, Bob Ippolito wrote: > So this is what you've been doing for every package?! Wow. > > What I do is download a package, chdir to its folder, make sure it > builds (if I don't know this already), type makepimp, edit the plist > if I need to, and then makepimp sync to upload the new plist ;) Yes, I already got the impression this is what you did:-) I think we have rather different ideas on what Package Manager is, and it's probably good if we work out whether it can be both. I think that to you Package Manager is mainly PyPI on steroids: not only does it allow the end user to find packages, but it builds them as well. The database maintainer once creates the build recipes, and hopefully that is all s/he ever does, preferably updates of the package should be handled by the package author, or else with as little trouble for the database maintainer as possible. Right? To me Package Manager is a way to split a Batteries Included distribution into multiple manageable parts. The database maintainer does similar work to what a System Integrator does for turnkey systems: combine the parts, test them, take responsibility for the end product. I didn't call him/her "scapegoat" for nothing:-) (Incidentally: I want to get rid of the term. Anyone a better idea? System Integrator is too serious, Database Manager too vague...) That the "database manager" may in actuality be multiple people doesn't really matter, to the end user they're a single entity with a single email address who take responsibility for things in the database working. Note that "responsible" should be taken with the open source context in mind: "morally responsible" is probably as far as it goes, if that far. I have been "responsible" for MacPython distributions for a couple of years. Not because you could sue me if they don't work, not because I did all the work on them, but simply because I created the final installer and they have my name on it as the first point of contact. I'll explain tomorrow why I think the two uses may bite each other, and also why I think that having lots and lots of packages may actually be a bad thing in stead of a good thing. -- - 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 dsposx at mac.com Fri Aug 1 16:40:09 2003 From: dsposx at mac.com (Donovan Preston) Date: Fri Aug 1 19:00:38 2003 Subject: [Pythonmac-SIG] PackageManager / Python 2.3.x - 2.4 ideas Message-ID: On Friday, August 1, 2003, at 6:26 AM, Schollnick, Benjamin wrote: > > This is a little too general... > > Concurrency does require a good examination of what is happening, and > the > project flow... This may be possible for smaller programs, but since threading introduces nondeterministic context switching (a context switch may happen at any time), I would argue that this is impossible for a program of sufficient complexity. > But what I found worked in multiple cases, was reducing the issue, > until I > had > the "actions" being handled by a object. Thus I would create multiple > objects, and > pass them into the threads for servicing. Once the thread finished, I > would > retrieve > the data from the object, destroy the object, and continue on... How do you know the thread is finished? Do you have a callback mechanism? Or Polling? > Yes, this model does not work every where... But often, when working > in a > OOP model, > I keep coming back to a similiar model... So how is this any different than making your API properly asynchronous? If you are already dividing your functions up into "actions", you might as well be handling control flow explicitly through the use of callbacks. The problem with threading is nondeterminacy. Since a context switch can happen at any time, and is beyond the control of the programmer, your program may work properly 99.999999999% of the time. However, it may fail 0.000000001% of the time due to lock contention issues (deadlocks) or data-corruption issues due to state sharing between threads, and when it does, it is utterly impossible to debug, because chances are the deadlock condition will be impossible to reproduce in the debugger due to timing issues. It is mathematically impossible to prove the correctness of a threaded program. The number of possible control flows is just too large. Would you rather be up all night debugging deadlocks (because all programs have bugs) or doing real work? But, you say, a single-threaded application does not take advantage of my dual 2ghz G5 machine with it's two processors. Well, for one, neither does Python. So the only way to take advantage of both of those processors is to fork another process and explicitly share state using IPC mechanisms, which is what you should be doing anyway. Operating systems implement protected memory mechanisms and process context switching for a reason. > Threading in a non-OOP environment is harder... When I rewrote parts > of > Stathost, > and made it into a multithreaded application, to speed it up... I had > to > basically > graft a OOP manager on top of the system for the threading... But it > was > not difficult.. There's no excuse for not using an asynchronous model in a language like Python which includes many features which make it very easy and convenient. Bound method references, closures, and lambdas make it very easy to capture state for use in your callbacks, while automatically and correctly managing the reference counting for garbage collection purposes. dp From bob at redivi.com Fri Aug 1 21:03:21 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 20:03:54 2003 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <7693DE64-C46F-11D7-A5E7-000A27B19B96@cwi.nl> Message-ID: On Friday, Aug 1, 2003, at 18:28 America/New_York, Jack Jansen wrote: > > On zaterdag, aug 2, 2003, at 00:14 Europe/Amsterdam, Bob Ippolito > wrote: > >> >> On Friday, Aug 1, 2003, at 18:04 America/New_York, Andrew Hartung >> wrote: >> >>> Ok, I installed MacPython; can I make the PackageManager recognize >>> programs I've installed via fink, like readline? fink has its own >>> SDL packages, should I stay away from them and use the ones from >>> Bob(thanks for pygame BTW)? >> >> Fink and MacPython are mutually exclusive.. Nothing from one should >> touch anything from the other for now. > > Do you really mean "mutually exclusive", as in: if you install the one > don't install the other? Or do you mean what I, in the other reply, > called "blissfully unaware": different install locations, different > pythonpaths, etc? Fink Python vs. MacPython are typically "blissfully unaware". Fink dylibs vs. building MacPython extensions is definitely not, you know this from experience by now, I'm sure ;) -bob From bob at redivi.com Fri Aug 1 21:42:01 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 20:42:24 2003 Subject: [Pythonmac-SIG] PackageManager philosophy In-Reply-To: Message-ID: <21200D99-C482-11D7-8BED-000A95686CD8@redivi.com> On Friday, Aug 1, 2003, at 18:44 America/New_York, Jack Jansen wrote: > Changing the subject on this, because it is important. > > On zaterdag, aug 2, 2003, at 00:17 Europe/Amsterdam, Bob Ippolito > wrote: >> So this is what you've been doing for every package?! Wow. >> >> What I do is download a package, chdir to its folder, make sure it >> builds (if I don't know this already), type makepimp, edit the plist >> if I need to, and then makepimp sync to upload the new plist ;) > > Yes, I already got the impression this is what you did:-) > > I think we have rather different ideas on what Package Manager is, and > it's probably good if we work out whether it can be both. > > I think that to you Package Manager is mainly PyPI on steroids: not > only does it allow the end user to find packages, but it builds them > as well. The database maintainer once creates the build recipes, and > hopefully that is all s/he ever does, preferably updates of the > package should be handled by the package author, or else with as > little trouble for the database maintainer as possible. Right? > > To me Package Manager is a way to split a Batteries Included > distribution into multiple manageable parts. The database maintainer > does similar work to what a System Integrator does for turnkey > systems: combine the parts, test them, take responsibility for the end > product. I didn't call him/her "scapegoat" for nothing:-) > (Incidentally: I want to get rid of the term. Anyone a better idea? > System Integrator is too serious, Database Manager too vague...) That > the "database manager" may in actuality be multiple people doesn't > really matter, to the end user they're a single entity with a single > email address who take responsibility for things in the database > working. > > Note that "responsible" should be taken with the open source context > in mind: "morally responsible" is probably as far as it goes, if that > far. I have been "responsible" for MacPython distributions for a > couple of years. Not because you could sue me if they don't work, not > because I did all the work on them, but simply because I created the > final installer and they have my name on it as the first point of > contact. > > I'll explain tomorrow why I think the two uses may bite each other, > and also why I think that having lots and lots of packages may > actually be a bad thing in stead of a good thing. I want someone to be able to download Python, click a few things, and then run whatever they want. Even if they don't have Developer Tools installed. I don't want someone to go to 12 different web pages, download 6 binary pkg installers, 3 source distributions, and check out 3 things from CVS. I probably want this for myself more than anyone else. I can't begin to count the hours I've spent finding packages, downloading source from the webpage, waiting for the compile, see it didn't work, fixing it, and then installing it. Basically, I want to be able to say "hey , go check out this app I wrote" and they'd be able to do it and get it working without me going to their house/desk/exchanging a flurry of emails/etc. I want to be able to manage the installations of Python on all of the machines at the office, so that the utilities I write for my coworkers run well. I'd love for them to be able to manage it themselves. I don't want to have to include a full copy of Python with any app I distribute. I want to be able to eat those words and include a slim version of Python and dependencies inside of an app bundle with a simple bundlebuilder flag if I need to. I could go on for a while here, but basically I want python to work for mac users, and to save people like us who can do it ourselves great deals of time in locating+installing packages. I mean obviously, it's not going to save the package maintainers much time, but someone has to do it. So like you, I want things to just work like anything else. But I also want the maximum amount of utility to the package database. I want people to be able to get up and going with Tk, WxWindows, Qt (soon?), ObjC, pygame, Twisted, Zope (eventually?), apple events, database programming, etc. within minutes (depending on their connection speed). I'm not too concerned about testing things up front at this point, because (a) not many people are using package manager (b) hardly anyone is using my database (c) I don't have time to test them all so I'm hoping someone else will tell me if it's broken. If something is broken (i.e. an install fails, or a source package doesn't build/install) then the user should have an option from the Package Manager interface to send a bug report to whoever put it in the database (you or I, whoever has that kind of access.. it should be sent directly to who is responsible, just like MacPython bug reports on SF get assigned to you automagically), this should be done automagically so it includes the actual debugging information we need (OS version, python version, installation locations, permissions, verbose log of what happened, etc) as well as whatever the user has to say. There should be a central place where a user can say "I want this package available for this platform+python version", so that someone would go ahead and test/build that. I definitely don't want to be more than morally responsible for anything I do :) System Integrator, Database Manager, Scapegoat, .. how about Platform Manager? -bob From Jack.Jansen at cwi.nl Sat Aug 2 04:28:16 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 1 21:28:22 2003 Subject: [Pythonmac-SIG] PackMan->ChapMan Message-ID: <976F9092-C488-11D7-AE60-000A27B19B96@cwi.nl> Folks, it's late, but I'd like to share this one. One of the non-issues that's been bothering me with Package Manager was the name, as you know. Package Manager is boring, pimp got voted down, PackMan is already taken... Then at a hunch I picked up the dictionary, and it turns out the (old-)english word for a traveling salesman in assorted wares ("marskramer" for those who speak dutch) is: "Chapman". What do you think? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bob at redivi.com Fri Aug 1 23:56:46 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Aug 1 22:56:51 2003 Subject: [Pythonmac-SIG] Additional binary packages for Python2.3 on 10.2.6 In-Reply-To: Message-ID: Anyone that's downloaded pygame from my repository should do an Overwrite on their sdl_pygame_deps-1.2.5-binary, the SDL_Mixer I had used before didn't have working OGG support (I believe it was the binary install from libsdl.org). The one up there now does (I compiled it from CVS). The Package Manager repository is (still) at: http://undefined.org/python/pimp/darwin-6.6-Power_Macintosh.plist The current package list: sdl_pygame_deps-1.2.5-binary aeve-0.0.2-binary egenix-mx-base-2.0.4-binary pyOpenSSL-0.5.1-binary ctypes-0.6.2-binary pycrypto-1.9a6-binary Twisted-1.0.7alpha2-binary PIL-1.1.4-binary (has freetype2 support) <-- Jack, you should pick this up ASAP PyOpenGL-2.0.1.05-binary (has andrew's patch) <-- Jack, you should pick this up ASAP pygame-1.5.6-binary (has some patches by me) Pyro-3.3beta-binary numarray-0.6.1-binary ZODB3-3.2b2-binary PythonCardPrototype-0.7.1-binary pycurl-7.10.5-binary (linked static to newest libcurl, OS X 10.2.6 libcurl is too old) PyChecker-0.8.12-binary pygsear-0.47.1-binary I think what I'm going to do next is compile PostgreSQL and MySQL modules for common installations (the entropy.ch PostgreSQL.. and whatever MySQL I find first). After that I'm going to go through these modules and make the "Extras" packages for them (particularly pygame, PythonCardPrototype, Twisted, pygsear, aeve). I also compiled a quick little bundle for Pyx (a Qix clone using pygame). You can take a look at it here: http://undefined.org/python/Pyx.app.tgz It needs MacPython 2.3 and pygame installed. If anyone has any requests for packages (no, I can't build panther packages right now.. my panther box broke) or finds an issue with what I've got, let me know. -bob From altis at semi-retired.com Fri Aug 1 21:35:44 2003 From: altis at semi-retired.com (Kevin Altis) Date: Fri Aug 1 23:29:19 2003 Subject: [Pythonmac-SIG] scrollback? In-Reply-To: Message-ID: If there was an answer to this question I never saw it, but I now realize I have the same issue with 2.3 in the Terminal; sorry I didn't mention it earlier. I'm assuming I need to set something for my TERM or TERMCAP environment variables? Pressing the Up arrow show give you the previously typed command in the shell at the >>> prompt, instead it just shows the VT100 escape sequence for the up arrow. ka > -----Original Message----- > From: Jack Jansen > Sent: Saturday, July 19, 2003 5:19 PM > To: chris@fisher.forestry.uga.edu > Cc: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] scrollback? > > > > On vrijdag, jul 18, 2003, at 02:13 Europe/Amsterdam, > chris@fisher.forestry.uga.edu wrote: > > > Is there any way of properly enabling the arrow keys in macpython? > > Either > > trying to scrollback with the up and down arrows, or moving through the > > current line with the left and right arrows instead produces nonsense > > characters like "^[[A". This is very frustrating; does anyone know how > > I can > > fix this? > > Which "MacPython" are you referring to, here? If you're referring to > either MacPython 2.2.X > or MacPython-OS9 2.3 then the answer is: "No, MacPython for OS9 is in > maintenance mode". > > If it's about MacPython 2.3 for OSX then the next question is "where > are you experiencing > this? In the IDE? In a Terminal window?" > -- > - 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 dsposx at mac.com Fri Aug 1 21:43:25 2003 From: dsposx at mac.com (Donovan Preston) Date: Fri Aug 1 23:43:33 2003 Subject: [Pythonmac-SIG] scrollback? In-Reply-To: References: Message-ID: <7902E1FE-C49B-11D7-86D8-000A95864FC4@mac.com> On Friday, August 1, 2003, at 8:35 PM, Kevin Altis wrote: > If there was an answer to this question I never saw it, but I now > realize I > have the same issue with 2.3 in the Terminal; sorry I didn't mention it > earlier. I'm assuming I need to set something for my TERM or TERMCAP > environment variables? > > Pressing the Up arrow show give you the previously typed command in the > shell at the >>> prompt, instead it just shows the VT100 escape > sequence for > the up arrow. You need readline. If you installed the MacPython 2.3 dmg, you can use Package Manager to install it. dp From kevino at tulane.edu Fri Aug 1 23:08:17 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Sat Aug 2 01:11:17 2003 Subject: [Pythonmac-SIG] PackMan->ChapMan In-Reply-To: <976F9092-C488-11D7-AE60-000A27B19B96@cwi.nl> Message-ID: <54086966-C4A7-11D7-8EAD-000393CB1C86@tulane.edu> I personally like Package Manager. I don't think the name is boring, in the sense that when someone hears of something called "Python Package Manager" I think their reaction will be "Cool, where can I get it?!" ;-) In this particular case, Package Manager so accurately sums up its purpose that it seems the natural choice. Kevin On Friday, August 1, 2003, at 06:28 PM, Jack Jansen wrote: > Folks, > it's late, but I'd like to share this one. One of the non-issues > that's been bothering me with Package Manager was the name, as you > know. Package Manager is boring, pimp got voted down, PackMan is > already taken... > > Then at a hunch I picked up the dictionary, and it turns out the > (old-)english word for a traveling salesman in assorted wares > ("marskramer" for those who speak dutch) is: "Chapman". > > What do you think? > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From kevino at tulane.edu Fri Aug 1 23:13:43 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Sat Aug 2 01:19:01 2003 Subject: [Pythonmac-SIG] PackageManager philosophy In-Reply-To: Message-ID: <1624762D-C4A8-11D7-8EAD-000393CB1C86@tulane.edu> On Friday, August 1, 2003, at 03:44 PM, Jack Jansen wrote: > Changing the subject on this, because it is important. > > On zaterdag, aug 2, 2003, at 00:17 Europe/Amsterdam, Bob Ippolito > wrote: >> So this is what you've been doing for every package?! Wow. >> >> What I do is download a package, chdir to its folder, make sure it >> builds (if I don't know this already), type makepimp, edit the plist >> if I need to, and then makepimp sync to upload the new plist ;) > > Yes, I already got the impression this is what you did:-) > > I think we have rather different ideas on what Package Manager is, and > it's probably good if we work out whether it can be both. > How about this? To make PM behave more in line with your goals (as I understand them, anyways) while still giving Bob and others (myself included) the functionality and flexibility they desire, I was thinking there could be some sort of "stamp of approval" to say that the 'scapegoat' (Package Inspector - PI? =) has tested package X binaries on platforms X, Y and Z. A warning could pop up if such an approval doesn't exist - "Warning: This package has not been confirmed to work on your particular platform or sufficiently tested. If you experience any installation problems, please report any problems to scapegoat@python.org" - sort of like digital signatures. Or, the end user could configure PM to simply not show any untested packages. (it could also be shipped this way by default) It seems to me that you're aiming for a more traditional development crowd who are used to commercial software and don't want unexpected snafus when trying to install and use modules, and I think that if we build in those sorts of controls, and maybe even turn them on by default, we could do that while still letting those who want to live dangerously install tons of modules without thinking twice. I would really, really like to see both of these goals merged into one kick-ass package management tool for Python. ;-) Thanks, Kevin From kevino at tulane.edu Sat Aug 2 00:14:44 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Sat Aug 2 02:17:43 2003 Subject: [Pythonmac-SIG] Re: [wxPython-mac] Draft wxPackageManager Screenshot In-Reply-To: <3F29561B.E944C904@noaa.gov> Message-ID: <9C5F2FEC-C4B0-11D7-8EAD-000393CB1C86@tulane.edu> On Thursday, July 31, 2003, at 10:47 AM, Chris Barker wrote: > Kevin Ollivier wrote: >> it's at a point where I can take a picture and get >> some comments on UI issues. > > It looks great. > >> - the options box needs to be moved up a bit, I'm using sizers so I >> need to play with this some more ;-) > > Frankly, I think it looks just fine, but you could put a space at the > bottom if you wanted. Let me know if you want any help with this. Actually, I figured out the problem. I was just padding the top and bottom margins too much. Now it looks better (to me, anyways, I'm picky about that stuff =) >> - I'd like there to be some way of visually conveying the status of a >> package. I'm leaning towards little green/yellow/red gumdrops >> (installed/outdated/not installed) next to the package name but I have >> to figure out how to put those into a list box or something similar, >> maybe a wxListCtrl. Or is this overkill? > > No. Visual feedback is important, and I'm pretty sure you can put an > icon in a wxListControl, at least in the first column. Note that there > is talk of having the packages in some kind of hierarchical list, so a > tree control may be warranted. > > Another option is to make the text itself a different color. I considered changing text color, but then I thought it would be too distracting or hard to read, especially yellow packages on Mac. =) The wxListControl approach is probably best and I will play with it some more. Eventually we may need to move to a tree view, but I want to keep it simple for now. >> - I'm planning on adding a "Show only: Installed/Not >> installed/Outdated/Not installed and outdated" combobox above the >> package list so that people can filter and see only what they need. > > Perhaps a set of check boxes: > > O show installed > X show outdated > X show uninstalled > ... > > That way it would be clear what you are looking at, and the user could > select any combo they wanted. This would work, maybe I'll try it this way for now. In the worst case I could move this to a "View" menu item if the interface started getting crowded. (I'd like to display more package info when the user clicks on the package as well.) >> Please let me know what you think! > > It looks great! > > And if this provides an incentive to make wxPython a "Battery", all the > better! Amen to that! ;-) Thanks, Kevin From erik at letterror.com Sat Aug 2 11:27:35 2003 From: erik at letterror.com (Erik van Blokland) Date: Sat Aug 2 04:28:00 2003 Subject: [Pythonmac-SIG] PackMan->ChapMan In-Reply-To: <976F9092-C488-11D7-AE60-000A27B19B96@cwi.nl> Message-ID: Jack Jansen, [Saturday, August 2, 2003] >Then at a hunch I picked up the dictionary, and >it turns out the (old-)english word for a >traveling salesman in assorted wares >("marskramer" for those who speak dutch) is: >"Chapman". Ha! Chapman gets my vote! Erik-the-half-a-Bee From altis at semi-retired.com Sat Aug 2 09:51:56 2003 From: altis at semi-retired.com (Kevin Altis) Date: Sat Aug 2 11:45:09 2003 Subject: [Pythonmac-SIG] PackMan->ChapMan In-Reply-To: <54086966-C4A7-11D7-8EAD-000393CB1C86@tulane.edu> Message-ID: > From: Kevin Ollivier > > I personally like Package Manager. I don't think the name is boring, in > the sense that when someone hears of something called "Python Package > Manager" I think their reaction will be "Cool, where can I get it?!" > ;-) In this particular case, Package Manager so accurately sums up its > purpose that it seems the natural choice. +1 Package Manager is a tool that doesn't need a clever name. It will just confuse users to call it Chapman. ka > Kevin > > On Friday, August 1, 2003, at 06:28 PM, Jack Jansen wrote: > > > Folks, > > it's late, but I'd like to share this one. One of the non-issues > > that's been bothering me with Package Manager was the name, as you > > know. Package Manager is boring, pimp got voted down, PackMan is > > already taken... > > > > Then at a hunch I picked up the dictionary, and it turns out the > > (old-)english word for a traveling salesman in assorted wares > > ("marskramer" for those who speak dutch) is: "Chapman". > > > > What do you think? > > -- > > - 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 oussoren at cistron.nl Sat Aug 2 20:26:52 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Sat Aug 2 13:26:58 2003 Subject: [Pythonmac-SIG] PackMan->ChapMan In-Reply-To: References: Message-ID: <819573C0-C50E-11D7-A095-0003931CFE24@cistron.nl> On Saturday, 2 August, 2003, at 17:51, Kevin Altis wrote: >> From: Kevin Ollivier >> >> I personally like Package Manager. I don't think the name is boring, >> in >> the sense that when someone hears of something called "Python Package >> Manager" I think their reaction will be "Cool, where can I get it?!" >> ;-) In this particular case, Package Manager so accurately sums up its >> purpose that it seems the natural choice. > > +1 > > Package Manager is a tool that doesn't need a clever name. It will just > confuse users to call it Chapman. I agree. An important reason for having the Package Manager is that less Unix-savvy (sp?) users can install new python packages, "hiding" the package manager application doesn't help with that. Sometimes boring is usefull. Ronald From joaoleao at gmx.net Sat Aug 2 19:26:06 2003 From: joaoleao at gmx.net (=?ISO-8859-1?Q?Jo=E3o_Le=E3o?=) Date: Sat Aug 2 13:28:14 2003 Subject: [Pythonmac-SIG] UpGrading + Pygame Message-ID: <6660BFBD-C50E-11D7-96D4-000393967AF4@gmx.net> Hi, I'm reporting this because i don't remember seeing much feedback about installing MacPython 2.3 (final) on top of previous versions (maybe everyone's doing that?). My previous MacPython was 2.3b2-2 and i'm running OS X 10.2.6. The reason i didn't want to make a clean installation was because i was using PyGame. I got it from Andrew Straw and, at that time, his version (MacPython 2.3a2 + PyGame Stuff) was the only (?) binary installer. MacPython 2.3a2 had some bugs (for ex: PM wasn't working) and i "upgraded" to 2.3b2-2. Finally, i installed 2.3 (final) and i was glad to see that PyGame continues to work. Maybe this is the easiest way for a non-experienced user like me to get PyGame running. If i did this the wrong way you can also use it as bad example.. Thanks, jo?o From kevino at tulane.edu Sat Aug 2 11:34:27 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Sat Aug 2 13:37:28 2003 Subject: [Pythonmac-SIG] UpGrading + Pygame In-Reply-To: <6660BFBD-C50E-11D7-96D4-000393967AF4@gmx.net> Message-ID: <90FCD686-C50F-11D7-8EAD-000393CB1C86@tulane.edu> Hi, Just thought I'd say that I also have been upgrading over previous installations rather than doing a clean install, and have never run into any problems with packages when using that method. Not sure if it is the preferred method, but it's the easiest way and if it works... =) Thanks, Kevin On Saturday, August 2, 2003, at 10:26 AM, Jo?o Le?o wrote: > Hi, > > I'm reporting this because i don't remember seeing much feedback about > installing MacPython 2.3 (final) on top of previous versions (maybe > everyone's doing that?). > > My previous MacPython was 2.3b2-2 and i'm running OS X 10.2.6. > The reason i didn't want to make a clean installation was because i > was using PyGame. I got it from Andrew Straw and, at that time, his > version (MacPython 2.3a2 + PyGame Stuff) was the only (?) binary > installer. > MacPython 2.3a2 had some bugs (for ex: PM wasn't working) and i > "upgraded" to 2.3b2-2. > > Finally, i installed 2.3 (final) and i was glad to see that PyGame > continues to work. Maybe this is the easiest way for a non-experienced > user like me to get PyGame running. > If i did this the wrong way you can also use it as bad example.. > > Thanks, > > jo?o > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From gandreas at delver.com Sat Aug 2 14:30:29 2003 From: gandreas at delver.com (Glenn Andreas) Date: Sat Aug 2 14:30:35 2003 Subject: [Pythonmac-SIG] PackMan->ChapMan In-Reply-To: <819573C0-C50E-11D7-A095-0003931CFE24@cistron.nl> References: <819573C0-C50E-11D7-A095-0003931CFE24@cistron.nl> Message-ID: At 7:26 PM +0200 8/2/03, Ronald Oussoren wrote: >On Saturday, 2 August, 2003, at 17:51, Kevin Altis wrote: > >>>From: Kevin Ollivier >>> >>>I personally like Package Manager. I don't think the name is boring, in >>>the sense that when someone hears of something called "Python Package >>>Manager" I think their reaction will be "Cool, where can I get it?!" >>>;-) In this particular case, Package Manager so accurately sums up its >>>purpose that it seems the natural choice. >> >>+1 >> >>Package Manager is a tool that doesn't need a clever name. It will just >>confuse users to call it Chapman. > >I agree. An important reason for having the Package Manager is that >less Unix-savvy (sp?) users can install new python packages, >"hiding" the package manager application doesn't help with that. >Sometimes boring is usefull. > >Ronald As much as I like obscure references, Chapman goes beyond me. Looking it up in dictionary.com shows definitions such as "itinerant peddler" (and has derivations from "Chap" which is "to cheapen"). Things like "Valet", "Porter" or even "Concierge" are a bit more common place and have connotations of people who carry stuff/provide services/fetch packages, etc... but "Package Manager" definitely summed up what it was and what it did. But hey, I also like real snakes... Glenn Andreas gandreas@delver.com Author of Macintosh games: Theldrow 2.3, Blobbo 1.0.2, Cythera 1.0.2 Be good, and you will be lonesome From joaoleao at gmx.net Sat Aug 2 20:46:20 2003 From: joaoleao at gmx.net (=?ISO-8859-1?Q?Jo=E3o_Le=E3o?=) Date: Sat Aug 2 14:48:39 2003 Subject: [Pythonmac-SIG] Additional binary packages for Python2.3 on 10.2.6 Message-ID: <9BA4417A-C519-11D7-96D4-000393967AF4@gmx.net> Hi, i have a previous version of PyGame; the one from Andrew Straw. If i want to install you're version what do you think i should i do with the older? ? clean up the older installation? ? just "upgrade" through PM as described in Andrew Straw's site? Thanks, jo?o On Saturday, August 2, 2003, at 03:56 AM, Bob Ippolito wrote: > Anyone that's downloaded pygame from my repository should do an > Overwrite on their sdl_pygame_deps-1.2.5-binary, the SDL_Mixer I had > used before didn't have working OGG support (I believe it was the > binary install from libsdl.org). The one up there now does (I > compiled it from CVS). > > The Package Manager repository is (still) at: > http://undefined.org/python/pimp/darwin-6.6-Power_Macintosh.plist > > The current package list: > sdl_pygame_deps-1.2.5-binary > aeve-0.0.2-binary > egenix-mx-base-2.0.4-binary > pyOpenSSL-0.5.1-binary > ctypes-0.6.2-binary > pycrypto-1.9a6-binary > Twisted-1.0.7alpha2-binary > PIL-1.1.4-binary (has freetype2 support) <-- Jack, you should pick > this up ASAP > PyOpenGL-2.0.1.05-binary (has andrew's patch) <-- Jack, you should > pick this up ASAP > pygame-1.5.6-binary (has some patches by me) > Pyro-3.3beta-binary > numarray-0.6.1-binary > ZODB3-3.2b2-binary > PythonCardPrototype-0.7.1-binary > pycurl-7.10.5-binary (linked static to newest libcurl, OS X 10.2.6 > libcurl is too old) > PyChecker-0.8.12-binary > pygsear-0.47.1-binary > > I think what I'm going to do next is compile PostgreSQL and MySQL > modules for common installations (the entropy.ch PostgreSQL.. and > whatever MySQL I find first). After that I'm going to go through > these modules and make the "Extras" packages for them (particularly > pygame, PythonCardPrototype, Twisted, pygsear, aeve). > > I also compiled a quick little bundle for Pyx (a Qix clone using > pygame). You can take a look at it here: > http://undefined.org/python/Pyx.app.tgz > > It needs MacPython 2.3 and pygame installed. > > If anyone has any requests for packages (no, I can't build panther > packages right now.. my panther box broke) or finds an issue with what > I've got, let me know. > > -bob From list at mchsi.com Sat Aug 2 17:09:05 2003 From: list at mchsi.com (Andrew Hartung) Date: Sat Aug 2 17:09:39 2003 Subject: [Pythonmac-SIG] Additional binary packages for Python2.3 on 10.2.6 In-Reply-To: Message-ID: <8C79133E-C52D-11D7-A4AC-00306583718C@mchsi.com> On Friday, August 1, 2003, at 09:56 PM, Bob Ippolito wrote: > Anyone that's downloaded pygame from my repository should do an > Overwrite on their sdl_pygame_deps-1.2.5-binary, I get 'sdl_pygame_deps-1.2.5-binary: download: archive does not have correct MD5 checksum' when I try to do this. From jmillr at umich.edu Sat Aug 2 18:13:48 2003 From: jmillr at umich.edu (John Miller) Date: Sat Aug 2 17:13:52 2003 Subject: [Pythonmac-SIG] Re: PackMan->ChapMan Message-ID: <353BFADC-C52E-11D7-9DED-00039303967A@umich.edu> > Then at a hunch I picked up the dictionary, and it turns out the > (old-)english word for a traveling salesman in assorted wares > ("marskramer" for those who speak dutch) is: "Chapman". The first thing I thought of when I read this was 'Johnny Appleseed' whose real name was 'John Chapman'. I then thought the name 'Chapman' quite clever for an Apple-derived product. However, I also agree with those who see 'Package Manager' as perfectly simple and self-descriptive. Perhaps the name 'Chapman' would be more appropriate for some other aspect of the MacPython package; an editor? or file browser? or...? John Miller Technology Services School of Education University of Michigan From Jack.Jansen at cwi.nl Sun Aug 3 00:15:15 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Aug 2 17:15:22 2003 Subject: [Pythonmac-SIG] UpGrading + Pygame In-Reply-To: <6660BFBD-C50E-11D7-96D4-000393967AF4@gmx.net> Message-ID: <6975D402-C52E-11D7-9384-000A27B19B96@cwi.nl> On zaterdag, aug 2, 2003, at 19:26 Europe/Amsterdam, Jo?o Le?o wrote: > Hi, > > I'm reporting this because i don't remember seeing much feedback about > installing MacPython 2.3 (final) on top of previous versions (maybe > everyone's doing that?). > > My previous MacPython was 2.3b2-2 and i'm running OS X 10.2.6. > The reason i didn't want to make a clean installation was because i > was using PyGame. I got it from Andrew Straw and, at that time, his > version (MacPython 2.3a2 + PyGame Stuff) was the only (?) binary > installer. > MacPython 2.3a2 had some bugs (for ex: PM wasn't working) and i > "upgraded" to 2.3b2-2. > > Finally, i installed 2.3 (final) and i was glad to see that PyGame > continues to work. If it works: great! But "officially" (whatever that means) this is discouraged, as there are no guarantees that alfa's and beta's are compatible with anything. In other words, we _could_ have changed APIs between 2.3b2 and 2.3 final, which would have stopped your pygame extension modules working. At best you would get an import error with an undefined symbol, at worst you would get a crash. I'm 99% sure that the only change to the API between b2 and final was the addition of a method to interrupt the main thread from another thread, so you should be safe for this release. -- - 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 joaoleao.gdf at sapo.pt Sat Aug 2 20:26:13 2003 From: joaoleao.gdf at sapo.pt (=?ISO-8859-1?Q?Jo=E3o_Le=E3o?=) Date: Sat Aug 2 17:15:41 2003 Subject: [Pythonmac-SIG] Additional binary packages for Python2.3 on 10.2.6 In-Reply-To: Message-ID: Hi, i have a previous version of PyGame; the one from Andrew Straw. If i want to install you're version what do you think i should i do with the older? ? clean up the older installation? ? just "upgrade" through PM as described in Andrew Straw's site? Thanks, jo?o On Saturday, August 2, 2003, at 03:56 AM, Bob Ippolito wrote: > Anyone that's downloaded pygame from my repository should do an > Overwrite on their sdl_pygame_deps-1.2.5-binary, the SDL_Mixer I had > used before didn't have working OGG support (I believe it was the > binary install from libsdl.org). The one up there now does (I > compiled it from CVS). > > The Package Manager repository is (still) at: > http://undefined.org/python/pimp/darwin-6.6-Power_Macintosh.plist > > The current package list: > sdl_pygame_deps-1.2.5-binary > aeve-0.0.2-binary > egenix-mx-base-2.0.4-binary > pyOpenSSL-0.5.1-binary > ctypes-0.6.2-binary > pycrypto-1.9a6-binary > Twisted-1.0.7alpha2-binary > PIL-1.1.4-binary (has freetype2 support) <-- Jack, you should pick > this up ASAP > PyOpenGL-2.0.1.05-binary (has andrew's patch) <-- Jack, you should > pick this up ASAP > pygame-1.5.6-binary (has some patches by me) > Pyro-3.3beta-binary > numarray-0.6.1-binary > ZODB3-3.2b2-binary > PythonCardPrototype-0.7.1-binary > pycurl-7.10.5-binary (linked static to newest libcurl, OS X 10.2.6 > libcurl is too old) > PyChecker-0.8.12-binary > pygsear-0.47.1-binary > > I think what I'm going to do next is compile PostgreSQL and MySQL > modules for common installations (the entropy.ch PostgreSQL.. and > whatever MySQL I find first). After that I'm going to go through > these modules and make the "Extras" packages for them (particularly > pygame, PythonCardPrototype, Twisted, pygsear, aeve). > > I also compiled a quick little bundle for Pyx (a Qix clone using > pygame). You can take a look at it here: > http://undefined.org/python/Pyx.app.tgz > > It needs MacPython 2.3 and pygame installed. > > If anyone has any requests for packages (no, I can't build panther > packages right now.. my panther box broke) or finds an issue with what > I've got, let me know. > > -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Jack.Jansen at cwi.nl Sun Aug 3 00:18:57 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Aug 2 17:19:03 2003 Subject: [Pythonmac-SIG] PackMan->ChapMan In-Reply-To: Message-ID: On zaterdag, aug 2, 2003, at 20:30 Europe/Amsterdam, Glenn Andreas wrote: > As much as I like obscure references, Chapman goes beyond me. Looking > it up in dictionary.com shows definitions such as "itinerant peddler" That is indeed the second reason why I thought about Chapman. The first being of course to honour Graham. But today I agree with the sentiment expressed here: the user visible tool should be called Package Manager (or Python Package Manager). I might want to use chapman as the name for the underlying machinery, the stuff that is called pimp nowadays. -- - 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 Sat Aug 2 18:22:05 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Aug 2 17:22:07 2003 Subject: [Pythonmac-SIG] PackMan->ChapMan In-Reply-To: Message-ID: <5DAA464C-C52F-11D7-91CE-000A95686CD8@redivi.com> On Saturday, Aug 2, 2003, at 11:51 America/New_York, Kevin Altis wrote: >> From: Kevin Ollivier >> >> I personally like Package Manager. I don't think the name is boring, >> in >> the sense that when someone hears of something called "Python Package >> Manager" I think their reaction will be "Cool, where can I get it?!" >> ;-) In this particular case, Package Manager so accurately sums up its >> purpose that it seems the natural choice. > > +1 > > Package Manager is a tool that doesn't need a clever name. It will just > confuse users to call it Chapman. Yeah, especially us stupid americans, who don't know old english from bad cologne. -bob From bob at redivi.com Sat Aug 2 18:24:02 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Aug 2 17:24:04 2003 Subject: [Pythonmac-SIG] UpGrading + Pygame In-Reply-To: <6660BFBD-C50E-11D7-96D4-000393967AF4@gmx.net> Message-ID: On Saturday, Aug 2, 2003, at 13:26 America/New_York, Jo?o Le?o wrote: > Hi, > > I'm reporting this because i don't remember seeing much feedback about > installing MacPython 2.3 (final) on top of previous versions (maybe > everyone's doing that?). > > My previous MacPython was 2.3b2-2 and i'm running OS X 10.2.6. > The reason i didn't want to make a clean installation was because i > was using PyGame. I got it from Andrew Straw and, at that time, his > version (MacPython 2.3a2 + PyGame Stuff) was the only (?) binary > installer. > MacPython 2.3a2 had some bugs (for ex: PM wasn't working) and i > "upgraded" to 2.3b2-2. > > Finally, i installed 2.3 (final) and i was glad to see that PyGame > continues to work. Maybe this is the easiest way for a non-experienced > user like me to get PyGame running. > If i did this the wrong way you can also use it as bad example.. That is not the "right" way, there is a newer version of pygame / sdl / PIL / etc in my unofficial package repository. This is now Andrew's recommended installation method, see: http://www.visionegg.org/install-macosx-details.html -bob From altis at semi-retired.com Sat Aug 2 15:31:02 2003 From: altis at semi-retired.com (Kevin Altis) Date: Sat Aug 2 17:24:14 2003 Subject: [Pythonmac-SIG] Re: PackMan->ChapMan In-Reply-To: <353BFADC-C52E-11D7-9DED-00039303967A@umich.edu> Message-ID: > From: John Miller > > > Then at a hunch I picked up the dictionary, and it turns out the > > (old-)english word for a traveling salesman in assorted wares > > ("marskramer" for those who speak dutch) is: "Chapman". > > The first thing I thought of when I read this was 'Johnny Appleseed' > whose real name was 'John Chapman'. I then thought the name 'Chapman' > quite clever for an Apple-derived product. However, I also agree with > those who see 'Package Manager' as perfectly simple and > self-descriptive. Perhaps the name 'Chapman' would be more appropriate > for some other aspect of the MacPython package; an editor? or file > browser? or...? For future reference http://us.imdb.com/Name?Chapman,%20Graham However, I think this shows why Monty Python sketches, cast members, etc. generally don't make very good names for Python projects regardless of the number of puns and other clever references you might be able to associate with the name. ka From bob at redivi.com Sat Aug 2 18:28:18 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Aug 2 17:28:19 2003 Subject: [Pythonmac-SIG] Additional binary packages for Python2.3 on 10.2.6 In-Reply-To: <8C79133E-C52D-11D7-A4AC-00306583718C@mchsi.com> Message-ID: <3BDA0F77-C530-11D7-91CE-000A95686CD8@redivi.com> On Saturday, Aug 2, 2003, at 17:09 America/New_York, Andrew Hartung wrote: > > On Friday, August 1, 2003, at 09:56 PM, Bob Ippolito wrote: > >> Anyone that's downloaded pygame from my repository should do an >> Overwrite on their sdl_pygame_deps-1.2.5-binary, > > > I get 'sdl_pygame_deps-1.2.5-binary: download: archive does not have > correct MD5 checksum' when I try to do this. You know what, you're right. This is fixed now, my bad. -bob From list at mchsi.com Sat Aug 2 17:42:12 2003 From: list at mchsi.com (Andrew Hartung) Date: Sat Aug 2 17:42:44 2003 Subject: [Pythonmac-SIG] Re: PackMan->ChapMan In-Reply-To: Message-ID: <2CC54302-C532-11D7-A4AC-00306583718C@mchsi.com> On Saturday, August 2, 2003, at 04:31 PM, Kevin Altis wrote: > > However, I think this shows why Monty Python sketches, cast members, > etc. > generally don't make very good names for Python projects regardless of > the > number of puns and other clever references you might be able to > associate > with the name. > How about the Ministry of silly upgrades? From Jack.Jansen at cwi.nl Sun Aug 3 01:11:21 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Aug 2 18:11:29 2003 Subject: [Pythonmac-SIG] PackageManager philosophy In-Reply-To: <1624762D-C4A8-11D7-8EAD-000393CB1C86@tulane.edu> Message-ID: <3F7A4DE4-C536-11D7-9384-000A27B19B96@cwi.nl> As it turns out Bob's ideas and my ideas are pretty similar, see his last message. The only difference seems to be that I prefer to have a small number of moderately rigorously (if that isn't a contradictio in terminis:-) tested modules, and he wants a more comprehensive set of lightly tested modules. And Kevin points at a solution: > To make PM behave more in line with your goals (as I understand them, > anyways) while still giving Bob and others (myself included) the > functionality and flexibility they desire, I was thinking there could > be some sort of "stamp of approval" to say that the 'scapegoat' > (Package Inspector - PI? =) has tested package X binaries on platforms > X, Y and Z. A warning could pop up if such an approval doesn't exist - > "Warning: This package has not been confirmed to work on your > particular platform or sufficiently tested. If you experience any > installation problems, please report any problems to > scapegoat@python.org" - sort of like digital signatures. Or, the end > user could configure PM to simply not show any untested packages. (it > could also be shipped this way by default) I think the stamp of approval is that a package is in the default database. How about the following: per platform there are two databases, the stable one and the experimental one. The experimental one is easier to select than currently, probably with a checkbox. The experimental database is actually only a set of include directives pointing off to a small number of databases maintained by Bob, Kevin, me and a few others. PM is modified so that when a database is included it knows that the maintainer of the included database is the scapegoat for those packages (currently the maintainer of the toplevel database is responsible for everything). One problem that we would still need to solve on the user side (there's lots of issues to solve on the scapegoat side) is that of finding packages, especially in the potentially large experimental database. The logical thing to do would be to use the PyPI model, but as of this writing it just doesn't cut it. I just tried find a gui package for MacOSX (pretending I didn't know any names). Whatever I typed in I couldn't find anything. I eventually located pyobjc by typing "cocoa" into the *description* field, but that's it. -- - 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 Aug 3 01:24:52 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Aug 2 18:25:02 2003 Subject: [Pythonmac-SIG] Re: [wxPython-mac] Draft wxPackageManager Screenshot In-Reply-To: <01762C68-C37B-11D7-8EAD-000393CB1C86@tulane.edu> Message-ID: <22B07C86-C538-11D7-9384-000A27B19B96@cwi.nl> On donderdag, jul 31, 2003, at 19:18 Europe/Amsterdam, Kevin Ollivier wrote: > Without further ado, the link: http://www.theolliviers.com/PYPM.png Oops, I hadn't replied to this one yet. First: I like it! Second: I have some suggestions:-) What I would like (and what I know is doable in Cocoa, but I'm not sure about wxWindows) is to have the scrolling list be a customizable list of options, sortable by column. This is the type of widget the finder list view uses, or Mail for its mailbox index. The columns should be customizable, with all relevant fields (status, name, version, flavor, description; later to add license, category, scapegoat...) being selectable. Actually, what I really really want (I think:-) is to replace the "show hidden" checkbox by a popup menu "View:". This would currently have "default" and "include hidden" for the current two values of the checkbox. Later it will include (at least) "include experimental" and maybe "include source" if we decide not to show source packages by default. It will also have an "Add..." where you can add a view and give it a name. A view consists of the columns displayed, plus selection criteria (also for invisible columns), plus sorting. I think that with the Cocoa list widget this is a question of 3 lines of code:-) -- - 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 Aug 3 01:26:38 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Aug 2 18:26:47 2003 Subject: [Pythonmac-SIG] Re: PackMan->ChapMan In-Reply-To: <2CC54302-C532-11D7-A4AC-00306583718C@mchsi.com> Message-ID: <62283298-C538-11D7-9384-000A27B19B96@cwi.nl> On zaterdag, aug 2, 2003, at 23:42 Europe/Amsterdam, Andrew Hartung wrote: > How about the Ministry of silly upgrades? Now there's a nice name for the scapegoat cabal:-) -- - 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 altis at semi-retired.com Sat Aug 2 16:45:25 2003 From: altis at semi-retired.com (Kevin Altis) Date: Sat Aug 2 18:38:38 2003 Subject: [Pythonmac-SIG] PackageManager philosophy In-Reply-To: <3F7A4DE4-C536-11D7-9384-000A27B19B96@cwi.nl> Message-ID: > From: Jack Jansen > > One problem that we would still need to solve on the user side (there's > lots of issues to solve on the scapegoat side) is that of finding > packages, especially in the potentially large experimental database. > The logical thing to do would be to use the PyPI model, but as of this > writing it just doesn't cut it. I just tried find a gui package for > MacOSX (pretending I didn't know any names). Whatever I typed in I > couldn't find anything. I eventually located pyobjc by typing "cocoa" > into the *description* field, but that's it. This is likely a combination of issues. One is that PyPI has a variety of different descriptors, some of which overlap, and only one field, the Classifiers is actually structured data, and only two fields: name and version are actually required for a PyPI entry. The search page let's you enter Summary, Description, and Keywords, though those should probably be reserved for an Advanced Search. The advanced search could also present a list of all the Classifiers or somehow present a more detailed specification from the trove categories. http://www.python.org/pypi?:action=search_form So, there should be simple one field search that does a case-insensitive search of all the fields to get the most hits. I would probably put that search on the main PyPI page and have both simple and advanced searches on the Search page. Even if PyPI doesn't follow the simpler model, the Package Manager can do its own simple search. The other side of the coin is whether the fields that make up the PyPI info need to be expanded or get more structure for things like the keywords. The trove categories are quite limited. ka From richardjones at optushome.com.au Sun Aug 3 10:12:47 2003 From: richardjones at optushome.com.au (Richard Jones) Date: Sat Aug 2 19:13:06 2003 Subject: [Catalog-sig] RE: [Pythonmac-SIG] PackageManager philosophy In-Reply-To: References: Message-ID: <200308030912.51894.richardjones@optushome.com.au> On Sun, 3 Aug 2003 08:45 am, Kevin Altis wrote: > > From: Jack Jansen > > > > One problem that we would still need to solve on the user side (there's > > lots of issues to solve on the scapegoat side) is that of finding > > packages, especially in the potentially large experimental database. > > The logical thing to do would be to use the PyPI model, but as of this > > writing it just doesn't cut it. I just tried find a gui package for > > MacOSX (pretending I didn't know any names). Whatever I typed in I > > couldn't find anything. I eventually located pyobjc by typing "cocoa" > > into the *description* field, but that's it. FWIW, I found pyobjc by clicking "browse" then "Environment :: Mac OS X" ... I presume this means that the interface is not user-friendly enough? Perhaps it needs to be more prominent? Differently worded? > This is likely a combination of issues. One is that PyPI has a variety of > different descriptors, some of which overlap, and only one field, the > Classifiers is actually structured data, and only two fields: name and > version are actually required for a PyPI entry. It's already been suggested that the classifiers field be required for submission to the index. I think it'd be a valuable change, if others agree... > The search page let's you enter Summary, Description, and Keywords, though > those should probably be reserved for an Advanced Search. The advanced > search could also present a list of all the Classifiers or somehow present > a more detailed specification from the trove categories. > > http://www.python.org/pypi?:action=search_form > > So, there should be simple one field search that does a case-insensitive > search of all the fields to get the most hits. I agree with this. The search part of the interface was quick-n-dirty :) In terms of the "present a list of all the Classifiers" ... have you tried the browsing interface? I recently fixed a bug so it no longer hides Mac OS X apps (and emailed the pythonmac-sig, but I don't know whether my message was allowed through moderation). > I would probably put that > search on the main PyPI page and have both simple and advanced searches on > the Search page. > > Even if PyPI doesn't follow the simpler model, the Package Manager can do > its own simple search. > > The other side of the coin is whether the fields that make up the PyPI info > need to be expanded or get more structure for things like the keywords. The > trove categories are quite limited. IMO, keywords are far from structured unless there's a strict set of them - and that's what the trove categories are for. I'm always willing to accept new classifiers for the places where it's lacking. A statement like "quite limited" leads me to believe you see large holes in its coverage - please, I need to know where those are or it'll never be fixed. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20030803/934787c4/attachment.bin From kevino at tulane.edu Sat Aug 2 17:20:28 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Sat Aug 2 19:23:29 2003 Subject: [Pythonmac-SIG] PackageManager philosophy In-Reply-To: <3F7A4DE4-C536-11D7-9384-000A27B19B96@cwi.nl> Message-ID: On Saturday, August 2, 2003, at 03:11 PM, Jack Jansen wrote: > As it turns out Bob's ideas and my ideas are pretty similar, see his > last message. > > The only difference seems to be that I prefer to have a small number > of moderately rigorously (if that isn't a contradictio in terminis:-) > tested modules, and he wants a more comprehensive set of lightly > tested modules. > > And Kevin points at a solution: > >> To make PM behave more in line with your goals (as I understand them, >> anyways) while still giving Bob and others (myself included) the >> functionality and flexibility they desire, I was thinking there could >> be some sort of "stamp of approval" to say that the 'scapegoat' >> (Package Inspector - PI? =) has tested package X binaries on >> platforms X, Y and Z. A warning could pop up if such an approval >> doesn't exist - "Warning: This package has not been confirmed to work >> on your particular platform or sufficiently tested. If you experience >> any installation problems, please report any problems to >> scapegoat@python.org" - sort of like digital signatures. Or, the end >> user could configure PM to simply not show any untested packages. (it >> could also be shipped this way by default) > > I think the stamp of approval is that a package is in the default > database. How about the following: per platform there are two > databases, the stable one and the experimental one. The experimental > one is easier to select than currently, probably with a checkbox. The > experimental database is actually only a set of include directives > pointing off to a small number of databases maintained by Bob, Kevin, > me and a few others. PM is modified so that when a database is > included it knows that the maintainer of the included database is the > scapegoat for those packages (currently the maintainer of the toplevel > database is responsible for everything). I'd like the experimental database to not have an 'official' scapegoat; that is, anyone could add their own packages in (ala PyPI). Then, anyone can add a package and if there is a demand, it could get moved into the stable database. > One problem that we would still need to solve on the user side > (there's lots of issues to solve on the scapegoat side) is that of > finding packages, especially in the potentially large experimental > database. The logical thing to do would be to use the PyPI model, but > as of this writing it just doesn't cut it. I just tried find a gui > package for MacOSX (pretending I didn't know any names). Whatever I > typed in I couldn't find anything. I eventually located pyobjc by > typing "cocoa" into the *description* field, but that's it. IMHO, the basic problem with the PyPI search is that it requires you to think about which 'field' contains the term you're searching for. Summary? Description? Keywords? I just want to type in a term and have it search name AND summary AND description AND keywords AND classifiers, unless I specifically tell it not to. I think the 'finder' search model works best here - just have a simple text box and have people type into it. Then if they click on something (maybe Edit->Find) they can be more specific about their search. Thanks, Kevin From kevino at tulane.edu Sat Aug 2 17:53:47 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Sat Aug 2 19:56:48 2003 Subject: [Pythonmac-SIG] Re: [wxPython-mac] Draft wxPackageManager Screenshot In-Reply-To: <22B07C86-C538-11D7-9384-000A27B19B96@cwi.nl> Message-ID: <8E9DD9B1-C544-11D7-8EAD-000393CB1C86@tulane.edu> On Saturday, August 2, 2003, at 03:24 PM, Jack Jansen wrote: > > On donderdag, jul 31, 2003, at 19:18 Europe/Amsterdam, Kevin Ollivier > wrote: > >> Without further ado, the link: http://www.theolliviers.com/PYPM.png > > Oops, I hadn't replied to this one yet. First: I like it! Second: I > have some > suggestions:-) > > What I would like (and what I know is doable in Cocoa, but I'm not > sure about wxWindows) > is to have the scrolling list be a customizable list of options, > sortable by column. This is the type of widget the finder list view > uses, or Mail for its mailbox index. The columns should be > customizable, with all relevant fields (status, name, version, flavor, > description; later to add license, category, scapegoat...) being > selectable. This is definitely doable, but I was thinking about putting the properties in a separate grouped box next to the "options" box. I will mock up a demo to show you. (I may just build an applet and post a link to that, actually.) I like the simplicity of the current interface, with the exceptions that it lacks a status mechanism, a search capability, and a category browser, and I'd like to keep it as simple as possible. I think that a vast majority of the time, category, name and description are all the user needs to narrow down their search. Once they've decided on a package or packages, then they may be interested in the author, license, version, status, etc. For example, you may (or may not) want a package under the GPL, but you need to find a package that does what you want before you can even think about it. ;-) > Actually, what I really really want (I think:-) is to replace the > "show hidden" checkbox by a popup menu "View:". This would currently > have "default" and "include hidden" for the current two values of the > checkbox. Later it will include (at least) "include experimental" and > maybe "include source" if we decide not to show source packages by > default. It will also have an "Add..." where you can add a view and > give it a name. A view consists of the columns displayed, plus > selection criteria (also for invisible columns), plus sorting. I think > that with the Cocoa list widget this is a question of 3 lines of > code:-) I don't know that I can break it down to 3 lines of code, but I can get it running on at least 3 platforms. ^_- This wouldn't be too hard to do and I had planned on creating a view menu anyways (which can be a popup as well). BTW, I think being able to turn off source packages is a good idea - I always install the binaries anyways. ;-) Thanks, Kevin From vtagle at newsguy.com Sun Aug 3 05:54:43 2003 From: vtagle at newsguy.com (Vince Tagle) Date: Sun Aug 3 07:55:19 2003 Subject: [Pythonmac-SIG] New to PythonMac + GUI questions Message-ID: Hello all, I just recently downloaded the latest version of PythonMac (2.3 final) to run under OS9 (because I'm a big loser that hasn't upgraded to OSX, despite all the cool toys available on it) and I'm about to dive in and start having some fun. Anyway, I have a couple questions about creating a GUI for Python scripts. According to the website, Tkinter is no longer supported. Will it ever come back? And why was it removed? I did some quick browsing of the mailing list archives but could find no mention of Tkinter being removed. Are there other alternatives for GUI packages that are cross-platform? I've also been looking at the FrameWork stuff but haven't been able to find much documentation on using it. Are there any good examples out there using FrameWork and W (widgets based on FrameWork)? Vince no .sig today From gandreas at delver.com Sun Aug 3 17:29:30 2003 From: gandreas at delver.com (Glenn Andreas) Date: Sun Aug 3 17:29:45 2003 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.2 - Cocoa based Python IDE Message-ID: Ever wanted a Python editor chocked full of Cocoa goodness? Syntax coloring, split windows, and large chunks of it written in Python (thanks to the wonders of PyObjC) so you can extend it for your special needs? PyOXIDE 0.2 is now freely available on my idisk (as PyOXIDE_0.2.dmg): http://homepage.mac.com/gandreas/ This version now includes support for a debugger, a module help browser, as well as the ability to easily extend it (large portions are written in Python). More importantly, it is now based on the current MacPython 2.3 framework (and PyObjC installed via the Package Manager). There are a lot of little things missing, and a bunch of rough edges, but the only _major_ thing missing that the old IDE has is breakpoints (which will be in the next version). Glenn Andreas gandreas@delver.com Author of Macintosh games: Theldrow 2.3, Blobbo 1.0.2, Cythera 1.0.2 Be good, and you will be lonesome From peter.maas at mplusr.de Mon Aug 4 12:32:58 2003 From: peter.maas at mplusr.de (Peter Maas) Date: Mon Aug 4 05:31:34 2003 Subject: [Pythonmac-SIG] Should we do a press release? In-Reply-To: References: Message-ID: <3F2E284A.9030909@mplusr.de> Jack Jansen wrote: > think we'd need to focus on the mac community. Also, we'd need to get a > fairly decent list of places to send it, otherwise it isn't worth the > trouble. Does anyone have a list of Mac publications? http://viworld.com/mac/MacPub.htm -- ------------------------------------------------------------------- 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 Jack.Jansen at cwi.nl Mon Aug 4 18:14:48 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Aug 4 11:12:26 2003 Subject: [Pythonmac-SIG] Re: problem with mac python 2.3 under mac os 9.1 In-Reply-To: Message-ID: <63433454-C68E-11D7-9A40-0030655234CE@cwi.nl> Craig, I'm cc-ing the SIG, hope that's okay. On Monday, Aug 4, 2003, at 15:10 Europe/Amsterdam, Craig Turner wrote: > When I try to install python 2.3 on a vanilla install of mac os 9.1, It > jams at the bit where the focus pane is saying "Creating PythonCore > aliases" with a Traceback in the background of: > > Traceback (most recent call last): > File "Moes:SWdev:Jack:MacPython:Mac:scripts:ConfigurePython.py", line > 178, in ? > .... line 167, in main > .... line 80, in mkcorealias > File "everyday:Applications (Mac OS 9):MacPython-OS9 > 2.3:Lib:plat-mac:macostools.py", line 46, in mkalias > File.FSGetResourceForkName()) > NotImplementedError: Not available in this shared library/OS version Apparently you're the first person to try this on MacOS 9.1 (I only have 9.2 myself). The error means that either FSGetResourceForkName() or FSCreateResourceFile() isn't available on MacOS 9.1. Let me check... Apple Documentation says FSGetResourceForkName() is available on MacOS9, but about FSCreateResourceFile() it says "available in CarbonLib 1.3". Could it be that 9.1 ships with an earlier version of CarbonLib? Is it possible to upgrade? -- 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 lanceboyle at myrealbox.com Mon Aug 4 17:12:03 2003 From: lanceboyle at myrealbox.com (Lance Boyle) Date: Mon Aug 4 19:11:49 2003 Subject: [Pythonmac-SIG] PackMan->ChapMan In-Reply-To: <976F9092-C488-11D7-AE60-000A27B19B96@cwi.nl> Message-ID: <0F17F8D0-C6D1-11D7-B6F7-003065F93FF0@myrealbox.com> Too obscure--not descriptive. Jerry On Friday, Aug 1, 2003, at 18:28 America/Phoenix, Jack Jansen wrote: > Folks, > it's late, but I'd like to share this one. One of the non-issues > that's been bothering me with Package Manager was the name, as you > know. Package Manager is boring, pimp got voted down, PackMan is > already taken... > > Then at a hunch I picked up the dictionary, and it turns out the > (old-)english word for a traveling salesman in assorted wares > ("marskramer" for those who speak dutch) is: "Chapman". > > What do you think? From lanceboyle at myrealbox.com Mon Aug 4 17:15:01 2003 From: lanceboyle at myrealbox.com (Lance Boyle) Date: Mon Aug 4 19:14:47 2003 Subject: [Pythonmac-SIG] Bad window scrolling Message-ID: <7941BBB1-C6D1-11D7-B6F7-003065F93FF0@myrealbox.com> Why does clicking once in the elevator area of some of MacPython's text windows cause two screenfuls to scroll instead of one? Jerry From robin at reportlab.com Tue Aug 5 12:01:54 2003 From: robin at reportlab.com (Robin Becker) Date: Tue Aug 5 06:02:03 2003 Subject: [Pythonmac-SIG] eps + pict preview Message-ID: Hi, I apologise in advance if this is a stupid question from a non mac user, but how do I create a file with a resource fork? I'm creating eps files fine for the PC and Mac with a TIFF preview, but the client wants to have transparency. Even when I do alpha transparency on the TIFF the clients application can't seem to make use of it. They want PICT previews. Currently my PICT output deosn't support transparancy, but I think I can fix that fairly easily. My difficulty is that PICT is only allowed as a preview in the resource fork (the eps lives in the data fork) of the eps file. I looked in the 2.2.3 Mac modules docs, but couldn't find out how to create a resource. I see there are some modules related to this, but didn't understand the code enough to see how to use them. So if I have strings representing the eps and preview PICT and I know the resource number for the preview is supposed to be 256, how do I actually create the required file and associated resource? -- Robin Becker From mwh at python.net Tue Aug 5 12:58:59 2003 From: mwh at python.net (Michael Hudson) Date: Tue Aug 5 06:59:01 2003 Subject: [Pythonmac-SIG] eps + pict preview In-Reply-To: (Robin Becker's message of "Tue, 5 Aug 2003 11:01:54 +0100") References: Message-ID: <2mfzkgqsjw.fsf@starship.python.net> Robin Becker writes: > Hi, I apologise in advance if this is a stupid question from a non mac > user, but how do I create a file with a resource fork? Assuming you have a FSSpec or something, Carbon.File.FSpCreateResourceFork or similar is your friend. Then you need to create a resource r = Res.Resource() and add it to the resource fork r.AddResouce(type, id, name) (this adds it to the "current resource file" or whatever). I'm not really competent to give a tutorial in the Resource Manager, but HTH. Apple's documentation isn't that hard to translate to Python. Cheers, mwh -- 93. When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From Jack.Jansen at cwi.nl Tue Aug 5 14:01:57 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Aug 5 06:59:38 2003 Subject: [Pythonmac-SIG] Re: problem with mac python 2.3 under mac os 9.1 In-Reply-To: <63433454-C68E-11D7-9A40-0030655234CE@cwi.nl> Message-ID: <3B587136-C734-11D7-BB10-0030655234CE@cwi.nl> On Monday, Aug 4, 2003, at 17:14 Europe/Amsterdam, Jack Jansen wrote: > Let me check... Apple Documentation says FSGetResourceForkName() is > available on MacOS9, > but about FSCreateResourceFile() it says "available in CarbonLib 1.3". > Could it be that > 9.1 ships with an earlier version of CarbonLib? Is it possible to > upgrade? Turns out it is indeed possible (and needed) to upgrade your CarbonLib. You can get it from Apple, or (more easily) through VersionTracker. I've added a note to the website. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From craig at ahdore.com Tue Aug 5 09:26:26 2003 From: craig at ahdore.com (Craig Turner) Date: Tue Aug 5 06:59:54 2003 Subject: [Pythonmac-SIG] Re: problem with mac python 2.3 under mac os 9.1 In-Reply-To: <63433454-C68E-11D7-9A40-0030655234CE@cwi.nl> Message-ID: On Mon, 4 Aug 2003, Jack Jansen wrote: > Craig, > I'm cc-ing the SIG, hope that's okay. yup :) > Let me check... Apple Documentation says FSGetResourceForkName() is > available on MacOS9, but about FSCreateResourceFile() it says > "available in CarbonLib 1.3". Could it be that 9.1 ships with an > earlier version of CarbonLib? Is it possible to upgrade? I downloaded an installed a new version, I think it was 1.6, and that worked fine. - C From Jack.Jansen at cwi.nl Tue Aug 5 14:09:01 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Aug 5 07:06:37 2003 Subject: [Pythonmac-SIG] eps + pict preview In-Reply-To: Message-ID: <379B45FA-C735-11D7-BB10-0030655234CE@cwi.nl> On Tuesday, Aug 5, 2003, at 12:01 Europe/Amsterdam, Robin Becker wrote: > Hi, I apologise in advance if this is a stupid question from a non mac > user, but how do I create a file with a resource fork? The functions for creating and reading resources are in Carbon.Res, the functions for creating a file with a resource fork are in Carbon.File (there are file creation functions in Carbon.Res too, but they are older, and you may have problems with long file names or so). These all pretty much follow the Apple documentation (except that they're methods on objects where applicable, in stead of functions taking the objects as first argument). macostools.py has some examples, and (if you have a source distribution) more can be found in Mac/Lib/ and Mac/Demo/PICTbrowse and various other places in Mac/Demo. -- 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 adama at augustinefam.org Tue Aug 5 16:59:32 2003 From: adama at augustinefam.org (Adam Augustine) Date: Tue Aug 5 17:56:15 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 Message-ID: <3F3028C4.80504@augustinefam.org> I should start out by saying that my experience with Mac OS X and Python is pretty limited, though I have a decent Unix background. I am running 10.2.6 and downloaded and installed MacPython 2.3. I have not been able to get the PackageManager, PythonIDE, nor BuildApplet to run. All fail with the following error in the console: Aug 5 15:41:57 Blue WindowServer[1360]: ERROR! execle(/Applications/MacPython-2.3/BuildApplet.app/Contents/MacOS/BuildApplet) returned, err=22 Replaceing "BuildApplet" with the respective application name. I am unable to find a satifactory/official explanation of this error by googling and searching info.apple.com. The closest I can find is a statement on someone's weblog that the application was compiled for a different CPU, which seems unlikely to me (in case it really does matter, I am running a G3 300 Mhz). I am trying to run a Tkinter app (Pyla, a fax client for HylaFAX), and downloaded MacPython 2.3 when I found out the 10.2 built-in python didn't support Tkinter. I the course of trying to get this to work, I have also installed TclTkAquaBI-8.4.2.0. While I suppose it I could give compiling from scratch a go, I am reluctant since I need to deploy this on all the Macs in the company I set this up for, and having pretty installers always makes the client happy. I am not too comfortable building an installer for Mac OS X (unless someone has a recipe for doing it) Can anyone help me out? What am I doing wrong? Thanks, Adam From bob at redivi.com Tue Aug 5 19:37:33 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Aug 5 18:37:40 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 In-Reply-To: <3F3028C4.80504@augustinefam.org> Message-ID: <67A551F4-C795-11D7-8933-000A95686CD8@redivi.com> On Tuesday, Aug 5, 2003, at 17:59 America/New_York, Adam Augustine wrote: > I should start out by saying that my experience with Mac OS X and > Python is pretty limited, though I have a decent Unix background. > > I am running 10.2.6 and downloaded and installed MacPython 2.3. I have > not been able to get the PackageManager, PythonIDE, nor BuildApplet to > run. All fail with the following error in the console: > > Aug 5 15:41:57 Blue WindowServer[1360]: ERROR! > execle(/Applications/MacPython-2.3/BuildApplet.app/Contents/MacOS/ > BuildApplet) returned, err=22 > > Replaceing "BuildApplet" with the respective application name. > > I am unable to find a satifactory/official explanation of this error > by googling and searching info.apple.com. The closest I can find is a > statement on someone's weblog that the application was compiled for a > different CPU, which seems unlikely to me (in case it really does > matter, I am running a G3 300 Mhz). > > I am trying to run a Tkinter app (Pyla, a fax client for HylaFAX), and > downloaded MacPython 2.3 when I found out the 10.2 built-in python > didn't support Tkinter. > > I the course of trying to get this to work, I have also installed > TclTkAquaBI-8.4.2.0. > > While I suppose it I could give compiling from scratch a go, I am > reluctant since I need to deploy this on all the Macs in the company I > set this up for, and having pretty installers always makes the client > happy. I am not too comfortable building an installer for Mac OS X > (unless someone has a recipe for doing it) > > Can anyone help me out? What am I doing wrong? err=22 apparently means EINVAL (Invalid Argument). execle -> execve isn't even supposed to return that according to the man pages. Open up a terminal and run: /Library/Frameworks/Python.framework/Versions/2.3/bin/python See if it loads properly.. you should see exactly this: Python 2.3 (#2, Jul 30 2003, 11:45:28) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> Make sure to check that your version string matches mine, if it's ok, then hit ctrl-d to quit. If that worked fine, try running this: /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/ Contents/MacOS/Python Python 2.3 (#2, Jul 30 2003, 11:45:28) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import MacOS >>> MacOS.WMAvailable() True >>> You have to type in the import MacOS and MacOS.WMAvailable() .. at this point you *should* see a bouncing trapezoid icon in the dock. If you *do* see it, then I have no idea why PackageManager won't work. If either of these behaves differently for you, post your results to the list and we may be able to figure it out from there. There shouldn't be any G4 specific code in the distribution. Did you install Tcl/Tk before or after Python 2.3? -bob From billb at mousa.demon.co.uk Wed Aug 6 13:33:46 2003 From: billb at mousa.demon.co.uk (Bill Bedford) Date: Wed Aug 6 07:34:37 2003 Subject: [Pythonmac-SIG] Dialogs Message-ID: <20030806123346872851.GyazMail.billb@mousa.demon.co.uk> Could anyone suggest a way of bring a Easydialog to the front after using another application? Maybe the Carbon equivalent of _InterfaceLib.GetCurrentProcess Bill Bedford "Nothing is as important as model railways and even that isn't very important" -some wiseguy somewhere From Jack.Jansen at cwi.nl Wed Aug 6 16:05:52 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Aug 6 09:03:28 2003 Subject: [Pythonmac-SIG] Dialogs In-Reply-To: <20030806123346872851.GyazMail.billb@mousa.demon.co.uk> Message-ID: On Wednesday, Aug 6, 2003, at 13:33 Europe/Amsterdam, Bill Bedford wrote: > Could anyone suggest a way of bring a Easydialog to the front after > using another application? You need to be a bit more specific. Did the user bring Python back to front, and you want to cater for the dialog being obscured by other windows? If so, that would need a fix in EasyDialogs, as the dialogs there are all modal. Or are you looking for something else? -- 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 billb at mousa.demon.co.uk Wed Aug 6 16:11:31 2003 From: billb at mousa.demon.co.uk (Bill Bedford) Date: Wed Aug 6 10:12:22 2003 Subject: [Pythonmac-SIG] Dialogs In-Reply-To: References: Message-ID: <20030806151131727605.GyazMail.billb@mousa.demon.co.uk> On Wed, 6 Aug 2003 15:05:52 +0200, Jack Jansen wrote: > > On Wednesday, Aug 6, 2003, at 13:33 Europe/Amsterdam, Bill Bedford wrote: > >> Could anyone suggest a way of bring a Easydialog to the front after >> using another application? > > You need to be a bit more specific. Did the user bring Python back to > front, and > you want to cater for the dialog being obscured by other windows? If > so, that > would need a fix in EasyDialogs, as the dialogs there are all modal. > > Or are you looking for something else? I have a script that brings another app to the front and then puts up Easydialogs. In OS9 I could bring python to the front by calling get/setFrontProcess via calldll, but I can't see any equivalent for Carbon Bill Bedford "Nothing is as important as model railways and even that isn't very important" -some wiseguy somewhere From Jack.Jansen at cwi.nl Wed Aug 6 17:50:52 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Aug 6 10:48:30 2003 Subject: [Pythonmac-SIG] Dialogs In-Reply-To: <20030806151131727605.GyazMail.billb@mousa.demon.co.uk> Message-ID: <5FF51004-C81D-11D7-9FB5-0030655234CE@cwi.nl> On Wednesday, Aug 6, 2003, at 16:11 Europe/Amsterdam, Bill Bedford wrote: > On Wed, 6 Aug 2003 15:05:52 +0200, Jack Jansen wrote: >> >> On Wednesday, Aug 6, 2003, at 13:33 Europe/Amsterdam, Bill Bedford >> wrote: >> >>> Could anyone suggest a way of bring a Easydialog to the front after >>> using another application? >> >> You need to be a bit more specific. Did the user bring Python back to >> front, and >> you want to cater for the dialog being obscured by other windows? If >> so, that >> would need a fix in EasyDialogs, as the dialogs there are all modal. >> >> Or are you looking for something else? > > I have a script that brings another app to the front and then puts up > Easydialogs. In OS9 I could bring python to the front by calling > get/setFrontProcess via calldll, but I can't see any equivalent for > Carbon That's indeed what you want to do. Unfortunately the process manager isn't exported through the Carbon modules yet, and calldll doesn't yet work on OSX (for Mach-O, at least). There is a hack, but it will only work once: call MacOS.WMAvailable(). The first time you call this it will try GetCurrentProcess/SetFrontProcess, but unfortunately for this use case it caches the result in a static variable. Something you could try is send yourself an "activate" AppleEvent. -- 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 Benjamin.Schollnick at usa.xerox.com Wed Aug 6 12:16:24 2003 From: Benjamin.Schollnick at usa.xerox.com (Schollnick, Benjamin) Date: Wed Aug 6 11:16:35 2003 Subject: [Pythonmac-SIG] Dialogs Message-ID: <51B62EFFBC83D6118ADA00096BB030A102CC2DC2@usamcms7.mc.usa.xerox.com> Jack, > There is a hack, but it will only work once: call MacOS.WMAvailable(). > The first time you call this it will try > GetCurrentProcess/SetFrontProcess, > but unfortunately for this use case it caches the result in a static > variable. > > Something you could try is send yourself an "activate" AppleEvent. I admit, this is not a great idea... But it is a work around... What about a small change to MacOs.WMAvailable ()? For example... def MacOs.WMAvailable ( cache = True): if not cache: <> else: <> In other words, it's behavior would be the same, except we could override the cache... At least, it would work until there was a chance to get the process manager exported... And later, when the process manager has been finished, you could add a depreciated warning on the false cache call... Or redirect it to the proper process manager call. - Benjamin From adama at augustinefam.org Wed Aug 6 10:25:06 2003 From: adama at augustinefam.org (Adam Augustine) Date: Wed Aug 6 11:21:47 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 In-Reply-To: References: Message-ID: <3F311DD2.8080302@augustinefam.org> Bob Ippolito wrote: > On Tuesday, Aug 5, 2003, at 19:01 America/New_York, Adam Augustine wrote: >>> >>> You have to type in the import MacOS and MacOS.WMAvailable() .. at >>> this point you *should* see a bouncing trapezoid icon in the dock. >>> If you *do* see it, then I have no idea why PackageManager won't >>> work. If either of these behaves differently for you, post your >>> results to the list and we may be able to figure it out from >>> there. There shouldn't be any G4 specific code in the >>> distribution. Did you install Tcl/Tk before or after Python 2.3? >>> -bob >> >> Worked just as you said it should. Nice bouncing 16 ton >> paperweight(?) in the dock (which properly (I suppose) disappears >> when I ctrl-d at the python prompt). >> >> I downloaded TclTkAquaBI-8.4.2.0.dmg and installed it AFTER I >> installed MacPython-OSX-2.3-1.dmg the first time. Thinking that >> perhaps it needed to be re-installed (based on my understanding of >> the tkinter FAQs on python.org talking about Modules/Setup and >> recompiling) I re-ran the MacPython installer (a few times now). What >> I haven't done is remove MacPython, since I haven't figured out how >> package management works in OS X (I didn't want to just rm -r since I >> wasn't sure if it would corrput some package management database). > > > rm -r is pretty safe, OS X's package management system doesn't really > care. The worst it does is label the button "upgrade" when it's really > a new install (b/c you killed the old one). Try rm -rf > /Library/Frameworks/Python.framework /Applications/MacPython-2.3 .. and > then go ahead and install it again and see if PythonIDE or > PackageManager work. Neither of those actually depend on Tcl/Tk, so > I'm having trouble guessing at what's wrong with your setup. > > -bob > Well, I've rm -rf 'ed both /Library/Frameworks/Python.framework and /Applications/MacPython-2.3 then re-run the MacPython-OSX.pkg installer. I get the same error as before: execle(/path/to/application) returned, err=22. I tried it twice. Any directories I may have missed? I didn't rm the /usr/local/bin/ symlinks, but that shouldn't matter any... Is there somewhere else I can look for error messages besides the console and /var/log/system.log? Is there a way to run a debugger on it? Thanks, Adam From andre at alpdesignworks.com Wed Aug 6 18:48:26 2003 From: andre at alpdesignworks.com (Andre Posumentov) Date: Wed Aug 6 12:48:33 2003 Subject: [Pythonmac-SIG] MacPython2.3 - locale problem in Idle Message-ID: Hi all, On a clean install of Jack's latest MacPython 2.3, together with everything listed in the Package Manager, on OS X 10.2.6: I encounter a problem starting Idle. The Dock icon bounces a couple of times and then silently dies. If I start Idle from the command line (inside 'IDLE.app/Contents'), I see the following: %% ./MacOS/IDLE Traceback (most recent call last): File "Resources/__argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "Resources/idle", line 4, in ? import idlelib.PyShell File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ PyShell.py", line 22, in ? from EditorWindow import EditorWindow, fixwordbreaks File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ EditorWindow.py", line 39, in ? class EditorWindow: File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ EditorWindow.py", line 43, in EditorWindow from IOBinding import IOBinding File "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ IOBinding.py", line 31, in ? locale.setlocale(locale.LC_CTYPE, "") File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: locale setting not supported Can anyone tell me whether this is likely to be a problem with my machine configuration, or a bug? The fact that I seem to be the only person reporting this would seem to indicate that it's the former - but I'm baffled as to the possible cause. I'd be eternally grateful for any insights. If I comment out the locale.setlocale(...) line in IOBinding.py, Idle seems to work just fine. Best regards, -- Andre ---------------------------------- Andre Posumentov andre@alpdesignworks.com From rowen at cesmail.net Wed Aug 6 11:59:59 2003 From: rowen at cesmail.net (Russell E. Owen) Date: Wed Aug 6 14:00:12 2003 Subject: [Pythonmac-SIG] where does the documentation go? Message-ID: I'm using MacPython 2.3 on OS X and have the documentation installed via the package manager. However, I'd like to link to it from my normal web browser and I've had no luck tracking down the html files. They don't appear to be in the framework itself, nor in /Library/Documentation nor in ~/Library/Documentation nor...we'll, I've looked a lot of places but obviously not the right one! Note that tcl/tk README makes the interesting statement that the "standard" place for help is in /Resources/.lproj/Documentation The actual quote is: - The Tcl and Tk frameworks contain documentation in html format in the standard location for frameworks: Tcl.framework/Resources/English.lproj/Documentation/Reference/Tcl Tk.framework/Resources/English.lproj/Documentation/Reference/Tk Do you suppose this really is the standard location? If so, is it worth putting Python's html documentation there? -- Russell P.S. in case anyone is using Tkinter, the binary installer for Tcl/Tk 8.4.4 was just released. No notable aqua bug fixes, but oh well... From adama at augustinefam.org Wed Aug 6 13:01:12 2003 From: adama at augustinefam.org (Adam Augustine) Date: Wed Aug 6 14:10:31 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 In-Reply-To: <3F311DD2.8080302@augustinefam.org> References: <3F311DD2.8080302@augustinefam.org> Message-ID: <3F314268.7020105@augustinefam.org> Adam Augustine wrote: > > > Bob Ippolito wrote: > >> On Tuesday, Aug 5, 2003, at 19:01 America/New_York, Adam Augustine >> wrote: >> >>>> >>>> You have to type in the import MacOS and MacOS.WMAvailable() .. >>>> at this point you *should* see a bouncing trapezoid icon in the >>>> dock. If you *do* see it, then I have no idea why PackageManager >>>> won't work. If either of these behaves differently for you, post >>>> your results to the list and we may be able to figure it out from >>>> there. There shouldn't be any G4 specific code in the >>>> distribution. Did you install Tcl/Tk before or after Python 2.3? >>>> -bob >>> >>> >>> Worked just as you said it should. Nice bouncing 16 ton >>> paperweight(?) in the dock (which properly (I suppose) disappears >>> when I ctrl-d at the python prompt). >>> >>> I downloaded TclTkAquaBI-8.4.2.0.dmg and installed it AFTER I >>> installed MacPython-OSX-2.3-1.dmg the first time. Thinking that >>> perhaps it needed to be re-installed (based on my understanding of >>> the tkinter FAQs on python.org talking about Modules/Setup and >>> recompiling) I re-ran the MacPython installer (a few times now). >>> What I haven't done is remove MacPython, since I haven't figured out >>> how package management works in OS X (I didn't want to just rm -r >>> since I wasn't sure if it would corrput some package management >>> database). >> >> >> >> rm -r is pretty safe, OS X's package management system doesn't really >> care. The worst it does is label the button "upgrade" when it's >> really a new install (b/c you killed the old one). Try rm -rf >> /Library/Frameworks/Python.framework /Applications/MacPython-2.3 .. >> and then go ahead and install it again and see if PythonIDE or >> PackageManager work. Neither of those actually depend on Tcl/Tk, so >> I'm having trouble guessing at what's wrong with your setup. >> >> -bob >> > > Well, I've rm -rf 'ed both /Library/Frameworks/Python.framework and > /Applications/MacPython-2.3 then re-run the MacPython-OSX.pkg installer. > I get the same error as before: execle(/path/to/application) returned, > err=22. I tried it twice. Any directories I may have missed? I didn't rm > the /usr/local/bin/ symlinks, but that shouldn't matter any... Is there > somewhere else I can look for error messages besides the console and > /var/log/system.log? Is there a way to run a debugger on it? > > Thanks, > Adam > What are the chances that the original version of python (which comes with 10.2.x) is causing problems with MacPython? Something I have noticed is that even running /usr/local/bin/pythonw and trying (per the troubleshooting FAQs on python.org) "import _tkinter" fails, saying "No module named _tkinter" which strikes me as strange since (or maybe I misunderstood) MacPython includes all the necessary stuff for tkinter... So I guess my question is whether there is a way to disable the built in python or at least remove the possiblity of conflict. Any ideas? Thanks, Adam Augustine From oussoren at cistron.nl Wed Aug 6 21:27:44 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Aug 6 14:27:54 2003 Subject: [Pythonmac-SIG] MacPython2.3 - locale problem in Idle In-Reply-To: References: Message-ID: On Wednesday, 6 August, 2003, at 18:48, Andre Posumentov wrote: > Hi all, > > On a clean install of Jack's latest MacPython 2.3, together with > everything listed in the Package Manager, on OS X 10.2.6: > > I encounter a problem starting Idle. The Dock icon bounces a couple > of times and then silently dies. > > If I start Idle from the command line (inside 'IDLE.app/Contents'), I > see the following: > > %% ./MacOS/IDLE > Traceback (most recent call last): > File "Resources/__argvemulator_idle", line 4, in ? > execfile(os.path.join(os.path.split(__file__)[0], "idle")) > File "Resources/idle", line 4, in ? > import idlelib.PyShell > File > "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ > PyShell.py", line 22, in ? > from EditorWindow import EditorWindow, fixwordbreaks > File > "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ > EditorWindow.py", line 39, in ? > class EditorWindow: > File > "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ > EditorWindow.py", line 43, in EditorWindow > from IOBinding import IOBinding > File > "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ > IOBinding.py", line 31, in ? > locale.setlocale(locale.LC_CTYPE, "") > File > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ > locale.py", line 381, in setlocale > return _setlocale(category, locale) > locale.Error: locale setting not supported > > Can anyone tell me whether this is likely to be a problem with my > machine configuration, or a bug? The fact that I seem to be the only > person reporting this would seem to indicate that it's the former - > but I'm baffled as to the possible cause. I'd be eternally grateful > for any insights. What is your language setting? I can reproduce this problem if I set the environment variable LANG to an unsupported value. Ronald From israel at sandlotgames.com Wed Aug 6 13:03:40 2003 From: israel at sandlotgames.com (Israel C. Evans) Date: Wed Aug 6 15:04:06 2003 Subject: [Pythonmac-SIG] where does the documentation go? In-Reply-To: Message-ID: What I did was to download the Regular Python dos from the python.org website and put them in /Resources/.lproj/Documentation by hand. I think what the package manager docs are for is the Mac Os X Help Browser, which I've found not very helpful and _painfully_ slow. On Wednesday, August 6, 2003, at 10:59 AM, Russell E. Owen wrote: > from my normal web > browser and I've had no luck tracking down the html files. They don't > appear to be in the framework itself, nor in /Library/Documentation nor > in ~/Library/Documentation nor...we'll, I've looked a lot of places but > obviously not the right one! > > Note that tcl/tk README makes the interesting statement that the > "standard" place for help is in > /Resources/.lproj/Documentation > > The actual quote is: > ~Israel~ From andre at alpdesignworks.com Wed Aug 6 21:32:35 2003 From: andre at alpdesignworks.com (Andre Posumentov) Date: Wed Aug 6 15:32:43 2003 Subject: [Pythonmac-SIG] Re: MacPython2.3 - locale problem in Idle In-Reply-To: Message-ID: Hi Ronald, That's what's puzzling me - I'm in the UK, and my 'LANG' environment is set to 'en'. Sorry, I should have mentioned that in my original mail. Not 'unsupported', surely? Cheers, -- Andre On Wednesday, August 6, 2003, at 07:27 pm, Ronald Oussoren wrote: > > On Wednesday, 6 August, 2003, at 18:48, Andre Posumentov wrote: > >> Hi all, >> >> On a clean install of Jack's latest MacPython 2.3, together with >> everything listed in the Package Manager, on OS X 10.2.6: >> >> I encounter a problem starting Idle. The Dock icon bounces a couple >> of times and then silently dies. >> >> If I start Idle from the command line (inside 'IDLE.app/Contents'), I >> see the following: >> >> %% ./MacOS/IDLE >> Traceback (most recent call last): >> File "Resources/__argvemulator_idle", line 4, in ? >> execfile(os.path.join(os.path.split(__file__)[0], "idle")) >> File "Resources/idle", line 4, in ? >> import idlelib.PyShell >> File >> "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ >> PyShell.py", line 22, in ? >> from EditorWindow import EditorWindow, fixwordbreaks >> File >> "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ >> EditorWindow.py", line 39, in ? >> class EditorWindow: >> File >> "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ >> EditorWindow.py", line 43, in EditorWindow >> from IOBinding import IOBinding >> File >> "/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idlelib/ >> IOBinding.py", line 31, in ? >> locale.setlocale(locale.LC_CTYPE, "") >> File >> "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ >> locale.py", line 381, in setlocale >> return _setlocale(category, locale) >> locale.Error: locale setting not supported >> >> Can anyone tell me whether this is likely to be a problem with my >> machine configuration, or a bug? The fact that I seem to be the only >> person reporting this would seem to indicate that it's the former - >> but I'm baffled as to the possible cause. I'd be eternally grateful >> for any insights. > > What is your language setting? I can reproduce this problem if I set > the environment variable LANG to an unsupported value. > > Ronald > > From oussoren at cistron.nl Wed Aug 6 22:43:46 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Aug 6 15:43:52 2003 Subject: [Pythonmac-SIG] Re: MacPython2.3 - locale problem in Idle In-Reply-To: References: Message-ID: <4B71498E-C846-11D7-9FDF-0003931CFE24@cistron.nl> On Wednesday, 6 August, 2003, at 21:32, Andre Posumentov wrote: > Hi Ronald, > > That's what's puzzling me - I'm in the UK, and my 'LANG' environment > is set to 'en'. Sorry, I should have mentioned that in my original > mail. Did you manually set LANG? I'm running an (US) English system and don't have an environment variable named LANG at all. > > Not 'unsupported', surely? LANG='en_GB' does work. See /usr/share/locale/ for a list of supported locales. There is an 'en' directory in there, but no 'en/LC_CTYPE'. The manpage for setlocale explains how these files are used. Ronald From p.oberndoerfer at urheberrecht.org Wed Aug 6 23:08:32 2003 From: p.oberndoerfer at urheberrecht.org (Pascal Oberndoerfer) Date: Wed Aug 6 17:03:02 2003 Subject: [Pythonmac-SIG] Installing PyObjC via PackMan Message-ID: I am running into trouble trying to update PyObjC from 0.9 to 1.0b1 on MacOS X 10.2.6/MacPython 2.3 (binary installer). PackMan shows me the previously installed 0.9 as "Old". Clicking on Install downloads to /tmp, but 0.9 isn't updated. The status of the overwrite checkbox didn't make any difference. Any ideas? Thanks. Pascal From Jack.Jansen at cwi.nl Thu Aug 7 00:55:54 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Aug 6 17:55:59 2003 Subject: [Pythonmac-SIG] where does the documentation go? In-Reply-To: References: Message-ID: On woensdag, 6 augustus 2003, at 19:59PM, Russell E. Owen wrote: > I'm using MacPython 2.3 on OS X and have the documentation installed > via > the package manager. However, I'd like to link to it from my normal web > browser and I've had no luck tracking down the html files. They don't > appear to be in the framework itself, nor in /Library/Documentation nor > in ~/Library/Documentation nor...we'll, I've looked a lot of places but > obviously not the right one! They are in /Library/Frameworks/Python.framework/Versions/Current/Resources/ Python.app/Contents/Resources. The reason for this is that when I initially put them in the framework Apple Help Viewer refused to recognize them, it seems it really is only interested in .app bundles. And, to answer Israel's message too: standard web browsers can handle them just fine, there's a few additions to the html files that bother no-one. And the one thing that Apple Help Viewer has in it's favor is the index. Now if only it would let me find things through the Help Viewer and then provided a popup menu or a button to view the results in a decent browser... From Jack.Jansen at cwi.nl Thu Aug 7 01:00:57 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Aug 6 18:01:31 2003 Subject: [Pythonmac-SIG] Re: MacPython2.3 - locale problem in Idle In-Reply-To: References: Message-ID: <750D3780-C859-11D7-8FF3-000A27B19B96@cwi.nl> On woensdag, 6 augustus 2003, at 21:32PM, Andre Posumentov wrote: > That's what's puzzling me - I'm in the UK, and my 'LANG' environment > is set to 'en'. Sorry, I should have mentioned that in my original > mail. On Mac OS X pretty much any language setting is unsupported:-( This comes from the FreeBSD heritage: they have some of the locale infrastructure, but not all of it. This means it's basically useless, but because it's there packages like Python think it will all work. Could you file a bug report for this, so it gets fixed in 2.3.1? Even though the bug could be considered to be in MacOSX I think Idle shouldn't crash if its setlocale() fails. From Jack.Jansen at cwi.nl Thu Aug 7 01:02:41 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Aug 6 18:02:45 2003 Subject: [Pythonmac-SIG] Installing PyObjC via PackMan In-Reply-To: References: Message-ID: On woensdag, 6 augustus 2003, at 22:08PM, Pascal Oberndoerfer wrote: > > I am running into trouble trying to update PyObjC from 0.9 to 1.0b1 on > MacOS > X 10.2.6/MacPython 2.3 (binary installer). PackMan shows me the > previously > installed 0.9 as "Old". Clicking on Install downloads to /tmp, but 0.9 > isn't > updated. The status of the overwrite checkbox didn't make any > difference. The workaround is probably to first remove the old PyObjC manually. But: I'd be interested to know why this fails, so we might fix it (or, at least, put a warning in the PackMan database). Ronald, any ideas? From Jack.Jansen at cwi.nl Thu Aug 7 00:39:11 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Aug 6 18:06:33 2003 Subject: 2.3.1 and 2.3 compatibility (was: [Pythonmac-SIG] Dialogs) In-Reply-To: <51B62EFFBC83D6118ADA00096BB030A102CC2DC2@usamcms7.mc.usa.xerox.com> References: <51B62EFFBC83D6118ADA00096BB030A102CC2DC2@usamcms7.mc.usa.xerox.com> Message-ID: <6AC950BE-C856-11D7-8FF3-000A27B19B96@cwi.nl> This touches on a larger subject that I'd like to discuss here, hence the change of subject. On woensdag, 6 augustus 2003, at 17:16PM, Schollnick, Benjamin wrote: >> There is a hack, but it will only work once: call MacOS.WMAvailable(). >> The first time you call this it will try >> GetCurrentProcess/SetFrontProcess, >> but unfortunately for this use case it caches the result in a static >> variable. >> [...] > What about a small change to MacOs.WMAvailable ()? > > For example... > > def MacOs.WMAvailable ( cache = True): > if not cache: > <> > else: > <> > > In other words, it's behavior would be the same, except we could > override > the > cache... Python officially has the rule that micro-releases contain bug fixes only. But this rule has often been interpreted as "micro-releases shouldn't break working code, except when they actually rely on the buggy behaviour, which is very unlikely, and silly too". Note that the two statements are different: the second is only about backward compatibility, the first one might be interpreted as being about forward compatibility too. MacPython has a history of taking the term "bug fix" to unprecedented heights:-) We've simply told people to upgrade, which worked because of the relatively small community. But all that is changed if Apple decides to include Python 2.3 in MacOS 10.3: there are going to be a few hundred active MacPython users (at least, initially:-) who can reasonably be expected to upgrade to 2.3.1, but millions of potential users out there who will remain at 2.3 until the next release of MacOSX. In other words: if we add a feature to an API in 2.3.1 (calling it "bug fix") the active developers will be tempted to use it. But once their software comes in the hands of a new MacPython convert it will crash. For this reason I think we have to be extremely conservative in including anything that would not be both backward and forward compatible into 2.3.1. From Jack.Jansen at cwi.nl Thu Aug 7 00:51:25 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Aug 6 18:15:26 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 In-Reply-To: <3F314268.7020105@augustinefam.org> References: <3F311DD2.8080302@augustinefam.org> <3F314268.7020105@augustinefam.org> Message-ID: <206D1514-C858-11D7-8FF3-000A27B19B96@cwi.nl> I'm going to reply only to the relevant parts here, and there's more homework for Adam:-) On woensdag, 6 augustus 2003, at 20:01PM, Adam Augustine wrote: >>>>> You have to type in the import MacOS and MacOS.WMAvailable() .. >>>>> at this point you *should* see a bouncing trapezoid icon in the >>>>> dock. If you *do* see it, then I have no idea why >>>>> PackageManager won't work. If either of these behaves >>>>> differently for you, post your results to the list and we may be >>>>> able to figure it out from there. There shouldn't be any G4 >>>>> specific code in the distribution. Did you install Tcl/Tk >>>>> before or after Python 2.3? >>>>> -bob >>>> >>>> >>>> Worked just as you said it should. Nice bouncing 16 ton >>>> paperweight(?) in the dock (which properly (I suppose) disappears >>>> when I ctrl-d at the python prompt). Ok, next step is to try running the applets from the Terminal command line. Try running % Applications/MacPython-2.3/PythonIDE.app/Contents/MacOS/PythonIDE and tell us whether that gives you a working IDE. Also, are there any things you have in your setup that are non-standard, such as using a third-party Finder, or having replaced the standard shell or something like that? Oh yes, do you have anything strange (or, actually, anything at all) in your .MacOSX/Environment.plist file? Are you running this as the same user ID as the one you installed with? Does it have admin privileges? > What are the chances that the original version of python (which comes > with 10.2.x) is causing problems with MacPython? No problem that we know of, or can imagine. > Something I have noticed is that even running /usr/local/bin/pythonw > and trying (per the troubleshooting FAQs on python.org) "import > _tkinter" fails, saying "No module named _tkinter" which strikes me as > strange since (or maybe I misunderstood) MacPython includes all the > necessary stuff for tkinter... No, MacPython does *not* contain _tkinter. You can download and install it through the Package Manager, once you get that to work. I think the chances of this problem having anything to do with _tkinter are pretty small. From owen at astro.washington.edu Wed Aug 6 16:21:36 2003 From: owen at astro.washington.edu (Russell E Owen) Date: Wed Aug 6 18:21:58 2003 Subject: [Pythonmac-SIG] where does the documentation go? In-Reply-To: References: Message-ID: At 11:55 PM +0200 8/6/03, Jack Jansen wrote: >On woensdag, 6 augustus 2003, at 19:59PM, Russell E. Owen wrote: > >>I'm using MacPython 2.3 on OS X and have the documentation installed via >>the package manager. However, I'd like to link to it from my normal web >>browser and I've had no luck tracking down the html files... > >They are in >/Library/Frameworks/Python.framework/Versions/Current/Resources/Python.app/Contents/Resources. >The reason for this is that when I initially put them in the >framework Apple Help Viewer refused to recognize them, it seems it >really is only interested in .app bundles. > >And, to answer Israel's message too: standard web browsers can >handle them just fine... Thank you very much. It never occurred to me to look inside the Python bundle itself. Would it be practical to install an alias in /Applications/MacPython (or rather in "the folder containing the running package manager") so it'd be easier to find? If so, I suggest a Documentation folder that contained two aliases: MacPython Help.html and Python Help.html (aliases to the appropriate index.html files). This saves a lot of clutter over supplying aliases to the folders full of html files, and one can still trivially get to those folders by resolving the aliases. If that sounds too messy, perhaps just a brief note in the ReadMe and/or the Package Manager's description of the Python docs as to where the html files for MacPython can be found would do. Anyway, thank you very much. I now have links to the docs in my browser (iCab) and am a happy camper. More generally, MacPython 2.3 is great and Package Manager is a truly wonderful addition. -- Russell From altis at semi-retired.com Wed Aug 6 17:34:44 2003 From: altis at semi-retired.com (Kevin Altis) Date: Wed Aug 6 19:28:02 2003 Subject: [Pythonmac-SIG] where does the documentation go? In-Reply-To: Message-ID: > From: Jack Jansen > > On woensdag, 6 augustus 2003, at 19:59PM, Russell E. Owen wrote: > > > I'm using MacPython 2.3 on OS X and have the documentation installed > > via > > the package manager. However, I'd like to link to it from my normal web > > browser and I've had no luck tracking down the html files. They don't > > appear to be in the framework itself, nor in /Library/Documentation nor > > in ~/Library/Documentation nor...we'll, I've looked a lot of places but > > obviously not the right one! > > They are in > /Library/Frameworks/Python.framework/Versions/Current/Resources/ > Python.app/Contents/Resources. The reason for this is that when I > initially put them in the framework Apple Help Viewer refused to > recognize them, it seems it really is only interested in .app bundles. > > And, to answer Israel's message too: standard web browsers can handle > them just fine, there's a few additions to the html files that bother > no-one. And the one thing that Apple Help Viewer has in it's favor is > the index. Now if only it would let me find things through the Help > Viewer and then provided a popup menu or a button to view the results > in a decent browser... Okay, so the MacPython distribution doesn't contain the Python docs at all? It looks like it just points the user to the online version? Ugh, I feel dumb for missing this earlier. It isn't user friendly to require a special download, more so since the docs won't even show up unless you do an rm on some special files. I'm a bit scared to go deleting the suggested files. ls ~/Library/Preferences/com.apple.*help* /Users/altis/Library/Preferences/com.apple.help.plist /Users/altis/Library/Preferences/com.apple.helpui.plist /Users/altis/Library/Preferences/com.apple.helpviewer.plist /Users/altis/Library/Preferences/com.apple.iTunes.helper.plist Will all of these really get rebuilt? Sadly, I can't use the Open File dialog with Safari to open the downloaded docs because it won't look inside the English.lproj directory. Luckily, I can just use the webbrowser module, so I just checked in a change to codeEditor to use the local docs if they exist, sweet. webbrowser.open('file:///Library/Frameworks/Python.framework/Versions/ Current/Resources/Python.app/Contents/Resources/English.lproj/ PythonDocumentation/index.html') The Windows EXE installer which is around 9MB does contain the complete documentation tree. I just made a quick zip of my c:\Python23\Doc directory and it is around 3MB but I'm sure that could be made even smaller by tweaking the compression settings, using bz2... I recommend future distributions including the complete documentation rather than requiring a separate download via the Package Manager. It seems like there should a be link to the docs in the MacPython-2.3 folder too, but I guess that isn't the Mac OS X way? On a related note, can there be an additional Python alias in the MacPython-2.3 folder rather than just having it sit in the Applications folder? And on yet another note, when 2.3.1, 2.3.2, etc. come out will that be available via Apple's System Update or will users have to wait until Apple's next "Big Cat" release? ka From adama at augustinefam.org Wed Aug 6 19:01:28 2003 From: adama at augustinefam.org (Adam Augustine) Date: Wed Aug 6 19:58:18 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 (Solved!) In-Reply-To: <206D1514-C858-11D7-8FF3-000A27B19B96@cwi.nl> References: <3F311DD2.8080302@augustinefam.org> <3F314268.7020105@augustinefam.org> <206D1514-C858-11D7-8FF3-000A27B19B96@cwi.nl> Message-ID: <3F3196D8.4060800@augustinefam.org> Jack Jansen wrote: > I'm going to reply only to the relevant parts here, and there's more > homework for > Adam:-) > > On woensdag, 6 augustus 2003, at 20:01PM, Adam Augustine wrote: > > > Ok, next step is to try running the applets from the Terminal command > line. Try running > % Applications/MacPython-2.3/PythonIDE.app/Contents/MacOS/PythonIDE > and tell us whether that gives you a working IDE. > Tah-dah! Running /Applications/MacPython-2.3/PythonIDE.app/Contents/MacOS/PythonIDE from the command line resulted in a "Command not found" error. This, of course was a big surprise since the command was clearly there. I did a "head PythonIDE" and lo and behold, there it was: #!/Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app /Contents/MacOS/python Doing an ls -lsa on that directory gives: 2 drwxrwxr-x 3 g3 admin 1024 Aug 6 17:07 . 2 drwxrwxr-x 4 g3 admin 1024 Aug 6 08:40 .. 20 -rwxrwxr-x 1 g3 admin 9608 Jul 30 03:47 Python 2 drwxr-xr-x 2 root admin 1024 Aug 6 17:07 Scripts > Also, are there any things you have in your setup that are non-standard, > such as using a third-party Finder, or having replaced the standard > shell or something like that? > Nope. > Oh yes, do you have anything strange (or, actually, anything at all) in > your .MacOSX/Environment.plist file? > Can't even find a directory named .MacOSX and only one file named Environment.plist and it is in a subdirectory of /System/Library/Frameworks/ApplicationServices.framework. > Are you running this as the same user ID as the one you installed with? > Does it have admin privileges? Yes, and yes. So I have done an "ln -s Python python" and now everything seems to be working properly. Seems there was some oddness with the case of the executable name. What is the difference between: /Library/Frameworks/Python.framework/Versions/2.3/bin/python* and /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app /Contents/MacOS/Python ? The byte counts are slightly different... Anyway, thanks for the help. I am putting some search terms for the benefit of those who come later since most of the initial error messages are now edited out of the message. execle returned, err=22 console error message PythonIDE PackageManager BuildApplet Thanks, Adam Augustine From bob at redivi.com Wed Aug 6 21:34:26 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Aug 6 20:34:33 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 (Solved!) In-Reply-To: <3F3196D8.4060800@augustinefam.org> Message-ID: On Wednesday, Aug 6, 2003, at 20:01 America/New_York, Adam Augustine wrote: > > > Jack Jansen wrote: > >> I'm going to reply only to the relevant parts here, and there's more >> homework for >> Adam:-) >> On woensdag, 6 augustus 2003, at 20:01PM, Adam Augustine wrote: >> Ok, next step is to try running the applets from the Terminal command >> line. Try running >> % Applications/MacPython-2.3/PythonIDE.app/Contents/MacOS/PythonIDE >> and tell us whether that gives you a working IDE. > > Tah-dah! Running > /Applications/MacPython-2.3/PythonIDE.app/Contents/MacOS/PythonIDE > from the command line resulted in a "Command not found" error. This, > of course was a big surprise since the command was clearly there. I > did a "head PythonIDE" and lo and behold, there it was: > > #!/Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python.app > /Contents/MacOS/python > > Doing an ls -lsa on that directory gives: > > 2 drwxrwxr-x 3 g3 admin 1024 Aug 6 17:07 . > 2 drwxrwxr-x 4 g3 admin 1024 Aug 6 08:40 .. > 20 -rwxrwxr-x 1 g3 admin 9608 Jul 30 03:47 Python > 2 drwxr-xr-x 2 root admin 1024 Aug 6 17:07 Scripts > >> Also, are there any things you have in your setup that are >> non-standard, such as using a third-party Finder, or having replaced >> the standard shell or something like that? > > Nope. > >> Oh yes, do you have anything strange (or, actually, anything at all) >> in your .MacOSX/Environment.plist file? > > Can't even find a directory named .MacOSX and only one file named > Environment.plist and it is in a subdirectory of > /System/Library/Frameworks/ApplicationServices.framework. > >> Are you running this as the same user ID as the one you installed >> with? Does it have admin privileges? > > Yes, and yes. > > So I have done an "ln -s Python python" and now everything seems to be > working properly. > > Seems there was some oddness with the case of the executable name. > What is the difference between: > > /Library/Frameworks/Python.framework/Versions/2.3/bin/python* > > and > > /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app > /Contents/MacOS/Python ? > > The byte counts are slightly different... > > Anyway, thanks for the help. I am putting some search terms for the > benefit of those who come later since most of the initial error > messages are now edited out of the message. > > execle returned, err=22 console error message PythonIDE PackageManager > BuildApplet Are you using HFS (Mac OS Extended), or UFS? Sounds like you might be using UFS, I don't think anyone tested that. -bob From ystarrev at uwo.ca Wed Aug 6 23:09:56 2003 From: ystarrev at uwo.ca (Yves Starreveld) Date: Wed Aug 6 22:09:59 2003 Subject: [Pythonmac-SIG] Python 2.3 vs 2.2, VTK, and Carbon Message-ID: <3D676B86-C87C-11D7-A504-003065497A0E@uwo.ca> Hi, folks, I have been sorting through the problems with 2.3 and VTK. One odd thing is that the importation of both Carbon/Carbon.h and Python.h from 2.3 leads to the following errors: In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/CarbonCore.h:165, from /System/Library/Frameworks/CoreServices.framework/Headers/ CoreServices.h:21, from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from /Users/ystarrev/Development/VTK/Rendering/ vtkCarbonRenderWindowInteractor.h:30, from /Users/ystarrev/Development/VTKRelease/Rendering/ vtkCarbonRenderWindowInteractorPython.cxx:7: /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function `long double scalbl(long double, long int)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:1896: error: ` scalb' undeclared (first use this function) /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:1896: error: (Each undeclared identifier is reported only once for each function it appears in.) Other files in vtk import Carbon.h without difficulty, so I am surmising a conflict. Has anyone run into anything similar? Thanks for any comments. Yves Starreveld From oussoren at cistron.nl Thu Aug 7 08:36:47 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Thu Aug 7 01:36:52 2003 Subject: [Pythonmac-SIG] Installing PyObjC via PackMan In-Reply-To: References: Message-ID: <22FBC045-C899-11D7-9FDF-0003931CFE24@cistron.nl> On Thursday, 7 August, 2003, at 00:02, Jack Jansen wrote: > > On woensdag, 6 augustus 2003, at 22:08PM, Pascal Oberndoerfer wrote: > >> >> I am running into trouble trying to update PyObjC from 0.9 to 1.0b1 >> on MacOS >> X 10.2.6/MacPython 2.3 (binary installer). PackMan shows me the >> previously >> installed 0.9 as "Old". Clicking on Install downloads to /tmp, but >> 0.9 isn't >> updated. The status of the overwrite checkbox didn't make any >> difference. > > The workaround is probably to first remove the old PyObjC manually. > But: I'd be > interested to know why this fails, so we might fix it (or, at least, > put a warning > in the PackMan database). > > Ronald, any ideas? Not yet. I'll try to reproduce this later today (much later, somewhere in the evening) Ronald > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From oussoren at cistron.nl Thu Aug 7 08:43:10 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Thu Aug 7 01:43:16 2003 Subject: [Pythonmac-SIG] where does the documentation go? In-Reply-To: References: Message-ID: <074143B2-C89A-11D7-9FDF-0003931CFE24@cistron.nl> On Thursday, 7 August, 2003, at 01:34, Kevin Altis wrote: > And on yet another note, when 2.3.1, 2.3.2, etc. come out will that be > available via Apple's System Update or will users have to wait until > Apple's > next "Big Cat" release? Only Apple knows the anwser to that question, and I don't think they will publicly state what they will do. Ronald From etienne at cs.vu.nl Thu Aug 7 11:42:55 2003 From: etienne at cs.vu.nl (Etienne Posthumus) Date: Thu Aug 7 04:42:59 2003 Subject: [Pythonmac-SIG] Readline support for Python 2.3 under OS X 10.2 Message-ID: The file mentioned in: http://mail.python.org/pipermail/pythonmac-sig/2003-June/007945.html by Bob Ippolito gives a 404. I have mailed Bob Ippolito directly but he may be on holiday or busy or whatever. Does anyone else have a copy of that file cached? Not having readline in the command line version is driving me nuts. EP From skip at pobox.com Thu Aug 7 09:15:14 2003 From: skip at pobox.com (Skip Montanaro) Date: Thu Aug 7 09:15:24 2003 Subject: [Pythonmac-SIG] What's this message mean? Message-ID: <16178.20706.903460.72849@montanaro.dyndns.org> When I run a Tkinter app from the command line (in an xterm or from the Terminal app) the main window comes up okay, but it's not at the top of the window stack. When I click its title, the window does not raise and this message is displayed in the terminal window: SetFrontProcess failed,-606 I have to pause the app (Ctl-Z) and kill it. otool tells me this about my _tkinter.so file: % otool -L ~/local/lib/python2.3/lib-dynload/_tkinter.so /Users/skip/local/lib/python2.3/lib-dynload/_tkinter.so: /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl (compatibility version 8.4.0, current version 8.4.0) /Library/Frameworks/Tk.framework/Versions/8.4/Tk (compatibility version 8.4.0, current version 8.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 63.0.0) Any suggestions? Thx, Skip From oussoren at cistron.nl Thu Aug 7 15:30:44 2003 From: oussoren at cistron.nl (Ronald_Oussoren) Date: Thu Aug 7 09:31:03 2003 Subject: [Pythonmac-SIG] What's this message mean? In-Reply-To: <16178.20706.903460.72849@montanaro.dyndns.org> References: <16178.20706.903460.72849@montanaro.dyndns.org> Message-ID: <20030807132746.M95820@concepts-ict.nl> On Thu, 7 Aug 2003 08:15:14 -0500, Skip Montanaro wrote > When I run a Tkinter app from the command line (in an xterm or from the > Terminal app) the main window comes up okay, but it's not at the top > of the window stack. When I click its title, the window does not > raise and this message is displayed in the terminal window: > > SetFrontProcess failed,-606 > > I have to pause the app (Ctl-Z) and kill it. > > Any suggestions? Use pythonw instead of python to start the script. Applications that use the WindowServer must be in a .app bundle, or must use an undocumented API. pythonw is a shell script that starts a pyton interpreter that is inside a .app bundle but is otherwise a normal interpreter. Ronald From mwh at python.net Thu Aug 7 16:24:40 2003 From: mwh at python.net (Michael Hudson) Date: Thu Aug 7 10:24:45 2003 Subject: [Pythonmac-SIG] Readline support for Python 2.3 under OS X 10.2 In-Reply-To: (Etienne Posthumus's message of "Thu, 7 Aug 2003 10:42:55 +0200 (CEST)") References: Message-ID: <2misp9pmtz.fsf@starship.python.net> Etienne Posthumus writes: > The file mentioned in: > http://mail.python.org/pipermail/pythonmac-sig/2003-June/007945.html > by Bob Ippolito gives a 404. > > I have mailed Bob Ippolito directly but he may be on holiday or busy or > whatever. Does anyone else have a copy of that file cached? > > Not having readline in the command line version is driving me nuts. You should be able to get it with Package Manager. Cheers, mwh -- MARVIN: Oh dear, I think you'll find reality's on the blink again. -- The Hitch-Hikers Guide to the Galaxy, Episode 12 From adama at augustinefam.org Thu Aug 7 10:42:32 2003 From: adama at augustinefam.org (Adam Augustine) Date: Thu Aug 7 11:39:12 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 (Solved!) In-Reply-To: References: Message-ID: <3F327368.9010905@augustinefam.org> Bob Ippolito wrote: > On Wednesday, Aug 6, 2003, at 20:01 America/New_York, Adam Augustine > wrote: > >> So I have done an "ln -s Python python" and now everything seems to >> be working properly. >> >> Anyway, thanks for the help. I am putting some search terms for the >> benefit of those who come later since most of the initial error >> messages are now edited out of the message. >> >> execle returned, err=22 console error message PythonIDE >> PackageManager BuildApplet > > > Are you using HFS (Mac OS Extended), or UFS? Sounds like you might be > using UFS, I don't think anyone tested that. > > -bob > You are correct, I am using UFS. I am happy to test, because, hey- free programming language. :-) Are there more tests I should do to help the project along? Thanks, Adam Augustine From bob at redivi.com Thu Aug 7 13:03:40 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Aug 7 12:03:50 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 (Solved!) In-Reply-To: <3F327368.9010905@augustinefam.org> Message-ID: On Thursday, Aug 7, 2003, at 11:42 America/New_York, Adam Augustine wrote: > > Bob Ippolito wrote: > >> On Wednesday, Aug 6, 2003, at 20:01 America/New_York, Adam Augustine >> wrote: >>> So I have done an "ln -s Python python" and now everything seems to >>> be working properly. >>> >>> Anyway, thanks for the help. I am putting some search terms for the >>> benefit of those who come later since most of the initial error >>> messages are now edited out of the message. >>> >>> execle returned, err=22 console error message PythonIDE >>> PackageManager BuildApplet >> Are you using HFS (Mac OS Extended), or UFS? Sounds like you might >> be using UFS, I don't think anyone tested that. >> -bob > > You are correct, I am using UFS. I am happy to test, because, hey- > free programming language. :-) > > Are there more tests I should do to help the project along? Well that was it! Here's what happened: The python executable (in the application bundle used to run GUI scripts) used to be lowercase It was renamed Python to meet Apple guidelines The she-bang lines for the GUI scripts were not also changed because worked on HFS and nobody noticed (HFS is not case sensitive) -bob From bob at redivi.com Thu Aug 7 13:06:51 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Aug 7 12:06:56 2003 Subject: [Pythonmac-SIG] Readline support for Python 2.3 under OS X 10.2 In-Reply-To: Message-ID: <28170513-C8F1-11D7-BBB5-000A95686CD8@redivi.com> On Thursday, Aug 7, 2003, at 04:42 America/New_York, Etienne Posthumus wrote: > The file mentioned in: > http://mail.python.org/pipermail/pythonmac-sig/2003-June/007945.html > by Bob Ippolito gives a 404. > > I have mailed Bob Ippolito directly but he may be on holiday or busy or > whatever. Does anyone else have a copy of that file cached? > > Not having readline in the command line version is driving me nuts. Use Package Manager to install it, my fix was only meant to be temporary to keep myself and others sane while we waited for Jack to get it in there :) -bob From adama at augustinefam.org Thu Aug 7 11:27:12 2003 From: adama at augustinefam.org (Adam Augustine) Date: Thu Aug 7 12:23:56 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 (Solved!) In-Reply-To: References: Message-ID: <3F327DE0.2010403@augustinefam.org> Bob Ippolito wrote: > On Thursday, Aug 7, 2003, at 11:42 America/New_York, Adam Augustine wrote: > >> >> Bob Ippolito wrote: >> >>> On Wednesday, Aug 6, 2003, at 20:01 America/New_York, Adam Augustine >>> wrote: >>> >>>> So I have done an "ln -s Python python" and now everything seems to >>>> be working properly. >>>> >>>> Anyway, thanks for the help. I am putting some search terms for the >>>> benefit of those who come later since most of the initial error >>>> messages are now edited out of the message. >>>> >>>> execle returned, err=22 console error message PythonIDE >>>> PackageManager BuildApplet >>> >>> Are you using HFS (Mac OS Extended), or UFS? Sounds like you might >>> be using UFS, I don't think anyone tested that. >>> -bob >> >> >> You are correct, I am using UFS. I am happy to test, because, hey- >> free programming language. :-) >> >> Are there more tests I should do to help the project along? > > > Well that was it! Here's what happened: > > The python executable (in the application bundle used to run GUI > scripts) used to be lowercase > It was renamed Python to meet Apple guidelines > The she-bang lines for the GUI scripts were not also changed because > worked on HFS and nobody noticed (HFS is not case sensitive) > > -bob > Yeah, I could have simply changed the she-bang line for all the relevant apps, but I thought, since MacPython doesn't look to be completely case-clean and probably can't reliably be so because of HFS, that the symbolic link was a better (read: easier for my lazy self to implement) solution. I know most people on other Unixes (Unicies, Unixii?) expect lowercase "python" executable names, but those are usually /usr/local/bin type places (which are already "as-expected") and not deep in the bowels of a framework. It makes sense to follow the Apple guidelines. It seems to me that the execle returned, err=22 message was pretty misleading. But then again, what do I know? :-) Adam Augustine From p.oberndoerfer at urheberrecht.org Thu Aug 7 19:40:36 2003 From: p.oberndoerfer at urheberrecht.org (Pascal Oberndoerfer) Date: Thu Aug 7 12:41:14 2003 Subject: [Pythonmac-SIG] Installing PyObjC via PackMan In-Reply-To: Message-ID: Jack Jansen at Jack.Jansen@cwi.nl: > > On woensdag, 6 augustus 2003, at 22:08PM, Pascal Oberndoerfer wrote: > >> >> I am running into trouble trying to update PyObjC from 0.9 to 1.0b1 on >> MacOS >> X 10.2.6/MacPython 2.3 (binary installer). PackMan shows me the >> previously >> installed 0.9 as "Old". Clicking on Install downloads to /tmp, but 0.9 >> isn't >> updated. The status of the overwrite checkbox didn't make any >> difference. > > The workaround is probably to first remove the old PyObjC manually. Yes, this worked for me. > But: I'd be > interested to know why this fails, so we might fix it (or, at least, > put a warning > in the PackMan database). Pascal From bob at redivi.com Thu Aug 7 13:42:50 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Aug 7 12:42:56 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 (Solved!) In-Reply-To: <3F327DE0.2010403@augustinefam.org> Message-ID: <2F078AB5-C8F6-11D7-86D4-000A95686CD8@redivi.com> On Thursday, Aug 7, 2003, at 12:27 America/New_York, Adam Augustine wrote: > > > Bob Ippolito wrote: > >> On Thursday, Aug 7, 2003, at 11:42 America/New_York, Adam Augustine >> wrote: >>> >>> Bob Ippolito wrote: >>> >>>> On Wednesday, Aug 6, 2003, at 20:01 America/New_York, Adam >>>> Augustine wrote: >>>> >>>>> So I have done an "ln -s Python python" and now everything seems >>>>> to be working properly. >>>>> >>>>> Anyway, thanks for the help. I am putting some search terms for >>>>> the benefit of those who come later since most of the initial >>>>> error messages are now edited out of the message. >>>>> >>>>> execle returned, err=22 console error message PythonIDE >>>>> PackageManager BuildApplet >>>> >>>> Are you using HFS (Mac OS Extended), or UFS? Sounds like you might >>>> be using UFS, I don't think anyone tested that. >>>> -bob >>> >>> >>> You are correct, I am using UFS. I am happy to test, because, hey- >>> free programming language. :-) >>> >>> Are there more tests I should do to help the project along? >> Well that was it! Here's what happened: >> The python executable (in the application bundle used to run GUI >> scripts) used to be lowercase >> It was renamed Python to meet Apple guidelines >> The she-bang lines for the GUI scripts were not also changed because >> worked on HFS and nobody noticed (HFS is not case sensitive) >> -bob > > Yeah, I could have simply changed the she-bang line for all the > relevant apps, but I thought, since MacPython doesn't look to be > completely case-clean and probably can't reliably be so because of > HFS, that the symbolic link was a better (read: easier for my lazy > self to implement) solution. It should be pretty much case clean, the only place where it might not be are in those GUI bundles, as you've seem. > I know most people on other Unixes (Unicies, Unixii?) expect lowercase > "python" executable names, but those are usually /usr/local/bin type > places (which are already "as-expected") and not deep in the bowels of > a framework. It makes sense to follow the Apple guidelines. It is a lowercase python executable everywhere that would be relevant to unix (/usr/local/bin/python*, /Library/Frameworks/Python.framework/Versions/2.3/bin/python*) It should, by convention, be a Capitalized exectuable everywhere that would be relevant to WindowServer (/Library/Frameworks/Python.framework/Versions/2.3/Resources/ Python.app/Contents/Resources/MacOS/Python) This is a fake application bundle that lives inside the Python framework. I don't have time to fully explain why, but basically the deal is that WindowServer has a bug/feature in that it will not like you unless it finds an application bundle at (the on-the-top-of-the-executable stack equivalent of) os.path.split(os.path.split(sys.executable)[0])[0] -- except it uses methods less intelligent than sys.executable to figure this out, so it also breaks in even more situations (executed from a shell script, executed from $PATH, executed from a relative path, executed from symlink, etc). Without this application bundle, and the pythonw script you would have a very hard time executing GUI python applications without calling into private Apple APIs (which I figured out how to do two years ago, but it's still discouraged) or creating an actual application bundle for any script you would like to execute. > It seems to me that the execle returned, err=22 message was pretty > misleading. As far as I could tell, it should've returned ENOENT (2), not EINVAL (22) according to the relevant man pages. Maybe we should look into this a bit more and file a bug against Darwin? -bob From lsloan at umich.edu Thu Aug 7 16:37:34 2003 From: lsloan at umich.edu (Lance E Sloan) Date: Thu Aug 7 15:37:42 2003 Subject: [Pythonmac-SIG] questions about the MacPython-OSX-2.3-1 installer Message-ID: <1459436.1060270654@141-213-238-90.umnet.umich.edu> When I ran the installer, the button I clicked to begin the actual install was labelled "Upgrade". Is it always labelled that? Is it ever labelled "Install"? I had deleted everything from /usr/local/bin related to the 2.3 beta that I installed a month ago. I also deleted /Library/Frameworks/Python.framework and the MacPython folder in /Applications before running the installer today. -- Lance E Sloan U-M WATS: Web Applications, Technologies, and Solutions Full-service web and database design, development, and hosting. http://www.itcs.umich.edu/wats/ - "Putting U on the Web" From jimpryor at Princeton.EDU Thu Aug 7 15:25:21 2003 From: jimpryor at Princeton.EDU (James Pryor) Date: Thu Aug 7 15:45:57 2003 Subject: [Pythonmac-SIG] Problem subclassing tuple in Python 2.3 Message-ID: In Python 2.3, there is no general difficulty with having tuples of Sets: >>> from sets import Set >>> t=tuple((Set([1]),Set([2]))) >>> print t Returns, as you'd expect: (Set([1]), Set([2])) But now suppose I subclass tuple, and want to convert the arguments supplied to the __init__ method into Sets. I'd expect this to work: >>> class mytuple(tuple): ... def __init__(self,arg): ... z=[Set([i]) for i in arg] ... tuple.__init__(self,tuple(z)) But when I try: >>> m=mytuple([1,2]) >>> m I get: (1, 2) instead of the expected: (Set([1]), Set([2])) Is this the expected behavior? If so, why? Is there a work-around? _________________________________________________ James Pryor Assoc Prof of Philosophy, Princeton University From Jack.Jansen at cwi.nl Thu Aug 7 22:47:04 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Aug 7 15:47:14 2003 Subject: [Pythonmac-SIG] questions about the MacPython-OSX-2.3-1 installer In-Reply-To: <1459436.1060270654@141-213-238-90.umnet.umich.edu> References: <1459436.1060270654@141-213-238-90.umnet.umich.edu> Message-ID: On donderdag, 7 augustus 2003, at 21:37PM, Lance E Sloan wrote: > When I ran the installer, the button I clicked to begin the actual > install was labelled "Upgrade". Is it always labelled that? Is it > ever labelled "Install"? This happens if you've done an install before, even if you manually deleted all the files. It's triggered by the receipt for the install, which is in /Library/Receipts. From bob at redivi.com Thu Aug 7 17:22:17 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Aug 7 16:22:23 2003 Subject: [Pythonmac-SIG] Problem subclassing tuple in Python 2.3 In-Reply-To: Message-ID: On Thursday, Aug 7, 2003, at 14:25 America/New_York, James Pryor wrote: > In Python 2.3, there is no general difficulty with having tuples of > Sets: > >>>> from sets import Set >>>> t=tuple((Set([1]),Set([2]))) >>>> print t > > Returns, as you'd expect: > (Set([1]), Set([2])) > > > But now suppose I subclass tuple, and want to convert the arguments > supplied > to the __init__ method into Sets. I'd expect this to work: > >>>> class mytuple(tuple): > ... def __init__(self,arg): > ... z=[Set([i]) for i in arg] > ... tuple.__init__(self,tuple(z)) > > But when I try: > >>>> m=mytuple([1,2]) >>>> m > > I get: > (1, 2) > > instead of the expected: > (Set([1]), Set([2])) > > > Is this the expected behavior? If so, why? Is there a work-around? Yes, tuple is an immutable type. It's already created and immutable before __init__ happens. In this particular example, it doesn't make much sense to subclass tuple because you're not adding any methods or changing any behavior other than the constructor.. so mytuple could be a simple function instead. In the case you do actually have a reason to subclass an immutable type and change its construction behavior, try something like the following: from sets import Set class mytuple(tuple): def __new__(klass, *args, **kwargs): return tuple.__new__(klass, *[[Set([i]) for i in arg] for arg in args], **kwargs) the reason for the *args is because your example can't create an empty mytuple >>> mytuple([1,2]) (Set([1]), Set([2])) >>> mytuple([1,2]).__class__ -bob From Jack.Jansen at cwi.nl Fri Aug 8 00:35:18 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Aug 7 17:36:03 2003 Subject: [Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 (Solved!) In-Reply-To: Message-ID: <0A4D45CE-C91F-11D7-BAD6-000A27B19B96@cwi.nl> On donderdag, aug 7, 2003, at 02:34 Europe/Amsterdam, Bob Ippolito wrote: > Are you using HFS (Mac OS Extended), or UFS? Sounds like you might be > using UFS, I don't think anyone tested that. Grpmf. I thought I had fixed this:-( I've added a note to the download page, and I'll put up a bug report so it gets fixed for 2.3.1. -- - 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 artelse at mohr-i.nl Fri Aug 8 01:13:08 2003 From: artelse at mohr-i.nl (Arthur Elsenaar) Date: Thu Aug 7 18:13:20 2003 Subject: [Pythonmac-SIG] Documentation install prob In-Reply-To: <0A4D45CE-C91F-11D7-BAD6-000A27B19B96@cwi.nl> Message-ID: <53201160-C924-11D7-B0F6-000393825740@mohr-i.nl> hi, when I try to overwrite my previous documentation with PM, it downloads fine, but then says: (FrameworkBuild): This package needs to be installed manually (no Download-URL field) It didn't say so using one of the recent beta's.. Arthur From Jack.Jansen at cwi.nl Fri Aug 8 11:36:01 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 8 04:33:36 2003 Subject: [Pythonmac-SIG] Documentation install prob In-Reply-To: <53201160-C924-11D7-B0F6-000393825740@mohr-i.nl> Message-ID: <572C44E2-C97B-11D7-8654-0030655234CE@cwi.nl> On Friday, Aug 8, 2003, at 00:13 Europe/Amsterdam, Arthur Elsenaar wrote: > hi, > > when I try to overwrite my previous documentation with PM, it > downloads fine, but then says: > > (FrameworkBuild): This package needs to be installed manually (no > Download-URL field) > > It didn't say so using one of the recent beta's.. Did you set the "Force Install" flag, as you seem to indicate from the use of overwrite? If so, then this is a known bug. The force-install bit is applied recursively to all dependency packages, hence PM tries to install FrameworkBuild too, but fails at this as it is a pseudo-package. -- 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 lsloan at umich.edu Fri Aug 8 14:11:48 2003 From: lsloan at umich.edu (Lance E Sloan) Date: Fri Aug 8 13:11:57 2003 Subject: [Pythonmac-SIG] MacPython 2.3 docs are handy! Message-ID: <2198749.1060348308@141-213-238-90.umnet.umich.edu> I just installed MacPython OSX 2.3 and used Package Manager to install the documentation, PyObjC, and a couple other things. It went smoothly. The documentation looks great in Apple's Help Viewer. There are a few problems I've noticed, but they're all just lackings of the Help Viewer and not the documentation. I've never had a copy before, but this may prompt me to get a copy of the documentation that I can browse with Safari, and keep it locally. Looking forward to more free time so I can really play with MacPython. -- Lance E Sloan U-M WATS: Web Applications, Technologies, and Solutions Full-service web and database design, development, and hosting. http://www.itcs.umich.edu/wats/ - "Putting U on the Web" From berkowit at silcom.com Fri Aug 8 11:32:07 2003 From: berkowit at silcom.com (Paul Berkowitz) Date: Fri Aug 8 13:40:25 2003 Subject: [Pythonmac-SIG] MacPython 2.3 docs are handy! In-Reply-To: <2198749.1060348308@141-213-238-90.umnet.umich.edu> Message-ID: On 8/8/03 10:11 AM, "Lance E Sloan" wrote: > I just installed MacPython OSX 2.3 and used Package Manager to install the > documentation, PyObjC, and a couple other things. It went smoothly. As a very new Pythonist, I've been noting the determined efforts of many of you here (especially Jack) to get everything organized. My own concern is that I will ultimately wish to use a version of Python which will work with no need for ordinary users to download anything whatsoever as long as they're using Panther when it's released. I can live with that limitation. And if there are tools in MacPython that make things easier or better for me while developing without losing that capability, that sounds great. In fact, I can't imagine that otherwise there would be any need for a separate MacPython, would there, if Panther contains Python 2.3? What I would really appreciate in due course would be a document or website that explained to me - who knows so far only what I've learned about Python from tutorials and books - what advantages there would be for me to install MacPython and ways to restrict my use of it to prevent any incompatibility with released unixy Python-to-come in Panther so that users will not need any installations other than my apps. A document I could read _before_ installing MacPython, and which also explains any conflicts or incompatibilities (or otherwise) I might have by having two different Python installations on my computer. I realize all you here have umpteen installations but I am really keen to keep my machine as close to a potential user's as possible. I imagine it's too soon to point me anywhere, but I'd appreciate if those of you working on MacPython could keep this request in the back of your minds and prepare something of the sort when the time is right. Think of me as a total Python newbie, but not programming newbie, looking for guidance here on the potential and ease-of-use of Python on the Mac. I suspect there are quite a few people like me. Many thanks in advance. -- Paul Berkowitz From oussoren at cistron.nl Fri Aug 8 21:43:27 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Fri Aug 8 14:43:30 2003 Subject: [Pythonmac-SIG] MacPython 2.3 docs are handy! In-Reply-To: References: Message-ID: <331C184B-C9D0-11D7-B048-0003931CFE24@cistron.nl> On Friday, 8 August, 2003, at 19:32, Paul Berkowitz wrote: > On 8/8/03 10:11 AM, "Lance E Sloan" wrote: > >> I just installed MacPython OSX 2.3 and used Package Manager to >> install the >> documentation, PyObjC, and a couple other things. It went smoothly. > > As a very new Pythonist, I've been noting the determined efforts of > many of > you here (especially Jack) to get everything organized. > > My own concern is that I will ultimately wish to use a version of > Python > which will work with no need for ordinary users to download anything > whatsoever as long as they're using Panther when it's released. I can > live > with that limitation. And if there are tools in MacPython that make > things > easier or better for me while developing without losing that > capability, > that sounds great. In fact, I can't imagine that otherwise there would > be > any need for a separate MacPython, would there, if Panther contains > Python > 2.3? Apple doesn't include the GUI frontends (e.g. the IDE and Package Manager). IIRC Jack already stated that he wants to do a MacPython for Panther that contains only the bits that are not included by Apple. Ronald From Jack.Jansen at cwi.nl Fri Aug 8 23:05:45 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 8 16:05:54 2003 Subject: [Pythonmac-SIG] MacPython 2.3 docs are handy! In-Reply-To: <331C184B-C9D0-11D7-B048-0003931CFE24@cistron.nl> Message-ID: On vrijdag, aug 8, 2003, at 20:43 Europe/Amsterdam, Ronald Oussoren wrote: >> My own concern is that I will ultimately wish to use a version of >> Python >> which will work with no need for ordinary users to download anything >> whatsoever as long as they're using Panther when it's released. I can >> live >> with that limitation. And if there are tools in MacPython that make >> things >> easier or better for me while developing without losing that >> capability, >> that sounds great. In fact, I can't imagine that otherwise there >> would be >> any need for a separate MacPython, would there, if Panther contains >> Python >> 2.3? > > Apple doesn't include the GUI frontends (e.g. the IDE and Package > Manager). IIRC Jack already stated that he wants to do a MacPython for > Panther that contains only the bits that are not included by Apple. Right. Moreover, this MacPython-for-Panther installer will put any modules it needs to install into site-packages. This means that you should be able to develop an application with MacPython-for-Panther, then build the deliverable with "bundlebuilder.py --semi-standalone" and the result will be runnable on a Panther machine without MacPython. I.e. anything you use that was installed by the MacPython installer, or through Package Manager, will be included in your executable if you use the --semi-standalone option to bundlebuilder. At least, that is the theory. The code is out there, but it has never been tested yet:-) -- - 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 Sat Aug 9 01:06:28 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 8 18:06:35 2003 Subject: [Pythonmac-SIG] Wanted: proofreader for www.python.org Mac information Message-ID: <8F13DB32-C9EC-11D7-A50E-000A27B19B96@cwi.nl> Folks, I need help as I'm developing large blind spots where reading webpages on MacPython is concerned. There are lots of places on www.python.org where there are references to "Macintosh" or "MacPython" that need updating, because the really refer only to the old OS9 stuff. If people have time to look at this that would be much appreciated. Please post your findings here, so if multiple people look at this you won't be doing double work. Thanks, -- - 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 Fri Aug 8 18:16:55 2003 From: skip at pobox.com (Skip Montanaro) Date: Fri Aug 8 18:17:04 2003 Subject: [Pythonmac-SIG] Wanted: proofreader for www.python.org Mac information In-Reply-To: <8F13DB32-C9EC-11D7-A50E-000A27B19B96@cwi.nl> References: <8F13DB32-C9EC-11D7-A50E-000A27B19B96@cwi.nl> Message-ID: <16180.8535.213955.204700@montanaro.dyndns.org> Jack> There are lots of places on www.python.org where there are Jack> references to "Macintosh" or "MacPython" that need updating, Jack> because the really refer only to the old OS9 stuff. Are there any generally preferred terms you would like used to distinguish the OS9 and OSX versions? Skip From Sung.Kim at corp.palm.com Fri Aug 8 18:29:44 2003 From: Sung.Kim at corp.palm.com (Sung Kim) Date: Fri Aug 8 20:30:10 2003 Subject: [Pythonmac-SIG] Folder locations? Message-ID: I have a general Mac question, which I'm having a hard time answering. I hope that's okay. If we create a new folder (inside another), open it and then set its window size, where is the size stored? Apparently, MacOS 9.x and MacOS X stores them in different places? Thank you! --Sung Kim Sung.Kim@corp.palm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20030808/9d9d6a8e/attachment.htm From mbagai at arslegal.com Fri Aug 8 21:24:49 2003 From: mbagai at arslegal.com (Morten Bagai) Date: Fri Aug 8 23:23:51 2003 Subject: [Pythonmac-SIG] Fwd: TIFF Group 4 support in PIL from PackageManager Message-ID: <0845434D-CA19-11D7-B134-003065CC438E@arslegal.com> Hi, Does the PIL 1.1.4 package available from PackageManager apply the patch recently posted to the Python Imaging SIG that enables support for TIFFS with Group 4 compression by using libtiff? If not, what is the easiest way to unsintall a package installed with PackageManager (newbie, sorry) /Morten --------------------------------- Morten Bagai 3949 Los Feliz Blvd Apt 612 Los Angeles, 90027 CA USA Cell: +01 323-893-7501 Email: morten AT bagai.com AIM: membrane AT mac.com --------------------------------- Morten Bagai 3949 Los Feliz Blvd Apt 612 Los Angeles, 90027 CA USA Cell: +01 323-893-7501 Email: morten AT bagai.com AIM: membrane AT mac.com From bob at redivi.com Sat Aug 9 06:13:45 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Aug 9 05:14:22 2003 Subject: [Pythonmac-SIG] Fwd: TIFF Group 4 support in PIL from PackageManager In-Reply-To: <0845434D-CA19-11D7-B134-003065CC438E@arslegal.com> Message-ID: On Friday, Aug 8, 2003, at 23:24 America/New_York, Morten Bagai wrote: > Does the PIL 1.1.4 package available from PackageManager apply the > patch recently posted to the Python Imaging SIG that enables support > for TIFFS with Group 4 compression by using libtiff? I dunno, why don't you tell me more specifically where to find this patch, and a Group 4 compression TIFF to test with? > If not, what is the easiest way to unsintall a package installed with > PackageManager (newbie, sorry) Just install a new copy over it. -bob From andrew.straw at adelaide.edu.au Sat Aug 9 14:20:33 2003 From: andrew.straw at adelaide.edu.au (Andrew Straw) Date: Sat Aug 9 07:20:09 2003 Subject: [Pythonmac-SIG] turning off "toolbar" without going fullscreen? Message-ID: <7DC6B754-CA5B-11D7-AE28-00039311EA24@adelaide.edu.au> Is it possible to turn off the toolbar on the upper part of the screen in a normal (non-fullscreen) app? How? (I'm trying to make full-screen windows on multiple monitors, which isn't supported by the library, SDL/pygame I'm using. Therefore, I've been using full-screen sized windows without a frame. This works fine, except the toolbar still appears.) Cheers! Andrew From bob at redivi.com Sat Aug 9 08:57:06 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Aug 9 07:57:42 2003 Subject: [Pythonmac-SIG] turning off "toolbar" without going fullscreen? In-Reply-To: <7DC6B754-CA5B-11D7-AE28-00039311EA24@adelaide.edu.au> Message-ID: <9939A55E-CA60-11D7-86D4-000A95686CD8@redivi.com> On Saturday, Aug 9, 2003, at 07:20 America/New_York, Andrew Straw wrote: > Is it possible to turn off the toolbar on the upper part of the screen > in a normal (non-fullscreen) app? How? > > (I'm trying to make full-screen windows on multiple monitors, which > isn't supported by the library, SDL/pygame I'm using. Therefore, I've > been using full-screen sized windows without a frame. This works > fine, except the toolbar still appears.) It's probably better to fix SDL/pygame than to try and do that :) If you show me what you're trying to do (i.e. by reduced code sample, or whatever) I can take a look at it.. I have two monitors (well a powerbook display and an external lcd) on this machine. -bob From bob at redivi.com Sat Aug 9 10:57:02 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Aug 9 09:57:41 2003 Subject: [Pythonmac-SIG] ANN: Tcl/Tk Aqua 8.4.4 Message-ID: <5A7B6092-CA71-11D7-BBE9-000A95686CD8@redivi.com> I'm not sure how many of you are watching freshmeat or the ADC mailer for these things.. but since it's particularly relevant to MacPython (tkinter -- which is what IDLE uses, among other things), I figured I'd send out a note that a new version of Tcl/Tk Aqua has been released. Here's the blurb from the ADC: Tcl/Tk Aqua 8.4.4 is the latest binary distribution of the Mac OS X native port of the Tcl scripting language, the Tk toolkit and more than 40 popular extensions like incrTcl, TclX, Expect, Tcllib etc. http://tcltkaqua.sourceforge.net/ -bob From skip at pobox.com Sat Aug 9 13:53:31 2003 From: skip at pobox.com (Skip Montanaro) Date: Sat Aug 9 13:53:41 2003 Subject: [Pythonmac-SIG] ANN: Tcl/Tk Aqua 8.4.4 In-Reply-To: <5A7B6092-CA71-11D7-BBE9-000A95686CD8@redivi.com> References: <5A7B6092-CA71-11D7-BBE9-000A95686CD8@redivi.com> Message-ID: <16181.13595.213803.669922@montanaro.dyndns.org> Bob> I'm not sure how many of you are watching freshmeat or the ADC Bob> mailer for these things.. [tcl/tk aqua bit] Thanks. I never look at freshmeat and the ADC mailings have so much other stuff in them I must have missed this. Skip From tjk at ams.org Sat Aug 9 15:46:47 2003 From: tjk at ams.org (Tom Kacvinsky) Date: Sat Aug 9 14:47:19 2003 Subject: [Pythonmac-SIG] ANN: Tcl/Tk Aqua 8.4.4 In-Reply-To: <16181.13595.213803.669922@montanaro.dyndns.org> References: <5A7B6092-CA71-11D7-BBE9-000A95686CD8@redivi.com> <16181.13595.213803.669922@montanaro.dyndns.org> Message-ID: This reminds me of a friend of mine who had freshmeat blocked at the firewall becasue the admins thought it was a porn site.... On Sat, 9 Aug 2003, Skip Montanaro wrote: > Thanks. I never look at freshmeat... From gandreas at delver.com Sun Aug 10 12:42:47 2003 From: gandreas at delver.com (Glenn Andreas) Date: Sun Aug 10 12:42:59 2003 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.3 - Cocoa based Python IDE Message-ID: PyOXIDE has finally reached a "mostly full featured" state - there are still bugs, and a few other rough edges, but this version fixes a lot of problems with debugging, add breakpoint support, a re-written module browser (that actually acts more like a browser), the ability to run scripts externally, and the ability to profile modules, as well as various bug fixes and the like. PyOXIDE 0.3 is now freely available on my idisk (as PyOXIDE_0.3.dmg): http://homepage.mac.com/gandreas/ Hopefully 0.3 is stable enough and feature-rich enough to accomplish anything that you could have done in the old IDE (and then some). Unless there are major problems that require another release, the plan is for 0.4 to add support for "projects", as well as (hopefully) full Objective-C source (including the "IDE Kit"), and a few other architectual changes, but that may take a bit, so I figured that this would be a good point to get it out the door. If there are any other features/capabilities that you'd like see, please let me know. Glenn Andreas gandreas@delver.com Author of Macintosh games: Theldrow 2.3, Blobbo 1.0.2, Cythera 1.0.2 Be good, and you will be lonesome From just at letterror.com Sun Aug 10 20:20:18 2003 From: just at letterror.com (Just van Rossum) Date: Sun Aug 10 13:25:17 2003 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.3 - Cocoa based Python IDE In-Reply-To: Message-ID: Glenn Andreas wrote: > PyOXIDE has finally reached a "mostly full featured" state - there > are still bugs, and a few other rough edges, but this version fixes a > lot of problems with debugging, add breakpoint support, a re-written > module browser (that actually acts more like a browser), the ability > to run scripts externally, and the ability to profile modules, as > well as various bug fixes and the like. > > PyOXIDE 0.3 is now freely available on my idisk (as PyOXIDE_0.3.dmg): > http://homepage.mac.com/gandreas/ > > Hopefully 0.3 is stable enough and feature-rich enough to accomplish > anything that you could have done in the old IDE (and then some). > > Unless there are major problems that require another release, the > plan is for 0.4 to add support for "projects", as well as (hopefully) > full Objective-C source (including the "IDE Kit"), and a few other > architectual changes, but that may take a bit, so I figured that this > would be a good point to get it out the door. > > > If there are any other features/capabilities that you'd like see, > please let me know. I'm a little annoyed you don't give the original MacPython IDE any credit, while when I read the (Python) sources I see some familiar code. You would do the community a great favor to publish the full source; it would be great to bundle our resources and make this a collaborative effort. Just From 4jxn at earthlink.net Fri Aug 8 16:57:41 2003 From: 4jxn at earthlink.net (George M. Jackson,M.D.) Date: Sun Aug 10 17:08:29 2003 Subject: [Pythonmac-SIG] loading 221 in OSX Message-ID: Greetings, I need to install Python interpreter version2.2.1 for use inside Fontlab. I am using the vise installer I downloaded from python.org (python.org/ftp/python/2.2.1/MacPython221full.hqx) On each try, the classic 9 version installs, but in the eleventh hour a pop-up warning instructs that the the "configure python carbon" routine will probably fail (which it does), and that I should run this routine "manually". At this juncture I have a screen freeze requiring a force quit and leaving a "terminate" notice box with a blinking cursor as though awaiting further instructions (as well as an installation box suggesting that Carbon installation is complete, the thermometer bar is all the way across, and specifies zero items remaining for installation) there is also a warning that this manual run through of the "configure" routine is needed before I try anything else with Python. Please inform how to run a "manual" once through with "configure python carbon." Thank you. Note: Fontlab specifies that 2.2.1 is the only version that runs inside Fontlab, and with few exceptions, I do not run Mac Classic 9 on this platform any more (I have to revert to Classic 9 to run my "Monty Python's Complete Waste of Time" interactive CD.........) For that matter if you know of a version of "Monty Python's Complete Wast of Time that runs in OS X, I am interested. In the event this problem is opaque to you as well, I would appreciate referal to other support sources. note: I have run through the FAQs at Python.org without success. George Jackson From lists at bagai.com Fri Aug 8 21:22:30 2003 From: lists at bagai.com (Morten Bagai) Date: Sun Aug 10 17:08:33 2003 Subject: [Pythonmac-SIG] TIFF Group 4 support in PIL from PackageManager Message-ID: Hi, Does the PIL 1.1.4 package available from PackageManager apply the patch recently posted to the Python Imaging SIG that enables support for TIFFS with Group 4 compression by using libtiff? If not, what is the easiest way to unsintall a package installed with PackageManager (newbie, sorry) /Morten --------------------------------- Morten Bagai 3949 Los Feliz Blvd Apt 612 Los Angeles, 90027 CA USA Cell: +01 323-893-7501 Email: morten AT bagai.com AIM: membrane AT mac.com From Jack.Jansen at cwi.nl Mon Aug 11 00:11:37 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Aug 10 17:11:50 2003 Subject: [Pythonmac-SIG] ANN: Tcl/Tk Aqua 8.4.4 In-Reply-To: <5A7B6092-CA71-11D7-BBE9-000A95686CD8@redivi.com> Message-ID: <3A53EC36-CB77-11D7-889B-000A27B19B96@cwi.nl> On zaterdag, aug 9, 2003, at 15:57 Europe/Amsterdam, Bob Ippolito wrote: > I'm not sure how many of you are watching freshmeat or the ADC mailer > for these things.. but since it's particularly relevant to MacPython > (tkinter -- which is what IDLE uses, among other things), I figured > I'd send out a note that a new version of Tcl/Tk Aqua has been > released. Here's the blurb from the ADC: > > Tcl/Tk Aqua 8.4.4 is the latest binary distribution of the Mac OS X > native port of the Tcl scripting language, the Tk toolkit and more > than 40 popular extensions like incrTcl, TclX, Expect, Tcllib etc. > http://tcltkaqua.sourceforge.net/ If someone tests it with _tkinter and IDLE, please let me know whether it works. If it works as-is, i.e. without rebuilding _tkinter, then I'll drop it in PackageManager straight away, if it needs _tkinter recompilation I'll put it on my to-do. -- - 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 joanca at casasin.com Sun Aug 10 18:27:21 2003 From: joanca at casasin.com (Joancarles Casasin) Date: Sun Aug 10 17:25:44 2003 Subject: [Pythonmac-SIG] loading 221 in OSX In-Reply-To: Message-ID: On 08/08/2003 at 15:57, George M. Jackson,M.D. <4jxn@earthlink.net> wrote: >Note: Fontlab specifies that 2.2.1 is the only version that runs inside >Fontlab, >and with few exceptions, I do not run Mac Classic 9 on this platform >any more I'm running FontLab with 2.2.3 version of Python and seems to work fine. I switched to 2.2.2 and after that to 2.2.3 without realizing that the FontLab manual says it's supposed to work *only* with 2.2.1 I don't use it too much scripting there, though (in fact, I don't use FontLab too much yet ). #in FontLab 4.5.2 "Macro" editor: import sys print sys.version #output window: 2.2.3 (#139, Jun 1 2003, 23:11:08) [CW CARBON GUSI2 THREADS GC] Joancarles From bob at redivi.com Sun Aug 10 18:29:01 2003 From: bob at redivi.com (Bob Ippolito) Date: Sun Aug 10 17:29:41 2003 Subject: [Pythonmac-SIG] ANN: Tcl/Tk Aqua 8.4.4 In-Reply-To: <3A53EC36-CB77-11D7-889B-000A27B19B96@cwi.nl> Message-ID: On Sunday, Aug 10, 2003, at 17:11 America/New_York, Jack Jansen wrote: > > On zaterdag, aug 9, 2003, at 15:57 Europe/Amsterdam, Bob Ippolito > wrote: > >> I'm not sure how many of you are watching freshmeat or the ADC mailer >> for these things.. but since it's particularly relevant to MacPython >> (tkinter -- which is what IDLE uses, among other things), I figured >> I'd send out a note that a new version of Tcl/Tk Aqua has been >> released. Here's the blurb from the ADC: >> >> Tcl/Tk Aqua 8.4.4 is the latest binary distribution of the Mac OS X >> native port of the Tcl scripting language, the Tk toolkit and more >> than 40 popular extensions like incrTcl, TclX, Expect, Tcllib etc. >> http://tcltkaqua.sourceforge.net/ > > If someone tests it with _tkinter and IDLE, please let me know whether > it works. > If it works as-is, i.e. without rebuilding _tkinter, then I'll drop it > in PackageManager straight away, if it needs _tkinter recompilation > I'll put it on my to-do. Works as-is for me. -bob From Jack.Jansen at cwi.nl Mon Aug 11 12:01:23 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Aug 11 04:58:56 2003 Subject: [Pythonmac-SIG] Wanted: proofreader for www.python.org Mac information In-Reply-To: <16180.8535.213955.204700@montanaro.dyndns.org> Message-ID: <61AD731A-CBDA-11D7-B8C8-0030655234CE@cwi.nl> On Saturday, Aug 9, 2003, at 00:16 Europe/Amsterdam, Skip Montanaro wrote: > > Jack> There are lots of places on www.python.org where there are > Jack> references to "Macintosh" or "MacPython" that need updating, > Jack> because the really refer only to the old OS9 stuff. > > Are there any generally preferred terms you would like used to > distinguish > the OS9 and OSX versions? I tend to use "MacPython" nowadays to refer to the OSX version, and "MacPython-OS9" to refer to the OS9 version. In text I'm also doing this for 2.2 and earlier, but I haven't gone as far as renaming downloadable installers, 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 astraw at insightscientific.com Mon Aug 11 16:29:42 2003 From: astraw at insightscientific.com (Andrew Straw) Date: Mon Aug 11 09:29:17 2003 Subject: [Pythonmac-SIG] turning off "toolbar" without going fullscreen? In-Reply-To: <9939A55E-CA60-11D7-86D4-000A95686CD8@redivi.com> Message-ID: >> Is it possible to turn off the toolbar on the upper part of the >> screen in a normal (non-fullscreen) app? How? >> >> (I'm trying to make full-screen windows on multiple monitors, which >> isn't supported by the library, SDL/pygame I'm using. Therefore, >> I've been using full-screen sized windows without a frame. This >> works fine, except the toolbar still appears.) > > It's probably better to fix SDL/pygame than to try and do that :) Yeah, well, here's hoping SDL starts supporting multiple screens and windows soon! Actually, I was hoping a Mac guru would just say, "oh, yeah -- turn of the toolbar with NSTurnToolbarOff()". :) > If you show me what you're trying to do (i.e. by reduced code sample, > or whatever) I can take a look at it.. I have two monitors (well a > powerbook display and an external lcd) on this machine. That would be cool. Here's a minimal pygame example: #!/usr/bin/env python import pygame from pygame.locals import * import os # set this to the combined resolution of the two monitors: RES = 1600, 600 # create window at lowerleft of screen to get fullscreen os.environ['SDL_VIDEO_WINDOW_POS']="0,0" # (requires SDL from late July 2003 to work in Quartz) pygame.init() screen = pygame.display.set_mode(RES, NOFRAME) # Now we have "fullscreen", but in OS X, there's still a toolbar on top. clock = pygame.time.Clock() while not pygame.event.peek((QUIT,KEYDOWN,MOUSEBUTTONDOWN)): clock.tick(100) pygame.display.flip() From lsloan at umich.edu Mon Aug 11 10:30:44 2003 From: lsloan at umich.edu (Lance E Sloan) Date: Mon Aug 11 09:30:51 2003 Subject: [Pythonmac-SIG] MacPython for Panther (was: Re: MacPython 2.3 docs are handy!) In-Reply-To: <331C184B-C9D0-11D7-B048-0003931CFE24@cistron.nl> References: <331C184B-C9D0-11D7-B048-0003931CFE24@cistron.nl> Message-ID: <2697510.1060594244@141-213-238-90.umnet.umich.edu> --On Friday, August 8, 2003 20:43 +0200 Ronald Oussoren wrote: > Apple doesn't include the GUI frontends (e.g. the IDE and Package > Manager). IIRC Jack already stated that he wants to do a MacPython for > Panther that contains only the bits that are not included by Apple. I hope that future versions of MacPython, released with Panther in mind, will be available as both "tools only" and "kitchen sink" packages. I think most developers will need only the "tools only" package. There might be some that would want the "kitchen sink" package that includes the Python interpreter and supporting files that Apple would normally include with Panther. For exmaple, to get a newer (or older) version, or to fix a broken installation. I agree with Mr. Berkowitz' desire to make as few changes to his development system as possible, in order to keep it similar to that of users of his software. I hope that the MacPython releases will eventually be needed by developers only. I wonder, though, if developers use the Package Manager to install packages for use in their software, how will end-users of that software install those packages? -- Lance E Sloan U-M WATS: Web Applications, Technologies, and Solutions Full-service web and database design, development, and hosting. http://www.itcs.umich.edu/wats/ - "Putting U on the Web" From mwh at python.net Mon Aug 11 15:36:13 2003 From: mwh at python.net (Michael Hudson) Date: Mon Aug 11 09:36:17 2003 Subject: [Pythonmac-SIG] MacPython for Panther In-Reply-To: <2697510.1060594244@141-213-238-90.umnet.umich.edu> (Lance E Sloan's message of "Mon, 11 Aug 2003 09:30:44 -0400") References: <331C184B-C9D0-11D7-B048-0003931CFE24@cistron.nl> <2697510.1060594244@141-213-238-90.umnet.umich.edu> Message-ID: <2m3cg8pb8y.fsf@starship.python.net> Lance E Sloan writes: > --On Friday, August 8, 2003 20:43 +0200 Ronald Oussoren > wrote: >> Apple doesn't include the GUI frontends (e.g. the IDE and Package >> Manager). IIRC Jack already stated that he wants to do a MacPython for >> Panther that contains only the bits that are not included by Apple. > > I hope that future versions of MacPython, released with Panther in > mind, will be available as both "tools only" and "kitchen sink" > packages. That was the impression I got. > I think most developers will need only the "tools only" package. > There might be some that would want the "kitchen sink" package that > includes the Python interpreter and supporting files that Apple > would normally include with Panther. For exmaple, to get a newer > (or older) version, or to fix a broken installation. > > I agree with Mr. Berkowitz' desire to make as few changes to his > development system as possible, in order to keep it similar to that of > users of his software. I hope that the MacPython releases will > eventually be needed by developers only. I wonder, though, if > developers use the Package Manager to install packages for use in > their software, how will end-users of that software install those > packages? Well, depending on various factors, two options are 1) tell them to install Package Manager and use it to get packages X, Y and Z, if they don't have them already and 2) use the --semi-standalone option to bundlebuilder, which bundles all non-standard modules and extensions into the .app. Cheers, mwh -- Well, yes. I don't think I'd put something like "penchant for anal play" and "able to wield a buttplug" in a CV unless it was relevant to the gig being applied for... -- Matt McLeod, alt.sysadmin.recovery From altis at semi-retired.com Mon Aug 11 10:25:40 2003 From: altis at semi-retired.com (Kevin Altis) Date: Mon Aug 11 12:18:40 2003 Subject: [Pythonmac-SIG] Wanted: proofreader for www.python.org Macinformation In-Reply-To: <61AD731A-CBDA-11D7-B8C8-0030655234CE@cwi.nl> Message-ID: > From: Jack Jansen > > On Saturday, Aug 9, 2003, at 00:16 Europe/Amsterdam, Skip Montanaro > wrote: > > > > > Jack> There are lots of places on www.python.org where there are > > Jack> references to "Macintosh" or "MacPython" that need updating, > > Jack> because the really refer only to the old OS9 stuff. > > > > Are there any generally preferred terms you would like used to > > distinguish > > the OS9 and OSX versions? > > I tend to use "MacPython" nowadays to refer to the OSX version, and > "MacPython-OS9" > to refer to the OS9 version. In text I'm also doing this for 2.2 and > earlier, but > I haven't gone as far as renaming downloadable installers, etc. I wonder if the name MacPython just confuses the issue. Its just Python, right? I have a couple of Mac OS X using friends that I have been pushing towards Python and the name difference has confused them, at least a bit. In the docs, the Mac stuff is put in its own section http://www.python.org/doc/current/mac/mac.html rather than http://www.python.org/doc/current/lib/lib.html Since Unix, Windows, SunOS, and SGI IRIX aren't separated, it seems strange to single out the Mac and force people to look in a different spot. Generally, the docs simply have a note about availability for a given module or function. Likewise, calling it MacPython to me makes it sound like somehow it is a different beast, like Jython is a totally different beast or it is some special package you need in addition to standard Python. So maybe in the future, the docs should be merged and the name MacPython is used just for the extras like the IDE? Then again, maybe that will confuse the issue even more. ka From andrew.straw at adelaide.edu.au Mon Aug 11 20:41:03 2003 From: andrew.straw at adelaide.edu.au (Andrew Straw) Date: Mon Aug 11 13:40:29 2003 Subject: [Pythonmac-SIG] turning off "toolbar" without going fullscreen? In-Reply-To: Message-ID: > Actually, I was hoping a Mac guru would just say, "oh, yeah -- turn of > the toolbar with NSTurnToolbarOff()". :) I figured it out: When using a recent pygame with Bob's latest macosx module, do this after importing (and probably initing) pygame: import pygame.macosx pygame.macosx.app.mainMenu().setMenuBarVisible_(False) This leads to another question from a total PyObjC (and ObjC) newbie: Is there anyway to grab the instance of NSApplication in use without knowing the innards of some (possibly) PyObjC module that started it? Cheers! Andrew From mwh at python.net Mon Aug 11 19:45:42 2003 From: mwh at python.net (Michael Hudson) Date: Mon Aug 11 13:45:44 2003 Subject: [Pythonmac-SIG] turning off "toolbar" without going fullscreen? In-Reply-To: (Andrew Straw's message of "Mon, 11 Aug 2003 19:41:03 +0200") References: Message-ID: <2misp4rsu1.fsf@starship.python.net> Andrew Straw writes: > Is there anyway to grab the instance of NSApplication in use without > knowing the innards of some (possibly) PyObjC module that started it? Either AppKit.NSApplication.sharedApplication() or AppKit.NSApp() should work. Cheers, mwh -- First time I've gotten a programming job that required a drug test. I was worried they were going to say "you don't have enough LSD in your system to do Unix programming". -- Paul Tomblin -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html From bob at redivi.com Mon Aug 11 14:40:37 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Aug 11 13:49:07 2003 Subject: [Pythonmac-SIG] turning off "toolbar" without going fullscreen? Message-ID: <04CE2971-CC24-11D7-A79E-000A95686CD8@redivi.com> On Monday, Aug 11, 2003, at 13:26 America/New_York, Andrew Straw wrote: >> Actually, I was hoping a Mac guru would just say, "oh, yeah -- turn >> of the toolbar with NSTurnToolbarOff()". :) > > I figured it out: > > When using a recent pygame with Bob's latest macosx module, do this > after importing (and probably initing) pygame: > > > import pygame.macosx > pygame.macosx.app.mainMenu().setMenuBarVisible_(False) > > > This leads to another question from a total PyObjC (and ObjC) newbie: > > Is there anyway to grab the instance of NSApplication in use without > knowing the innards of some (possibly) PyObjC module that started it? Wow, cool, I'm glad you got it working :) NSApplication is a singleton.. NSApplication.sharedApplication() will always return the same thing for a particular process, you don't need to dig at the pygame one. -bob From Benjamin.Schollnick at usa.xerox.com Mon Aug 11 15:07:14 2003 From: Benjamin.Schollnick at usa.xerox.com (Schollnick, Benjamin) Date: Mon Aug 11 14:07:20 2003 Subject: [Pythonmac-SIG] Wanted: proofreader for www.python.org Macinf ormation Message-ID: <51B62EFFBC83D6118ADA00096BB030A102CC2DD6@usamcms7.mc.usa.xerox.com> > I wonder if the name MacPython just confuses the issue. Its > just Python, > right? I have a couple of Mac OS X using friends that I have > been pushing > towards Python and the name difference has confused them, at > least a bit. That's a good point.... I don't know if anyone has really thought about that... We could call it "Python", and add a small "with Macintosh Add-ons. Including a Gui IDE, and other accessories...And Batteries" - Benjamin From sb.list at sb.org Mon Aug 11 15:13:58 2003 From: sb.list at sb.org (Stonewall Ballard) Date: Mon Aug 11 14:17:07 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? Message-ID: I've been trying out Python for a few weeks, and have decided to convert to it for scripting. I had been using Perl and AppleScript for scripting. I'm on OS X 10.2.6. I spent many hours yesterday trying to figure out how to use the AppleScript support that comes with MacPython 2.3, and wasn't able to make much progress. Even a simple script like this: tell application "TextEdit" get word 1 of document 1 end tell doesn't work. I guess I'm missing some understanding of how this works, since according to ScriptDebugger, "word" isn't an element of "document" in the first place. But somehow it works in AppleScript. Can anyone explain this? It would be really nice to have something that works like the MacPerl "doScript" command, which takes a string, compiles it as an AppleScript, and runs it. It's much easier to figure out how to drive AppleScriptable apps that way. Perhaps it's slower than sending apple events directly, but for my purposes, that doesn't matter. The archives of this group suggest that such a "doscript" facility used to exist, but I don't see it anywhere. Can someone tell me where I can find this if it exists? It would also be very helpful to see examples of Python sending Apple Events. The doc example is too trivial to help much. I'd greatly appreciate any source code that you all might want to share. Thanks for any help. - Stoney -- Stonewall Ballard stoney@sb.org http://stoney.sb.org/ From bob at redivi.com Mon Aug 11 15:29:13 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Aug 11 14:29:48 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: Message-ID: Try aeve .. from http://undefined.org/python/ import aeve textedit = aeve.talkto('/Applications/TextEdit.app') print textedit.documents[0].text Currently, I think aeve just coerces text to a python string and doesn't give you access to asking for paragraph/word/etc. I'll probably change that in the future. -bob The only reason the "word" stuff works is because AppleScript handles that stuff internally On Monday, Aug 11, 2003, at 14:13 America/New_York, Stonewall Ballard wrote: > I've been trying out Python for a few weeks, and have decided to > convert to > it for scripting. I had been using Perl and AppleScript for scripting. > I'm > on OS X 10.2.6. > > I spent many hours yesterday trying to figure out how to use the > AppleScript > support that comes with MacPython 2.3, and wasn't able to make much > progress. Even a simple script like this: > > tell application "TextEdit" > get word 1 of document 1 > end tell > > doesn't work. I guess I'm missing some understanding of how this works, > since according to ScriptDebugger, "word" isn't an element of > "document" in > the first place. But somehow it works in AppleScript. Can anyone > explain > this? > > It would be really nice to have something that works like the MacPerl > "doScript" command, which takes a string, compiles it as an > AppleScript, and > runs it. It's much easier to figure out how to drive AppleScriptable > apps > that way. Perhaps it's slower than sending apple events directly, but > for my > purposes, that doesn't matter. > > The archives of this group suggest that such a "doscript" facility > used to > exist, but I don't see it anywhere. Can someone tell me where I can > find > this if it exists? > > It would also be very helpful to see examples of Python sending Apple > Events. The doc example is too trivial to help much. I'd greatly > appreciate > any source code that you all might want to share. > > Thanks for any help. > > - Stoney > > -- > Stonewall Ballard > stoney@sb.org http://stoney.sb.org/ > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From sb.list at sb.org Mon Aug 11 15:54:39 2003 From: sb.list at sb.org (Stonewall Ballard) Date: Mon Aug 11 14:54:44 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: Message-ID: Bob, That looks like it might be useful, but the aeve dl link is broken. - Stoney On 8/11/03 2:29 PM, "Bob Ippolito" wrote: > Try aeve .. from http://undefined.org/python/ > > import aeve > textedit = aeve.talkto('/Applications/TextEdit.app') > print textedit.documents[0].text > > Currently, I think aeve just coerces text to a python string and > doesn't give you access to asking for paragraph/word/etc. I'll > probably change that in the future. > > -bob > > The only reason the "word" stuff works is because AppleScript handles > that stuff internally > From berkowit at silcom.com Mon Aug 11 12:58:40 2003 From: berkowit at silcom.com (Paul Berkowitz) Date: Mon Aug 11 15:02:12 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: Message-ID: On 8/11/03 11:13 AM, "Stonewall Ballard" wrote: > I spent many hours yesterday trying to figure out how to use the AppleScript > support that comes with MacPython 2.3, and wasn't able to make much > progress. Even a simple script like this: > > tell application "TextEdit" > get word 1 of document 1 > end tell No, this shouldn't really work in AppleScript either. There must be some sort of coercion going on. 'document' class in TextEdit has no 'word' element, nor does the AppleScript reserved 'word' know anything other than strings and Unicode text. (TextEdit, like most of the new Cocoa Apple apps, had its scripting implemented by people who knew next to nothing about AppleScript and did not study well-thought-out AppleScript dictionaries such as Tex-Edit Plus or BBEdit (sticking to text editors).) The correct script is: tell application "TextEdit" get word 1 of text of document 1 end tell 'text' is a property of 'document' and 'word' is an element of 'text'. Try this version using Python - in fact how exactly are you trying to do AppleScript in Python? Or maybe stick with well-behaved apps to start with... -- Paul Berkowitz From bob at redivi.com Mon Aug 11 16:15:20 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Aug 11 15:15:53 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: Message-ID: <26288C7E-CC30-11D7-A79E-000A95686CD8@redivi.com> Looks like I forgot to upload it last time I updated that html, it's there now. -bob On Monday, Aug 11, 2003, at 14:54 America/New_York, Stonewall Ballard wrote: > Bob, > > That looks like it might be useful, but the aeve dl link > is broken. > > - Stoney > > On 8/11/03 2:29 PM, "Bob Ippolito" wrote: > >> Try aeve .. from http://undefined.org/python/ >> >> import aeve >> textedit = aeve.talkto('/Applications/TextEdit.app') >> print textedit.documents[0].text >> >> Currently, I think aeve just coerces text to a python string and >> doesn't give you access to asking for paragraph/word/etc. I'll >> probably change that in the future. >> >> -bob >> >> The only reason the "word" stuff works is because AppleScript handles >> that stuff internally >> > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Mon Aug 11 16:20:47 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Aug 11 15:21:22 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: Message-ID: On Monday, Aug 11, 2003, at 14:58 America/New_York, Paul Berkowitz wrote: > No, this shouldn't really work in AppleScript either. There must be > some > sort of coercion going on. 'document' class in TextEdit has no 'word' > element, nor does the AppleScript reserved 'word' know anything other > than > strings and Unicode text. (TextEdit, like most of the new Cocoa Apple > apps, > had its scripting implemented by people who knew next to nothing about > AppleScript and did not study well-thought-out AppleScript > dictionaries such > as Tex-Edit Plus or BBEdit (sticking to text editors).) Hey, at least the TextEdit scripting dictionary does what it says and says what it does.. unlike some of the applications developed by AppleEvent savvy teams, like iTunes for example has an "artwork" class that isn't a property or element of anything in the dictionary, but in reality it *is* an element of a track. Also, the shared track stuff in the dictionary is totally bogus, there's two of them and neither do much of anything. -bob From sb.list at sb.org Mon Aug 11 16:25:37 2003 From: sb.list at sb.org (Stonewall Ballard) Date: Mon Aug 11 15:25:41 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: Message-ID: On 8/11/03 2:58 PM, "Paul Berkowitz" wrote: > On 8/11/03 11:13 AM, "Stonewall Ballard" wrote: > >> I spent many hours yesterday trying to figure out how to use the AppleScript >> support that comes with MacPython 2.3, and wasn't able to make much >> progress. Even a simple script like this: >> >> tell application "TextEdit" >> get word 1 of document 1 >> end tell > > No, this shouldn't really work in AppleScript either. There must be some > sort of coercion going on. 'document' class in TextEdit has no 'word' > element, nor does the AppleScript reserved 'word' know anything other than > strings and Unicode text. (TextEdit, like most of the new Cocoa Apple apps, > had its scripting implemented by people who knew next to nothing about > AppleScript and did not study well-thought-out AppleScript dictionaries such > as Tex-Edit Plus or BBEdit (sticking to text editors).) > > The correct script is: > > tell application "TextEdit" > get word 1 of text of document 1 > end tell > > > 'text' is a property of 'document' and 'word' is an element of 'text'. > > Try this version using Python - in fact how exactly are you trying to do > AppleScript in Python? Or maybe stick with well-behaved apps to start > with... I guess this is just broken. I tried: import TextEdit app = TextEdit.TextEdit() # why is this necessary? app._start() app.get( app.document(1).text.word(1) ) and it failed. with AttributeError: _Prop_text instance has no attribute 'word'. I can believe that this is just a messed up AS dictionary in TextEdit. The object model shown by ScriptDebugger indicates that something in the inheritance tree in TextEdit is broken. Thanks for your help. - Stoney From berkowit at silcom.com Mon Aug 11 13:30:57 2003 From: berkowit at silcom.com (Paul Berkowitz) Date: Mon Aug 11 15:33:12 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: Message-ID: On 8/11/03 12:20 PM, "Bob Ippolito" wrote: > Hey, at least the TextEdit scripting dictionary does what it says and > says what it does.. unlike some of the applications developed by > AppleEvent savvy teams, like iTunes for example has an "artwork" class > that isn't a property or element of anything in the dictionary, but in > reality it *is* an element of a track. Also, the shared track stuff in > the dictionary is totally bogus, there's two of them and neither do > much of anything. True enough. (Although TextEdit's 'save in' takes POSIX paths instead of colon AppleScript paths, but doesn't tell you so.) Mail.app is very hairy too - virtually unscriptable, whereas Address Book is not bad and getting better all the time. -- Paul Berkowitz From bob at redivi.com Mon Aug 11 17:04:31 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Aug 11 16:05:07 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: Message-ID: <05449575-CC37-11D7-A79E-000A95686CD8@redivi.com> On Monday, Aug 11, 2003, at 15:30 America/New_York, Paul Berkowitz wrote: > On 8/11/03 12:20 PM, "Bob Ippolito" wrote: > >> Hey, at least the TextEdit scripting dictionary does what it says and >> says what it does.. unlike some of the applications developed by >> AppleEvent savvy teams, like iTunes for example has an "artwork" class >> that isn't a property or element of anything in the dictionary, but in >> reality it *is* an element of a track. Also, the shared track stuff >> in >> the dictionary is totally bogus, there's two of them and neither do >> much of anything. > > True enough. (Although TextEdit's 'save in' takes POSIX paths instead > of > colon AppleScript paths, but doesn't tell you so.) Mail.app is very > hairy > too - virtually unscriptable, whereas Address Book is not bad and > getting > better all the time. I've scripted Mail.app just fine for simple tasks (counting messages in folders and such). There's even an example of this in aeve. -bob From Chris.Barker at noaa.gov Mon Aug 11 15:29:11 2003 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Aug 11 17:32:38 2003 Subject: [Pythonmac-SIG] Wanted: proofreader for www.python.orgMacinformation References: Message-ID: <3F380AA7.A3922931@noaa.gov> Kevin Altis wrote: > I wonder if the name MacPython just confuses the issue. Its just Python, > right? I have a couple of Mac OS X using friends that I have been pushing > towards Python and the name difference has confused them, at least a bit. I agree. And I still dont understand why the installer isn't available directly from python.org, just like the Windows one. > In the docs, the Mac stuff is put in its own section > > http://www.python.org/doc/current/mac/mac.html > > rather than > > http://www.python.org/doc/current/lib/lib.html That's because there is a LOT more stuff there. It's more like the Win32 modules, which are not documented in the standard library docs. > Since Unix, Windows, SunOS, and SGI IRIX aren't separated, it seems strange > to single out the Mac and force people to look in a different spot. there is very little OS specific stuff in the standard lib docs. By the way, those docs are pretty out of date. It would be great if we could put the collective effort in to update them. I coordinated some effort the last go around. I'd be glad to do it again...if some others step up to do various parts. -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 lmeyn at mail.arc.nasa.gov Mon Aug 11 15:47:59 2003 From: lmeyn at mail.arc.nasa.gov (Larry Meyn) Date: Mon Aug 11 17:48:38 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? Message-ID: <79846908-CC45-11D7-B314-000A95A06CF6@mail.arc.nasa.gov> On a related subject of colon separated AppleScript paths, how does one get the name of the root disk for generating absolute OS 9 style (colon separated) paths? The abspath function from the macpath module doesn't work under OS X , because it uses os.getcwd() which returns a "/" delimited path. Are some nice functions that someone has written that can convert between the two path styles under OS X? > > True enough. (Although TextEdit's 'save in' takes POSIX paths instead > of > colon AppleScript paths, but doesn't tell you so.) Mail.app is very > hairy > too - virtually unscriptable, whereas Address Book is not bad and > getting > better all the time. > > Larry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center Fax: (650) 604-0222 Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov E-Fax: (425) 944-5526 sent via e-mail -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1094 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20030811/3bb18d91/attachment.bin From bob at redivi.com Mon Aug 11 19:15:52 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Aug 11 18:16:29 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: <79846908-CC45-11D7-B314-000A95A06CF6@mail.arc.nasa.gov> Message-ID: <5ED1AD58-CC49-11D7-A79E-000A95686CD8@redivi.com> On Monday, Aug 11, 2003, at 17:47 America/New_York, Larry Meyn wrote: > On a related subject of colon separated AppleScript paths, how does > one get the name of the root disk for generating absolute OS 9 style > (colon separated) paths? The abspath function from the macpath module > doesn't work under OS X , because it uses os.getcwd() which returns a > "/" delimited path. Are some nice functions that someone has written > that can convert between the two path styles under OS X? import Carbon.File print Carbon.File.FSRef('/').FSGetCatalogInfo(0)[1] # looks like the full unicode name for the volume.. but maybe OS9 colon paths use the FSSpec paths? I only know about the OS9 APIs from very very very limited experience with C on the mac a few years ago (porting director xtras).. so I wouldn't take stuff I say as authoritative on the subject. -bob From mday at mac.com Mon Aug 11 17:10:40 2003 From: mday at mac.com (Mark Day) Date: Mon Aug 11 19:10:57 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: <5ED1AD58-CC49-11D7-A79E-000A95686CD8@redivi.com> References: <5ED1AD58-CC49-11D7-A79E-000A95686CD8@redivi.com> Message-ID: <06B46522-CC51-11D7-B275-00039354009A@mac.com> On Monday, August 11, 2003, at 3:15 PM, Bob Ippolito wrote: > On Monday, Aug 11, 2003, at 17:47 America/New_York, Larry Meyn wrote: > >> On a related subject of colon separated AppleScript paths, how does >> one get the name of the root disk for generating absolute OS 9 style >> (colon separated) paths? The abspath function from the macpath >> module doesn't work under OS X , because it uses os.getcwd() which >> returns a "/" delimited path. Are some nice functions that someone >> has written that can convert between the two path styles under OS X? > > import Carbon.File > print Carbon.File.FSRef('/').FSGetCatalogInfo(0)[1] > # looks like the full unicode name for the volume.. but maybe OS9 > colon paths use the FSSpec paths? Close. In general, you convert the POSIX-style path to an FSRef (in Carbon this would be FSPathMakeRef; in Python you can also use Carbon.File.FSRef()). Then, call FSGetCatalogInfo and get the FSSpec. Look inside the FSSpec for the name. That's the name used by traditional Mac OS 9 style paths. (Note that there is no such thing as a Unicode path as far as the Carbon File Manager is concerned). Here's what you'd use to get just the name: print Carbon.File.FSRef('/').FSGetCatalogInfo(0)[2].as_tuple()[2] The first [2] gets the FSSpec output from FSGetCatalogInfo. The second [2] gets the name out of the FSSpec. -Mark From bob at redivi.com Mon Aug 11 20:58:08 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Aug 11 19:58:45 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: <06B46522-CC51-11D7-B275-00039354009A@mac.com> Message-ID: On Monday, Aug 11, 2003, at 19:10 America/New_York, Mark Day wrote: > > On Monday, August 11, 2003, at 3:15 PM, Bob Ippolito wrote: > >> On Monday, Aug 11, 2003, at 17:47 America/New_York, Larry Meyn wrote: >> >>> On a related subject of colon separated AppleScript paths, how does >>> one get the name of the root disk for generating absolute OS 9 >>> style (colon separated) paths? The abspath function from the >>> macpath module doesn't work under OS X , because it uses os.getcwd() >>> which returns a "/" delimited path. Are some nice functions that >>> someone has written that can convert between the two path styles >>> under OS X? >> >> import Carbon.File >> print Carbon.File.FSRef('/').FSGetCatalogInfo(0)[1] >> # looks like the full unicode name for the volume.. but maybe OS9 >> colon paths use the FSSpec paths? > > Close. In general, you convert the POSIX-style path to an FSRef (in > Carbon this would be FSPathMakeRef; in Python you can also use > Carbon.File.FSRef()). Then, call FSGetCatalogInfo and get the FSSpec. > Look inside the FSSpec for the name. That's the name used by > traditional Mac OS 9 style paths. (Note that there is no such thing > as a Unicode path as far as the Carbon File Manager is concerned). > > Here's what you'd use to get just the name: > print Carbon.File.FSRef('/').FSGetCatalogInfo(0)[2].as_tuple()[2] > > The first [2] gets the FSSpec output from FSGetCatalogInfo. The > second [2] gets the name out of the FSSpec. I thought the FSRef was capable of long utf8 file names, and it was my guess that's what FSGetCatalogInfo(0)[1] was? -bob From mday at mac.com Mon Aug 11 19:00:06 2003 From: mday at mac.com (Mark Day) Date: Mon Aug 11 21:01:47 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: References: Message-ID: <4FF4551C-CC60-11D7-B275-00039354009A@mac.com> On Monday, August 11, 2003, at 4:58 PM, Bob Ippolito wrote: > I thought the FSRef was capable of long utf8 file names, and it was my > guess that's what FSGetCatalogInfo(0)[1] was? FSGetCatalogInfo returns the long Unicode name via the HFSUniStr255 type. That is an array of 255 UTF-16 characters with a preceding length. It looks like the Python glue is turning that into a Python unicode object. The BSD (POSIX-style) APIs use UTF-8 pathnames. -Mark From krjackson at lbl.gov Mon Aug 11 20:28:51 2003 From: krjackson at lbl.gov (Keith Jackson) Date: Mon Aug 11 22:29:29 2003 Subject: [Pythonmac-SIG] _environ Message-ID: Sorry if this has been asked before, but the only refs I found were back in 2002. I just built python 2.3 using the mac build instructions, so it is built as a framework. I then tried to build some of my extension modules and they would fail with an undefined symbol error for _environ. nm shows that this is defined in the python executable. Looking through the linker man page, I see that since two level namespaces are being used it wants to resolve all symbols at static link time. To fix this problem, I added in "-bundle_loader /usr/local/bin/python". I think this tells the linker to look in the python executable to find symbols. Does anybody know if this is the *right* thing to do? Can I safely add this into my python config/Makefile so all extension builds do this? thanks, --keith From brian_l at mac.com Mon Aug 11 23:56:47 2003 From: brian_l at mac.com (Brian Lenihan) Date: Tue Aug 12 01:56:58 2003 Subject: [Pythonmac-SIG] _environ In-Reply-To: References: Message-ID: On Monday, August 11, 2003, at 7:28 PM, Keith Jackson wrote: > Sorry if this has been asked before, but the only refs I found were > back in 2002. I just built python 2.3 using the mac build > instructions, so it is built as a framework. I then tried to build > some of my extension modules and they would fail with an undefined > symbol error for _environ. nm shows that this is defined in the python > executable. Looking through the linker man page, I see that since two > level namespaces are being used it wants to resolve all symbols at > static link time. > > To fix this problem, I added in "-bundle_loader > /usr/local/bin/python". I think this tells the linker to look in the > python executable to find symbols. Does anybody know if this is the > *right* thing to do? Can I safely add this into my python > config/Makefile so all extension builds do this? I've sometimes resorted to doing something like the fragment, below, to fix other people's extensions when I'm too lazy to go through the whole tool chain and fix it properly: #if defined (__APPLE__) #include #define environ (* _NSGetEnviron()) #endif Since you are using a framework build, you should be able to use -framework Python for your extensions. grep for bundle_loader in Python's configure file. It will give you a pretty good idea of what to do. From eric.nieuwland at xs4all.nl Tue Aug 12 09:14:12 2003 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Tue Aug 12 02:15:47 2003 Subject: [Pythonmac-SIG] How to build a dylib Message-ID: <665C4C97-CC8C-11D7-BEE3-000393894CEA@xs4all.nl> Hi all, I'm almost done porting a C library to MacOS X. Now I'm at the point where I need to change the make file/distutil setup so it will produce a .dylib that can be loaded by MacPython. Any hint on how to proceed? --eric From rdacker at pacbell.net Mon Aug 11 23:22:45 2003 From: rdacker at pacbell.net (robert ackerman) Date: Tue Aug 12 05:23:48 2003 Subject: [Pythonmac-SIG] build problem Message-ID: <012FDA2C-CC85-11D7-A583-003065428126@pacbell.net> in setup.py, i set custom include and lib to: include_dirs = ["/Library/PostgreSQL/include"] library_dirs = ["/Library/PostgreSQL/lib"] do i need other dirs? i get errors: % python setup.py build /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ distutils/dist.py:213: UserWarning: 'licence' distribution option is deprecated; use 'license' warnings.warn(msg) running build running build_py running build_ext building 'pyPgSQL.libpq.libpqmodule' extension gcc -Wl,-x -Wl,-F. -bundle -framework Python build/temp.darwin-6.6-Power_Macintosh-2.3/libpqmodule.o build/temp.darwin-6.6-Power_Macintosh-2.3/pgboolean.o build/temp.darwin-6.6-Power_Macintosh-2.3/pgint2object.o build/temp.darwin-6.6-Power_Macintosh-2.3/pgint8object.o build/temp.darwin-6.6-Power_Macintosh-2.3/pgversion.o build/temp.darwin-6.6-Power_Macintosh-2.3/pglargeobject.o build/temp.darwin-6.6-Power_Macintosh-2.3/pgnotify.o build/temp.darwin-6.6-Power_Macintosh-2.3/pgconnection.o build/temp.darwin-6.6-Power_Macintosh-2.3/pgresult.o build/temp.darwin-6.6-Power_Macintosh-2.3/pymemstrdup.o build/temp.darwin-6.6-Power_Macintosh-2.3/port/strtoll.o build/temp.darwin-6.6-Power_Macintosh-2.3/port/strtoull.o build/temp.darwin-6.6-Power_Macintosh-2.3/port/strtok.o -L/Library/PostgreSQL/lib -lpq -o build/lib.darwin-6.6-Power_Macintosh-2.3/pyPgSQL/libpq/libpqmodule.so ld: Undefined symbols: _ERR_get_error _ERR_reason_error_string _SSL_CTX_new _SSL_connect _SSL_free _SSL_library_init _SSL_load_error_strings _SSL_new _SSL_set_fd _SSLv23_method _SSL_read _SSL_write error: command 'gcc' failed with exit status 1 From mjb at uma.pt Tue Aug 12 14:48:47 2003 From: mjb at uma.pt (Michael J. Barber) Date: Tue Aug 12 08:43:53 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? Message-ID: <50B1B151-CCC3-11D7-A3E9-0050E4794D0F@uma.pt> > It would be really nice to have something that works like the MacPerl > "doScript" command, which takes a string, compiles it as an > AppleScript, and > runs it. It's much easier to figure out how to drive AppleScriptable > apps > that way. Perhaps it's slower than sending apple events directly, but > for my > purposes, that doesn't matter. > > The archives of this group suggest that such a "doscript" facility > used to > exist, but I don't see it anywhere. Can someone tell me where I can > find > this if it exists? > I have something that works along those lines. It works by piping AppleScript strings to osacompile and osascript. It's pretty slow, but since you say that doesn't matter, it may do the job. You can get it at . Definitely check out aeve as other have mentioned, though. As a side note for those who've tried OSATools before: I mentioned the package on the mailing list some months ago. Nothing at all has changed with it since then. -- Michael From bob at redivi.com Tue Aug 12 09:46:14 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Aug 12 08:47:01 2003 Subject: [Pythonmac-SIG] build problem In-Reply-To: <012FDA2C-CC85-11D7-A583-003065428126@pacbell.net> Message-ID: You need to link to libcrypto and libssl.. they're in /usr/lib, so you don't need to add the directories, just the libraries. Why don't you just use my binary distribution? Use this from Package Manager: http://undefined.org/python/pimp/darwin-6.6-Power_Macintosh.plist On Tuesday, Aug 12, 2003, at 01:22 America/New_York, robert ackerman wrote: > in setup.py, i set custom include and lib to: > include_dirs = ["/Library/PostgreSQL/include"] > library_dirs = ["/Library/PostgreSQL/lib"] > > do i need other dirs? > > i get errors: > % python setup.py build > /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ > distutils/dist.py:213: UserWarning: 'licence' distribution option is > deprecated; use 'license' > warnings.warn(msg) > running build > running build_py > running build_ext > building 'pyPgSQL.libpq.libpqmodule' extension > gcc -Wl,-x -Wl,-F. -bundle -framework Python > build/temp.darwin-6.6-Power_Macintosh-2.3/libpqmodule.o > build/temp.darwin-6.6-Power_Macintosh-2.3/pgboolean.o > build/temp.darwin-6.6-Power_Macintosh-2.3/pgint2object.o > build/temp.darwin-6.6-Power_Macintosh-2.3/pgint8object.o > build/temp.darwin-6.6-Power_Macintosh-2.3/pgversion.o > build/temp.darwin-6.6-Power_Macintosh-2.3/pglargeobject.o > build/temp.darwin-6.6-Power_Macintosh-2.3/pgnotify.o > build/temp.darwin-6.6-Power_Macintosh-2.3/pgconnection.o > build/temp.darwin-6.6-Power_Macintosh-2.3/pgresult.o > build/temp.darwin-6.6-Power_Macintosh-2.3/pymemstrdup.o > build/temp.darwin-6.6-Power_Macintosh-2.3/port/strtoll.o > build/temp.darwin-6.6-Power_Macintosh-2.3/port/strtoull.o > build/temp.darwin-6.6-Power_Macintosh-2.3/port/strtok.o > -L/Library/PostgreSQL/lib -lpq -o > build/lib.darwin-6.6-Power_Macintosh-2.3/pyPgSQL/libpq/libpqmodule.so > ld: Undefined symbols: > _ERR_get_error > _ERR_reason_error_string > _SSL_CTX_new > _SSL_connect > _SSL_free > _SSL_library_init > _SSL_load_error_strings > _SSL_new > _SSL_set_fd > _SSLv23_method > _SSL_read > _SSL_write > error: command 'gcc' failed with exit status 1 > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From adama at augustinefam.org Tue Aug 12 15:03:29 2003 From: adama at augustinefam.org (Adam Augustine) Date: Tue Aug 12 15:59:54 2003 Subject: [Pythonmac-SIG] Unclickable window when not running from shell... Message-ID: <3F394811.9060207@augustinefam.org> I am using MacPython 2.3 with 10.2.6. I am trying to get pyla (a HylaFAX client http://www.teamsw.it/pyla/) set up as a cups printer. When I run: /usr/local/bin/pythonw pyla.py -i Things run normally, meaning I get my 16-ton paperweight in the dock and I can interact with the tkinter GUI as I would expect to be able to. When I run a similar command from within a shell script, it works normally as well (provided I run the script rom a shell). If I run the script through the cups daemon, the window appears, but I don't get a 16-ton paperweight in the dock. I cannot click on the window to bring it to the front, and I don't seem to be getting any errors that I can find (well, that is not entirely true, I get one message that shows up even when things work properly when run from the shell, "GetProfileBySpaceFromShmem returned NULL for 'RRRR' : Calling Dispatch"). This seems to be similar to the difference between running /usr/local/bin/python and /usr/local/bin/pythonw, but I am sure I am running pythonw in both instances. Thinking it has something to do with the environment variables I dumped them for both executions. For the shell executed script I have: HOME=/var/root SHELL=/bin/tcsh USER=root PATH=/bin:/sbin:/usr/bin:/usr/sbin __CF_USER_TEXT_ENCODING=0x0:0:0 TERM=vt100 TERMCAP=??? TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=81 LOGNAME=root HOSTTYPE=macintosh VENDOR=apple OSTYPE=darwin MACHTYPE=powerpc SHLVL=1 PWD=/ GROUP=wheel HOST=Blue.local. When run from cups I get: CUPS_SERVERROOT=/private/etc/cups PWD=/ TZ=GMT RIP_MAX_CACHE=8m TMPDIR=/private/var/spool/cups/tmp CUPS_DATADIR=/usr/share/cups USER=root PPD=/private/etc/cups/ppd/test_hylafax_on_milo_ac20_com.ppd CUPS_FONTPATH=/usr/share/cups/fonts LANG=en_US CFProcessPath=/usr/libexec/cups/backend/hylafax SOFTWARE=CUPS/1.1 SHLVL=1 PRINTER=test_hylafax_on_milo_ac20_com CHARSET=iso-8859-1 DEVICE_URI=hylafax://milo.ac20.com/test-hylafax PATH=/usr/libexec/cups/filter:/bin:/usr/bin CONTENT_TYPE=application/pdf _=/usr/bin/env So my question is, Does MacPython (or does MacOS) care about enviroment variables as far as allowing interaction with a tkinter application? Do I need to set a variable or command line option or something to allow the user to interact with the window that will pop up? Thanks, Adam Augustine From chmod007 at mac.com Tue Aug 12 23:05:01 2003 From: chmod007 at mac.com (David Remahl) Date: Tue Aug 12 16:05:22 2003 Subject: [Pythonmac-SIG] Unclickable window when not running from shell... In-Reply-To: <3F394811.9060207@augustinefam.org> References: <3F394811.9060207@augustinefam.org> Message-ID: <419A8E5D-CD00-11D7-A460-000393DC5D80@mac.com> Could it be that the cups daemon runs as another user? The only users allowed to bring up applications are root and the currently logged in user. The cups or lp user that owns the cupsd process is not allowed to interact with the windowserver in that fashion. / Rgds, David On Tuesday, August 12, 2003, at 10:03:29 PM, Adam Augustine wrote: > I am using MacPython 2.3 with 10.2.6. I am trying to get pyla (a > HylaFAX client http://www.teamsw.it/pyla/) set up as a cups printer. > > When I run: > > /usr/local/bin/pythonw pyla.py -i > > Things run normally, meaning I get my 16-ton paperweight in the dock > and I can interact with the tkinter GUI as I would expect to be able > to. When I run a similar command from within a shell script, it works > normally as well (provided I run the script rom a shell). > > If I run the script through the cups daemon, the window appears, but I > don't get a 16-ton paperweight in the dock. I cannot click on the > window to bring it to the front, and I don't seem to be getting any > errors that I can find (well, that is not entirely true, I get one > message that shows up even when things work properly when run from the > shell, "GetProfileBySpaceFromShmem returned NULL for 'RRRR' : Calling > Dispatch"). > > This seems to be similar to the difference between running > /usr/local/bin/python and /usr/local/bin/pythonw, but I am sure I am > running pythonw in both instances. > > Thinking it has something to do with the environment variables I > dumped them for both executions. For the shell executed script I have: > > HOME=/var/root > SHELL=/bin/tcsh > USER=root > PATH=/bin:/sbin:/usr/bin:/usr/sbin > __CF_USER_TEXT_ENCODING=0x0:0:0 > > TERM=vt100 > TERMCAP=??? > TERM_PROGRAM=Apple_Terminal > TERM_PROGRAM_VERSION=81 > LOGNAME=root > HOSTTYPE=macintosh > VENDOR=apple > OSTYPE=darwin > MACHTYPE=powerpc > SHLVL=1 > PWD=/ > GROUP=wheel > HOST=Blue.local. > > When run from cups I get: > > CUPS_SERVERROOT=/private/etc/cups > PWD=/ > TZ=GMT > RIP_MAX_CACHE=8m > TMPDIR=/private/var/spool/cups/tmp > CUPS_DATADIR=/usr/share/cups > USER=root > PPD=/private/etc/cups/ppd/test_hylafax_on_milo_ac20_com.ppd > CUPS_FONTPATH=/usr/share/cups/fonts > LANG=en_US > CFProcessPath=/usr/libexec/cups/backend/hylafax > SOFTWARE=CUPS/1.1 > SHLVL=1 > PRINTER=test_hylafax_on_milo_ac20_com > CHARSET=iso-8859-1 > DEVICE_URI=hylafax://milo.ac20.com/test-hylafax > PATH=/usr/libexec/cups/filter:/bin:/usr/bin > CONTENT_TYPE=application/pdf > _=/usr/bin/env > > So my question is, Does MacPython (or does MacOS) care about > enviroment variables as far as allowing interaction with a tkinter > application? Do I need to set a variable or command line option or > something to allow the user to interact with the window that will pop > up? > > Thanks, > Adam Augustine From adama at augustinefam.org Tue Aug 12 15:37:52 2003 From: adama at augustinefam.org (Adam Augustine) Date: Tue Aug 12 16:34:20 2003 Subject: [Pythonmac-SIG] Unclickable window when not running from shell... In-Reply-To: <419A8E5D-CD00-11D7-A460-000393DC5D80@mac.com> References: <3F394811.9060207@augustinefam.org> <419A8E5D-CD00-11D7-A460-000393DC5D80@mac.com> Message-ID: <3F395020.1040901@augustinefam.org> I suspected that could possibly be the case, but as you can see from the environment dump, root is the USER in both cases... unless I am missing something... Adam Augustine David Remahl wrote: > Could it be that the cups daemon runs as another user? The only users > allowed to bring up applications are root and the currently logged in > user. The cups or lp user that owns the cupsd process is not allowed to > interact with the windowserver in that fashion. > > / Rgds, David > > On Tuesday, August 12, 2003, at 10:03:29 PM, Adam Augustine wrote: > >> I am using MacPython 2.3 with 10.2.6. I am trying to get pyla (a >> HylaFAX client http://www.teamsw.it/pyla/) set up as a cups printer. >> >> When I run: >> >> /usr/local/bin/pythonw pyla.py -i >> >> Things run normally, meaning I get my 16-ton paperweight in the dock >> and I can interact with the tkinter GUI as I would expect to be able >> to. When I run a similar command from within a shell script, it works >> normally as well (provided I run the script rom a shell). >> >> If I run the script through the cups daemon, the window appears, but I >> don't get a 16-ton paperweight in the dock. I cannot click on the >> window to bring it to the front, and I don't seem to be getting any >> errors that I can find (well, that is not entirely true, I get one >> message that shows up even when things work properly when run from the >> shell, "GetProfileBySpaceFromShmem returned NULL for 'RRRR' : Calling >> Dispatch"). >> >> This seems to be similar to the difference between running >> /usr/local/bin/python and /usr/local/bin/pythonw, but I am sure I am >> running pythonw in both instances. >> >> Thinking it has something to do with the environment variables I >> dumped them for both executions. For the shell executed script I have: >> >> HOME=/var/root >> SHELL=/bin/tcsh >> USER=root >> PATH=/bin:/sbin:/usr/bin:/usr/sbin >> __CF_USER_TEXT_ENCODING=0x0:0:0 >> >> TERM=vt100 >> TERMCAP=??? >> TERM_PROGRAM=Apple_Terminal >> TERM_PROGRAM_VERSION=81 >> LOGNAME=root >> HOSTTYPE=macintosh >> VENDOR=apple >> OSTYPE=darwin >> MACHTYPE=powerpc >> SHLVL=1 >> PWD=/ >> GROUP=wheel >> HOST=Blue.local. >> >> When run from cups I get: >> >> CUPS_SERVERROOT=/private/etc/cups >> PWD=/ >> TZ=GMT >> RIP_MAX_CACHE=8m >> TMPDIR=/private/var/spool/cups/tmp >> CUPS_DATADIR=/usr/share/cups >> USER=root >> PPD=/private/etc/cups/ppd/test_hylafax_on_milo_ac20_com.ppd >> CUPS_FONTPATH=/usr/share/cups/fonts >> LANG=en_US >> CFProcessPath=/usr/libexec/cups/backend/hylafax >> SOFTWARE=CUPS/1.1 >> SHLVL=1 >> PRINTER=test_hylafax_on_milo_ac20_com >> CHARSET=iso-8859-1 >> DEVICE_URI=hylafax://milo.ac20.com/test-hylafax >> PATH=/usr/libexec/cups/filter:/bin:/usr/bin >> CONTENT_TYPE=application/pdf >> _=/usr/bin/env >> >> So my question is, Does MacPython (or does MacOS) care about >> enviroment variables as far as allowing interaction with a tkinter >> application? Do I need to set a variable or command line option or >> something to allow the user to interact with the window that will pop up? >> >> Thanks, >> Adam Augustine > > From Chris.Barker at noaa.gov Tue Aug 12 17:50:10 2003 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Aug 12 19:50:44 2003 Subject: [Pythonmac-SIG] Numeric headers and Package Manager In-Reply-To: Message-ID: Hi all, I just installed 2.3 and then loaded most of the stuff in Package Manager, and it all went swimmingly! Very nice job, Jack, and everyone else involved. I use Numeric a lot, including a bunch of extensions I've written and need to compile. Unfortunately, the Numeric header files (most notably arrayobject.h) are not installed by Package Manager. My solution is to go download the source form sourceforge, and copy arrayobject.h to: /Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 Now I can compile my extensions with distutils in the usual way. Would it make sense to do this by default? Or maybe have a Numeric-dev package? by the way, ifyou do a standard setup.py install of Numeric, it doesn't put the header in either, but at least in that case, you have all the source right in front of you. -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 brian_l at mac.com Tue Aug 12 18:03:14 2003 From: brian_l at mac.com (Brian Lenihan) Date: Tue Aug 12 20:03:26 2003 Subject: [Pythonmac-SIG] Numeric headers and Package Manager In-Reply-To: References: Message-ID: <890FEB9C-CD21-11D7-BDD7-000A95841920@mac.com> On Tuesday, August 12, 2003, at 4:50 PM, Chris Barker wrote: > Would it make sense to do this by default? Or maybe have a Numeric-dev > package? by the way, ifyou do a standard setup.py install of Numeric, > it doesn't put the header in either, but at least in that case, you > have all the source right in front of you. The Numeric setup.py does install the headers, but in a Numeric subdirectory. ls /Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ Numeric arrayobject.h f2c.h ranlib.h ufuncobject.h From haertle at iqe.phys.ethz.ch Tue Aug 12 16:54:53 2003 From: haertle at iqe.phys.ethz.ch (Daniel Haertle) Date: Wed Aug 13 07:31:59 2003 Subject: [Pythonmac-SIG] Default package installation in MacPython 2.3 Message-ID: <8C829BF1-CCCC-11D7-879D-00039363A0CE@iqe.phys.ethz.ch> Hello I just released PyGallery 2.0beta, a thumbnail gallery generator with TkInter GUI, see http://pygallery.sourceforge.net/ It works on Mac OS X, but the installation procedure reads a bit lengthy: 1. install MacPython-OSX 2.3 or later 2. install TkTclAqua 3. run PacketManager and install PIL and TkInter with it 4. install PyGallery. This is done in the standard way, by opening the disc image and copy the application by dragging it to the desired position. 5. ensure that the Python scripts inside PyGallery.app are loaded with the new PythonLauncher2.3 Will TkInter and PIL ever be installed by default again (I liked this so much in the old MacPython distributions). Also bundling TkTclAqua with MacPython would be very nice, since as far as I see you cannot run a TkInter script without it. The second thing was that after installing MacPython 2.3 the .py scripts are still opened by default with Python 2.2 (without GUI). Is there a possibility to change that (for me as a packager or for you in a later release of MacPython)? My third and last question: by dragging the PyGallery.py script on BuildApplet, I could build PyGallery.app, but only one module (PyGallery.py) was in Contents/Resources/, and thus nothing worked. I copied all other scripts in Contents/Resources/ and all works nicely. Is this supposed to work so? Regards, and thanks for the great work for Python on the Mac Daniel ---------------------------------------------------------------------- Daniel Haertle haertle@iqe.phys.ethz.ch _________________ ___ http://www.nlo.ethz.ch / ____/_ __/ /_/ / Nonlinear Optics Laboratory, HPF E18 / __/_ / / / __ / Institute of Quantum Electronics, ETHZ /______/ /__/ /__/ /__/ 8093 Zuerich - Switzerland Tel +41 1 63 32338 Fax +41 1 63 31056 ---------------------------------------------------------------------- From Larry.A.Meyn at nasa.gov Tue Aug 12 23:57:32 2003 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Wed Aug 13 07:32:05 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: <4FF4551C-CC60-11D7-B275-00039354009A@mac.com> Message-ID: <07D40711-CD53-11D7-9C8F-000A95A06CF6@nasa.gov> My thanks to Mark and Bob for their help. I've thrown together the following crude function to generate OS 9 style path names under OS X for a scriptable application that needs them. def makeOS9abspath(path): """Returns an ":" delimited, OS 9 style absolute path. """ import Carbon.File, os.path abspath = os.path.abspath(path) rootdisk = Carbon.File.FSRef('/').FSGetCatalogInfo(0)[2].as_tuple()[2] abspath = rootdisk + ":".join(abspath.split('/')) #make ':' delimited if os.path.isdir(path): return abspath + ":" #add trailing ':' for directories else: return abspath Larry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center Fax: (650) 604-0222 Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov E-Fax: (425) 944-5526 sent via e-mail -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 965 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20030812/ab544001/attachment.bin From Jack.Jansen at cwi.nl Wed Aug 13 14:38:36 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Aug 13 07:36:07 2003 Subject: [Pythonmac-SIG] Numeric headers and Package Manager In-Reply-To: <890FEB9C-CD21-11D7-BDD7-000A95841920@mac.com> Message-ID: On Wednesday, Aug 13, 2003, at 02:03 Europe/Amsterdam, Brian Lenihan wrote: > > On Tuesday, August 12, 2003, at 4:50 PM, Chris Barker wrote: > >> Would it make sense to do this by default? Or maybe have a >> Numeric-dev package? by the way, ifyou do a standard setup.py install >> of Numeric, it doesn't put the header in either, but at least in that >> case, you have all the source right in front of you. > > The Numeric setup.py does install the headers, but in a Numeric > subdirectory. > > ls > /Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ > Numeric > arrayobject.h f2c.h ranlib.h ufuncobject.h And this is the same as what happens when you install Numeric from source (be it through Package Manager or manually). The only thing that does *not* work is installing Numeric per-user, then you don't get the header files (simply because there is nowhere to put them). I think there is a warning in the Numeric description in PM about 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 Chris.Barker at noaa.gov Wed Aug 13 10:52:23 2003 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Aug 13 12:56:20 2003 Subject: [Pythonmac-SIG] Numeric headers and Package Manager References: <890FEB9C-CD21-11D7-BDD7-000A95841920@mac.com> Message-ID: <3F3A6CC7.1B007BD2@noaa.gov> Brian Lenihan wrote: > The Numeric setup.py does install the headers, but in a Numeric > subdirectory. where they are not found by disutils, which seems almost, but not quite, what is needed. -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 Wed Aug 13 11:05:36 2003 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Aug 13 13:09:27 2003 Subject: [Pythonmac-SIG] Numeric headers and Package Manager References: Message-ID: <3F3A6FE0.BAF25C54@noaa.gov> Jack Jansen wrote: > > The Numeric setup.py does install the headers, but in a Numeric > > subdirectory. > > > > ls > > /Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ > > Numeric > > arrayobject.h f2c.h ranlib.h ufuncobject.h > > And this is the same as what happens when you install Numeric from > source (be it through Package Manager or > manually). Ok, this seems reasonable. Installing from source makes sense if you are developing extensions. Now, does anyone know how to write a setup.py that will indicate that there are headers in ...../include/python2.3/Numeric/ Note that I can't hard-code the path, because Linux puts the whole pile somewhere else, and I want it to work with other versions of python. I guess what I would like it for distutils to automatically look in sub-directories of the main include directory, but it doesn't seem to do this by default. -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 Aug 13 14:15:48 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Aug 13 13:16:24 2003 Subject: [Pythonmac-SIG] Numeric headers and Package Manager In-Reply-To: <3F3A6FE0.BAF25C54@noaa.gov> Message-ID: On Wednesday, Aug 13, 2003, at 13:05 America/New_York, Chris Barker wrote: > Jack Jansen wrote: > >>> The Numeric setup.py does install the headers, but in a Numeric >>> subdirectory. >>> >>> ls >>> /Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >>> Numeric >>> arrayobject.h f2c.h ranlib.h ufuncobject.h >> >> And this is the same as what happens when you install Numeric from >> source (be it through Package Manager or >> manually). > > Ok, this seems reasonable. Installing from source makes sense if you > are > developing extensions. > > Now, does anyone know how to write a setup.py that will indicate that > there are headers in ...../include/python2.3/Numeric/ > > Note that I can't hard-code the path, because Linux puts the whole pile > somewhere else, and I want it to work with other versions of python. I > guess what I would like it for distutils to automatically look in > sub-directories of the main include directory, but it doesn't seem to > do > this by default. Well, since it's always supposed to be in a directory called Numeric, you're supposed to use: #include and not #include Distutils doesn't have to do anything that it normally wouldn't at this point. -bob From gandreas at delver.com Wed Aug 13 14:33:53 2003 From: gandreas at delver.com (Glenn Andreas) Date: Wed Aug 13 14:35:17 2003 Subject: [Pythonmac-SIG] Unclickable window when not running from shell... In-Reply-To: <3F395020.1040901@augustinefam.org> References: <3F394811.9060207@augustinefam.org> <419A8E5D-CD00-11D7-A460-000393DC5D80@mac.com> <3F395020.1040901@augustinefam.org> Message-ID: At 2:37 PM -0600 8/12/03, Adam Augustine wrote: >I suspected that could possibly be the case, but as you can see from >the environment dump, root is the USER in both cases... unless I am >missing something... > >Adam Augustine Things in the printing system (except for the Print Center, PDE's and stand alone utilities) do not have access to the window server to bring up any sort of UI (neither Tioga based nor CUPS based - one of the most common problems for Tioga printer driver writers was "my PM stopped working" when people would link in Carbon.Framework, since that needed to talk to the window server when it was loaded). While this may seem draconian, there are actually good reasons (well, more like "good side effects") - especially since shared printers "magically work" now, if the PM/CUPS filter could bring up a UI, they would bring it up on the wrong machine (i.e., the server, and not the client that initiated the print job). The ability to talk to the window server isn't actually controlled by the USER, but (IIRC) it is a Mach port that is inherited from the parent process. So something that is run as a decendant of "login", (such as something run from a shell script run by the user logged into the console) can talk to the window server, but cups filters are launched by the print server which isn't. Depending on what you are trying to accomplish, you might want to check out the Tioga mailing list on lists.apple.com (I guess it is just called "printing" these days, but it is geared towards people writing printer drivers & CUPS filters, not so much application side of printing). Glenn Andreas gandreas@delver.com Author of Macintosh games: Theldrow 2.3, Blobbo 1.0.2, Cythera 1.0.2 Be good, and you will be lonesome From managan at llnl.gov Wed Aug 13 12:39:48 2003 From: managan at llnl.gov (Rob Managan) Date: Wed Aug 13 14:40:25 2003 Subject: [Pythonmac-SIG] Numeric headers and Package Manager In-Reply-To: <3F3A6FE0.BAF25C54@noaa.gov> References: <3F3A6FE0.BAF25C54@noaa.gov> Message-ID: >Jack Jansen wrote: > >> > The Numeric setup.py does install the headers, but in a Numeric >> > subdirectory. >> > >> > ls >> > /Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> > Numeric >> > arrayobject.h f2c.h ranlib.h ufuncobject.h >> >> And this is the same as what happens when you install Numeric from >> source (be it through Package Manager or >> manually). > >Ok, this seems reasonable. Installing from source makes sense if you are >developing extensions. > >Now, does anyone know how to write a setup.py that will indicate that >there are headers in ...../include/python2.3/Numeric/ > >Note that I can't hard-code the path, because Linux puts the whole pile >somewhere else, and I want it to work with other versions of python. I >guess what I would like it for distutils to automatically look in >sub-directories of the main include directory, but it doesn't seem to do >this by default. > I do remember that with some version of Numeric that the includes changed from #include to #include I suspect that this may solve your problem. I was annoyed by this change as well. -- *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From Chris.Barker at noaa.gov Wed Aug 13 12:53:54 2003 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Aug 13 14:57:50 2003 Subject: [Pythonmac-SIG] Numeric headers and Package Manager References: Message-ID: <3F3A8942.B3FEC5B1@noaa.gov> Bob Ippolito wrote: > Well, since it's always supposed to be in a directory called Numeric, > you're supposed to use: > #include > and not > #include well DUH!..thanks for re-booting my brain for me. -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 eric.nieuwland at xs4all.nl Wed Aug 13 22:47:27 2003 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Wed Aug 13 15:47:36 2003 Subject: [Pythonmac-SIG] How to build a dylib In-Reply-To: Message-ID: Brian Lenihan wrote: > You haven't specified anything about your environment, which makes it > kind of difficult to give you a definitive answer. If you are using a > framework build of Python 2.3 and Apple's dev tools from Dec 2002 or > later, you may not need to do anything special. Stupid me: framework MacPython 2.3 + Dec 2002 dev tools ( gcc updated ) Jack Jansen wrote: > Actually, you need a Mach-O bundle with a ".so" extension. > > But: if you're using distutils this should all happen automatically, > do I understand from your message that somehow it doesn't work for > you? What happens? I have a replacement for a library in /usr/lib installed in /usr/local/lib and can't figure out how the modify the library search path so it will take the replacement. Strangely enough the search for include file seems to be OK. Ronald Oussoren wrote: > If this is a python extension module it will magically work ;-) > > If the library isn't too large and used from only 1 extension module > I'd create a static library and link with that, GCC seems to create > position independent code for static libraries as well. This makes it > easier to distribute the python extension module that uses your > library, as you no longer have to worry about the .dylib. We do this > with libffi in PyObjC and nobody has complained about this not > > working. Yes, that was what I was planning to do. So, no more .dylib, just a .so. --eric From adama at augustinefam.org Wed Aug 13 18:43:53 2003 From: adama at augustinefam.org (Adam Augustine) Date: Wed Aug 13 19:40:17 2003 Subject: [Pythonmac-SIG] Unclickable window when not running from shell... In-Reply-To: References: <3F394811.9060207@augustinefam.org> <419A8E5D-CD00-11D7-A460-000393DC5D80@mac.com> <3F395020.1040901@augustinefam.org> Message-ID: <3F3ACD39.9090406@augustinefam.org> Glenn Andreas wrote: > At 2:37 PM -0600 8/12/03, Adam Augustine wrote: > >> I suspected that could possibly be the case, but as you can see from >> the environment dump, root is the USER in both cases... unless I am >> missing something... >> >> Adam Augustine > > > Things in the printing system (except for the Print Center, PDE's and > stand alone utilities) do not have access to the window server to bring > up any sort of UI (neither Tioga based nor CUPS based Hmm. The fact that the window with the UI actually displays properly, but is simply unclickable, would seem to indicate that the process does have access to the window server (at some level at least). > The ability to talk to the window server isn't actually controlled by > the USER, but (IIRC) it is a Mach port that is inherited from the parent > process. So something that is run as a decendant of "login", (such as > something run from a shell script run by the user logged into the > console) can talk to the window server, but cups filters are launched by > the print server which isn't. > > Depending on what you are trying to accomplish, you might want to check > out the Tioga mailing list on lists.apple.com (I guess it is just called > "printing" these days, but it is geared towards people writing printer > drivers & CUPS filters, not so much application side of printing). > Well, I did a search on "window server" and read the postings that came back. It seems that they all indicate that /any/ communication with the window server should fail resulting in a "WindowServer[184]: _CGXGetDisplayShmem: Unauthorized user" error. I get no such error and the UI does show up. The python script is just waiting for input. If it shouldn't be able to speak with the window server, then it shouldn't get that far and there is a bug somewhere that looks like my script has priviledges it shouldn't. If it should be able to get that far, then there is something wrong that it isn't able to be made active for input. Any more ideas? Adam From dpwildboar at yahoo.com Thu Aug 14 11:26:00 2003 From: dpwildboar at yahoo.com (dave wilbur) Date: Thu Aug 14 13:26:09 2003 Subject: [Pythonmac-SIG] ANN: Tcl/Tk Aqua 8.4.4 Message-ID: <20030814172600.83579.qmail@web20006.mail.yahoo.com> wanted to express a word of caution about this installer for Tcl/Tk Aqua 8.4.4... not sure if it was coincidance... but, right after i used it i lost the ability to authinticate as administrator on my machine. i was in the midst of installing the various things for python and after i installed Tcl/Tk Aqua 8.4.4 any installer after that and/or sudo would behave in odd ways and not install. in one case it would come back saying you must be logged in as Administrator and in others just crashing out. anyone have this happen? also i tried after ... reinstalling macos ( =( ) just doing the shell install and got the following error for tk 8.4.4 with gcc 3.3 CompileC /Downloads/tk8.4.4/macosx/../../build/tk/Development.build/Wish.build/TkLibrary.build/Objects-normal/ppc/tkMacOSXMenu.o /usr/bin/gcc2 -c -F/Downloads/tk8.4.4/macosx/../../build/tk -F/Downloads/tk8.4.4/macosx/../../build/tcl -I/Downloads/tk8.4.4/macosx/../../build/tk/include -I/Downloads/tk8.4.4/macosx/../../build/tcl/Tcl.framework/Headers -I/Downloads/tk8.4.4/macosx/../../build/tcl/Tcl.framework/PrivateHeaders -I../bitmaps -I../generic -I../xlib -arch ppc -fno-common -fpascal-strings -O0 -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -pipe -g -precomp-trustfile /Downloads/tk8.4.4/macosx/../../build/tk/Development.build/Wish.build/TkLibrary.build/TrustedPrecomps.txt -Wp,-header-mapfile,/Downloads/tk8.4.4/macosx/../../build/tk/Development.build/Wish.build/TkLibrary.build/Tk.hmap `source /Downloads/tk8.4.4/macosx/../../build/tcl/Tcl.framework/tclConfig.sh; echo ${TCL_EXTRA_CFLAGS} ${TCL_DEFS} | sed -e 's|\\\"|"|g' | sed -e 's| -DTCL_WIDE_INT_TYPE=long. long||'` -U_REENTRANT "-DMAC_OSX_TK" "-DTCL_WIDE_INT_TYPE=long long" tkMacOSXMenu.c -o /Downloads/tk8.4.4/macosx/../../build/tk/Development.build/Wish.build/TkLibrary.build/Objects-normal/ppc/tkMacOSXMenu.o tkMacOSXMenu.c: In function `TkpConfigureMenuEntry': tkMacOSXMenu.c:954: warning: unused variable `helpMenuHdl' tkMacOSXMenu.c:953: warning: unused variable `macMenuHdl' tkMacOSXMenu.c:952: warning: unused variable `index' tkMacOSXMenu.c: In function `ReconfigureIndividualMenu': tkMacOSXMenu.c:1086: warning: unused variable `destWrote' tkMacOSXMenu.c:1047: warning: unused variable `itemText' tkMacOSXMenu.c: In function `DrawMenuBarWhenIdle': tkMacOSXMenu.c:1760: warning: unused variable `helpMenuHdl' tkMacOSXMenu.c: In function `TkMacOSXDispatchMenuEvent': tkMacOSXMenu.c:2148: parse error before `int' tkMacOSXMenu.c:2150: `newIndex' undeclared (first use in this function) tkMacOSXMenu.c:2150: (Each undeclared identifier is reported only once tkMacOSXMenu.c:2150: for each function it appears in.) tkMacOSXMenu.c: In function `HandleMenuFindItemsMsg': tkMacOSXMenu.c:4464: warning: unused variable `updateRgn' tkMacOSXMenu.c:4463: warning: unused variable `menuFont' tkMacOSXMenu.c:4297: warning: unused variable `fmPtr' tkMacOSXMenu.c:4296: warning: unused variable `entryMetrics' tkMacOSXMenu.c:4296: warning: unused variable `fontMetrics' tkMacOSXMenu.c:4295: warning: unused variable `tkfont' ...failed CompileC /Downloads/tk8.4.4/macosx/../../build/tk/Development.build/Wish.build/TkLibrary.build/Objects-normal/ppc/tkMacOSXMenu.o ... ** BUILD FAILED ** make: *** [develop] Error 1 solving either is fine with me since i just want it for tk... dave __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From adama at augustinefam.org Thu Aug 14 14:51:03 2003 From: adama at augustinefam.org (Adam Augustine) Date: Thu Aug 14 15:46:55 2003 Subject: [Pythonmac-SIG] Unclickable window when not running from shell... In-Reply-To: <3F3ACD39.9090406@augustinefam.org> References: <3F394811.9060207@augustinefam.org> <419A8E5D-CD00-11D7-A460-000393DC5D80@mac.com> <3F395020.1040901@augustinefam.org> <3F3ACD39.9090406@augustinefam.org> Message-ID: <3F3BE827.1040400@augustinefam.org> Adam Augustine wrote: > > > Glenn Andreas wrote: > >> At 2:37 PM -0600 8/12/03, Adam Augustine wrote: >> > Hmm. The fact that the window with the UI actually displays properly, > but is simply unclickable, would seem to indicate that the process does > have access to the window server (at some level at least). > > Well, I did a search on "window server" and read the postings that came > back. It seems that they all indicate that /any/ communication with the > window server should fail resulting in a "WindowServer[184]: > _CGXGetDisplayShmem: Unauthorized user" error. I get no such error and > the UI does show up. The python script is just waiting for input. > > If it shouldn't be able to speak with the window server, then it > shouldn't get that far and there is a bug somewhere that looks like my > script has priviledges it shouldn't. > > If it should be able to get that far, then there is something wrong that > it isn't able to be made active for input. > > Any more ideas? > Having re-read some of the postings on this list, I am thinking that this behavior of my app may actually be related to the python vs. pythonw issue since the symptoms are exactly the same, except for the error message (which I now suspect may be getting eaten somewhere). In a previous posting (2003-08-07 7:30am), Ronald Oussoren says: "Applications that use the WindowServer must be in a .app bundle, or must use an undocumented API. pythonw is a shell script that starts a pyton interpreter that is inside a .app bundle but is otherwise a normal interpreter." I am wondering if I need to make my app into a .app bundle, or do something (beyond calling /usr/local/bin/pythonw) to convince WindowServer that I am calling from a .app bundle. How would that be done? I have tried BuildApplet, and now am calling from my cups/backend script via: "/path/pyla-app.app/Contents/MacOS/Python /path/pyla-app.app/Contents/MacOS/pyla-app -i" But it still will not come to the foreground when clicked. Ah, after doing a bit of 2>&1 I found the errors (which were getting eaten). They are the same SetFrontProcess failed,-606 errors that people get when running UI apps without pythonw, so this is almost certainly what Ronald was referring to. How do I convince MacOS I am launching from an .app bundle? Adam From owen at astro.washington.edu Thu Aug 14 14:05:40 2003 From: owen at astro.washington.edu (Russell E. Owen) Date: Thu Aug 14 16:19:16 2003 Subject: [Pythonmac-SIG] Re: ANN: Tcl/Tk Aqua 8.4.4 References: <20030814172600.83579.qmail@web20006.mail.yahoo.com> Message-ID: I'm afraid I can't help you troubleshoot. Both the binary installer and the source installer for Tcl/Tk 8.4.4 worked fine for me. Perhaps the installer is fine and triggered some existing fault in your system (have you run Disk Warrior?) or else it's a configuration-dependent problem. For the source install, I assume you followed the instructions in tk8.4.4/macosx/README? -- Russell From dpwildboar at yahoo.com Fri Aug 15 10:25:24 2003 From: dpwildboar at yahoo.com (dave wilbur) Date: Fri Aug 15 12:25:28 2003 Subject: [Pythonmac-SIG] Re: ANN: Tcl/Tk Aqua 8.4.4 In-Reply-To: Message-ID: <20030815162524.80274.qmail@web20002.mail.yahoo.com> since after it refused to authenticate, i felt i wasn't going to be able to back out to a point where i could have a normal system i wiped the disk and started over so disk warrior wouldn't help now. it was a rather clean system, and is now again. i have two boot disks on the Ti and the external has the updates from adc (ie: Dec 2002 gcc Updater - This GCC updater includes the new GCC 3.3 compiler in addition to other updates that will allow development of G5 optimized code with the December 2002 Mac OS X Developer Tools. it also has the update to java 1.4.1 tools) and the internal doesn't (only has the developer tools that are from the 10.2 distribution ie: dec 02) the external is the one that had issues. what i can tell you is that, the internal compiles fine. ie: the last thing you see is ** BUILD SUCCEEDED ** this has the compiler version: Halley:~] wildboar% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs Thread model: posix Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420 (prerelease) the external disk has: [Hazardous Waste:~] wildboar% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1435) and results in the following when it tries to complie tkMacOSXMenu.c: CompileC /Downloads/tk8.4.4/macosx/../../build/tk/Development.build/Wish.build/TkLibrary.build/Objects-normal/ppc/tkMacOSXMenu.o /usr/bin/gcc2 -c -F/Downloads/tk8.4.4/macosx/../../build/tk -F/Downloads/tk8.4.4/macosx/../../build/tcl -I/Downloads/tk8.4.4/macosx/../../build/tk/include -I/Downloads/tk8.4.4/macosx/../../build/tcl/Tcl.framework/Headers -I/Downloads/tk8.4.4/macosx/../../build/tcl/Tcl.framework/PrivateHeaders -I../bitmaps -I../generic -I../xlib -arch ppc -fno-common -fpascal-strings -O0 -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -pipe -g -precomp-trustfile /Downloads/tk8.4.4/macosx/../../build/tk/Development.build/Wish.build/TkLibrary.build/TrustedPrecomps.txt -Wp,-header-mapfile,/Downloads/tk8.4.4/macosx/../../build/tk/Development.build/Wish.build/TkLibrary.build/Tk.hmap `source /Downloads/tk8.4.4/macosx/../../build/tcl/Tcl.framework/tclConfig.sh; echo ${TCL_EXTRA_CFLAGS} ${TCL_DEFS} | sed -e 's|\\\"|"|g' | sed -e 's| -DTCL_WIDE_INT_TYPE=long. long||'` -U_REENTRANT "-DMAC_OSX_TK" "-DTCL_WIDE_INT_TYPE=long long" tkMacOSXMenu.c -o /Downloads/tk8.4.4/macosx/../../build/tk/Development.build/Wish.build/TkLibrary.build/Objects-normal/ppc/tkMacOSXMenu.o tkMacOSXMenu.c: In function `TkpConfigureMenuEntry': tkMacOSXMenu.c:954: warning: unused variable `helpMenuHdl' tkMacOSXMenu.c:953: warning: unused variable `macMenuHdl' tkMacOSXMenu.c:952: warning: unused variable `index' tkMacOSXMenu.c: In function `ReconfigureIndividualMenu': tkMacOSXMenu.c:1086: warning: unused variable `destWrote' tkMacOSXMenu.c:1047: warning: unused variable `itemText' tkMacOSXMenu.c: In function `DrawMenuBarWhenIdle': tkMacOSXMenu.c:1760: warning: unused variable `helpMenuHdl' tkMacOSXMenu.c: In function `TkMacOSXDispatchMenuEvent': tkMacOSXMenu.c:2148: parse error before `int' tkMacOSXMenu.c:2150: `newIndex' undeclared (first use in this function) tkMacOSXMenu.c:2150: (Each undeclared identifier is reported only once tkMacOSXMenu.c:2150: for each function it appears in.) tkMacOSXMenu.c: In function `HandleMenuFindItemsMsg': tkMacOSXMenu.c:4464: warning: unused variable `updateRgn' tkMacOSXMenu.c:4463: warning: unused variable `menuFont' tkMacOSXMenu.c:4297: warning: unused variable `fmPtr' tkMacOSXMenu.c:4296: warning: unused variable `entryMetrics' tkMacOSXMenu.c:4296: warning: unused variable `fontMetrics' tkMacOSXMenu.c:4295: warning: unused variable `tkfont' ...failed CompileC /Downloads/tk8.4.4/macosx/../../build/tk/Development.build/Wish.build/TkLibrary.build/Objects-normal/ppc/tkMacOSXMenu.o ... ** BUILD FAILED ** make: *** [develop] Error 1 so i am more inclined to think that this is something to do with the update to gcc that apple has on adc vs anything else. the thing is that i have also found that the updated gcc sometimes compiles things that the dec 02 tools can not... so i am not enthused about not having it installed some where... and yes, i did read the read me... several times wouldn't want to waste all your time with something silly like me not doing that. i can get tcl and tk to compile with the dec 02 tools so i know i am doing the right thing. does anyone think it would be bad to install the gcc 3.1 built tcl/tk on the system that has the gcc 3.3 update? btw, russell i wanted to thank you for all the nice helpful stuff you have on http://www.astro.washington.edu/owen/ it was a great help the first time i went to place python on macos 10. i hope that you continue maintaining that. thanks for the help, dave --- "Russell E. Owen" wrote: > I'm afraid I can't help you troubleshoot. Both the > binary installer and > the source installer for Tcl/Tk 8.4.4 worked fine > for me. Perhaps the > installer is fine and triggered some existing fault > in your system (have > you run Disk Warrior?) or else it's a > configuration-dependent problem. > > For the source install, I assume you followed the > instructions in > tk8.4.4/macosx/README? > > -- Russell > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From brian_l at mac.com Fri Aug 15 13:57:13 2003 From: brian_l at mac.com (Brian Lenihan) Date: Fri Aug 15 15:58:04 2003 Subject: [Pythonmac-SIG] Re: ANN: Tcl/Tk Aqua 8.4.4 In-Reply-To: <20030815162524.80274.qmail@web20002.mail.yahoo.com> References: <20030815162524.80274.qmail@web20002.mail.yahoo.com> Message-ID: On Friday, August 15, 2003, at 9:25 AM, dave wilbur wrote: > > [Hazardous Waste:~] wildboar% gcc -v > Reading specs from > /usr/libexec/gcc/darwin/ppc/3.3/specs > Thread model: posix > gcc version 3.3 20030304 (Apple Computer, Inc. build > 1435) > > /usr/bin/gcc2 -c You aren't using 3.3. You appear to have a borked install of the dev tools. Try running sudo gcc_select 3.3 and check /usr/bin/gcc* to make sure gcc -> gcc-3.3 From Jack.Jansen at cwi.nl Sat Aug 16 00:58:37 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 15 17:58:50 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: <07D40711-CD53-11D7-9C8F-000A95A06CF6@nasa.gov> Message-ID: <9FBAD938-CF6B-11D7-A73A-000A27B19B96@cwi.nl> On woensdag, aug 13, 2003, at 07:57 Europe/Amsterdam, Larry Meyn wrote: > My thanks to Mark and Bob for their help. I've thrown together the > following crude function to generate OS 9 style path names under OS X > for a scriptable application that needs them. > > > def makeOS9abspath(path): > """Returns an ":" delimited, OS 9 style absolute path. > """ > import Carbon.File, os.path > > abspath = os.path.abspath(path) > rootdisk = Carbon.File.FSRef('/').FSGetCatalogInfo(0)[2].as_tuple()[2] > abspath = rootdisk + ":".join(abspath.split('/')) #make ':' delimited > > if os.path.isdir(path): > return abspath + ":" #add trailing ':' for directories > else: > return abspath This will work for 90% of the paths, but fail on all sorts of exceptional ones. Some of the problems: - It doesn't handle ':' in unix filenames (should be converted to /) - It only handles 7-bit ascii (unix filenames use utf8 encoding, OS9 paths use MacRoman or another encoding) - It will fail for filenames longer than 32 (or 31) characters What you should do is create an FSSpec for the file, and recursively get the pathname components from it. Here it is: def makeOS9abspath(path): """Returns an ":" delimited, OS 9 style absolute path. """ import Carbon.File, os.path rv = [] fss = Carbon.File.FSSpec(path) while 1: vrefnum, dirid, filename = fss.as_tuple() rv.insert(0, filename) if dirid == 1: break fss = Carbon.File.FSSpec((vrefnum, dirid, "")) if len(rv) == 1: rv.append('') return ':'.join(rv) This one still has a problem in that it will not work if path doesn't yet exist, on OSX FSSpec(path) goes via FSRef's, and these are only defined on existing files. The bad news is that I don't think there is a 100% failsafe way to create an OS9 path for a nonexisting item on OSX (given a UTF8 unix path). -- - 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 Larry.A.Meyn at nasa.gov Fri Aug 15 16:26:56 2003 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Fri Aug 15 18:27:33 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: <9FBAD938-CF6B-11D7-A73A-000A27B19B96@cwi.nl> Message-ID: <941B8194-CF6F-11D7-9C35-000A95A06CF6@nasa.gov> Jack, Thanks! This should should work great for my application. Although I'm wanting paths to new files, I'm only placing them in existing directories and your function can give me robust OS 9 paths for those. Larry On Friday, August 15, 2003, at 02:58 PM, Jack Jansen wrote: > > This will work for 90% of the paths, but fail on all sorts of > exceptional > ones. Some of the problems: > - It doesn't handle ':' in unix filenames (should be converted to /) > - It only handles 7-bit ascii (unix filenames use utf8 encoding, OS9 > paths > use MacRoman or another encoding) > - It will fail for filenames longer than 32 (or 31) characters > > > What you should do is create an FSSpec for the file, and recursively > get > the pathname components from it. Here it is: > > def makeOS9abspath(path): > """Returns an ":" delimited, OS 9 style absolute path. > """ > import Carbon.File, os.path > > rv = [] > fss = Carbon.File.FSSpec(path) > while 1: > vrefnum, dirid, filename = fss.as_tuple() > rv.insert(0, filename) > if dirid == 1: break > fss = Carbon.File.FSSpec((vrefnum, dirid, "")) > if len(rv) == 1: > rv.append('') > return ':'.join(rv) > > This one still has a problem in that it will not work if path doesn't > yet > exist, on OSX FSSpec(path) goes via FSRef's, and these are only > defined on > existing files. The bad news is that I don't think there is a 100% > failsafe > way to create an OS9 path for a nonexisting item on OSX (given a UTF8 > unix > path). > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > Larry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center Fax: (650) 604-0222 Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov E-Fax: (425) 944-5526 sent via e-mail -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2147 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20030815/b0752440/attachment.bin From krjackson at lbl.gov Fri Aug 15 16:27:10 2003 From: krjackson at lbl.gov (Keith Jackson) Date: Fri Aug 15 18:27:48 2003 Subject: [Pythonmac-SIG] _environ In-Reply-To: Message-ID: <9C4E4BD2-CF6F-11D7-B5D8-000A9577489A@lbl.gov> All right, I'm totally confused. :) Any help would be *greatly* appreciated. I can build other extension modules, and everything is fine. It is just my modules that exhibit the problem with _environ. Clearly I'm doing something wrong, but I don't have a clue what it is. I've attached working output from a build of m2crypto, and broken output from my build. If anyone has any ideas about what I'm doing wrong, please let me know. thanks, --keith working m2crypto extension build: gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/Users/kjackson/src/m2crypto-0.11/SWIG -I/sw/include -I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c SWIG/_m2crypto_wrap.c -o build/temp.darwin-6.6-Power_Macintosh-2.3/SWIG/_m2crypto_wrap.o -DTHREADING gcc -Wl,-F. -bundle -framework Python build/temp.darwin-6.6-Power_Macintosh-2.3/SWIG/_m2crypto_wrap.o -L/sw/lib -lssl -lcrypto -o build/lib.darwin-6.6-Power_Macintosh-2.3/M2Crypto/__m2crypto.so broken extension build: gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/sw/globus/globus/include/gcc32dbgpthr -I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c src/util_wrap.c -o build/temp.darwin-6.6-Power_Macintosh-2.3/src/util_wrap.o -g -fno-common -I/sw/include -D_REENTRANT -Wall cc1: warning: ` -fno-common -I/sw/include -D_REENTRANT -Wall ': unknown or unsupported -g option gcc -Wl,-F. -bundle -framework Python build/temp.darwin-6.6-Power_Macintosh-2.3/src/util_wrap.o -L/sw/globus/globus/lib -L/sw/globus/globus/lib -L/sw/lib -L/sw/lib -lglobus_common_gcc32dbgpthr -lpthread -o build/lib.darwin-6.6-Power_Macintosh-2.3/pyGlobus/utilc.so ld: Undefined symbols: _environ error: command 'gcc' failed with exit status 1 On Monday, August 11, 2003, at 10:56 PM, Brian Lenihan wrote: > > On Monday, August 11, 2003, at 7:28 PM, Keith Jackson wrote: > >> Sorry if this has been asked before, but the only refs I found were >> back in 2002. I just built python 2.3 using the mac build >> instructions, so it is built as a framework. I then tried to build >> some of my extension modules and they would fail with an undefined >> symbol error for _environ. nm shows that this is defined in the >> python executable. Looking through the linker man page, I see that >> since two level namespaces are being used it wants to resolve all >> symbols at static link time. >> >> To fix this problem, I added in "-bundle_loader >> /usr/local/bin/python". I think this tells the linker to look in the >> python executable to find symbols. Does anybody know if this is the >> *right* thing to do? Can I safely add this into my python >> config/Makefile so all extension builds do this? > > I've sometimes resorted to doing something like the fragment, below, > to fix other people's extensions when I'm too lazy to go through the > whole tool chain and fix it properly: > > #if defined (__APPLE__) > #include > #define environ (* _NSGetEnviron()) > #endif > > Since you are using a framework build, you should be able to use > -framework Python for your extensions. grep for bundle_loader in > Python's configure file. It will give you a pretty good idea of what > to do. > From kevino at tulane.edu Fri Aug 15 23:19:26 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Sat Aug 16 01:22:36 2003 Subject: [Pythonmac-SIG] wxPackageManager prototype Message-ID: <344B8AB2-CFA9-11D7-9D7D-000393CB1C86@tulane.edu> Hi all, Sorry for being quiet for a while. Had two exams and some work deadlines that kept me incapacitated. ;-) Since I know that geeks like to play with things more than look at them, I decided to post a prototype of wxPackageManager instead of posting another boring screenshot. Without further ado: http://www.theolliviers.com/wxPackMan.tar.gz Just unpack and double-click on wxPackageManager.app! Note that it requires MacPython OS X 2.3 and the latest wxPython (binary installer available at http://www.wxpython.org) to run. I've used this prototype to implement some new ideas, and I'd like to hear your thoughts. I've added a (non-functional) category selector and search box, and also implemented a "properties" box that shows various properties of the software that was selected. It also implements the pretty, lickable status buttons to show if a package is installed, in need of update, or not installed (or broken dependency). Note that I consider a broken dependency to be equated to a non-installed program; while to PackMan implementers they are different, the end user should not have to even think about dependency issues - they just want to click "Install" and have everything work. ;-) If PackMan tries and it can't be installed, I think only then PackMan should prompt the user and let them know there's an issue they need to resolve and give them guidance. Oh, and I've gotten this to work on Windows (of course, there are no packages yet...!) by copying plistlib.py and pimp.py from /lib/plat-mac into the Python/lib directory. (Oh, and I needed to comment out the code for finding the Windows install path... need to fix that. =) I imagine a similar process will work for *nix. It doesn't look *quite* as good as the OS X version, but that is to be expected. ;-) Making progress...! Oh, and one question - how hard would it be to show the PKG-INFO file when selecting the package? I'm thinking of putting that info in instead of the description textbox. Of course, if I could pull that info direct from PyPI... =) Thanks, Kevin From Jack.Jansen at cwi.nl Sat Aug 16 13:52:37 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Aug 16 06:52:48 2003 Subject: [Pythonmac-SIG] AppleEvents in MacPython 2.3? In-Reply-To: <941B8194-CF6F-11D7-9C35-000A95A06CF6@nasa.gov> Message-ID: On zaterdag, aug 16, 2003, at 00:26 Europe/Amsterdam, Larry Meyn wrote: > Jack, > > Thanks! This should should work great for my application. Although I'm > wanting paths to new files, I'm only placing them in existing > directories and your function can give me robust OS 9 paths for those. What I would do if the path can be new is something like if os.path.exists(path): return makeOS9abspath(path) head, tail = os.path.split(path) head = makeOS9abspath(head) if len(tail) > 31 or ':' in tail: raise IOError, "Come up with good error message here" return macpath.join(head, unicode(tail, 'utf8').encode('mac-roman')) -- - 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 dpwildboar at yahoo.com Sun Aug 17 11:36:35 2003 From: dpwildboar at yahoo.com (dave wilbur) Date: Sun Aug 17 13:36:40 2003 Subject: [Pythonmac-SIG] Re: ANN: Tcl/Tk Aqua 8.4.4 In-Reply-To: Message-ID: <20030817173635.4584.qmail@web20008.mail.yahoo.com> hum... well for everything else it is using the proper gcc... here is all the gcc info you mentioned: [HazardousWaste:~] wildboar% ls -al `which gcc` lrwxr-xr-x 1 root wheel 7 Aug 15 01:50 /usr/bin/gcc -> gcc-3.3 [HazardousWaste:~] wildboar% ls -al /usr/bin/gcc* lrwxr-xr-x 1 root wheel 7 Aug 15 01:50 /usr/bin/gcc -> gcc-3.3 -r-xr-xr-x 1 root wheel 131280 Aug 15 01:47 /usr/bin/gcc-3.3 -r-xr-xr-x 1 root wheel 117932 Aug 15 01:46 /usr/bin/gcc2 -r-xr-xr-x 1 root wheel 135348 Aug 15 01:46 /usr/bin/gcc3 [HazardousWaste:~] wildboar% sudo gcc_select 3.3 Password: You are already using gcc version 3.3 as the default compiler. [HazardousWaste:~] wildboar% so... this implies that when you do the following: set ver="8.4.4" make -C tcl${ver}/macosx make -C tk${ver}/macosx that when it is CompileC it is using gcc2 for some reason vs just using gcc. anyone know where CompileC defines how it invokes gcc? dave --- Brian Lenihan wrote: > > On Friday, August 15, 2003, at 9:25 AM, dave wilbur > wrote: > > > > [Hazardous Waste:~] wildboar% gcc -v > > Reading specs from > > /usr/libexec/gcc/darwin/ppc/3.3/specs > > Thread model: posix > > gcc version 3.3 20030304 (Apple Computer, Inc. > build > > 1435) > > > > /usr/bin/gcc2 -c > > You aren't using 3.3. You appear to have a borked > install of the dev > tools. Try running sudo gcc_select 3.3 and check > /usr/bin/gcc* to make > sure gcc -> gcc-3.3 > > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From andrae.muys at braintree.com.au Mon Aug 18 18:54:30 2003 From: andrae.muys at braintree.com.au (Andrae Muys) Date: Mon Aug 18 03:55:13 2003 Subject: [Pythonmac-SIG] Problem with PackageManager Message-ID: <3F408636.7080003@braintree.com.au> I've been banging my head against this for a couple of weeks now and haven't had any success. I have installed MacPython-2.3, on an iBook running MacOSX 10.2.6. However everytime I try to run the PackageManager I get the same error: "Unspecified error while parsing database: http://www.python.org/packman/version-0.3/darwin-6.6-Power_Macintosh.plist Usually, this means the database is not correctly formatted. See MacPython Package Manager help page." Which isn't all that useful. I have tried reinstalling MacPython numerous times. I have tried downloading the .plist file manually and pointing PackageManager at the file using OpenURL. I have checked the .plist file in vim to ensure it looks sane. All attempts result in the same error. I am hoping someone can suggest what the problem might be. Andrae Muys -- Andrae Muys Engineer Braintree Communications "Now, allowing captured continuations to be inspected and altered at runtime (including binding mutation, complete rebinding of scopes, and call tree mutation)... *that* is really evil. And, I should point out, quite useful." - Dan Sugalski From Jack.Jansen at cwi.nl Mon Aug 18 12:05:13 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Aug 18 05:02:29 2003 Subject: [Pythonmac-SIG] Problem with PackageManager In-Reply-To: <3F408636.7080003@braintree.com.au> Message-ID: <140007D4-D15B-11D7-907E-0030655234CE@cwi.nl> On Monday, August 18, 2003, at 09:54 AM, Andrae Muys wrote: > > I've been banging my head against this for a couple of weeks now and > haven't had any success. I have installed MacPython-2.3, on an iBook > running MacOSX 10.2.6. However everytime I try to run the > PackageManager I get the same error: > > "Unspecified error while parsing database: > http://www.python.org/packman/version-0.3/darwin-6.6- > Power_Macintosh.plist > Usually, this means the database is not correctly formatted. > > See MacPython Package Manager help page." Do you have a firewall between you and the internet? If so, did you read the section on firewalls in the Package Manager help page? For this release PM doesn't pick up the firewall information you have set in System Preferences, it needs a different method to specify the firewall. If this isn't the problem please report back, and we'll try to come up with other things to 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 dieterg at pandora.be Mon Aug 18 12:15:23 2003 From: dieterg at pandora.be (Dieter Gyselinck) Date: Mon Aug 18 05:16:09 2003 Subject: [Pythonmac-SIG] PYTHONPATH question Message-ID: <7F7FF507-D15C-11D7-BC6C-0003938B87E2@pandora.be> Hi, I'm setting up a new development webserver on a Mac OS X 10.2.6 and I have installed the Python 2.3 version with Jack Jansen's installer, which works great by the way. I have a few modules that I need to import in a lot of cgi-scripts that are spread over a number of directories. I want to keep the modules together in one directory for easy management. I have set the $PYTHONPATH environment variable and I can import my modules when I start python but when I run a cgi script, I cannot import the modules. Is there a solution for this? Thanx, Dieter. From Martina at Oefelein.de Mon Aug 18 19:38:26 2003 From: Martina at Oefelein.de (Martina Oefelein) Date: Mon Aug 18 12:38:19 2003 Subject: [Pythonmac-SIG] PYTHONPATH question In-Reply-To: <7F7FF507-D15C-11D7-BC6C-0003938B87E2@pandora.be> Message-ID: <64265D7A-D19A-11D7-B5AA-000A957DBE94@Oefelein.de> Hi Dieter, > I have set the $PYTHONPATH environment variable and I can import my > modules when I start python but when I run a cgi script, I cannot > import the modules. Is there a solution for this? exactly how did you set $PYTHONPATH? Are you sure it's defined also in the server's context? .MacOSX/Environment.plist is only defined in your user context, for example. ciao Martina From dieterg at pandora.be Mon Aug 18 19:47:29 2003 From: dieterg at pandora.be (Dieter Gyselinck) Date: Mon Aug 18 12:48:16 2003 Subject: [Pythonmac-SIG] PYTHONPATH question In-Reply-To: <64265D7A-D19A-11D7-B5AA-000A957DBE94@Oefelein.de> Message-ID: Hi Martina, thanx a lot for looking into this problem. I don't think the server 'knows' about the path, and that is my problem. I can't find good info about how to do that. Do you know (or have resources on) how to fix this one? Viel danke, Dieter. On Monday, August 18, 2003, at 06:38 PM, Martina Oefelein wrote: > Hi Dieter, > >> I have set the $PYTHONPATH environment variable and I can import my >> modules when I start python but when I run a cgi script, I cannot >> import the modules. Is there a solution for this? > > exactly how did you set $PYTHONPATH? Are you sure it's defined also in > the server's context? > .MacOSX/Environment.plist is only defined in your user context, for > example. > > ciao > Martina > > > From Martina at Oefelein.de Mon Aug 18 22:51:48 2003 From: Martina at Oefelein.de (Martina Oefelein) Date: Mon Aug 18 15:51:46 2003 Subject: [Pythonmac-SIG] PYTHONPATH question In-Reply-To: Message-ID: <679BFF42-D1B5-11D7-B5AA-000A957DBE94@Oefelein.de> Hi Dieter, > thanx a lot for looking into this problem. I don't think the > server 'knows' about the path, and that is my problem. I can't find > good info about how to do that. Do you know (or have resources on) > how to fix this one? This depends on the web server. Assuming that you are using Apache, you can use the SetEnv directive. See: http://localhost/manual/mod/mod_env.html#setenv or http://httpd.apache.org/docs/mod/mod_env.html#setenv ciao Martina From dieterg at pandora.be Tue Aug 19 11:15:24 2003 From: dieterg at pandora.be (Dieter Gyselinck) Date: Tue Aug 19 04:15:33 2003 Subject: [Pythonmac-SIG] PYTHONPATH question In-Reply-To: <679BFF42-D1B5-11D7-B5AA-000A957DBE94@Oefelein.de> Message-ID: <48A71AE9-D21D-11D7-B781-0003936BBD2C@pandora.be> Hey Martina, thanx for showing me the way;-) I've managed to get it working. I had to: - Uncomment line: LoadModule env_module libexec/httpd/mod_env.so - Uncomment line: AddModule mod_env.c - Add line in http.conf : PassEnv PYTHONPATH Thanx, Dieter. Martina Oefelein heeft op maandag, 18 aug 2003 om 21:51 (Europe/Brussels) het volgende geschreven: > Hi Dieter, > >> thanx a lot for looking into this problem. I don't think the >> server 'knows' about the path, and that is my problem. I can't find >> good info about how to do that. Do you know (or have resources on) >> how to fix this one? > > This depends on the web server. Assuming that you are using Apache, > you can use the SetEnv directive. See: > http://localhost/manual/mod/mod_env.html#setenv > or > http://httpd.apache.org/docs/mod/mod_env.html#setenv > > ciao > Martina > > > From barry at python.org Tue Aug 19 18:05:30 2003 From: barry at python.org (barry@python.org) Date: Tue Aug 19 11:05:38 2003 Subject: [Pythonmac-SIG] Re: Your application Message-ID: Please see the attached file for details. From barry at python.org Tue Aug 19 19:33:25 2003 From: barry at python.org (barry@python.org) Date: Tue Aug 19 12:33:28 2003 Subject: [Pythonmac-SIG] Re: Thank you! Message-ID: See the attached file for details From barry at python.org Tue Aug 19 21:31:36 2003 From: barry at python.org (barry@python.org) Date: Tue Aug 19 14:31:44 2003 Subject: [Pythonmac-SIG] Thank you! Message-ID: See the attached file for details From nogard at cats.ucsc.edu Tue Aug 19 16:32:58 2003 From: nogard at cats.ucsc.edu (Travis Seymour) Date: Wed Aug 20 04:27:48 2003 Subject: [Pythonmac-SIG] Help me make the PC to MAC transition! Message-ID: <5.2.0.9.2.20030819152024.01e63af0@cats-po-1.ucsc.edu> Hi, I'm a PC user since the IBM XT. Every since OSX arrived, I've been wanting to switch over to the mac. I have a mac with OSX 10.2 installed and would like to setup a FAQ server as a way to begin migrating my research lab over to mac. I'd like to use FAQ WIZARD which is part of Python. (Is it also part of MacPython?) I'm in need of a step-by-step guide to setting up the webserver (I understand it's very easy on the mac) and then getting FAQ WIZARD installed. I understand a good bit about OSs and computers in general, and a moderate amount of unix and shells. However, since I know relatively little about OSX (have not yet fired up a terminal window), you would have to be pretty explicit. If this works, I'll have taken the first step..otherwise, I'll have to do this in Linux and my Mac OS dreams will be shattered. In return, I'd promise to host this step-by-step guide on my server as a service to MacPython. Can someone help? Is there already such a guide somewhere? Thanks Travis Seymour http://www.travisseymour.com ----------------------------------------------------------------------------------------- Travis L. Seymour, Ph.D Psychology Department 374 Social Sciences II University of California phone: 831-459-3384 Santa Cruz, CA 95064 email: nogard@cats.ucsc.edu ----------------------------------------------------------------------------------------- From vtagle at newsguy.com Thu Aug 21 13:33:25 2003 From: vtagle at newsguy.com (Vince Tagle) Date: Fri Aug 22 08:34:52 2003 Subject: [Pythonmac-SIG] Getting the location of an applet under OSX Message-ID: Hello, I have a python script that I saved as an applet (running OSX here) and I'm trying to get the path to the applet but nothing I've tried has worked so far. Is what I'm trying to do even possible? os.getcwd() always returns the path to the root and sys.argv[0] returns the path to the .py module buried within the package of the applet. Vince no .sig today From joaoleao at gmx.net Wed Aug 20 20:25:28 2003 From: joaoleao at gmx.net (=?ISO-8859-1?Q?Jo=E3o_Le=E3o?=) Date: Fri Aug 22 09:58:48 2003 Subject: [Pythonmac-SIG] Distribution Message-ID: Hi everyone, could anyone give some hints about distribution of Python programs on OS X? More precisely: what are the possibilities of distributing a program to someone who doesn't have Python? (Standalone or Applet + dependencies) I tried tu use the "freeze" module but something goes wrong in the "make" part of the process and i couldn't find any additional documentation. I also remember that someone talked recently in this sig about "bundlebuilder" but again i don't know how to use this. Thanks, joao From Larry.A.Meyn at nasa.gov Wed Aug 20 07:45:09 2003 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Fri Aug 22 12:10:43 2003 Subject: [Pythonmac-SIG] Help me make the PC to MAC transition! In-Reply-To: <5.2.0.9.2.20030819152024.01e63af0@cats-po-1.ucsc.edu> Message-ID: <83DA7995-D314-11D7-8EBC-000A95A06CF6@nasa.gov> Travis, I haven't done this myself, but O'Reilly has several articles on web serving with OS X at http://www.macdevcenter.com/pub/a/mac/collections/webserving.html Good luck! On Tuesday, August 19, 2003, at 03:32 PM, Travis Seymour wrote: > Hi, I'm a PC user since the IBM XT. > Every since OSX arrived, I've been wanting to switch over to the mac. > I have a mac with OSX 10.2 installed and would like to setup a FAQ > server as a way to begin migrating my research lab over to mac. > I'd like to use FAQ WIZARD which is part of Python. (Is it also part > of MacPython?) > > I'm in need of a step-by-step guide to setting up the webserver (I > understand it's very easy on the mac) and then getting FAQ WIZARD > installed. > I understand a good bit about OSs and computers in general, and a > moderate amount of unix and shells. > However, since I know relatively little about OSX (have not yet fired > up a terminal window), you would have to be pretty explicit. > > If this works, I'll have taken the first step..otherwise, I'll have to > do this in Linux and my Mac OS dreams will be shattered. > In return, I'd promise to host this step-by-step guide on my server as > a service to MacPython. > > Can someone help? Is there already such a guide somewhere? > Thanks > Travis Seymour > http://www.travisseymour.com > > > > ----------------------------------------------------------------------- > ------------------ > Travis L. Seymour, Ph.D > Psychology Department > 374 Social Sciences II > University of California phone: 831-459-3384 > Santa Cruz, CA 95064 email: nogard@cats.ucsc.edu > ----------------------------------------------------------------------- > ------------------ > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > Larry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center Fax: (650) 604-0222 Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov E-Fax: (425) 944-5526 sent via e-mail -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2211 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20030820/f05c9b91/attachment.bin From Jack.Jansen at cwi.nl Tue Aug 19 23:29:39 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 22 15:53:39 2003 Subject: [Pythonmac-SIG] Virus time again Message-ID: As you've probably all seen it's virus time again today, with a new sobig version. And a couple came through because the From: (which the virus forges) happened to be one of our esteemed list members. We'll just have to live with this, I don't want to close off the list more than we already do. And remember that the good news is that the other 85 viruses that were sent to the SIG in the last eight hours have only bothered me. Along with the 1500 copies (I kid you not! 1500 viruses in the last 8 hours!) I got from other sources. From etienne at cs.vu.nl Wed Aug 20 14:32:09 2003 From: etienne at cs.vu.nl (Etienne Posthumus) Date: Fri Aug 22 15:59:07 2003 Subject: [Pythonmac-SIG] Help me make the PC to MAC transition! In-Reply-To: <5.2.0.9.2.20030819152024.01e63af0@cats-po-1.ucsc.edu> Message-ID: On woensdag, aug 20, 2003, at 00:32 Europe/Amsterdam, Travis Seymour wrote: > I'm in need of a step-by-step guide to setting up the webserver (I > understand it's very easy on the mac) and then getting FAQ WIZARD > installed. > I understand a good bit about OSs and computers in general, and a > moderate amount of unix and shells. > However, since I know relatively little about OSX (have not yet fired > up a terminal window), you would have to be pretty explicit. Hi Travis What you are actually asking is: "How do I set up and run CGI on OS X?" This is only vaguely related to Python on the Mac. OS X comes with Apache 1.3 installed 'out-of-the-box'. So you need simply need to switch on the 'Personal Web Sharing' button in the System Preferences panel, and you have a webserver running on your machine. You then follow the same procedure for configuring a directory to use for CGI as with any other Apache install (even if it is on Linux or some other OS). The configuration file is at: /private/etc/httpd/httpd.conf (which is symlinked in the root too). A bit of Googling on setting up CGI is your best bet. Etienne Posthumus From oussoren at cistron.nl Fri Aug 22 17:18:34 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Fri Aug 22 20:17:32 2003 Subject: [Pythonmac-SIG] Distribution In-Reply-To: References: Message-ID: <83EEF794-D4AB-11D7-88ED-0003931CFE24@cistron.nl> On Wednesday, 20 August 2003, at 20:25, Jo?o Le?o wrote: > Hi everyone, > > could anyone give some hints about distribution of Python programs on > OS X? > More precisely: what are the possibilities of distributing a program > to someone who doesn't have Python? (Standalone or Applet + > dependencies) > > I tried tu use the "freeze" module but something goes wrong in the > "make" part of the process and i couldn't find any additional > documentation. > I also remember that someone talked recently in this sig about > "bundlebuilder" but again i don't know how to use this. bundlebuilder has online documentation (e.g. help("bundlebuilder") from the interpreter). Here's an example of how you can use bundlebuilder: ######### from bundlebuilder import buildapp OTHERSRC=[ 'WSTApplicationDelegateClass.py', 'WSTConnectionWindowControllerClass.py'] buildapp( name = "Web Services Tool", mainprogram = "Main.py", resources = ["English.lproj", "Preferences.png", "Reload.png", "WST.png"] + OTHERSRC, nibname = "MainMenu", iconfile = "WST.icns", ) ########## This script is used to build an applet for one of the PyObjC examples. This script is usually named 'buildapp.py', and you can use 'python buildapp.py build' to build the applet. The '--standalone' flag can be used to build a standalone application. Ronald From brownr at ucalgary.ca Fri Aug 22 13:16:01 2003 From: brownr at ucalgary.ca (brownr@ucalgary.ca) Date: Fri Aug 22 21:09:18 2003 Subject: [Pythonmac-SIG] Building extensions on OS X w/ Python 2.3 Message-ID: <200308221816.h7MIG3L02605@mhost1.ucalgary.ca> I've got some extension modules written in C/C++ that build and work fine with Python 2.2 but give an _environ unresolved symbol when building for 2.3. I'm using OS X 10.2 and the problem is the same with GCC 2.95, 3.1 and 3.3. Using distutils. I tried the Python.org example extension and it had the same problem. Anybody know how to fix this? Thanks, Robb From rafferty29 at mchsi.com Sat Aug 23 18:39:02 2003 From: rafferty29 at mchsi.com (Rob Bedford) Date: Sun Aug 24 06:54:30 2003 Subject: [Pythonmac-SIG] Getting the location of an applet under OSX In-Reply-To: Message-ID: <97F7C6C2-D5BA-11D7-92A6-00039374C97A@mchsi.com> So if you have the path to the .py which is in a known place just delete the proper amout of directories. In other words os.chdir(os.path.dirname(sys.argv[0])) which will put you at the .py then os.chdir("..") for each level you need to go up. Rob On Thursday, August 21, 2003, at 02:33 PM, Vince Tagle wrote: > Hello, > > I have a python script that I saved as an applet (running OSX here) > and I'm > trying to get the path to the applet but nothing I've tried has worked > so > far. Is what I'm trying to do even possible? os.getcwd() always > returns the > path to the root and sys.argv[0] returns the path to the .py module > buried > within the package of the applet. > > > Vince > no .sig today > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Benjamin.Schollnick at usa.xerox.com Wed Aug 20 13:31:49 2003 From: Benjamin.Schollnick at usa.xerox.com (Schollnick, Benjamin) Date: Sun Aug 24 12:05:09 2003 Subject: [Pythonmac-SIG] Help me make the PC to MAC transition! Message-ID: <51B62EFFBC83D6118ADA00096BB030A102CC2E0D@usamcms7.mc.usa.xerox.com> Travis, Welcome to the Mac OS X world... I actually migrated from OS/2 to the Macintosh in 1997, and had to wait several years for MOSX to come out... >g< The FAQ wizard is really quite dated, and I recall reading that the Python crew are moving away from it... So I wouldn't suggest moving to the FAQ Wizard... Starting up Apache under MOSX is quite simple... Open the System Preferences panel. Choosing Sharing. Turn on Personal Web Sharing. That will start up the Web server... How to register Python with Apache, I am not sure... I haven't done any web projects on Python w/Apache... - Ben > -----Original Message----- > From: Travis Seymour [mailto:nogard@cats.ucsc.edu] > Sent: Tuesday, August 19, 2003 6:33 PM > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] Help me make the PC to MAC transition! > > > Hi, I'm a PC user since the IBM XT. > Every since OSX arrived, I've been wanting to switch over to the mac. > I have a mac with OSX 10.2 installed and would like to setup > a FAQ server > as a way to begin migrating my research lab over to mac. > I'd like to use FAQ WIZARD which is part of Python. (Is it > also part of > MacPython?) > > I'm in need of a step-by-step guide to setting up the webserver (I > understand it's very easy on the mac) and then getting FAQ > WIZARD installed. > I understand a good bit about OSs and computers in general, > and a moderate > amount of unix and shells. > However, since I know relatively little about OSX (have not > yet fired up a > terminal window), you would have to be pretty explicit. > > If this works, I'll have taken the first step..otherwise, > I'll have to do > this in Linux and my Mac OS dreams will be shattered. > In return, I'd promise to host this step-by-step guide on my > server as a > service to MacPython. > > Can someone help? Is there already such a guide somewhere? > Thanks > Travis Seymour > http://www.travisseymour.com > > > > -------------------------------------------------------------- > --------------------------- > Travis L. Seymour, Ph.D > Psychology Department > 374 Social Sciences II > University of California phone: 831-459-3384 > Santa Cruz, CA 95064 email: nogard@cats.ucsc.edu > -------------------------------------------------------------- > --------------------------- > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From andre at alpdesignworks.com Sat Aug 23 18:54:14 2003 From: andre at alpdesignworks.com (Andre Posumentov) Date: Sun Aug 24 12:24:11 2003 Subject: [Pythonmac-SIG] Re: Help me make the PC to MAC transition! Message-ID: <6D495FB8-D58A-11D7-92E0-000393912B32@alpdesignworks.com> Hi Travis, There's a good four-part article on setting up Apache for Mac OS X on the O'Reilly Mac Devcenter. Look for "Apache Web Serving with Jaguar", here: http://www.macdevcenter.com/pub/a/mac/collections/webserving.html Regards, -- Andre >> Hi, I'm a PC user since the IBM XT. >> Every since OSX arrived, I've been wanting to switch over to the mac. >> I have a mac with OSX 10.2 installed and would like to setup a FAQ >> server as a way to begin migrating my research lab over to mac. >> I'd like to use FAQ WIZARD which is part of Python. (Is it also part >> of MacPython?) >> >> I'm in need of a step-by-step guide to setting up the webserver (I >> understand it's very easy on the mac) and then getting FAQ WIZARD >> installed. >> I understand a good bit about OSs and computers in general, and a >> moderate amount of unix and shells. >> However, since I know relatively little about OSX (have not yet fired >> up a terminal window), you would have to be pretty explicit. >> >> If this works, I'll have taken the first step..otherwise, I'll have >> to do this in Linux and my Mac OS dreams will be shattered. >> In return, I'd promise to host this step-by-step guide on my server >> as a service to MacPython. >> >> Can someone help? Is there already such a guide somewhere? >> Thanks >> Travis Seymour >> http://www.travisseymour.com >> >> From robin at reportlab.com Sat Aug 23 10:53:32 2003 From: robin at reportlab.com (Robin Becker) Date: Sun Aug 24 18:49:11 2003 Subject: [Pythonmac-SIG] weirdness with Mac OS 9 extension Message-ID: <2GfMmjAMuyR$EwqK@jessikat.fsnet.co.uk> Hi I'm throwing this out in the hope that someone else has seen the ssame kind of problem. With Just van Rossum and Jack Jansen's help we've created a compact python+reportlab distro for a client, but so far all our attempts at getting the extensions built in house (rather than by Just) have failed. We have Code Warrior patched to 8.3 and have been using the mcp files contributed by Just (with file paths changed to match our system). Even so in at least one module _renderPM we get a strange error at run time in the following code f = fopen (filename, "rb"); /*f is non NULL supposedly a good descriptor*/ if (f == NULL) return NULL; pfb_size = 0; pfb_size_max = 32768; pfb = gt1_new (char, pfb_size_max); while (1) { bytes_read = fread (pfb + pfb_size, 1, pfb_size_max - pfb_size, f); /*the first fread returns zero*/ if (bytes_read == 0) break; pfb_size += bytes_read; gt1_double (pfb, char, pfb_size_max); } /*errno here is 9 (ie bad file descriptor)*/ fclose (f); ie we get a non null descriptor, but the first fread seems to treat it as bad. We have GUSI2 & Python/include on the paths list and supposedly the right things on the linker path, but this code just doesn't work. If I try the above in a console linked in the standard way things work as expected as does the binary created by Just. Anyone with any good ideas? -- Robin Becker From Jack.Jansen at cwi.nl Mon Aug 25 11:49:05 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Aug 25 04:49:12 2003 Subject: [Pythonmac-SIG] weirdness with Mac OS 9 extension In-Reply-To: <2GfMmjAMuyR$EwqK@jessikat.fsnet.co.uk> Message-ID: Robin, the only thing I can think of is that somehow the GUSI stdio library and the MSL stdio library are getting mixed up. First thing to do is to check again that the libraries are in the right order. If you look at the link order tab you should first have your gusiconfig, then gusi_msl, then gusi_core and only then all your other files. Also, carefully check the warning messages from the build step, there should be warnings about fopen() and fread() from gusi_msl being used in stead of those from MSL. If that seems okay there may still a way that fread() from MSL got pulled in with fopen() from GUSI, although I've never seen it myself. You could try generating a link map, and checking the filenames from which the relevant routines are pulled in. If this also fails to provide a solution it may be that you are indeed pulling in everything from GUSI but something is wrong at a lower level. Build the debugging variants of the GUSI libraries, link against those and step in to fread (or fopen) to see what the problem is. On Saturday, August 23, 2003, at 10:53 AM, Robin Becker wrote: > Hi I'm throwing this out in the hope that someone else has seen the > ssame kind of > problem. > > With Just van Rossum and Jack Jansen's help we've created a compact > python+reportlab > distro for a client, but so far all our attempts at getting the > extensions built in > house (rather than by Just) have failed. We have Code Warrior patched > to 8.3 and > have been using the mcp files contributed by Just (with file paths > changed to match > our system). > > Even so in at least one module _renderPM we get a strange error at run > time in the > following code > > f = fopen (filename, "rb"); /*f is non NULL supposedly a good > descriptor*/ > if (f == NULL) return NULL; > > pfb_size = 0; > pfb_size_max = 32768; > pfb = gt1_new (char, pfb_size_max); > while (1) > { > bytes_read = fread (pfb + pfb_size, 1, pfb_size_max - > pfb_size, f); > /*the first fread returns zero*/ > if (bytes_read == 0) break; > pfb_size += bytes_read; > gt1_double (pfb, char, pfb_size_max); > } > /*errno here is 9 (ie bad file descriptor)*/ > fclose (f); > > ie we get a non null descriptor, but the first fread seems to treat it > as bad. > We have GUSI2 & Python/include on the paths list and supposedly the > right things on > the linker path, but this code just doesn't work. > > If I try the above in a console linked in the standard way things work > as expected > as does the binary created by Just. > > Anyone with any good ideas? > -- > Robin Becker > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- 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 robin at reportlab.com Mon Aug 25 10:57:50 2003 From: robin at reportlab.com (Robin Becker) Date: Mon Aug 25 04:59:25 2003 Subject: [Pythonmac-SIG] weirdness with Mac OS 9 extension In-Reply-To: <8343E329-D6C9-11D7-8D87-000393894CEA@xs4all.nl> References: <2GfMmjAMuyR$EwqK@jessikat.fsnet.co.uk> <8343E329-D6C9-11D7-8D87-000393894CEA@xs4all.nl> Message-ID: In message <8343E329-D6C9-11D7-8D87-000393894CEA@xs4all.nl>, Eric Nieuwland writes >Robin, > >Is your 'f' variable local or global? If it is global, check whether >'gt1_new' modifies it in some way. >Also, check whether 'fread' itself is what you exxpect it to be. There >might be another version on the pah between your code and libc. > >--eric > f is indeed local, so if fread is wrong it must be somewhere on the include paths, but I'm allegedly using the same as others have succeeded with. I suppose if fread could be wrong, then so could fopen. I wonder if CW has anyway to dump link maps or something els that could help. >On zaterdag, aug 23, 2003, at 10:53 Europe/Amsterdam, Robin Becker >wrote: > >> Hi I'm throwing this out in the hope that someone else has seen the >> ssame kind of >> problem. >> >> With Just van Rossum and Jack Jansen's help we've created a compact >> python+reportlab >> distro for a client, but so far all our attempts at getting the >> extensions built in >> house (rather than by Just) have failed. We have Code Warrior patched >> to 8.3 and >> have been using the mcp files contributed by Just (with file paths >> changed to match >> our system). >> >> Even so in at least one module _renderPM we get a strange error at run >> time in the >> following code >> >> f = fopen (filename, "rb"); /*f is non NULL supposedly a good >> descriptor*/ >> if (f == NULL) return NULL; >> >> pfb_size = 0; >> pfb_size_max = 32768; >> pfb = gt1_new (char, pfb_size_max); >> while (1) >> { >> bytes_read = fread (pfb + pfb_size, 1, pfb_size_max - >> pfb_size, f); >> /*the first fread returns zero*/ >> if (bytes_read == 0) break; >> pfb_size += bytes_read; >> gt1_double (pfb, char, pfb_size_max); >> } >> /*errno here is 9 (ie bad file descriptor)*/ >> fclose (f); >> >> ie we get a non null descriptor, but the first fread seems to treat it >> as bad. >> We have GUSI2 & Python/include on the paths list and supposedly the >> right things on >> the linker path, but this code just doesn't work. >> >> If I try the above in a console linked in the standard way things work >> as expected >> as does the binary created by Just. >> >> Anyone with any good ideas? >> -- >> Robin Becker >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > -- Robin Becker From robin at reportlab.com Tue Aug 26 14:00:42 2003 From: robin at reportlab.com (Robin Becker) Date: Tue Aug 26 08:01:05 2003 Subject: [Pythonmac-SIG] weirdness with Mac OS 9 extension Message-ID: <9gluPJAqv0S$Ewwt@jessikat.fsnet.co.uk> OK I think I know what my problem is. Just told us that we need only use the GUSI2 headers and things would get pulled out of Pythoncore, but I'm guessing that we really need the GUSI2 libs built as well. Perhaps fread isn't used by Python. I'm not sure why we don't have a requirement for that embedded in Just's .mcp but I don't see any mention of the gusi core or other libs explicitly. Perhaps they can be made available globally somehow. Anyhow the problem now is that I can't seem to build the GUSI2 libs with CW8 starting from the CW7 project file. I get 66 errors trying to build the PPC core alone. A lot of those relate to time_t being redefined, but some seem more complex. Has anyone else used CW8 to build GUSI2? -- Robin Becker From bob at redivi.com Tue Aug 26 10:07:55 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Aug 26 09:08:33 2003 Subject: [Pythonmac-SIG] ANN: LaunchServices 0.1 - Pythonic wrapper for the Launch Services API Message-ID: <4EBCB1C6-D7C6-11D7-9D42-000A95686CD8@redivi.com> Have you ever tried to figure out how to find an application by its creator signature? Or the editor/viewer of a particular file type? The "user interface names" for paths? Well, I figured it out. Apple's API to do it is called Launch Services (part of ApplicationServices.framework). It doesn't have a whole lot of documentation, but reading the header file was sufficient. I developed a Pyrex wrapper around it, leveraging the (meager and buggy :)) CoreFoundation support that comes stock with Python 2.3. I'm basically using this as a way to make the application-finding code for aeve sane. A new version of aeve should be coming sometime in the next two weeks or so. Example usage: >>> import LaunchServices as LS >>> LS.GetDisplayNameForPath('/') u'Crack' >>> LS.GetKindStringForPath('/') u'Volume' >>> LS.GetApplicationPathForInfo(extension='mp3') u'/Applications/iTunes.app' >>> LS.GetApplicationPathForInfo(creator='MACS') u'/System/Library/CoreServices/Finder.app' >>> LS.FindApplicationPath(bundle='com.apple.iChat') u'/Applications/iChat.app' I'm sure somone will find this useful. I made sure everything has doc strings, and it's fully tested (in normal use, not for memory leaks yet) against Jack's Python 2.3 (#2, Jul 30 2003, 11:45:28). homepage: http://undefined.org/python/ pydoc documentation: http://undefined.org/python/LaunchServices-0.1-pydoc.html source tarball: http://undefined.org/python/LaunchServices-0.1.tar.gz PackageManager URL (Python 2.3 - 10.2.x): http://undefined.org/python/pimp/darwin-6.6-Power_Macintosh.plist -bob From jjb5 at cornell.edu Tue Aug 26 12:39:57 2003 From: jjb5 at cornell.edu (Joel Bender) Date: Tue Aug 26 11:39:58 2003 Subject: [Pythonmac-SIG] Broken something? Message-ID: MacOS 10.2.6, Python 2.2.2 (Apple) I've been using the built-in Queue module with great success to transfer data structures between threads, except for today. Now from the "supplier" I'm getting a very strange error: File "/sw/src/root-python22-2.2.2-5/sw/lib/python2.2/Queue.py", line 58, in put release_fsema = True NameError: global name 'True' is not defined Running interactively shows: >>> True 1 Any help figuring out where 'True' went would be appreciated! Joel From mwh at python.net Tue Aug 26 18:08:15 2003 From: mwh at python.net (Michael Hudson) Date: Tue Aug 26 12:08:24 2003 Subject: [Pythonmac-SIG] Broken something? In-Reply-To: (Joel Bender's message of "Tue, 26 Aug 2003 11:39:57 -0400") References: Message-ID: <2mhe44ieq8.fsf@starship.python.net> Joel Bender writes: > MacOS 10.2.6, Python 2.2.2 (Apple) Erm, no. Apple only supply a 2.2(.0) with Jaguar. That doesn't have True. > I've been using the built-in Queue module with great success to > transfer data structures between threads, except for today. Now from > the "supplier" I'm getting a very strange error: > > File "/sw/src/root-python22-2.2.2-5/sw/lib/python2.2/Queue.py", > line 58, in put > release_fsema = True > NameError: global name 'True' is not defined > > Running interactively shows: > > >>> True > 1 > > Any help figuring out where 'True' went would be appreciated! The /sw/bin/python you're (presumably) running here does, though. Was the first example with /usr/bin/python? Cheers, mwh -- ... Windows proponents tell you that it will solve things that your Unix system people keep telling you are hard. The Unix people are right: they are hard, and Windows does not solve them, ... -- Tim Bradshaw, comp.lang.lisp From oussoren at cistron.nl Tue Aug 26 19:24:23 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Tue Aug 26 12:24:36 2003 Subject: [Pythonmac-SIG] ANN: LaunchServices 0.1 - Pythonic wrapper for the Launch Services API In-Reply-To: <4EBCB1C6-D7C6-11D7-9D42-000A95686CD8@redivi.com> References: <4EBCB1C6-D7C6-11D7-9D42-000A95686CD8@redivi.com> Message-ID: On Tuesday, 26 August 2003, at 15:07, Bob Ippolito wrote: > I developed a Pyrex wrapper around it, leveraging the (meager and > buggy :)) CoreFoundation support that comes stock with Python 2.3. To go completely off-topic, what's wrong with the CoreFoundation support in Python 2.3? That is, what bugs did you find? Ronald From bob at redivi.com Tue Aug 26 14:33:24 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Aug 26 13:34:06 2003 Subject: [Pythonmac-SIG] ANN: LaunchServices 0.1 - Pythonic wrapper for the Launch Services API In-Reply-To: Message-ID: <65477BB6-D7EB-11D7-9D42-000A95686CD8@redivi.com> On Tuesday, Aug 26, 2003, at 12:24 America/New_York, Ronald Oussoren wrote: > > On Tuesday, 26 August 2003, at 15:07, Bob Ippolito wrote: > >> I developed a Pyrex wrapper around it, leveraging the (meager and >> buggy :)) CoreFoundation support that comes stock with Python 2.3. > > To go completely off-topic, what's wrong with the CoreFoundation > support in Python 2.3? That is, what bugs did you find? Well first of all, a lot of stuff is missing (CFRunLoop, CFSocket, etc...), which I've ended up wrapping parts of already. I'm guessing it wasn't worth the bother for CFTypeRef's that are wholly or mostly toll-free bridged to the Objective C side of the fence. If would also make sense if they actually inherited CFTypeRef, so you could issubclass/isinstance based upon that. It would be convenient if you could sensibly do things like CFStringRef('somestring') rather than _CF.toCF('somestring') and crossing your fingers. I had a lot of problems with reference counting.. for example, try this: >>> import _CF >>> url = _CF.toCF('file://localhost/').CFURLCreateWithString(None) >>> url.CFURLGetString().toPython() u'file://localhost/' >>> url.CFURLGetString().toPython() Program received signal EXC_BAD_ACCESS, Could not access memory. 0x9068ba54 in objc_msgSend () >>> import _CF >>> url = _CF.toCF('file://localhost/').CFURLCreateWithString(None) >>> url.CFURLGetString().CFRetain().toPython() u'file://localhost/' >>> url.CFURLGetString().CFRetain().toPython() Program received signal EXC_BAD_ACCESS, Could not access memory. 0x9068ba54 in objc_msgSend () CFRetain doesn't do anything useful at all from the Python side. You never get a "nice" _CF.SomeObject out of it (you always end up with a CFTypeRef), and it doesn't increase the retain count in a useful way (the retain count does go up -- but only so long as you hold on to the new object.. it's just giving you two python references to the same thing each with their own reference to the CFTypeRef, when both go away so does the CFTypeRef). I ended up doing this in Pyrex as a workaround for now: def CFRetainForReal(obj): cdef CFTypeRef tref CFObj_Convert(obj, &tref) CFRetain(tref) return obj I only had to use it in one function (I'll include the relevant others for context).. I could just be lucky, I haven't gone through it with a hammer and a fine toothed comb to check for leaks. def CFStringFromObject(obj): """ CFStringFromObject(obj) -> _CF.CFStringRef """ if isinstance(obj, _CF.CFStringRef): return obj if isinstance(obj, _CF.CFURLRef): # XXX - this one seems ok w/o the retain hack url = obj.CFURLCopyAbsoluteURL() return url.CFURLGetString() # cross fingers and hope a CFStringRef pops out cfString = _CF.toCF(obj) if not isinstance(cfString, _CF.CFStringRef): raise ValueError, 'Must be a string' return cfString def CFURLFromObject(obj, base=None): """ CFURLFromObject(obj, base=None) -> _CF.CFURLRef """ cdef CFStringRef _cfString cdef CFURLRef _cfURL cdef CFURLRef _cfURLbase if isinstance(obj, _CF.CFURLRef): return obj cfString = CFStringFromObject(obj) CFStringRefObj_Convert(cfString, &_cfString) if base is None: _cfURLbase = NULL else: CFURLRefObj_Convert(CFURLFromObject(base), &_cfURLbase) _cfURL = CFURLCreateWithString(kCFAllocatorDefault, _cfString, _cfURLbase) if (_cfURL == NULL): raise ValueError, 'Not a valid URL' return CFObj_New(CFRetain(_cfURL)) def PathToURL(path): """ PathToURL(path) -> unicode_url """ path = CFStringFromObject(path).toPython().encode('utf8') # XXX - this is where the bug shows up cfurl = CFRetainForReal(_CF.CFURLCreateFromFSRef(path)) cfstr = CFStringFromObject(cfurl) return cfstr.toPython() From eric.nieuwland at xs4all.nl Wed Aug 27 16:05:00 2003 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Wed Aug 27 09:05:13 2003 Subject: [Pythonmac-SIG] image processing Message-ID: <10D839F0-D88F-11D7-8259-000393894CEA@xs4all.nl> Hi all, I have to do some image analysis and would prefer to do it in Python on a Mac. Could anyone come up with suggestions? Tasks: - identify pixels of the same colour - produce a list of coordinates per colour - cluster like coloured pixels to identify bigger areas of the same colour File format: - bmp, but may be converted to any other --eric From bob at redivi.com Wed Aug 27 10:52:45 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Aug 27 09:58:02 2003 Subject: [Pythonmac-SIG] image processing In-Reply-To: <10D839F0-D88F-11D7-8259-000393894CEA@xs4all.nl> Message-ID: Sounds like a pretty slow way to go about it.. but you should be able to do it just fine with Numeric and PIL. -bob On Wednesday, Aug 27, 2003, at 09:05 America/New_York, Eric Nieuwland wrote: > Hi all, > > I have to do some image analysis and would prefer to do it in Python > on a Mac. Could anyone come up with suggestions? > > Tasks: > - identify pixels of the same colour > - produce a list of coordinates per colour > - cluster like coloured pixels to identify bigger areas of the same > colour > > File format: > - bmp, but may be converted to any other From eric.nieuwland at xs4all.nl Wed Aug 27 17:22:00 2003 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Wed Aug 27 10:22:24 2003 Subject: [Pythonmac-SIG] image processing In-Reply-To: Message-ID: How slow would be slow, in your estimate? The images will be of various sizes, so let's assume 800x640 as a reference. --eric On woensdag, aug 27, 2003, at 15:52 Europe/Amsterdam, Bob Ippolito wrote: > Sounds like a pretty slow way to go about it.. but you should be able > to do it just fine with Numeric and PIL. > > -bob > > On Wednesday, Aug 27, 2003, at 09:05 America/New_York, Eric Nieuwland > wrote: > >> Hi all, >> >> I have to do some image analysis and would prefer to do it in Python >> on a Mac. Could anyone come up with suggestions? >> >> Tasks: >> - identify pixels of the same colour >> - produce a list of coordinates per colour >> - cluster like coloured pixels to identify bigger areas of the same >> colour >> >> File format: >> - bmp, but may be converted to any other > > From bob at redivi.com Wed Aug 27 11:48:17 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Aug 27 10:48:57 2003 Subject: [Pythonmac-SIG] image processing In-Reply-To: Message-ID: <7EBDEB2F-D89D-11D7-9146-000A95686CD8@redivi.com> It really depends on how you're doing it and what you're trying to achieve. I'm not a signal processing expert, but I can imagine the naive algorithms to do this sort of stuff could involve multiple passes over every pixel in the image -- 800x640 as a reference would be 512000 pixels. I can't imaging doing anything in python bytecode half a million times is going to be very speedy. Though you may be able to process multiple pixels at the same time, or leverage some existing library in Numeric to do something like find a histogram of the image. It also depends on what you mean by color exactly.. specifying it as identical pixel values is rather easy, but probably not very useful. Even identifying those areas of the same color is rather vague.. what's a useful description of a cluster? You might want to try preprocessing the image with something like AutoTrace, since what you're describing is basically what AutoTrace does before it attempts to create a vectorized version of the image. http://autotrace.sourceforge.net/ It might be easier for you to work with vectors anyway (i.e. by approximating the area of the paths to find your clusters). -bob On Wednesday, Aug 27, 2003, at 10:22 America/New_York, Eric Nieuwland wrote: > How slow would be slow, in your estimate? > The images will be of various sizes, so let's assume 800x640 as a > reference. > > --eric > > On woensdag, aug 27, 2003, at 15:52 Europe/Amsterdam, Bob Ippolito > wrote: > >> Sounds like a pretty slow way to go about it.. but you should be able >> to do it just fine with Numeric and PIL. >> >> -bob >> >> On Wednesday, Aug 27, 2003, at 09:05 America/New_York, Eric Nieuwland >> wrote: >> >>> Hi all, >>> >>> I have to do some image analysis and would prefer to do it in Python >>> on a Mac. Could anyone come up with suggestions? >>> >>> Tasks: >>> - identify pixels of the same colour >>> - produce a list of coordinates per colour >>> - cluster like coloured pixels to identify bigger areas of the same >>> colour >>> >>> File format: >>> - bmp, but may be converted to any other From jjb5 at cornell.edu Wed Aug 27 12:08:38 2003 From: jjb5 at cornell.edu (Joel Bender) Date: Wed Aug 27 11:08:38 2003 Subject: [Pythonmac-SIG] Broken something? In-Reply-To: <2mhe44ieq8.fsf@starship.python.net> References: <2mhe44ieq8.fsf@starship.python.net> Message-ID: Michael Hudson wrote: >Was the first example with /usr/bin/python? No, /sw/bin/python. I think. Now I've found so many versions of python installed it's making my head hurt! Between Apple's, Fink, and MacPython, along with alphas of a few of those along the way...I knew I broke *something*. Time to do some housecleaning :). Joel From brownr at ucalgary.ca Wed Aug 27 10:40:58 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Wed Aug 27 11:42:06 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? Message-ID: I'm trying to write wrappers for dcmtk (a toolkit for the medical imaging DICOM standard). At the moment I have three functions, to open an association (basically a network connection), close it, and send an echo request (like a ping). A test program written entirely in C works fine but when compiled as a module and called from Python I get an illegal instruction when the dcmtk function to actually open the association is called. I believe this function is simply opening a socket, connecting to a server and negotiating what flavour of the protocol to use. Are there things that simply can't be done in a Python module? What exactly is an illegal instruction? Thanks for any help, Robb _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From bob at redivi.com Wed Aug 27 12:56:45 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Aug 27 11:57:22 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: Message-ID: <0F3E1AC6-D8A7-11D7-9146-000A95686CD8@redivi.com> On Wednesday, Aug 27, 2003, at 11:40 America/New_York, Robb Brown wrote: > I'm trying to write wrappers for dcmtk (a toolkit for the medical > imaging DICOM standard). At the moment I have three functions, to > open an association (basically a network connection), close it, and > send an echo request (like a ping). A test program written entirely > in C works fine but when compiled as a module and called from Python I > get an illegal instruction when the dcmtk function to actually open > the association is called. I believe this function is simply opening > a socket, connecting to a server and negotiating what flavour of the > protocol to use. > > Are there things that simply can't be done in a Python module? What > exactly is an illegal instruction? Illegal instruction is a CPU level exception. What it means is that the CPU tried to execute invalid opcode. It has nothing to do with security or Python. Generally what it means that some branch instruction told the CPU to go somewhere that wasn't code at all, which can happen if you have a corrupted stack or function pointer. In any case, this is almost certainly a bug in your wrapper. If dcmtk uses threads you might not be doing the right thing with thread states from Python, otherwise you've just got some bad C code somewhere. If you post the code you have, someone might look at it. -bob From brownr at ucalgary.ca Wed Aug 27 12:53:07 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Wed Aug 27 13:54:18 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? Message-ID: <50E5738D-D8B7-11D7-B82A-000A959032C4@ucalgary.ca> Hm. Strange that the same code works from C but not Python... dcmtk does apparently use some threads. Do I have to do something specific to make C threads work with Python? Unfortunately, any threading is done within the toolkit - which I'd rather not modify too much. Is there something I put in the wrapper? Thanks, Robb Bob Ippolito said: > On Wednesday, Aug 27, 2003, at 11:40 America/New_York, Robb Brown > wrote: > >> I'm trying to write wrappers for dcmtk (a toolkit for the medical >> imaging DICOM standard). At the moment I have three functions, to >> open an association (basically a network connection), close it, and >> send an echo request (like a ping). A test program written entirely >> in C works fine but when compiled as a module and called from Python I >> get an illegal instruction when the dcmtk function to actually open >> the association is called. I believe this function is simply opening >> a socket, connecting to a server and negotiating what flavour of the >> protocol to use. >> >> Are there things that simply can't be done in a Python module? What >> exactly is an illegal instruction? > > Illegal instruction is a CPU level exception. What it means is that > the CPU tried to execute invalid opcode. It has nothing to do with > security or Python. Generally what it means that some branch > instruction told the CPU to go somewhere that wasn't code at all, which > can happen if you have a corrupted stack or function pointer. > > In any case, this is almost certainly a bug in your wrapper. If dcmtk > uses threads you might not be doing the right thing with thread states > from Python, otherwise you've just got some bad C code somewhere. If > you post the code you have, someone might look at it. > > -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From mwh at python.net Wed Aug 27 20:02:34 2003 From: mwh at python.net (Michael Hudson) Date: Wed Aug 27 14:02:20 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: <50E5738D-D8B7-11D7-B82A-000A959032C4@ucalgary.ca> (Robb Brown's message of "Wed, 27 Aug 2003 11:53:07 -0600") References: <50E5738D-D8B7-11D7-B82A-000A959032C4@ucalgary.ca> Message-ID: <2mekz7yo5h.fsf@starship.python.net> Robb Brown writes: > Hm. Strange that the same code works from C but not Python... dcmtk > does apparently use some threads. Meep! Here be dragons, at least possibly. > Do I have to do something specific to make C threads work with > Python? I don't think so. But if the toolkit makes callbacks to your code, then things can get really entertaining. > Unfortunately, any threading is done within the toolkit - which I'd > rather not modify too much. Is there something I put in the > wrapper? Can you show us a small example? Even if there's noone here who understands the toolkit we might be able to spot some potential red flags. Cheers, mwh -- I think if we have the choice, I'd rather we didn't explicitly put flaws in the reST syntax for the sole purpose of not insulting the almighty. -- /will on the doc-sig From brownr at ucalgary.ca Wed Aug 27 13:12:15 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Wed Aug 27 14:13:22 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: <2mekz7yo5h.fsf@starship.python.net> Message-ID: No problem -- here's the wrapper in it's entirety -- it's not very big at the moment, only the three functions. No, there are no callbacks. In fact, I can't even be sure dcmtk is using threads -- for what I'm doing there's no real reason for it to, everything blocks as far as I'm concerned. Anyway, here's the code. The crash is on line 104, where all the setup is finished and I actually ask dcmtk to connect. Thanks for the help, Robb -------------- next part -------------- #include "Python.h" #define PY_ARRAY_UNIQUE_SYMBOL RobbDICOM #include "arrayobject.h" #include "ofstdinc.h" #include "dimse.h" #include "diutil.h" #include "dcfilefo.h" #include "dcdebug.h" #include "dcdict.h" #include "dcuid.h" #include "dcuid.h" /* for dcmtk version name */ /* DICOM standard transfer syntaxes */ static const char* transferSyntaxes[] = { UID_LittleEndianImplicitTransferSyntax, /* default xfer syntax first */ UID_LittleEndianExplicitTransferSyntax, UID_BigEndianExplicitTransferSyntax, UID_JPEGProcess1TransferSyntax, UID_JPEGProcess2_4TransferSyntax, UID_JPEGProcess3_5TransferSyntax, UID_JPEGProcess6_8TransferSyntax, UID_JPEGProcess7_9TransferSyntax, UID_JPEGProcess10_12TransferSyntax, UID_JPEGProcess11_13TransferSyntax, UID_JPEGProcess14TransferSyntax, UID_JPEGProcess15TransferSyntax, UID_JPEGProcess16_18TransferSyntax, UID_JPEGProcess17_19TransferSyntax, UID_JPEGProcess20_22TransferSyntax, UID_JPEGProcess21_23TransferSyntax, UID_JPEGProcess24_26TransferSyntax, UID_JPEGProcess25_27TransferSyntax, UID_JPEGProcess28TransferSyntax, UID_JPEGProcess29TransferSyntax, UID_JPEGProcess14SV1TransferSyntax, UID_RLELossless}; int checkCond(OFCondition cond) { if (cond.bad()) { DimseCondition::dump(cond); return 0; } else return 1; } static PyObject * openAssociation(PyObject *self, PyObject *args) { T_ASC_Association * assoc; char *aet; char *aec; char *address; int port; PyObject* ret; T_ASC_Network *net; T_ASC_Parameters *params; DIC_NODENAME localHost; DIC_NODENAME peerHost; if (!PyArg_ParseTuple(args,"sssi", &aet, &aec, &address, &port)) return NULL; if (!dcmDataDict.isDictionaryLoaded()) { fprintf(stderr, "DICOM Error: no data dictionary loaded\n"); return NULL; } fprintf(stderr,"DICOM Dictionary loaded okay\n"); OFCondition cond = ASC_initializeNetwork(NET_REQUESTOR, 0, 1000, &net); if (!checkCond(cond)) return NULL; fprintf(stderr,"Network Initialized\n"); cond = ASC_createAssociationParameters(¶ms, ASC_DEFAULTMAXPDU); if (!checkCond(cond)) return NULL; fprintf(stderr,"Association parameters okay\n"); ASC_setAPTitles(params, aec, aet, NULL); cond = ASC_setTransportLayerType(params,OFFalse); if (!checkCond(cond)) return NULL; fprintf(stderr,"Set Transport Layer type\n"); gethostname(localHost,sizeof(localHost)-1); sprintf(peerHost, "%s:%d", address, port); ASC_setPresentationAddresses(params, localHost, peerHost); fprintf(stderr,"Set Presentation address\n"); cond = ASC_addPresentationContext(params, 1, UID_VerificationSOPClass, transferSyntaxes, 1); if (!checkCond(cond)) return NULL; fprintf(stderr,"Added Presentation Contexts...\n"); cond = ASC_requestAssociation(net, params, &assoc); if (!checkCond(cond)) return NULL; fprintf(stderr,"Done Requesting association\n"); if (ASC_countAcceptedPresentationContexts(params) == 0) { fprintf(stderr, "DICOM Error: No acceptable presentaiton contexts.\n"); return NULL; } ret = PyCObject_FromVoidPtr((void*) assoc, NULL); return ret; } static PyObject * closeAssociation(PyObject *self, PyObject *args) { PyObject *assocObj; T_ASC_Association * assoc; // if (!PyArg_ParseTuple(args, "O!", &PyObject, &assocObj)) return NULL; if (!PyArg_ParseTuple(args,"O", &assocObj)) return NULL; if (!PyCObject_Check(assocObj)) return NULL; assoc = (T_ASC_Association *) PyCObject_AsVoidPtr(assocObj); OFCondition cond = ASC_releaseAssociation(assoc); if (!checkCond(cond)); return NULL; } static PyObject * echo(PyObject *self, PyObject *args) { PyObject *assocObj; T_ASC_Association * assoc; char * retstr; PyObject *ret; if (!PyArg_ParseTuple(args,"O",&assocObj)) return NULL; if (!PyCObject_Check(assocObj)) return NULL; assoc = (T_ASC_Association *) PyCObject_AsVoidPtr(assocObj); DIC_US msgId = assoc->nextMsgID++; DIC_US status; DcmDataset *statusDetail = NULL; OFCondition cond = DIMSE_echoUser(assoc,msgId,DIMSE_BLOCKING, 0, &status, &statusDetail); if (!checkCond(cond)); retstr = DU_cstoreStatusString(status); ret = Py_BuildValue("s",retstr); return ret; } static PyMethodDef DicomMethods[] = { {"openAssociation", openAssociation, METH_VARARGS, "Open a DICOM association with a remote host."}, {"closeAssociation",closeAssociation,METH_VARARGS,"Close a DICOM association with a remote host."}, {"echo",echo,METH_VARARGS,"Send a DICOM EchoSCU request."}, {NULL, NULL, 0, NULL} }; extern "C" void initdicom(void) { (void) Py_InitModule("dicom",DicomMethods); import_array(); } -------------- next part -------------- On Wednesday, August 27, 2003, at 12:02 PM, Michael Hudson wrote: > Robb Brown writes: > >> Hm. Strange that the same code works from C but not Python... dcmtk >> does apparently use some threads. > > Meep! Here be dragons, at least possibly. > >> Do I have to do something specific to make C threads work with >> Python? > > I don't think so. But if the toolkit makes callbacks to your code, > then things can get really entertaining. > >> Unfortunately, any threading is done within the toolkit - which I'd >> rather not modify too much. Is there something I put in the >> wrapper? > > Can you show us a small example? Even if there's noone here who > understands the toolkit we might be able to spot some potential red > flags. > > Cheers, > mwh > > -- > I think if we have the choice, I'd rather we didn't explicitly put > flaws in the reST syntax for the sole purpose of not insulting the > almighty. -- /will on the doc-sig > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From bob at redivi.com Wed Aug 27 15:20:37 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Aug 27 14:21:13 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: <2mekz7yo5h.fsf@starship.python.net> Message-ID: <280CD595-D8BB-11D7-9146-000A95686CD8@redivi.com> On Wednesday, Aug 27, 2003, at 14:02 America/New_York, Michael Hudson wrote: > Robb Brown writes: > >> Hm. Strange that the same code works from C but not Python... dcmtk >> does apparently use some threads. > > Meep! Here be dragons, at least possibly. It's also not the same code, he could quite possibly be doing something wrong (either generically wrong, or not handling threadstates, the GIL, or callbacks correctly.. I think this bites a lot of people the first time they run into it) at the Python C API level. Personally, I find Pyrex ( http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex ) to be extremely useful for writing C extensions (either wrappers or otherwise). It does a *whole lot* of stuff for you that's quite a chore from the Python C API, and you get to write the code in (a slightly reduced in some respects, but extended in others to support C things like static types, typecasts, structures, etc) python syntax. You do have to do a bit of text processing to wrap existing header files (most of which I've been able to do with regular expressions), but perhaps someone sometime can write something that automates this. >> Do I have to do something specific to make C threads work with >> Python? > > I don't think so. But if the toolkit makes callbacks to your code, > then things can get really entertaining. http://www.python.org/doc/current/api/threads.html > >> Unfortunately, any threading is done within the toolkit - which I'd >> rather not modify too much. Is there something I put in the >> wrapper? > > Can you show us a small example? Even if there's noone here who > understands the toolkit we might be able to spot some potential red > flags. That would help immensely. -bob From bob at redivi.com Wed Aug 27 15:39:50 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Aug 27 14:40:26 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: Message-ID: On Wednesday, Aug 27, 2003, at 14:12 America/New_York, Robb Brown wrote: > No problem -- here's the wrapper in it's entirety -- it's not very big > at the moment, only the three functions. > > No, there are no callbacks. In fact, I can't even be sure dcmtk is > using threads -- for what I'm doing there's no real reason for it to, > everything blocks as far as I'm concerned. > > Anyway, here's the code. The crash is on line 104, where all the > setup is finished and I actually ask dcmtk to connect. That's a really strange place to have a crash. Have you tried running it under gdb to see what the traceback looks like? Maybe the net or params structures didn't get initialized properly? -bob From eric.wichterich at gmx.de Wed Aug 27 23:42:51 2003 From: eric.wichterich at gmx.de (Eric Wichterich) Date: Wed Aug 27 16:45:54 2003 Subject: [Pythonmac-SIG] Replace placeholder in string with content of ONE variable??? Message-ID: <06A0B3C2-D8CF-11D7-9D76-00039315E356@gmx.de> Hello, Can anyone help me out? I want to replace a string with several placeholders (%s) with the content of ONE variable. Here is a small (silly) example: action = "barking" print "My %s dog keeps %s all the time." % action The output I am looking for is "My barking dog keeps barking all the time." Does anybody know how to proceed? Thank you very much, Eric From cjl at physics.otago.ac.nz Thu Aug 28 10:02:07 2003 From: cjl at physics.otago.ac.nz (Chris Lee) Date: Wed Aug 27 17:02:53 2003 Subject: [Pythonmac-SIG] unixy python and applescript Message-ID: Hi All, I use an application called Pro Fit for graphing, data analysis and some numerical analysis. However I do most of my numerical work in python and now I want to link the two :) What I am doing at the moment is using an applescript to get the variables out of ProFit and then I am calling do script 'thescript v1 v2 v3....' I have a python function which extracts the variables and then returns the result to applescript which in turn passes it back to Pro Fit. It all works just fine provided you have set up all your paths in environment.plist file. The problem of course is that it is very slow. I know that Macpython can be linked directly with applescript but what I really want to do is to allow the user to choose which python they use (so they install the minimum of stuff to use it). What modules have to be installed for the UNIX pythons (either apple or third party installed) to communicate with an applescript ? Cheers Chris ################################# Chris Lee Physics Department Otago University PO Box 56 Dunedin New Zealand Phone ++64 3 479 7749 Fax ++64 3 479 0964 ################################# From dsposx at mac.com Wed Aug 27 15:03:04 2003 From: dsposx at mac.com (Donovan Preston) Date: Wed Aug 27 17:04:43 2003 Subject: [Pythonmac-SIG] Replace placeholder in string with content of ONE variable??? In-Reply-To: <06A0B3C2-D8CF-11D7-9D76-00039315E356@gmx.de> References: <06A0B3C2-D8CF-11D7-9D76-00039315E356@gmx.de> Message-ID: On Wednesday, August 27, 2003, at 1:42 PM, Eric Wichterich wrote: > Hello, > > Can anyone help me out? I want to replace a string with several > placeholders (%s) with the content of ONE variable. > Here is a small (silly) example: > > action = "barking" > print "My %s dog keeps %s all the time." % action > > The output I am looking for is "My barking dog keeps barking all the > time." >>> "My %(verb)s dog keeps %(verb)s all the time." % {'verb': 'barking'} 'My barking dog keeps barking all the time.' From bob at redivi.com Wed Aug 27 18:07:20 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Aug 27 17:09:04 2003 Subject: [Pythonmac-SIG] Replace placeholder in string with content of ONE variable??? In-Reply-To: <06A0B3C2-D8CF-11D7-9D76-00039315E356@gmx.de> Message-ID: <7261ED15-D8D2-11D7-9146-000A95686CD8@redivi.com> On Wednesday, Aug 27, 2003, at 16:42 America/New_York, Eric Wichterich wrote: > Hello, > > Can anyone help me out? I want to replace a string with several > placeholders (%s) with the content of ONE variable. > Here is a small (silly) example: > > action = "barking" > print "My %s dog keeps %s all the time." % action > > The output I am looking for is "My barking dog keeps barking all the > time." # perlish local variable string interpolation using dict of local variables action = "barking" print "My %(action)s dog keeps %(action)s all the time." % locals() # same dict style, a bit safer if the string might be tainted or whatnot actiondict = {'action': 'barking'} print "My %(action)s dog keeps %(action)s all the time." % actiondict # tuple style action = 'barking' print "My %s dog keeps %s all the time." % ((action,) * 2) # "automatic" tuple style action = 'barking' message = "My %s dog keeps %s all the time." print message % ((action,) * message.count('%s')) # "cheap" not-really-string-interpolation action = 'barking' print "My %s dog keeps %s all the time.".replace('%s', action) ... In any case, there's more than one way to do it. The only one obvious way to do it would be one of the first two, depending on your laziness and where the variables are coming from. -bob From brownr at ucalgary.ca Wed Aug 27 15:44:06 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Wed Aug 27 17:11:39 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: Message-ID: <333FF44E-D8CF-11D7-B82A-000A959032C4@ucalgary.ca> I haven't tried running it under gdb though I will. I don't know whether the toolkit was compiled with debugging symbols on though. The exact same code runs fine when called from a C++ main part though (not compiled as a library). On Wednesday, August 27, 2003, at 12:39 PM, Bob Ippolito wrote: > On Wednesday, Aug 27, 2003, at 14:12 America/New_York, Robb Brown > wrote: > >> No problem -- here's the wrapper in it's entirety -- it's not very >> big at the moment, only the three functions. >> >> No, there are no callbacks. In fact, I can't even be sure dcmtk is >> using threads -- for what I'm doing there's no real reason for it to, >> everything blocks as far as I'm concerned. >> >> Anyway, here's the code. The crash is on line 104, where all the >> setup is finished and I actually ask dcmtk to connect. > > That's a really strange place to have a crash. Have you tried running > it under gdb to see what the traceback looks like? Maybe the net or > params structures didn't get initialized properly? > > -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From bob at redivi.com Wed Aug 27 18:12:52 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Aug 27 17:13:30 2003 Subject: [Pythonmac-SIG] unixy python and applescript In-Reply-To: Message-ID: <3825D3B6-D8D3-11D7-9146-000A95686CD8@redivi.com> On Wednesday, Aug 27, 2003, at 17:02 America/New_York, Chris Lee wrote: > Hi All, > > I use an application called Pro Fit for graphing, data analysis and > some numerical analysis. However I do most of my numerical work in > python and now I want to link the two :) > > What I am doing at the moment is using an applescript to get the > variables out of ProFit and then I am calling do script 'thescript v1 > v2 v3....' > I have a python function which extracts the variables and then returns > the result to applescript which in turn passes it back to Pro Fit. It > all works just fine provided you have set up all your paths in > environment.plist file. The problem of course is that it is very > slow. > > I know that Macpython can be linked directly with applescript but what > I really want to do is to allow the user to choose which python they > use (so they install the minimum of stuff to use it). What modules > have to be installed for the UNIX pythons (either apple or third party > installed) to communicate with an applescript ? Argh.. I don't recommend that idea. Don't encourage people to use Fink python, and DEFINITELY don't encourage people to use Jaguar's python. If you're dead set on making it work on an arbitrary version of python on OS X, and since you're just using "do script" anyways, just bite the bullet and format a string to pass to osascript(1). Panther's python will come with all the necessary modules for AppleScript. I highly recommend taking a look at my aeve module ( http://undefined.org.python/ ) for any serious python <-> applescript interaction. I'll be releasing a new version pretty soon that makes it more robust and cleans up all the terminiology finding junk I had stolen from gensuite. Note that the setup.py in the current version of aeve is broken, add 'aeve.aetypes' to the packages list before installing. -bob From cjl at physics.otago.ac.nz Thu Aug 28 11:07:52 2003 From: cjl at physics.otago.ac.nz (Chris Lee) Date: Wed Aug 27 18:08:56 2003 Subject: [Pythonmac-SIG] unixy python and applescript In-Reply-To: <3825D3B6-D8D3-11D7-9146-000A95686CD8@redivi.com> Message-ID: On Thursday, August 28, 2003, at 09:12 AM, Bob Ippolito wrote: > > On Wednesday, Aug 27, 2003, at 17:02 America/New_York, Chris Lee wrote: > >> Hi All, >> >> I use an application called Pro Fit for graphing, data analysis and >> some numerical analysis. However I do most of my numerical work in >> python and now I want to link the two :) >> >> What I am doing at the moment is using an applescript to get the >> variables out of ProFit and then I am calling do script 'thescript v1 >> v2 v3....' >> I have a python function which extracts the variables and then >> returns the result to applescript which in turn passes it back to Pro >> Fit. It all works just fine provided you have set up all your paths >> in environment.plist file. The problem of course is that it is very >> > slow. >> >> I know that Macpython can be linked directly with applescript but >> what I really want to do is to allow the user to choose which python >> they use (so they install the minimum of stuff to use it). What >> modules have to be installed for the UNIX pythons (either apple or >> third party installed) to communicate with an applescript ? > > Argh.. I don't recommend that idea. Don't encourage people to use > Fink python, and DEFINITELY don't encourage people to use Jaguar's > python. Yes but then you are asking people to download another python... Not everyone wants to have 4 versions of the same app. At the moment I use it with Fink python because Fink is the only thing that allows me to install scipy, Scientific and rpy and Numpy (linked to ATLAS instead of it's own libraries) right out of the box. I don't have the skills to make these things work myself so have no choice but to use the Fink version. > If you're dead set on making it work on an arbitrary version of > python on OS X, and since you're just using "do script" anyways, just > bite the bullet and format a string to pass to osascript(1). That's the point I don't want to use "do script". At this point for every x value python starts up, loads the required functions from various modules and then executes my functions and returns. It is very very very slow, the only time you would use it is when the computational time for each pass through the function is well in excess of the start up time (not to mention the overhead of the applescript itself) > > Panther's python will come with all the necessary modules for > AppleScript. I highly recommend taking a look at my aeve module ( > http://undefined.org.python/ ) for any serious python <-> applescript > interaction. I'll be releasing a new version pretty soon that makes > it more robust and cleans up all the terminiology finding junk I had > stolen from gensuite. Yes I've been vaguely following this thread and even installed it. But my understanding is that it requires Macpython yes? I may write a version that is specific for Macpython but until the packages mentioned above build out of the box for it then there isn't too much incentive for me to do so. I guess I will re-write when Panther comes out. Better any communication than none at all :) Thanks for your help Cheers Chris ################################# Chris Lee Physics Department Otago University PO Box 56 Dunedin New Zealand Phone ++64 3 479 7749 Fax ++64 3 479 0964 ################################# From bob at redivi.com Wed Aug 27 19:41:00 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Aug 27 18:42:44 2003 Subject: [Pythonmac-SIG] unixy python and applescript In-Reply-To: Message-ID: <883622D8-D8DF-11D7-A53B-000A95686CD8@redivi.com> On Wednesday, Aug 27, 2003, at 18:07 America/New_York, Chris Lee wrote: > > On Thursday, August 28, 2003, at 09:12 AM, Bob Ippolito wrote: > >> >> On Wednesday, Aug 27, 2003, at 17:02 America/New_York, Chris Lee >> wrote: >> >>> Hi All, >>> >>> I use an application called Pro Fit for graphing, data analysis and >>> some numerical analysis. However I do most of my numerical work in >>> python and now I want to link the two :) >>> >>> What I am doing at the moment is using an applescript to get the >>> variables out of ProFit and then I am calling do script 'thescript >>> v1 v2 v3....' >>> I have a python function which extracts the variables and then >>> returns the result to applescript which in turn passes it back to >>> Pro Fit. It all works just fine provided you have set up all your >>> paths in environment.plist file. The problem of course is that it >>> is very > slow. >>> >>> I know that Macpython can be linked directly with applescript but >>> what I really want to do is to allow the user to choose which python >>> they use (so they install the minimum of stuff to use it). What >>> modules have to be installed for the UNIX pythons (either apple or >>> third party installed) to communicate with an applescript ? >> >> Argh.. I don't recommend that idea. Don't encourage people to use >> Fink python, and DEFINITELY don't encourage people to use Jaguar's >> python. > > Yes but then you are asking people to download another python... Not > everyone wants to have 4 versions of the same app. At the moment I > use it with Fink python because Fink is the only thing that allows me > to install scipy, Scientific and rpy and Numpy (linked to ATLAS > instead of it's own libraries) right out of the box. I don't have the > skills to make these things work myself so have no choice but to use > the Fink version. You don't have to tell your users they're downloading another Python, just include the framework in the app bundle with your application. If the application is something that a user actually needs, they'd be willing to download MacPython (directly or indirectly) to use it anyways! I consider Fink Python to be an ugly little crutch. The only real use I'd have for it personally would be to have a sandboxed version of Python designed specifically to talk to X11 with everything compiled for X11 (Tk, etc.). At the moment I just forward X11 over ssh to a linux box whenever I really need to do something with X11 (very rarely), because maintaining it on my OS X box scares me. I'll probably get around to compiling Numpy+ATLAS, Scipy, etc. for MacPython sometime. I'd have done it by now, but the damn thing needs a Fortran compiler and I haven't come across one that's reasonably easy to install/use with the gcc 3.3 toolchain. If you find one, let me know, and I'll see about doing it. >> If you're dead set on making it work on an arbitrary version of >> python on OS X, and since you're just using "do script" anyways, just >> bite the bullet and format a string to pass to osascript(1). > > That's the point I don't want to use "do script". At this point for > every x value python starts up, loads the required functions from > various modules and then executes my functions and returns. It is > very very very slow, the only time you would use it is when the > computational time for each pass through the function is well in > excess of the start up time (not to mention the overhead of the > applescript itself) I guess I didn't make it very clear as to what I meant by using osascript(1). Here's how I would do it in your scenario: 1) Have Python do all the processing in one fell swoop, and spit the results out to a textfile or the like in some known path. 2) Have Python run osascript(1) with some AppleScript that takes the contents of the text file and tells Pro Fit what to plot. If you're scripting from *inside* Pro Fit, what you could do is write a Python webserver daemon, and use AppleScript's SOAP support to talk to your Python daemon (which would use SOAPy, Twisted, or whatever).. this should be a lot quicker than using do script to start python, extract a value, and shutdown python. >> Panther's python will come with all the necessary modules for >> AppleScript. I highly recommend taking a look at my aeve module ( >> http://undefined.org.python/ ) for any serious python <-> applescript >> interaction. I'll be releasing a new version pretty soon that makes >> it more robust and cleans up all the terminiology finding junk I had >> stolen from gensuite. > > Yes I've been vaguely following this thread and even installed it. > But my understanding is that it requires Macpython yes? > I may write a version that is specific for Macpython but until the > packages mentioned above build out of the box for it then there isn't > too much incentive for me to do so. > I guess I will re-write when Panther comes out. Better any > communication than none at all :) I *only* support MacPython 2.3. All the other versions of Python on the Mac are too broken or limited for me to care about. Not caring about Fink and Jaguar Python is a huge time/sanity saver :) If I need to distribute something I can either have users install MacPython 2.3 (which I find isn't really a problem if they actually want to run your application), run on Panther, or distribute a copy of the Python framework inside the app bundle (which saves you all kinds of support headaches in exchange for a little bloat). -bob From brownr at ucalgary.ca Thu Aug 28 13:08:05 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Thu Aug 28 14:09:09 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: Message-ID: <92404561-D982-11D7-B82A-000A959032C4@ucalgary.ca> I thought you might be interested... dctk is a DICOM (medical image file format / network protocol for those not in the know) toolkit -- file read and write as well as network connectivity. My idea is to wrap the basic functions in Python and then writing DICOM enabled apps is no problem. Plus, I'm frequently annoyed by our expensive research PACS (a medical image archiving server)... a good Python DICOM package and existing Python database modules would let you write your own PACS in an afternoon. If it works I'm sure there would be a lot of interest... we've been considering the MERGE toolkit which is several thousand dollars a seat and is only C++. On Wednesday, August 27, 2003, at 09:15 PM, Yves Starreveld wrote: > Hi, Robb, > > That stuff sounds like it would be of fairly general interest.... > > What kind of thing are you putting together? We are stringing > something together using php at this time. > > Yves > On Wednesday, August 27, 2003, at 11:40 AM, Robb Brown wrote: > >> I'm trying to write wrappers for dcmtk (a toolkit for the medical >> imaging DICOM standard). At the moment I have three functions, to >> open an association (basically a network connection), close it, and >> send an echo request (like a ping). A test program written entirely >> in C works fine but when compiled as a module and called from Python >> I get an illegal instruction when the dcmtk function to actually open >> the association is called. I believe this function is simply opening >> a socket, connecting to a server and negotiating what flavour of the >> protocol to use. >> >> Are there things that simply can't be done in a Python module? What >> exactly is an illegal instruction? >> >> Thanks for any help, >> >> Robb >> >> _____________________________ >> Robb Brown >> Seaman Family MR Center >> Calgary, AB >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From paul at fxtech.com Thu Aug 28 14:21:46 2003 From: paul at fxtech.com (Paul Miller) Date: Thu Aug 28 14:22:03 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: <92404561-D982-11D7-B82A-000A959032C4@ucalgary.ca> References: Message-ID: <5.2.1.1.2.20030828132058.021a3cb0@cedar.he.net> >I thought you might be interested... dctk is a DICOM (medical image file >format / network protocol for those not in the know) toolkit -- file read >and write as well as network connectivity. My idea is to wrap the basic >functions in Python and then writing DICOM enabled apps is no >problem. Plus, I'm frequently annoyed by our expensive research PACS (a >medical image archiving server)... a good Python DICOM package and >existing Python database modules would let you write your own PACS in an >afternoon. Do you know what the protocols are and how they work? If so, why not just reimplement them directly in Python, and skip the library entirely? -- Paul Miller | paul@fxtech.com | Got Tivo? From Jack.Jansen at cwi.nl Fri Aug 29 00:59:08 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Aug 28 17:59:17 2003 Subject: [Pythonmac-SIG] PackageManager wishlists, please! (was: unixy python and applescript) In-Reply-To: References: Message-ID: On donderdag 28 augustus 2003, at 0:07AM, Chris Lee wrote: > Yes but then you are asking people to download another python... Not > everyone wants to have 4 versions of the same app. At the moment I > use it with Fink python because Fink is the only thing that allows me > to install scipy, Scientific and rpy and Numpy (linked to ATLAS > instead of it's own libraries) right out of the box. I don't have the > skills to make these things work myself so have no choice but to use > the Fink version. Information like this I need to make Package Manager a success: if there are packages that people want I'd love to know. Depending on a number of factors (how many people want it, is it easy, is someone willing to do the work so I only have to shove it into the database, etc) I'll add it. Hmm, this is the first time that I have a problem where having a Wiki actually seems like a solution: it would allow voting, and people who did the work before (or tried and failed) could annotate it, etc. Should we setup a Wiki for the PM wishlist? Anyone willing to do the work (in a way that I could easily incorporate into the MacPython website)? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Aug 29 01:15:37 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Aug 28 18:15:48 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: References: Message-ID: <26A3C1F6-D9A5-11D7-B899-000A27B19B96@cwi.nl> On woensdag 27 augustus 2003, at 20:12PM, Robb Brown wrote: > Anyway, here's the code. The crash is on line 104, where all the > setup is finished and I actually ask dcmtk to connect. That line looks harmless enough. A few ideas: - Try building with -O0. The crash may actually be on a different line if you've compiled with optimizing on. - How are you compiling and linking? If you're using distutils you should be fine, otherwise please send the Makefile. Actually: don't send the Makefile, but use distutils and see if the problem goes away;-) - Try building the working C++ version with the exact same libraries and defines and other compiler flags that are used for compile/link of the Python module. See if it still works. Finally, you probably know what you're doing, but the treatment of some objects strikes me as funny. For instance, the "params" structure appears to be allocated by your library (because you initialize it with "ASC_createAssociationParameters(¶ms, ASC_DEFAULTMAXPDU)", but there isn't a corresponding ASC_freeAssociationParameters() or something similar. This looks suspicious. You could examine the values of the various pointers in gdb to make sure that they make sense. Or, even better, initialize them all to NULL at function entry, so you know you'll get a segmentation violation if there's a misunderstanding about the API. -- 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 gshao1 at san.rr.com Thu Aug 28 16:32:07 2003 From: gshao1 at san.rr.com (Gary Shao) Date: Thu Aug 28 18:33:22 2003 Subject: [Pythonmac-SIG] speech support in MacPython? Message-ID: <3F4E82E7.7020807@san.rr.com> As the developer of a Python-based application suite supporting the use of Project Gutenberg e-texts that is intended to be fully cross-platform, I was wondering about the state of support for speech capabilities in MacPython. I have included some basic text-to-speech capabilities for Windows and Linux/Unix platforms, and would like to do the same for Mac OSX. Details about my project can be found here: http://pyge.sourceforge.net/ Earlier MacPython documents indicated that the macspeech module provided some basic support for the Macintosh Speech Manager, but the latest documentation I could find on MacPython does not mention any Carbon module for the Speech Manager. The documentation I am referring to is located here: http://www.python.org/doc/current/mac/mac.html My question is whether speech support has been dropped from MacPython, is still present but unfinished or undocumented, or is something that is planned to be developed at a later date? I appreciate any information I can get from participants in this list, since I don't currently have a Mac OSX platform on which to run tests. Thanks,s --Gary From brownr at ucalgary.ca Thu Aug 28 19:24:40 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Thu Aug 28 20:25:50 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: <5.2.1.1.2.20030828132058.021a3cb0@cedar.he.net> Message-ID: <2DFA5458-D9B7-11D7-B82A-000A959032C4@ucalgary.ca> Ah, if only. The DICOM specification was (is being) written by committee. It's an evil piece of work. I believe the paper specs will fill a couple of shelves by themselves. And all this was written to help reduce confusion.... On Thursday, August 28, 2003, at 12:21 PM, Paul Miller wrote: > >> I thought you might be interested... dctk is a DICOM (medical image >> file format / network protocol for those not in the know) toolkit -- >> file read and write as well as network connectivity. My idea is to >> wrap the basic functions in Python and then writing DICOM enabled >> apps is no problem. Plus, I'm frequently annoyed by our expensive >> research PACS (a medical image archiving server)... a good Python >> DICOM package and existing Python database modules would let you >> write your own PACS in an afternoon. > > Do you know what the protocols are and how they work? If so, why not > just reimplement them directly in Python, and skip the library > entirely? > > > -- > Paul Miller | paul@fxtech.com | Got Tivo? > > > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From daniel_t at earthlink.net Thu Aug 28 23:30:58 2003 From: daniel_t at earthlink.net (Daniel Tartaglia) Date: Thu Aug 28 22:31:04 2003 Subject: [Pythonmac-SIG] Closing a blocked socket? In-Reply-To: <2DFA5458-D9B7-11D7-B82A-000A959032C4@ucalgary.ca> Message-ID: The code below fails. Socket.accept blocks inside the thread and doesn't let go, even after the socket was closed. From the error presented, the socket never actually closes. I realize that the below is a basic Java idiom but how do you do the same thing in Python? I ask here because when I asked on the newsgroup I got no response, so I started thinking it was a Mac only thing... import unittest import socket import threading import time class SocketAcceptor ( threading.Thread ): def __init__( self, socket ): threading.Thread.__init__( self ) self.socket = socket self.done = 0 def run( self ): self.socket.bind( ( "", 3424 ) ) self.socket.listen( 5 ) try: child, ip = self.socket.accept() except: pass self.done = 1 class SocketTester ( unittest.TestCase ): def testClose( self ): for each in range( 4 ): ss = socket.socket() acceptor_thread = SocketAcceptor( ss ) acceptor_thread.start() time.sleep( 1 ) ss.close() time.sleep( 1 ) self.assertEquals( acceptor_thread.done, 1 ) if __name__ == '__main__': unittest.main() From Jack.Jansen at cwi.nl Fri Aug 29 14:17:41 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 29 07:17:35 2003 Subject: [Pythonmac-SIG] speech support in MacPython? In-Reply-To: <3F4E82E7.7020807@san.rr.com> Message-ID: <67F6E62E-DA12-11D7-9345-0030655234CE@cwi.nl> On Friday, August 29, 2003, at 12:32 AM, Gary Shao wrote: > As the developer of a Python-based application suite supporting the > use of > Project Gutenberg e-texts that is intended to be fully cross-platform, > I was > wondering about the state of support for speech capabilities in > MacPython. There used to be a macspeech module, but I dropped it. It was (literally!) the first Python extension module I wrote for the Macintosh, and it was rather hopelessly incomplete. With Carbon it stopped working completely, so I didn't want to spend any time on trying to fix it. There isn't any intrinsically non-Carbon about it, though, so if someone wants to revive it: be my guest. Alternatively, a bgen-based wrapper module shouldn't be too much work either. But again: I don't really have time to put into this right now. -- 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 Aug 29 14:27:10 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 29 07:27:01 2003 Subject: [Pythonmac-SIG] Closing a blocked socket? In-Reply-To: Message-ID: This sounds like it could be a bug in Python: the Python accept() method first does a select() and then the actual accept(). To confirm that this is a Python bug you could rewrite the code in C, and see how it behaves then. If the accept() does return in C then Python should take measures to make it return too (this shouldn't be to hard, fiddling the select() parameters should do it). The problem is not platform dependent, by the way: things work the same on Linux. On Friday, August 29, 2003, at 04:30 AM, Daniel Tartaglia wrote: > The code below fails. Socket.accept blocks inside the thread and > doesn't let go, even after the socket was closed. From the error > presented, the socket never actually closes. > > I realize that the below is a basic Java idiom but how do you do the > same thing in Python? I ask here because when I asked on the newsgroup > I got no response, so I started thinking it was a Mac only thing... > > import unittest > import socket > import threading > import time > > class SocketAcceptor ( threading.Thread ): > def __init__( self, socket ): > threading.Thread.__init__( self ) > self.socket = socket > self.done = 0 > > def run( self ): > self.socket.bind( ( "", 3424 ) ) > self.socket.listen( 5 ) > try: > child, ip = self.socket.accept() > except: > pass > self.done = 1 > > class SocketTester ( unittest.TestCase ): > def testClose( self ): > for each in range( 4 ): > ss = socket.socket() > acceptor_thread = SocketAcceptor( ss ) > acceptor_thread.start() > time.sleep( 1 ) > ss.close() > time.sleep( 1 ) > self.assertEquals( acceptor_thread.done, 1 ) > > if __name__ == '__main__': > unittest.main() > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- 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 brownr at ucalgary.ca Fri Aug 29 11:41:20 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Aug 29 12:42:20 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? Message-ID: <9E10A484-DA3F-11D7-8042-000A959032C4@ucalgary.ca> >> On woensdag 27 augustus 2003, at 20:12PM, Robb Brown wrote: >>> Anyway, here's the code. The crash is on line 104, where all the >>> setup is finished and I actually ask dcmtk to connect. >> >> That line looks harmless enough. > > You'd think.... How would one go about using a debugger on a Python > module (remember, the code does not crash when not compiled as a > module). I've been debugging with printf's and it was a trip down the > rabbit hole. That line winds through a couple of functions to a > finite state machine that uses a doubly linked list. The actual error > seems to be when one of the nodes in this list is deleted. I don't > know why this would be different in and out of a module. My next step > is to try running it as an executable to see how it SHOULD work. > > >> A few ideas: >> - Try building with -O0. The crash may actually be on a different line >> if you've compiled with optimizing on. >> - How are you compiling and linking? If you're using distutils you >> should be >> fine, otherwise please send the Makefile. Actually: don't send the >> Makefile, >> but use distutils and see if the problem goes away;-) >> - Try building the working C++ version with the exact same libraries >> and defines and other compiler flags that are used for compile/link >> of the Python module. See if it still works. >> >> Finally, you probably know what you're doing, but the treatment >> of some objects strikes me as funny. For instance, the "params" >> structure appears to be allocated by your library (because you >> initialize >> it with "ASC_createAssociationParameters(¶ms, ASC_DEFAULTMAXPDU)", >> but there isn't a corresponding ASC_freeAssociationParameters() or >> something >> similar. This looks suspicious. You could examine the values of the >> various pointers in gdb to make sure that they make sense. Or, even >> better, >> initialize them all to NULL at function entry, so you know you'll get >> a segmentation >> violation if there's a misunderstanding about the API. >> -- >> Jack Jansen, , http://www.cwi.nl/~jack >> If I can't dance I don't want to be part of your revolution -- Emma >> Goldman >> >> _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From Jack.Jansen at cwi.nl Sat Aug 30 00:11:37 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Aug 29 17:12:47 2003 Subject: [Pythonmac-SIG] Restrictions on what you can do in a Python module? In-Reply-To: <3952E79A-DA3F-11D7-8042-000A959032C4@ucalgary.ca> References: <3952E79A-DA3F-11D7-8042-000A959032C4@ucalgary.ca> Message-ID: <606DBB6D-DA65-11D7-AD2E-000A27B19B96@cwi.nl> On 29-aug-03, at 18:38, Robb Brown wrote: >> On woensdag 27 augustus 2003, at 20:12PM, Robb Brown wrote: >>> Anyway, here's the code. The crash is on line 104, where all the >>> setup is finished and I actually ask dcmtk to connect. >> >> That line looks harmless enough. > > You'd think.... How would one go about using a debugger on a Python > module (remember, the code does not crash when not compiled as a > module). What I tend to do is as follows: % gdb python ..... (gdb) run ..... >>> import themoduletodebug >>> control-C (gdb) break thefunctioninthemodulethatIwanttosee (gdb) continue >>> do_something_that_calls_that_function Then gdb should break on the function, and you can start single-stepping, etc. Again, let me emphasize that -O0 is required if you want to keep your sanity. gcc moves code all over the place without it. -- 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 dev_python at impactdev.com Fri Aug 29 19:13:24 2003 From: dev_python at impactdev.com (Python Development) Date: Fri Aug 29 21:13:31 2003 Subject: [Pythonmac-SIG] Gordon McMillan's installer question for the Mac Message-ID: <272B8B98-DA87-11D7-B8CB-00306578E9DA@impactdev.com> Hi, Currently in our PC product, the Gordon McMillan wrapper is ran within a thread, while the other thread runs the UI. On the Mac, we had some problems with that, so we are thinking of having the UI in one process, while the wrapper app is running along side as a second process. So on the PC there is one process running two threads, and on the Mac their will be two processes running each one thread and communicating between each process other with unix sockets on the local machine. But before we went any further in the design work and time, I am checking here to see if it is going to be possible or if others have tried but failed a two process approach. I have asked Gordon McMillan, but he has not done anything with the Mac since OS 8/9. Our current product is for OS X, with an objective-C UI. And just so you know, I am having to go this way because this is an 80% PC market solution. Thank you for your time, Randy From gandreas at delver.com Sat Aug 30 10:43:16 2003 From: gandreas at delver.com (Glenn Andreas) Date: Sat Aug 30 10:43:33 2003 Subject: [Pythonmac-SIG] Licensing issues Message-ID: So I'm getting closer to the next release of PyOXIDE, which will have full source available. It is broken into two parts: IDEKit.framework, and PyOXIDE itself. The framework is a reusable framework that handles running the editors (syntax coloring, language support, split panes, macro expansion/completion, etc...), provides preference settings, has infrastructure for "projects" (grouped listings of files, file orders, multiple targets), and various other little things. The PyOXIDE code is mostly a shim between IDEKit.framework and the underlying python code, as well as some refinements on IDEKit.framework (for example, there are no "headers" to provide a popup header function, and it only supports python). The plan was to have IDEKit.framework handled much like MySQL - released under (L)GPL, and any software that is released under GPL (or compatible OSI license) can use it for free, with a commercial license available for everybody else. The intent here is that there is a lot of work in this thing, and I don't mind sharing, but I'm not too keen on somebody else making a buck off of my work without me getting something in return. The PyOXIDE part will be either GPL or BSD. So the question is, if PyOXIDE is to aspire to become the standard MacPython IDE (which seems like a good thing), and possibly even allow for Apple to include in some post-panther cat, will this work? Jack mentioned that GPL might be a no-no for standard distribution, though fine for developer stuff. Anybody have any ideas/insights/opinions on this? -- Glenn Andreas gandreas@delver.com Author of Macintosh games: Theldrow 2.3, Blobbo 1.0.2, Cythera 1.0.2 Be good, and you will be lonesome From Jack.Jansen at cwi.nl Sun Aug 31 01:25:09 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Aug 30 18:25:16 2003 Subject: [Pythonmac-SIG] Gordon McMillan's installer question for the Mac In-Reply-To: <272B8B98-DA87-11D7-B8CB-00306578E9DA@impactdev.com> References: <272B8B98-DA87-11D7-B8CB-00306578E9DA@impactdev.com> Message-ID: On 30-aug-03, at 3:13, Python Development wrote: > Hi, > > Currently in our PC product, the Gordon McMillan wrapper is ran within > a thread, while the other thread runs the UI. On the Mac, we had some > problems with that, [...] Randy, what I only realised after reading your message for the second time is that it could make a difference *which* thread runs the UI. On MacOSX it *must* be the main thread that runs the UI. As far as I know this is true for all (non-X11) UI libraries on the Mac, it has something to do with the way Mach threads are handled. -- 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 dev_python at impactdev.com Sat Aug 30 20:40:58 2003 From: dev_python at impactdev.com (Python Development) Date: Sat Aug 30 22:41:04 2003 Subject: [Pythonmac-SIG] Re: Gordon McMillan's installer question for the Mac (take 2) In-Reply-To: Message-ID: <8D6ADC4C-DB5C-11D7-9A36-00306578E9DA@impactdev.com> We have bigger issues than threading.... We need to be able to communicate outside the McMillan installer. Gordon states that you can not. I need to either use local UNIX sockets or a NSDistributedNotificationCenter to hook up to the UI running as a different process. Has anyone been able to communicate outside the McMillan installer using local UNIX sockets or a cfmessageport or even a NSDistributedNotificationCenter?? On Saturday, August 30, 2003, at 03:25 PM, Jack Jansen wrote: > > On 30-aug-03, at 3:13, Python Development wrote: > >> Hi, >> >> Currently in our PC product, the Gordon McMillan wrapper is ran >> within a thread, while the other thread runs the UI. On the Mac, we >> had some problems with that, > [...] > > Randy, > what I only realised after reading your message for the second time is > that it could > make a difference *which* thread runs the UI. On MacOSX it *must* be > the main thread > that runs the UI. As far as I know this is true for all (non-X11) UI > libraries > on the Mac, it has something to do with the way Mach threads are > handled. > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > Randy Chapel Mac, Window, Unix, Palm, Internet and Java engineering www.chapelhome.com, www.impactdev.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1447 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20030830/ac261632/attachment.bin