From pecora@anvil.nrl.navy.mil Tue Apr 2 21:15:23 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Tue, 2 Apr 2002 16:15:23 -0500 Subject: [Pythonmac-SIG] Console input in the IDE? Message-ID: I'd like to avoid that awful Input window in the IDE that comes up whenever I call raw_input(). It comes to the front, covering part of the output window (which often has things I'd like to look at), it's immovable, and it pops up over Piddle plots I've done so I can't see part of them or close them or whatever. It just takes over. I thought there might be a way to use the "Interactive" window as a console, but I haven't figured that out. Doing a cmd-R is very nice, but is there a way to input like a console tty window rather than the special input window? Any help appreciated. -- Lou Pecora P.S. Apologies to whomever did the input window in the IDE (Jack? Sorry.). I'm sure you spent some time coding it and I don't mean to be nasty, but it's making it hard for me to use my program interactively and still display things, copy Piddle graphics, etc. -- Cheers, Lou Pecora From pecora@anvil.nrl.navy.mil Tue Apr 2 21:23:20 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Tue, 2 Apr 2002 16:23:20 -0500 Subject: [Pythonmac-SIG] Running Piddle on Interpreter with QD?? Message-ID: When I run a program that uses the Quickdraw backend of Piddle on the Int= erpreter I get a resource error: Traceback (most recent call last): File "Drive:Code =9F:python =9F:plotwindow:plotwindow.py", line 2, in ? from piddleQD import * # The graphics engine File "Drive:Applications =9F:Python 2.2:Lib:site-packages:piddle:piddle= QD.py", line 45, in ? import W File "Drive:Applications =9F:Python 2.2:Mac:Tools:IDE:W.py", line 5, in= ? from Wbase import * File "Drive:Applications =9F:Python 2.2:Mac:Tools:IDE:Wbase.py", line 6= 98, in ? _cursors =3D { MacOS.Error: (-192, 'Resource not found') I saw this a year ago when I tried this, but I can't remember what's up. = Something about the cursors, but I'm not sure what to do. Any hints? P.S. The program runs fine in the IDE. Plots nice stuff. --=20 Cheers, Lou Pecora From footrot@mac.com Tue Apr 2 21:29:33 2002 From: footrot@mac.com (Matthew Smith) Date: Wed, 03 Apr 2002 07:29:33 +1000 Subject: [Pythonmac-SIG] Using python with Cocoa on OSX Message-ID: Hello, I was wondering if you could point me in the direction of some docs or examples on using python with project builder and preferably cocoa (though if the only way is with C or C++ it won't matter)... I'm working on an OSX program that uses python to do most of it's work, and I'd like to use Cocoa for my GUI. I have compiled the python framework but have no clue how to go about using it... Any hints, docs or examples you guys could pass on would be great, Cheers Matthew Smith From Jack.Jansen@oratrix.com Tue Apr 2 21:56:45 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 2 Apr 2002 23:56:45 +0200 Subject: [Pythonmac-SIG] Looking for a sponsor Message-ID: <85FA7BBC-4684-11D6-920D-003065517236@oratrix.com> Folks, I'm looking for a sponsor. Specifically: I'm looking for someone to sponsor my Apple Select membership which ran out yesterday, and which I've come to really appreciate over the last two years: it gives me access to the latest MacOS releases and lots of other goodies that are a great boost for MacPython and MachoPython development. With Oratrix having put Mac development on hold for the time being, and given the current lean-and-mean times I cannot justify having the company pay for this. And I've already paid for CodeWarrior 7 out of my own pocket, so another $500 for something that has a grand total of $0 on the income side isn't very attractive.... -- - 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@oratrix.com Tue Apr 2 22:05:01 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 3 Apr 2002 00:05:01 +0200 Subject: [Pythonmac-SIG] Fwd: Apple Design Awards Update: Open Source Category In-Reply-To: Message-ID: On vrijdag, februari 22, 2002, at 10:43 , Jack Jansen wrote: > Folks, > Apple have just added a category "best open source product" to > their yearly design awards. > How about giving it a go and trying to win that award with Python? This isn't going to happen. At least: not this year. Why not, you may wonder? A number of reasons: - the amount of help I got offered here on pythonmac-sig wasn't exactly staggering. It did trigger a couple of people to work on Cocoa-Python, but that was about it. - The timing of Python 2.2.1 has been delayed. I was hoping to use Python 2.2.1 for the core, plus the CVS head (Python 2.3a0) for the Mac portion, plus the universal newlines patch (also not accepted yet) as the basis for this. But with no Python 2.2.1 for another week this would mean basing a release for which we want a lot of visibility on a lot of unproven technology (all of it, in fact;-). - There are still a lot of open ends: I never got a pointer the the Applescript Studio stuff, integrating the documentation with the IDE hasn't been done yet, there's no installer and I don't know yet how to make one, and many many more. But: I'll try and continue on the path I'm on and get these worked out so we can do an all-singing-all-dancing MacOSX distribution for 2.3 (or maybe earlier). So: help is still requested in the areas listed above! -- - 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@oratrix.com Tue Apr 2 22:08:34 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 3 Apr 2002 00:08:34 +0200 Subject: [Pythonmac-SIG] Running Piddle on Interpreter with QD?? In-Reply-To: Message-ID: <2C98D69C-4686-11D6-920D-003065517236@oratrix.com> On dinsdag, april 2, 2002, at 11:23 , Louis M. Pecora wrote: > When I run a program that uses the Quickdraw backend of Piddle=20 > on the Interpreter I get a resource error: > > Traceback (most recent call last): > File "Drive:Code =9F:python =9F:plotwindow:plotwindow.py", line=20 > 2, in ? > from piddleQD import * # The graphics engine > File "Drive:Applications =9F:Python 2.2:Lib:site- > packages:piddle:piddleQD.py", line 45, in ? > import W > File "Drive:Applications =9F:Python 2.2:Mac:Tools:IDE:W.py",=20 > line 5, in ? > from Wbase import * > File "Drive:Applications =9F:Python=20 > 2.2:Mac:Tools:IDE:Wbase.py", line 698, in ? > _cursors =3D { > MacOS.Error: (-192, 'Resource not found') If you use W outside of the IDE you must make sure that you have=20 it's resource file (:Mac:Tools:IDE:Widgets.rsrc) open. Hmm, coming to think of it: W can take care of this itself since=20 we have the macresource module. Just? -- - Jack Jansen =20 http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution --=20 Emma Goldman - From seanh@real.com Tue Apr 2 22:11:16 2002 From: seanh@real.com (Sean Hummel) Date: Tue, 2 Apr 2002 14:11:16 -0800 (PST) Subject: [Pythonmac-SIG] Looking for a sponsor In-Reply-To: <85FA7BBC-4684-11D6-920D-003065517236@oratrix.com> Message-ID: Well Jack, I can't afford that kind of money for that either. Do you perhaps have a PayPal account? We could all send you a small amount via PayPal, I for one appreciate your efforts over the years, and would love to be able to give something back. On Tue, 2 Apr 2002, Jack Jansen wrote: > Folks, > I'm looking for a sponsor. Specifically: I'm looking for someone > to sponsor my Apple Select membership which ran out yesterday, > and which I've come to really appreciate over the last two > years: it gives me access to the latest MacOS releases and lots > of other goodies that are a great boost for MacPython and > MachoPython development. > > With Oratrix having put Mac development on hold for the time > being, and given the current lean-and-mean times I cannot > justify having the company pay for this. And I've already paid > for CodeWarrior 7 out of my own pocket, so another $500 for > something that has a grand total of $0 on the income side isn't > very attractive.... > -- > - 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 jacobkm@cats.ucsc.edu Tue Apr 2 22:36:55 2002 From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss) Date: Tue, 2 Apr 2002 14:36:55 -0800 Subject: [Pythonmac-SIG] Looking for a sponsor In-Reply-To: References: Message-ID: I agree. I couldn't afford $500 any more than you can, but $25 or $50 wouldn't be a problem at all, and if twenty people each donate $25, we could keep your membership going. Why don't you set up a tip jar and make an announcement about it -- it can't hurt to try. Also, could you try getting in touch with Apple and asking them to cut you a deal, seeing how you are doing them a service by providing tools with which to develop mac software? Jacob At 2:11 PM -0800 4/2/02, Sean Hummel wrote: >Well Jack, I can't afford that kind of money for that either. Do you >perhaps have a PayPal account? We could all send you a small amount via >PayPal, I for one appreciate your efforts over the years, and would love >to be able to give something back. > >On Tue, 2 Apr 2002, Jack Jansen wrote: > >> Folks, >> I'm looking for a sponsor. Specifically: I'm looking for someone >> to sponsor my Apple Select membership which ran out yesterday, >> and which I've come to really appreciate over the last two >> years: it gives me access to the latest MacOS releases and lots >> of other goodies that are a great boost for MacPython and >> MachoPython development. >> >> With Oratrix having put Mac development on hold for the time >> being, and given the current lean-and-mean times I cannot >> justify having the company pay for this. And I've already paid >> for CodeWarrior 7 out of my own pocket, so another $500 for >> something that has a grand total of $0 on the income side isn't >> very attractive.... >> -- >> - 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 >> >> > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig From pecora@anvil.nrl.navy.mil Tue Apr 2 22:47:02 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Tue, 2 Apr 2002 17:47:02 -0500 Subject: [Pythonmac-SIG] Looking for a sponsor In-Reply-To: References: Message-ID: > >Well Jack, I can't afford that kind of money for that either. Do you >perhaps have a PayPal account? We could all send you a small amount via >PayPal, I for one appreciate your efforts over the years, and would love >to be able to give something back. Now there's a great idea. If that can be done, let me know how to contribute. -- Cheers, Lou Pecora From dennisstanley@mac.com Wed Apr 3 00:56:52 2002 From: dennisstanley@mac.com (Dennis Stanley) Date: Tue, 2 Apr 2002 19:56:52 -0500 Subject: [Pythonmac-SIG] (no subject) Message-ID: From stefan.witzgall@online.de Wed Apr 3 08:12:04 2002 From: stefan.witzgall@online.de (Stefan Witzgall) Date: Wed, 3 Apr 2002 10:12:04 +0200 Subject: [Pythonmac-SIG] Looking for a sponsor In-Reply-To: <85FA7BBC-4684-11D6-920D-003065517236@oratrix.com> Message-ID: Hi Jack, >Folks, >I'm looking for a sponsor. Specifically: I'm looking for someone >to sponsor my Apple Select membership which ran out yesterday, >and which I've come to really appreciate over the last two >years: it gives me access to the latest MacOS releases and lots I would denote 25 Euro to keep your work on rolling. Could you please tell me whether it is possible to tranfer this amount via a normal bank account? It should not be a great affair, because, if I see right, ... >- Jack Jansen >http://www.cwi.nl/~jack - ... we are both in Europe. Stefan From gherman@darwin.in-berlin.de Wed Apr 3 08:29:17 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 03 Apr 2002 10:29:17 +0200 (CEST) Subject: [Pythonmac-SIG] Looking for a sponsor In-Reply-To: <85FA7BBC-4684-11D6-920D-003065517236@oratrix.com> References: <85FA7BBC-4684-11D6-920D-003065517236@oratrix.com> Message-ID: <1017822557.3caabd5d3d87c@webmail.in-berlin.de> Jack Jansen : > Folks, > I'm looking for a sponsor. Specifically: I'm looking for someone > to sponsor my Apple Select membership which ran out yesterday, > and which I've come to really appreciate over the last two > years: it gives me access to the latest MacOS releases and lots > of other goodies that are a great boost for MacPython and > MachoPython development. > > With Oratrix having put Mac development on hold for the time > being, and given the current lean-and-mean times I cannot > justify having the company pay for this. And I've already paid > for CodeWarrior 7 out of my own pocket, so another $500 for > something that has a grand total of $0 on the income side isn't > very attractive.... > -- > - Jack Jansen Jack, I'm sure you can collect the amount you need and I'm willing to contribute to it. Just indicate somehow your preferred way of accepting payments, please! Regards, Dinu From lists@netelligent.biz Wed Apr 3 08:39:24 2002 From: lists@netelligent.biz (tmk) Date: Wed, 3 Apr 2002 10:39:24 +0200 Subject: [Pythonmac-SIG] Fwd: Apple Design Awards Update: Open Source Category In-Reply-To: Message-ID: <4D6E4F0A-46DE-11D6-B0FA-003065C18BA0@netelligent.biz> Yo, On Wednesday, April 3, 2002, at 12:05 AM, Jack Jansen wrote: [snip] > > - There are still a lot of open ends: I never got a pointer the > the Applescript Studio stuff, integrating the documentation with > the IDE hasn't been done yet, there's no installer and I don't > know yet how to make one, and many many more. > > But: I'll try and continue on the path I'm on and get these worked > out so we can do an all-singing-all-dancing MacOSX distribution > for 2.3 (or maybe earlier). So: help is still requested in the > areas listed above! I may be able to help re: integrating the documentation with the IDE. Is there some kind of blueprint as to how this should be done? = tmk = > -- > - 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 footrot@mac.com Wed Apr 3 09:14:22 2002 From: footrot@mac.com (Matthew Smith) Date: Wed, 03 Apr 2002 19:14:22 +1000 Subject: [Pythonmac-SIG] Using python with Cocoa on OSX In-Reply-To: Message-ID: > Hi Matthew, > > Here is what I am working on because Mac OS X GUI is a real problem that > does not look to solved soon. My concept which I have done a little > with is to split the application into two applications, the GUI (Cocoa > via Interface Builder and Project Builder) and the logic (Python) which > communicate via sockets. Since in a good design there is little > coupling between these two portions this makes good sense and only a > small amount of code need be written on each side to interface with the > socket. Right, I'll have a look at how to create sockets in both python and c. So there is no way at all to access python through project builder? Not even as a simple C app? Thanks, Matthew Smith From estechmann@advresp.com Wed Apr 3 13:41:36 2002 From: estechmann@advresp.com (Eric Stechmann) Date: Wed, 03 Apr 2002 07:41:36 -0600 Subject: [Pythonmac-SIG] Looking for a sponsor In-Reply-To: <85FA7BBC-4684-11D6-920D-003065517236@oratrix.com> Message-ID: <5.1.0.14.0.20020403073815.037432a0@abicomm2.abivest.com> At 11:56 PM 4/2/02 +0200, you wrote: >Folks, >I'm looking for a sponsor. I concur with others comments and can donate to the cause. Let us know how it can be done. -------------------------------------------------------------------------- Eric Stechmann Direct: +1 (651) 234-1217 Software Critter Fax: +1 (651) 490-1484 Advanced Respiratory, Inc. E-mail: estechmann@advresp.com 1020 West County Road F URL: www.thevest.com St.Paul MN 55126 -------------------------------------------------------------------------- These opinions are mine and not necessarily those of my employer. From just@letterror.com Wed Apr 3 07:17:08 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 3 Apr 2002 09:17:08 +0200 Subject: [Pythonmac-SIG] Running Piddle on Interpreter with QD?? In-Reply-To: <2C98D69C-4686-11D6-920D-003065517236@oratrix.com> Message-ID: <20020403161921-r01010800-c6824e75-0920-010c@10.0.0.23> Jack Jansen wrote: > If you use W outside of the IDE you must make sure that you have > it's resource file (:Mac:Tools:IDE:Widgets.rsrc) open. Yup. > Hmm, coming to think of it: W can take care of this itself since > we have the macresource module. Just? Not sure what you mean by this? On the other hand we could get rid of that res file entirely: the cursor data could be hardcoded in the source and the other resources are either obsolete (2 LDEFs) or not always neccesary (arrow icons for the object browser). Just From just@letterror.com Wed Apr 3 07:27:57 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 3 Apr 2002 09:27:57 +0200 Subject: [Pythonmac-SIG] Console input in the IDE? In-Reply-To: Message-ID: <20020403161919-r01010800-14c1e53b-0920-010c@10.0.0.23> Louis M. Pecora wrote: > I'd like to avoid that awful Input window in the IDE that comes up whenever I > call raw_input(). It comes to the front, covering part of the output window > (which often has things I'd like to look at), it's immovable, and it pops up > over Piddle plots I've done so I can't see part of them or close them or > whatever. It just takes over. I thought there might be a way to use the > "Interactive" window as a console, but I haven't figured that out. Doing a > cmd-R is very nice, but is there a way to input like a console tty window > rather than the special input window? Any help appreciated. > > -- Lou Pecora > > P.S. Apologies to whomever did the input window in the IDE (Jack? Sorry.). > I'm sure you spent some time coding it and I don't mean to be nasty, but it's > making it hard for me to use my program interactively and still display > things, copy Piddle graphics, etc. It was probably me, but then again, I'm not sure. Whoever it did didn't spend all that much time on it. I honestly don't care about both that window and raw_input() working nicely. The whole concept of raw_input() simply doesn't work well with a GUI app. Yeah, the input dialog is awful, but the only goal was for raw_input() to not blow up. To do _something_. It should be possible to use the interactive window instead, but it isn't completely trivial, and I'm definitely not going to do it... Just From R.Niemeijer@NiemConsult.com Wed Apr 3 16:10:35 2002 From: R.Niemeijer@NiemConsult.com (Rudo Niemeijer) Date: Wed, 3 Apr 2002 18:10:35 +0200 Subject: [Pythonmac-SIG] Apple select mebership Message-ID: At 9:22 AM -0500 4/3/02, Jack Jansen wrote: >Folks, >I'm looking for a sponsor. Specifically: I'm looking for someone to >sponsor my Apple Select membership which ran out yesterday, and >which I've come to really appreciate over the last two years: it >gives me access to the latest MacOS releases and lots of other >goodies that are a great boost for MacPython and MachoPython >development. I have been a silent reader till now. But let me join the chorus: let us have your bank account details and I will be glad to join in. -- Rudo Niemeijer +31 3560 33287 (tel) Niemeijer Consult +31 3560 28120 (fax) R.Niemeijer@NiemConsult.com (e-mail) http://www.niemconsult.com/ From fgranger@mac.com Wed Apr 3 18:57:47 2002 From: fgranger@mac.com (=?iso-8859-1?Q?Fran=E7ois?= Granger) Date: Wed, 3 Apr 2002 20:57:47 +0200 Subject: [Pythonmac-SIG] Looking for a sponsor In-Reply-To: <5.1.0.14.0.20020403073815.037432a0@abicomm2.abivest.com> References: <5.1.0.14.0.20020403073815.037432a0@abicomm2.abivest.com> Message-ID: At 7:41 -0600 3/04/02, in message Re: [Pythonmac-SIG] Looking for a sponsor, Eric Stechmann wrote: >At 11:56 PM 4/2/02 +0200, you wrote: >>Folks, >>I'm looking for a sponsor. > >I concur with others comments and can donate to the cause. Let us >know how it can be done. Me too ;-) -- =46ran=E7ois Granger fgranger@mac.com From pecora@anvil.nrl.navy.mil Wed Apr 3 19:40:12 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Wed, 3 Apr 2002 14:40:12 -0500 Subject: [Pythonmac-SIG] Running Piddle on Interpreter with QD?? In-Reply-To: <20020403161921-r01010800-c6824e75-0920-010c@10.0.0.23> References: <20020403161921-r01010800-c6824e75-0920-010c@10.0.0.23> Message-ID: >Jack: > > If you use W outside of the IDE you must make sure that you have >> it's resource file (:Mac:Tools:IDE:Widgets.rsrc) open. Just: >Yup. Me: But how do I do that? -- Cheers, Lou Pecora From Jack.Jansen@oratrix.com Wed Apr 3 19:51:01 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 3 Apr 2002 21:51:01 +0200 Subject: [Pythonmac-SIG] Running Piddle on Interpreter with QD?? In-Reply-To: <20020403161921-r01010800-c6824e75-0920-010c@10.0.0.23> Message-ID: <20308D50-473C-11D6-8037-003065517236@oratrix.com> On woensdag, april 3, 2002, at 09:17 , Just van Rossum wrote: >> Hmm, coming to think of it: W can take care of this itself since >> we have the macresource module. Just? > > Not sure what you mean by this? In the W init code we could put a macresource.need() call, which would locate the resource file and open it, but only if a given test resource isn't available already (as it would be when running as an applet). I'll have a look at 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@oratrix.com Wed Apr 3 21:36:19 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 3 Apr 2002 23:36:19 +0200 Subject: [Pythonmac-SIG] Running Piddle on Interpreter with QD?? In-Reply-To: <20020403161921-r01010800-c6824e75-0920-010c@10.0.0.23> Message-ID: On woensdag, april 3, 2002, at 09:17 , Just van Rossum wrote: > Jack Jansen wrote: > >> If you use W outside of the IDE you must make sure that you have >> it's resource file (:Mac:Tools:IDE:Widgets.rsrc) open. > > Yup. > >> Hmm, coming to think of it: W can take care of this itself since >> we have the macresource module. Just? > > Not sure what you mean by this? Louis, it turns out to be very simple, add the two lines import macresource macresource.need('CURS', 468, "Widgets.rsrc") to the very top of Wapplication.Application.__init__ (before the "import W"). Or check out the current CVS version (which is slightly different but equivalent). -- - 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 pecora@anvil.nrl.navy.mil Thu Apr 4 16:17:32 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Thu, 4 Apr 2002 11:17:32 -0500 Subject: [Pythonmac-SIG] Help running Piddle in Interpreter on a Mac Message-ID: Whenever I try to use Piddle plotting in the Python Interpreter I get the following message: Traceback (most recent call last): File "Drive:Applications:Python 2.2:Lib:site-packages:piddletest.py", line 398, in ? mainLoop() File "Drive:Applications:Python 2.2:Lib:site-packages:piddletest.py", line 392, in mainLoop() runtest(backends[backend], tests[test]) File "Drive:Applications:Python 2.2:Lib:site-packages:piddletest.py", line 329, in runtest canvas = testfunc(canvasClass) File "Drive:Applications:Python 2.2:Lib:site-packages:piddletest.py", line 20, in minimal canvas = canvasClass(pagesizes.A6, "testA") # A6 is a quarter page File "Drive:Applications:Python 2.2:Lib:site-packages:piddle:piddleQD.py", line 166, in __init__ self._window = _QDCanvasWindow(self, size, name) File "Drive:Applications:Python 2.2:Lib:site-packages:piddle:piddleQD.py", line 91, in __init__ W.Window.__init__(self, size, title) File "Drive:Applications:Python 2.2:Mac:Tools:IDE:Wwindows.py", line 19, in __init__ fontsettings = W.getdefaultfont() File "Drive:Applications:Python 2.2:Mac:Tools:IDE:W.py", line 28, in getdefaultfont prefs = getapplication().getprefs() File "Drive:Applications:Python 2.2:Mac:Tools:IDE:W.py", line 24, in getapplication raise WidgetsError, 'W not properly initialized: unknown Application' Wbase.WidgetsError: W not properly initialized: unknown Application Exception exceptions.AttributeError: "QDCanvas instance has no attribute 'picture'" in > ignored "Drive" is my HD name and Python is kept in the "Applications" folder. This problem happens even with the original piddletest.py module which works ok until attempting to open a plot window -- meaning I don't get far. Then I get the above msg. I am running Python 2.2 on a Macintosh G4, system 9.1. Same problem on my G3 and PB. Anyone have success in getting Piddle to work with the Interpreter on a Mac? Any help appreciated. -- Cheers, Lou Pecora From p.oberndoerfer@urheberrecht.org Thu Apr 4 17:03:52 2002 From: p.oberndoerfer@urheberrecht.org (Pascal Oberndoerfer) Date: Thu, 04 Apr 2002 19:03:52 +0200 Subject: [Pythonmac-SIG] Looking for a sponsor In-Reply-To: Message-ID: Am 04.04.2002 19:00 Uhr schrieb pythonmac-sig-request@python.org : > At 7:41 -0600 3/04/02, in message Re: [Pythonmac-SIG] Looking for a > sponsor, Eric Stechmann wrote: >> At 11:56 PM 4/2/02 +0200, you wrote: >>> Folks, >>> I'm looking for a sponsor. >> >> I concur with others comments and can donate to the cause. Let us >> know how it can be done. > > Me too Yes, please. Pascal From Pieter.Claerhout@Creo.com Thu Apr 4 22:18:05 2002 From: Pieter.Claerhout@Creo.com (Pieter Claerhout) Date: Fri, 5 Apr 2002 00:18:05 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application Message-ID: <490316A24CC5D411ACD700B0D078F7F0020A5900@cseexch01.cse.creoscitex.com> Hi all, I'm trying to wrap the module xmlrpclibServer, which is downloadable from http://mrken.net/code/xml-rpc/xmlrpcServer.py. The most simple thing of course is to just use the BuildApplication utility to make a standalone version of it, and you're done. Unfortunately, I want to add an about box, and I also want to add the menu File with the option Quit. I got so far that I came up with the following piece of code: import threading import FrameWork import EasyDialogs import xmlrpcServer class DaemonMac(FrameWork.Application): def __init__(self): FrameWork.Application.__init__(self) self.MyRPCServer = threading.Thread(target=xmlrpcServer._main) self.MyRPCServer.start() self.mainloop() def makeusermenus(self): self.filemenu = m = FrameWork.Menu(self.menubar, "File") self.quititem = FrameWork.MenuItem(m, "Quit", "Q", self.quit) def quit(self, *args): self._quit() if __name__ == '__main__': DaemonMac() I tried to use the threading module to start the XML RPC server in a different thread (xmlrpcServer itself also is a threaded piece of code), but that seems to conflict with the mainloop. If you start this application, it starts the thread, starts the mainloop and stays in there, once you finish the mainloop, the thread continues. Is there an easy way to wrap Python scripts like this in a macintosh application? If not, what options should I look at? If so, how should I do it? My guess is that I should hack it somewhere in the mainloop, but I'm not sure how and I don't know where I should start looking. Hope someone can help here. Thanks, Pieter From seanh@real.com Fri Apr 5 01:22:22 2002 From: seanh@real.com (Sean Hummel) Date: Thu, 4 Apr 2002 17:22:22 -0800 (PST) Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: <490316A24CC5D411ACD700B0D078F7F0020A5900@cseexch01.cse.creoscitex.com> Message-ID: Well the first thing I would do, would be to check the version of threading for Python, you have compiled in. If the the Threading module is using the built-in thread model, (weren't they called micro-threads?,) then this would be something I could really see happening. If you use Apple's Development tools, (I can't remember the name of the specific tool,) there is a tool which lets you look at the threads running in a current task. You should use that and see what's running. On Fri, 5 Apr 2002, Pieter Claerhout wrote: > Hi all, > > I'm trying to wrap the module xmlrpclibServer, which is downloadable from > http://mrken.net/code/xml-rpc/xmlrpcServer.py. The most simple thing of > course is to just use the BuildApplication utility to make a standalone > version of it, and you're done. > > Unfortunately, I want to add an about box, and I also want to add the menu > File with the option Quit. I got so far that I came up with the following > piece of code: > > > import threading > import FrameWork > import EasyDialogs > import xmlrpcServer > > class DaemonMac(FrameWork.Application): > > def __init__(self): > FrameWork.Application.__init__(self) > self.MyRPCServer = threading.Thread(target=xmlrpcServer._main) > self.MyRPCServer.start() > self.mainloop() > > def makeusermenus(self): > self.filemenu = m = FrameWork.Menu(self.menubar, "File") > self.quititem = FrameWork.MenuItem(m, "Quit", "Q", self.quit) > > def quit(self, *args): > self._quit() > > if __name__ == '__main__': > DaemonMac() > > > I tried to use the threading module to start the XML RPC server in a > different thread (xmlrpcServer itself also is a threaded piece of code), but > that seems to conflict with the mainloop. If you start this application, it > starts the thread, starts the mainloop and stays in there, once you finish > the mainloop, the thread continues. > > Is there an easy way to wrap Python scripts like this in a macintosh > application? If not, what options should I look at? If so, how should I do > it? My guess is that I should hack it somewhere in the mainloop, but I'm not > sure how and I don't know where I should start looking. > > Hope someone can help here. > > Thanks, > > > > Pieter > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From heiko_hartmann@bigfoot.de Fri Apr 5 09:08:19 2002 From: heiko_hartmann@bigfoot.de (Heiko Hartmann) Date: Fri, 05 Apr 2002 11:08:19 +0200 Subject: [Pythonmac-SIG] Strange import error with pygame Message-ID: I downloaded the binary pygame 1.1 distribution and then tried to start some of the sample programs (inputbox.py) and then I get the following error: Traceback (most recent call last): File "Macintosh HD:Applications (Mac OS 9):Python 2.2:Mac:pygame:inputbox.py", line 29, in ? import pygame, pygame.font, pygame.event, pygame.draw, string File "Macintosh HD:Applications (Mac OS 9):Python 2.2:Extensions:pygame:__init__.py", line 27, in ? from pygame.base import * ImportError: PythonCoreCarbon: An import library was too new for a client. Does anybody know what this error means? What do I have to do now? Ciao, Heiko. From tony@metanet.com Fri Apr 5 15:29:56 2002 From: tony@metanet.com (Tony Lownds) Date: Fri, 5 Apr 2002 07:29:56 -0800 Subject: [Pythonmac-SIG] Looking for a sponsor In-Reply-To: References: Message-ID: I'm in! Perhaps the US-based folks could PayPal their money to one person here and then that person could send an aggregated check to Jack. -Tony At 7:03 PM +0200 4/4/02, Pascal Oberndoerfer wrote: >Am 04.04.2002 19:00 Uhr schrieb pythonmac-sig-request@python.org >: > >> At 7:41 -0600 3/04/02, in message Re: [Pythonmac-SIG] Looking for a >> sponsor, Eric Stechmann wrote: >>> At 11:56 PM 4/2/02 +0200, you wrote: >>>> Folks, >>>> I'm looking for a sponsor. >>> >>> I concur with others comments and can donate to the cause. Let us >>> know how it can be done. >> >> Me too > >Yes, please. > >Pascal > > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- From tony@metanet.com Fri Apr 5 17:10:02 2002 From: tony@metanet.com (Tony Lownds) Date: Fri, 5 Apr 2002 09:10:02 -0800 Subject: [Pythonmac-SIG] Tkinter for Carbon timetable? In-Reply-To: <8A3404FD-435E-11D6-91A0-003065517236@oratrix.com> References: <8A3404FD-435E-11D6-91A0-003065517236@oratrix.com> Message-ID: >Yes, Tkinter works fine with AquaTk in MachoPython (how's that for >buzzwords:-). Somewhere in the pythonmac-sig archives you'll find a >set of instructions for how to get it to work. AquaTk has been updated since those archived instructions were written. Here are new instructions, also at http://tony.lownds.com/macosx/tkinter.html Rough notes on getting Tkinter+MachoPython to work 1. Download the latest Mac OS X Tk Snapshot from the Tcl/Tk Project File List. http://sourceforge.net/project/showfiles.php?group_id=10894 2. Untar that file: sudo tar -zxf MacOSXTk8.4a4-2.tar.gz -C / 3. Download python sources - either CVS or version 2.2. cd into source directory. 4. ./configure --enable-framework 5. Append the following to Modules/Setup.local *shared* _tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \ -I/Library/Frameworks/Tcl.framework/Headers/ \ -I/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders/ \ -I/Library/Frameworks/Tk.framework/Headers/ \ -I/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders/ \ -I/usr/X11R6/include/ \ -framework Tcl -framework Tk 6. make 7. sudo make frameworkinstall 8. cd to Mac/OSX; sudo make install 9. Copy IDLE into Python.app 1. cd back to the top-level source directory ../.. 2. cp -r Tools/idle /Applications/Python.app/Contents/Resources/ 3. echo import idle.idle > /Applications/Python.app/Contents/Resources/__main__.py 10. open -a Python NOTE ON STEP 5: If you don't have /usr/X11R6/include you'll need to go out and find those headers... -Tony -- From pieter.claerhout@pandora.be Fri Apr 5 17:56:57 2002 From: pieter.claerhout@pandora.be (Pieter Claerhout) Date: Fri, 5 Apr 2002 19:56:57 +0200 Subject: [Pythonmac-SIG] Subtle difference between PythonMac and command line on OS X Message-ID: <000901c1dccb$476be650$152b76d5@tsjernochill> Hi all, I just found out a subtle difference between the command line version of OS X (running under terminal) and the Python Mac distribution from Jack Jansen. Here's what happening: Using Python Mac: >>> import socket >>> socket.gethostname() '192.168.0.4' Using command line python: >>> import socket >>> socket.gethostname() 'localhost' Both versions are running on the same machine with the same os configuration. I'm using Python 2.1, and I'm just wondering if that has an influence. I want to have the command line version return '192.168.0.4' as well if possible, since I'm trying to open a socket on that. Is there a way to do this? Cheers, --Pieter From tony@metanet.com Fri Apr 5 18:19:12 2002 From: tony@metanet.com (Tony Lownds) Date: Fri, 5 Apr 2002 10:19:12 -0800 Subject: [Pythonmac-SIG] Subtle difference between PythonMac and command line on OS X In-Reply-To: <000901c1dccb$476be650$152b76d5@tsjernochill> References: <000901c1dccb$476be650$152b76d5@tsjernochill> Message-ID: > >I want to have the command line version return '192.168.0.4' as well On command line: sudo hostname 192.168.0.4 ...but that probably doesn't really do what you want. I'd guess that he reason for the difference is there are entirely different subsystems returning the value. PythonMac using GUSI while MachoPython (command line on OS X) uses standard POSIX calls. So, this probably isn't a bug, just expected deviations across platforms (PythonMac and MachoPython are different platforms.) > since I'm trying to open a socket on that. Whats wrong with opening the socket to 'localhost' on the command line version? -Tony -- From pieter.claerhout@pandora.be Fri Apr 5 18:29:04 2002 From: pieter.claerhout@pandora.be (Pieter Claerhout) Date: Fri, 5 Apr 2002 20:29:04 +0200 Subject: [Pythonmac-SIG] Subtle difference between PythonMac and command line on OS X In-Reply-To: Message-ID: <000a01c1dccf$c4378b40$152b76d5@tsjernochill> The socket I'm trying to open is actually a SocketServer accepting requests from other computers, and that's a bit difficult if it's only listening on 127.0.0.1... --Pieter -----Original Message----- From: Tony Lownds [mailto:tony@metanet.com] Sent: Friday, April 05, 2002 8:19 PM To: pieter.claerhout@pandora.be; pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Subtle difference between PythonMac and command line on OS X > >I want to have the command line version return '192.168.0.4' as well On command line: sudo hostname 192.168.0.4 ...but that probably doesn't really do what you want. I'd guess that he reason for the difference is there are entirely different subsystems returning the value. PythonMac using GUSI while MachoPython (command line on OS X) uses standard POSIX calls. So, this probably isn't a bug, just expected deviations across platforms (PythonMac and MachoPython are different platforms.) > since I'm trying to open a socket on that. Whats wrong with opening the socket to 'localhost' on the command line version? -Tony -- From macnerd@realmspace.com Fri Apr 5 19:01:08 2002 From: macnerd@realmspace.com (macnerd) Date: Fri, 5 Apr 2002 11:01:08 -0800 Subject: [Pythonmac-SIG] Looking for a sponsor In-Reply-To: Message-ID: <001c01c1dcd4$3f906650$bdc8a8c0@corp.good.com> Me too. I'm in. > -----Original Message----- > From: pythonmac-sig-admin@python.org > [mailto:pythonmac-sig-admin@python.org]On Behalf Of Pascal > Oberndoerfer > Sent: Thursday, April 04, 2002 9:04 AM > To: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] Looking for a sponsor > > > Am 04.04.2002 19:00 Uhr schrieb pythonmac-sig-request@python.org > : > > > At 7:41 -0600 3/04/02, in message Re: [Pythonmac-SIG] Looking for a > > sponsor, Eric Stechmann wrote: > >> At 11:56 PM 4/2/02 +0200, you wrote: > >>> Folks, > >>> I'm looking for a sponsor. > >> > >> I concur with others comments and can donate to the cause. Let us > >> know how it can be done. > > > > Me too > > Yes, please. > > Pascal > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From tony@metanet.com Fri Apr 5 19:02:28 2002 From: tony@metanet.com (Tony Lownds) Date: Fri, 5 Apr 2002 11:02:28 -0800 Subject: [Pythonmac-SIG] Subtle difference between PythonMac and command line on OS X In-Reply-To: <000a01c1dccf$c4378b40$152b76d5@tsjernochill> References: <000a01c1dccf$c4378b40$152b76d5@tsjernochill> Message-ID: Try using '' for the hostname. That's the proper* way to do this on MachoPython, at least. Does it work on PythonMac? -Tony * as shown in http://www.python.org/doc/current/lib/socket-example.html At 8:29 PM +0200 4/5/02, Pieter Claerhout wrote: >The socket I'm trying to open is actually a SocketServer accepting requests >from other computers, and that's a bit difficult if it's only listening on >127.0.0.1... > >--Pieter > > >-----Original Message----- >From: Tony Lownds [mailto:tony@metanet.com] >Sent: Friday, April 05, 2002 8:19 PM >To: pieter.claerhout@pandora.be; pythonmac-sig@python.org >Subject: Re: [Pythonmac-SIG] Subtle difference between PythonMac and >command line on OS X > > >> >>I want to have the command line version return '192.168.0.4' as well > > >On command line: > >sudo hostname 192.168.0.4 > >...but that probably doesn't really do what you want. > >I'd guess that he reason for the difference is there are entirely >different subsystems returning the value. PythonMac using GUSI while >MachoPython (command line on OS X) uses standard POSIX calls. > >So, this probably isn't a bug, just expected deviations across >platforms (PythonMac and MachoPython are different platforms.) > > > >> since I'm trying to open a socket on that. > >Whats wrong with opening the socket to 'localhost' on the command line >version? > >-Tony > > >-- > > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- From pieter.claerhout@pandora.be Fri Apr 5 20:01:56 2002 From: pieter.claerhout@pandora.be (Pieter Claerhout) Date: Fri, 5 Apr 2002 22:01:56 +0200 Subject: [Pythonmac-SIG] Subtle difference between PythonMac and command line on OS X In-Reply-To: Message-ID: <000f01c1dcdc$bd6f2c20$152b76d5@tsjernochill> That did work under command line Python, but not using Python for Mac. I got around it by checking the value of os.name, and it it's "mac", then I do pass the name of the computer, if it's another os, I simply pass an empty string... --Pieter -----Original Message----- From: pythonmac-sig-admin@python.org [mailto:pythonmac-sig-admin@python.org]On Behalf Of Tony Lownds Sent: Friday, April 05, 2002 9:02 PM To: pieter.claerhout@pandora.be; pythonmac-sig@python.org Subject: RE: [Pythonmac-SIG] Subtle difference between PythonMac and command line on OS X Try using '' for the hostname. That's the proper* way to do this on MachoPython, at least. Does it work on PythonMac? -Tony * as shown in http://www.python.org/doc/current/lib/socket-example.html At 8:29 PM +0200 4/5/02, Pieter Claerhout wrote: >The socket I'm trying to open is actually a SocketServer accepting requests >from other computers, and that's a bit difficult if it's only listening on >127.0.0.1... > >--Pieter > > >-----Original Message----- >From: Tony Lownds [mailto:tony@metanet.com] >Sent: Friday, April 05, 2002 8:19 PM >To: pieter.claerhout@pandora.be; pythonmac-sig@python.org >Subject: Re: [Pythonmac-SIG] Subtle difference between PythonMac and >command line on OS X > > >> >>I want to have the command line version return '192.168.0.4' as well > > >On command line: > >sudo hostname 192.168.0.4 > >...but that probably doesn't really do what you want. > >I'd guess that he reason for the difference is there are entirely >different subsystems returning the value. PythonMac using GUSI while >MachoPython (command line on OS X) uses standard POSIX calls. > >So, this probably isn't a bug, just expected deviations across >platforms (PythonMac and MachoPython are different platforms.) > > > >> since I'm trying to open a socket on that. > >Whats wrong with opening the socket to 'localhost' on the command line >version? > >-Tony > > >-- > > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.com Fri Apr 5 09:31:04 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 5 Apr 2002 11:31:04 +0200 Subject: [Pythonmac-SIG] Strange import error with pygame In-Reply-To: Message-ID: On vrijdag, april 5, 2002, at 11:08 , Heiko Hartmann wrote: > I downloaded the binary pygame 1.1 distribution and then tried > to start some > of the sample programs (inputbox.py) and then I get the > following error: > > Traceback (most recent call last): > File "Macintosh HD:Applications (Mac OS 9):Python > 2.2:Mac:pygame:inputbox.py", line 29, in ? > import pygame, pygame.font, pygame.event, pygame.draw, string > File "Macintosh HD:Applications (Mac OS 9):Python > 2.2:Extensions:pygame:__init__.py", line 27, in ? > from pygame.base import * > ImportError: PythonCoreCarbon: An import library was too new > for a client. The pygame.base module was built for an older version of Python. I also stared at the "too new" for a while, until I saw that it was PythonCoreCarbon that was too new, and that's indeed what the problem is. Try contacting the pygame distributors to see whether they have a 2.2 version. -- - 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@oratrix.com Fri Apr 5 09:37:33 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 5 Apr 2002 11:37:33 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: <490316A24CC5D411ACD700B0D078F7F0020A5900@cseexch01.cse.creoscitex.com> Message-ID: On vrijdag, april 5, 2002, at 12:18 , Pieter Claerhout wrote: > I tried to use the threading module to start the XML RPC server in a > different thread (xmlrpcServer itself also is a threaded piece > of code), but > that seems to conflict with the mainloop. If you start this > application, it > starts the thread, starts the mainloop and stays in there, once > you finish > the mainloop, the thread continues. You've stumbled on a bug in Framework.mainloop(): it doesn't know anything about multiple threads. It gives time to other applications (by calling WaitNextEvent) but not to other threads within Python. Please file a bug report in the sourceforge Python bugs database and assign it to me (so I won't forget to fix this). Does anyone have any suggestions as to what mainloop() could do to give time to other threads? There must be a way to do this, but I don't immediately see 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 pieter.claerhout@pandora.be Fri Apr 5 21:29:59 2002 From: pieter.claerhout@pandora.be (Pieter Claerhout) Date: Fri, 5 Apr 2002 23:29:59 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: Message-ID: <000001c1dce9$0a996400$152b76d5@tsjernochill> Done. The bug got ID 539990. YOu can find the summary at: http://sourceforge.net/tracker/index.php?func=detail&aid=539990&group_id=547 0&atid=105470 --Pieter -----Original Message----- From: pythonmac-sig-admin@python.org [mailto:pythonmac-sig-admin@python.org]On Behalf Of Jack Jansen Sent: Friday, April 05, 2002 11:38 AM To: Pieter Claerhout Cc: 'pythonmac-sig@python.org' Subject: Re: [Pythonmac-SIG] Threading and FrameWork.Application On vrijdag, april 5, 2002, at 12:18 , Pieter Claerhout wrote: > I tried to use the threading module to start the XML RPC server in a > different thread (xmlrpcServer itself also is a threaded piece > of code), but > that seems to conflict with the mainloop. If you start this > application, it > starts the thread, starts the mainloop and stays in there, once > you finish > the mainloop, the thread continues. You've stumbled on a bug in Framework.mainloop(): it doesn't know anything about multiple threads. It gives time to other applications (by calling WaitNextEvent) but not to other threads within Python. Please file a bug report in the sourceforge Python bugs database and assign it to me (so I won't forget to fix this). Does anyone have any suggestions as to what mainloop() could do to give time to other threads? There must be a way to do this, but I don't immediately see 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 - _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.com Fri Apr 5 22:00:12 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 6 Apr 2002 00:00:12 +0200 Subject: [Pythonmac-SIG] Subtle difference between PythonMac and command line on OS X In-Reply-To: <000f01c1dcdc$bd6f2c20$152b76d5@tsjernochill> Message-ID: <81231774-48E0-11D6-8E9E-003065517236@oratrix.com> On vrijdag, april 5, 2002, at 10:01 , Pieter Claerhout wrote: > That did work under command line Python, but not using Python > for Mac. This is the real bug, then, but see below. Apparently there is no hostname for your 192.168.0.4 address (which, I assume, is your primary interface) and then the C implementations of gethostname() diverge: the unix version looks for a hostname for the next interface (the loopback interface) and the GUSI version gives up (which leads socket.gethostname() to return the numeric address). But: binding to '' should always work, and should always bind to any interface (i.e. incoming connections on any interface will connect to your socket). And I can't reproduce your behaviour (MacPython 2.2c2). I've done the following >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.bind(('', 4242)) # or 4343 for MacPython >>> s.listen(1) and here's the relevant bit of my "netstat -an" output: tcp 0 0 *.4343 *.* LISTEN tcp 0 0 *.4242 *.* LISTEN And my socket.gethostname() behaves the same as yours (my primary interface also doesn't have a name associated with 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 pieter.claerhout@pandora.be Fri Apr 5 22:08:21 2002 From: pieter.claerhout@pandora.be (Pieter Claerhout) Date: Sat, 6 Apr 2002 00:08:21 +0200 Subject: [Pythonmac-SIG] Subtle difference between PythonMac and command line on OS X In-Reply-To: <81231774-48E0-11D6-8E9E-003065517236@oratrix.com> Message-ID: <000101c1dcee$668c9160$152b76d5@tsjernochill> I'm afraid I was mixing up some stuff. I took a closer look at the code, and the socket part does work fine, it's just the xmlrpcServer.py module I'm using that is having troubles with this. Sorry for the confusion! Apart from that, in my example, the 192.168.0.4 is indeed the primary interface but doesn't have a hostname (seems to be the default if you install Mac OS X). So this means that if you use the command line Python version, you'll have a hard time finding out the IP address of the primary interface, while MacPython gives it by default. I have it working now, so I'm a happy man again :-) Cheers, --Pieter -----Original Message----- From: pythonmac-sig-admin@python.org [mailto:pythonmac-sig-admin@python.org]On Behalf Of Jack Jansen Sent: Saturday, April 06, 2002 12:00 AM To: pieter.claerhout@pandora.be Cc: 'Tony Lownds'; pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Subtle difference between PythonMac and command line on OS X On vrijdag, april 5, 2002, at 10:01 , Pieter Claerhout wrote: > That did work under command line Python, but not using Python > for Mac. This is the real bug, then, but see below. Apparently there is no hostname for your 192.168.0.4 address (which, I assume, is your primary interface) and then the C implementations of gethostname() diverge: the unix version looks for a hostname for the next interface (the loopback interface) and the GUSI version gives up (which leads socket.gethostname() to return the numeric address). But: binding to '' should always work, and should always bind to any interface (i.e. incoming connections on any interface will connect to your socket). And I can't reproduce your behaviour (MacPython 2.2c2). I've done the following >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.bind(('', 4242)) # or 4343 for MacPython >>> s.listen(1) and here's the relevant bit of my "netstat -an" output: tcp 0 0 *.4343 *.* LISTEN tcp 0 0 *.4242 *.* LISTEN And my socket.gethostname() behaves the same as yours (my primary interface also doesn't have a name associated with 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 - _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From bob@redivi.com Fri Apr 5 23:30:59 2002 From: bob@redivi.com (Bob Ippolito) Date: Fri, 5 Apr 2002 18:30:59 -0500 Subject: [Pythonmac-SIG] Strange import error with pygame In-Reply-To: Message-ID: <2FC6F720-48ED-11D6-BE69-0003938210D6@redivi.com> pygame 1.1 is really old, as are the rest of the dependencies it uses (freetype, SDL, etc).. I ported it sometime last year; wasn't much of a mac programmer back then but I had one at the office and a little experience porting director xtras to the MacOS platform so I gave it a (fairly successful) try. I'm primarily mac user now (was linux / beos / win32 back then), but only because of OS X, iPods, and titanium powerbooks :) Anyways, I don't have codewarrior anymore (cd disappeared somewhere during the move), so I can't really maintain the MacOS9 port even if I wanted to. If someone wants to buy me a copy, I'd go ahead and try and get pygame 1.4 up to speed for older macs.. but I would prefer if someone else were to maintain the port because I don't run OS9 anywhere (other than classic mode in OS X) and I really don't have a whole lot of time these days to begin with... -bob On Friday, April 5, 2002, at 04:31 AM, Jack Jansen wrote: > > On vrijdag, april 5, 2002, at 11:08 , Heiko Hartmann wrote: > >> I downloaded the binary pygame 1.1 distribution and then tried to >> start some >> of the sample programs (inputbox.py) and then I get the following >> error: >> >> Traceback (most recent call last): >> File "Macintosh HD:Applications (Mac OS 9):Python >> 2.2:Mac:pygame:inputbox.py", line 29, in ? >> import pygame, pygame.font, pygame.event, pygame.draw, string >> File "Macintosh HD:Applications (Mac OS 9):Python >> 2.2:Extensions:pygame:__init__.py", line 27, in ? >> from pygame.base import * >> ImportError: PythonCoreCarbon: An import library was too new for a >> client. > > The pygame.base module was built for an older version of Python. > > I also stared at the "too new" for a while, until I saw that it was > PythonCoreCarbon that was too new, and that's indeed what the problem > is. > > Try contacting the pygame distributors to see whether they have a 2.2 > version. > -- > - 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 just@letterror.com Sat Apr 6 11:09:00 2002 From: just@letterror.com (Just van Rossum) Date: Sat, 6 Apr 2002 13:09:00 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: Message-ID: <20020406130904-r01010800-3f159e97-0920-010c@10.0.0.23> Jack Jansen wrote: > Does anyone have any suggestions as to what mainloop() could do > to give time to other threads? There must be a way to do this, > but I don't immediately see it... Erm, aren't we talking about pre-emptive threads here? If I recall correctly GUSI only switches contexts when I/O blocks, so it doesn't really implement pre-emptive threads. Yet I think GUSI is to blame for that, not FrameWork's mainloop. As in: it should work correctly in MachoPython. Am I missing something? Just From aparente@adobe.com Sat Apr 6 21:15:25 2002 From: aparente@adobe.com (Alexandre Parenteau) Date: Sat, 06 Apr 2002 13:15:25 -0800 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: <20020406130904-r01010800-3f159e97-0920-010c@10.0.0.23> Message-ID: > Jack Jansen wrote: > >> Does anyone have any suggestions as to what mainloop() could do >> to give time to other threads? There must be a way to do this, >> but I don't immediately see it... > > Erm, aren't we talking about pre-emptive threads here? If I recall correctly > GUSI only switches contexts when I/O blocks, so it doesn't really implement > pre-emptive threads. Yet I think GUSI is to blame for that, not FrameWork's > mainloop. As in: it should work correctly in MachoPython. Am I missing > something? GUSI yield to other cooperative threads, not only when I/O blocks (it's in GUSIContext::Yield(). But the YieldToAnyThread that GUSI is doing is likely to do nothing on Python threads because typically these Python threads are locked and wait for the current Python thread to give away the lock. I think the question is more "which threads ?". For threads opened by Python, the only way to switch context is to have the main loop execute some python code. Maybe I'm missing something too... Alex. -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From junkster@rochester.rr.com Sun Apr 7 20:33:35 2002 From: junkster@rochester.rr.com (Benjamin Schollnick) Date: Sun, 07 Apr 2002 15:33:35 -0400 Subject: [Pythonmac-SIG] Macintosh GUI's w/o TK? In-Reply-To: Message-ID: Folks, I'm not exactly positive on how to deal with this.... I've got a IPOD on order, and I'm trying to find a VCF editor/creator, or someway to export VCF's from Outlook Express... I'm not finding any, that are really setup for Carbon or Mac OS 9... So, I'd like to make something in Python... But my understanding from the TK threads, is that under v2.2+ (?) Tkinter isn't being supported... Since we're having serious problems with it... So.... how can I make a GUI on the Macintosh without using Tkinter... I haven't seen any toolkits available for utilizing the Macintosh native GUI calls... Anyone have any suggestions? - Benjamin From Jack.Jansen@oratrix.com Sun Apr 7 22:21:07 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 7 Apr 2002 23:21:07 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: Message-ID: <60296926-4A6D-11D6-9DCE-003065517236@oratrix.com> On zaterdag, april 6, 2002, at 11:15 , Alexandre Parenteau wrote: >> Jack Jansen wrote: >> >>> Does anyone have any suggestions as to what mainloop() could do >>> to give time to other threads? There must be a way to do this, >>> but I don't immediately see it... >> >> Erm, aren't we talking about pre-emptive threads here? If I >> recall correctly >> GUSI only switches contexts when I/O blocks, so it doesn't >> really implement >> pre-emptive threads. Yet I think GUSI is to blame for that, >> not FrameWork's >> mainloop. As in: it should work correctly in MachoPython. Am I missing >> something? > > GUSI yield to other cooperative threads, not only when I/O > blocks (it's in > GUSIContext::Yield(). But the YieldToAnyThread that GUSI is > doing is likely > to do nothing on Python threads because typically these Python > threads are > locked and wait for the current Python thread to give away the lock. Well, the call I'm looking for would definitely have to give up the global interpreter lock before doing the call to give up the CPU. And it turns out GUSI's sleep(0) (or usleep(0), for that matter) does exactly what we want: it allows a threadswitch without further delay. But unfortunately Python's time.sleep() doesn't call sleep or usleep: it calls select(0, NULL, NULL, NULL, 0). And select with no filedescriptors doesn't do anything. And even with filedescriptors but zero timeout it never switches threads. So, the fix is going to have to be partially in C: time.sleep(0) should call sleep(0), not select. And it's too late for 2.2.1, so this will have to wait for 2.2.2 and 2.3. In the mean time, Pieter, for your specific case you can add the following code to your Application class (it's not a good idea in general, because it slows down the main loop, but in Pieter's case the main loop isn't supposed to do anything anyway except wait for quit). def getevent(self, mask = everyEvent, wait = None): time.sleep(0.1) return Framework.Application.getevent(self, mask, wait) -- - 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 just@letterror.com Mon Apr 8 13:53:45 2002 From: just@letterror.com (Just van Rossum) Date: Mon, 8 Apr 2002 14:53:45 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: <60296926-4A6D-11D6-9DCE-003065517236@oratrix.com> Message-ID: <20020408145350-r01010800-d8a1a7ac-0920-010c@10.0.0.23> Jack Jansen wrote: > Well, the call I'm looking for would definitely have to give up > the global interpreter lock before doing the call to give up the > CPU. And it turns out GUSI's sleep(0) (or usleep(0), for that > matter) does exactly what we want: it allows a threadswitch > without further delay. Why would you even have to think about the GIL when you're in an all-Python event loop? Or is it that no switching occurs once we're in WaitNextEvent? (Not pretending to know, I'm only learning about this stuff, too...) Just From mattmsykes@yahoo.co.uk Tue Apr 9 06:30:48 2002 From: mattmsykes@yahoo.co.uk (=?iso-8859-1?q?Matt=20Sykes?=) Date: Tue, 9 Apr 2002 06:30:48 +0100 (BST) Subject: [Pythonmac-SIG] Carbonized embedded python Message-ID: <20020409053048.21749.qmail@web21002.mail.yahoo.com> Hi, I would like to embed Python into an already-existing Carbon application. The application is quite large, so removing/replacing all the Carbon API calls would be infeasible at this point due to time constraints. That is, I must use Carbonized Python libs. I downloaded and installed MacPython22full.bin which contains some Carbon libs. I soon found that I didn't have any header files. On to the source. There are two places to obtain sources: python.org and the MacPython homepage, http://www.cwi.nl/~jack/macpython.html. I grab MacPython22src.sit from ftp://ftp.cwi.nl/pub/jack/python/mac/. Hoping for the best, I tried using those header files to compile an embedded-python test program with my Carbon libs. My machine promptly crashed when I ran it. To me this means that either the header files don't match the libs I have or that my runtime environment is different than what exists in the headers/libs. The exact same code runs perfectly on Windows and FreeBSD. Looks like I need to build python from the source. Following the instructions on Mac/Demo/building.html I was unable to build it using Codewarrior 6.1. I know a fair amount about Codewarrior but was unable to resolve all the errors which were being produced. My guess is that Jack is doing some magic here which isn't mentioned in the docs. The source at ftp.python.org appears to require the unix-type build environment on OS X; the instructions are to run the configure script and compile with the unix-type (GNU?) compiler using make. >From what I understand, I must use the same compiler (same runtime environment) to build both python and my target application if I wish to embed python in the target application. For political and practical reasons beyond my control, the target application must use the Metrowerks compiler (I am not in charge of the Mac builds, I'm just helping with the embedded python side of it). Besides, to my knowledge the 'naked darwin' compiler is unable to build a Carbon application anyway since resource forks and such are needed. All I need (I think) are the exact header files which were used to build the Carbon libs which are available at the MacPython website, as well as info on the precise build environment and settings. Where can I find this? The good news is that it says the Carbon libs were built with the Metrowerks compiler; I'll just make sure to use the exact same version. Is there anyone who has embedded Python into a Carbon app? Is anyone able to build Carbon-MacPython from sources? Is it even recommended to use Carbon MacPython in a professional product? i.e., would you say Carbon MacPython is too experimental for this? Any help would be appreciated. --Matt __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From Jack.Jansen@oratrix.com Mon Apr 8 16:48:30 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 8 Apr 2002 17:48:30 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: <20020408145350-r01010800-d8a1a7ac-0920-010c@10.0.0.23> Message-ID: <12D4DB98-4B08-11D6-A541-003065517236@oratrix.com> On maandag, april 8, 2002, at 02:53 , Just van Rossum wrote: > Jack Jansen wrote: > >> Well, the call I'm looking for would definitely have to give up >> the global interpreter lock before doing the call to give up the >> CPU. And it turns out GUSI's sleep(0) (or usleep(0), for that >> matter) does exactly what we want: it allows a threadswitch >> without further delay. > > Why would you even have to think about the GIL when you're in > an all-Python > event loop? Or is it that no switching occurs once we're in > WaitNextEvent? Indeed, no *thread* switching occurs in WNE(), only *application* switching. Or, in other words, if you're doing a WNE() loop without any other (file, socket) I/O you won't get any thread switch. This could be seen as a problem in GUSI (it pretends to implement preemptive threads, but they're only preempive really if you do enough GUSI I/O calls), but there's little to be done about this given the MacOS (<=9) architecture. -- - 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@oratrix.com Tue Apr 9 22:16:17 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 9 Apr 2002 23:16:17 +0200 Subject: [Pythonmac-SIG] MacPython 2.2.1 ready - please test. Message-ID: <07B2D36E-4BFF-11D6-BA9A-003065517236@oratrix.com> Folks, MacPython 2.2.1 is finished, barring any real showstoppers. It will be announced to a wider audience tomorrow. But I'd like the folks here to download it today so that there's a 12 hour window in which we can find any showstoppers. Please mail immedeately (to pythonmac-sig@python.org and to me) if you think there's something wrong. Get it via http://www.cwi.nl/~jack/macpython.html, as usual. Note that 2.2 is still in there too, at the top, so make sure you download the right thing. Note that as this is a micro release it should be 100% compatible with MacPython 2.2, and there should really be no reason not to upgrade. And there are two very good reasons to upgrade (mac-specific reasons, there's oodles of machine-independent reasons too:-): - The IDE works a lot better on OSX - This release works on an OSX multiprocessor. -- - 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@oratrix.com Tue Apr 9 22:19:55 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 9 Apr 2002 23:19:55 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: <12D4DB98-4B08-11D6-A541-003065517236@oratrix.com> Message-ID: <8A1F438B-4BFF-11D6-BA9A-003065517236@oratrix.com> On maandag, april 8, 2002, at 05:48 , Jack Jansen wrote: > > Indeed, no *thread* switching occurs in WNE(), only > *application* switching. I've been thinking about this a bit more, and I now think it's wrong, really. Shouldn't the toolbox call release the global interpreter lock? Are there any toolbox calls for which this would be unsafe (i.e. the calls that have a callback into Python, maybe)? Input is welcome, -- - 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 mattmsykes@yahoo.co.uk Wed Apr 10 01:13:57 2002 From: mattmsykes@yahoo.co.uk (=?iso-8859-1?q?Matt=20Sykes?=) Date: Wed, 10 Apr 2002 01:13:57 +0100 (BST) Subject: [Pythonmac-SIG] compiling MacPython Message-ID: <20020410001357.62667.qmail@web21008.mail.yahoo.com> Apologies if I am sounding naive; I am new to this SIG. The link to the MacPython SIG archives at http://www.python.org/sigs/pythonmac-sig/ is broken so I can't search to see if this is a FAQ. I am unable to compile MacPython (2.2 and the brand-new 2.2.1) from source with Codewarrior 6.1. Do I need Codewarrior 7? Are the docs that mention Codewarrior 6.1 out of date? When I open PythonCore.mcp it asks me if I wish to convert the file to a newer format. After I do this, it appears the project is *hosed*. I am unable to add or remove files from the project, among other problems which appear to be obvious bugs from the conversion. GUSI compiles without trouble for all targets. Thanks, --Matt __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From just@letterror.com Wed Apr 10 08:39:56 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 10 Apr 2002 09:39:56 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: <8A1F438B-4BFF-11D6-BA9A-003065517236@oratrix.com> Message-ID: <20020410093958-r01050000-28CF94F4-4C56-11D6-AFD7-003065D5E7E4-1013-010c@10.0.0.23> Jack Jansen wrote: > I've been thinking about this a bit more, and I now think it's > wrong, really. I've been thinking, too, but I haven't reached any conclusions, though ;-) > Shouldn't the toolbox call release the global interpreter lock? > Are there any toolbox calls for which this would be unsafe (i.e. > the calls that have a callback into Python, maybe)? WaitNextEvent() on the one hand should indeed release the GIL (as it blocks), but on the other hand it may call into Python at any time, due to a Carbon Event that wants to be handled. This would mean (I think) that at each Python callback entry point the GIL should be acquired again. And that in turn seems to mean that we should release the GIL when entering *any* call that could trigger a Carbon Event handler. Eg. RunApplicationEventLoop(), TrackMouseLocation(), etc. Just From just@letterror.com Wed Apr 10 09:42:59 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 10 Apr 2002 10:42:59 +0200 Subject: [Pythonmac-SIG] Writing Contextual Menu Items in Python Message-ID: <20020410104302-r01050000-F80D5BB6-4C5E-11D6-AFD7-003065D5E7E4-1013-010c@10.0.0.23> After I installed Jack's latest 2.2.1 installer (it works!) I remembered I had Alexandre Parenteau's Contextual Menu Plugin still sitting on my hard disk. Last time I tried it I failed, as I didn't have a compatible Python version properly installed (somehow it didn't work if Python wasn't installed by the official installer, that was more my problem than anything else I suppose). Now I tried again and it *does* work! I also remember that Alexandre didn't get *any* feedback; maybe that was because it was posted with an unsexy subject line: "Embedding example" or something... People, this is *great* stuff: you can now write contexual menu items *in Python*! Very, very cool. Sure, it's a great embedding demo, but I think it's a fantastic project all by itself. Alexandre, shall I simply repost the StuffIt file (it's only 44k), or do you perhaps have a newer version? Or would you prefer to put it on a web page? I had to muck with the install script before I got it to work (open & save again in the script editor) but that seemed to be all. Oh, and I get a traceback on the "copy mac/unix paths" item on Scrap.ZeroScrap(), but the line ending and file type demos work perfectly. Just From just@letterror.com Wed Apr 10 09:46:56 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 10 Apr 2002 10:46:56 +0200 Subject: [Pythonmac-SIG] Writing Contextual Menu Items in Python In-Reply-To: <20020410104302-r01050000-F80D5BB6-4C5E-11D6-AFD7-003065D5E7E4-1013-010c@10.0.0.23> Message-ID: <20020410104659-r01050000-84FAF5E4-4C5F-11D6-AFD7-003065D5E7E4-1013-010c@10.0.0.23> I should've simply posted a link to the previous article... http://aspn.activestate.com/ASPN/Mail/Message/pythonmac-sig/1012642 Just From Jack.Jansen@oratrix.com Wed Apr 10 10:41:30 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 10 Apr 2002 11:41:30 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: <20020410093958-r01050000-28CF94F4-4C56-11D6-AFD7-003065D5E7E4-1013-010c@10.0.0.23> Message-ID: <22B61DA0-4C67-11D6-BDEF-003065517236@oratrix.com> On woensdag, april 10, 2002, at 09:39 , Just van Rossum wrote: >> Shouldn't the toolbox call release the global interpreter lock? >> Are there any toolbox calls for which this would be unsafe (i.e. >> the calls that have a callback into Python, maybe)? > > WaitNextEvent() on the one hand should indeed release the GIL > (as it blocks), > but on the other hand it may call into Python at any time, due > to a Carbon Event > that wants to be handled. This would mean (I think) that at > each Python callback > entry point the GIL should be acquired again. And that in turn > seems to mean > that we should release the GIL when entering *any* call that > could trigger a > Carbon Event handler. Eg. RunApplicationEventLoop(), > TrackMouseLocation(), etc. That's more or less what I had in mind. All toolbox calls release the GIL, and all callback routines re-acquire it. But there's a gotcha here: any *other* calls to WaitNextEvent also have to release the GIL. And some of those calls may not be under our control (because they're in wxPython, or Tk, or whereever)... Hmm, and no documentation is available on the GIL and callback routines (at least, I couldn't find anything, I looked in "extending and embedding" and in the "Python/C API" docs). Maybe this whole exercise is too dangerous, really... -- - 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 just@letterror.com Wed Apr 10 11:53:38 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 10 Apr 2002 12:53:38 +0200 Subject: [Pythonmac-SIG] Threading and FrameWork.Application In-Reply-To: <22B61DA0-4C67-11D6-BDEF-003065517236@oratrix.com> Message-ID: <20020410125341-r01050000-384BEE76-4C71-11D6-AFD7-003065D5E7E4-1013-010c@10.0.0.23> Jack Jansen wrote: > Maybe this whole exercise is too dangerous, really... But also neccesary if we ever want threading in CarbonEvents-based GUI apps :-/ Just From mattmsykes@yahoo.co.uk Wed Apr 10 17:11:50 2002 From: mattmsykes@yahoo.co.uk (=?iso-8859-1?q?Matt=20Sykes?=) Date: Wed, 10 Apr 2002 17:11:50 +0100 (BST) Subject: [Pythonmac-SIG] compiling MacPython In-Reply-To: Message-ID: <20020410161150.71659.qmail@web21005.mail.yahoo.com> Thanks for replying. There is no configure script in the MacPython source, so I assume you are using the python distribution from python.org/sourceforge? Are you able to build Carbon MacPython with gcc, or just the 'bare darwin' command-line version? As far as I know, I'm stuck with Codewarrior if I need a Carbon MacPython. Yes I've tried buildfull.py and other python build scripts; they always launch the PythonCore.mcp project file which is the root of my problem as I've described below. The MacPython-SIG archive is unavailable so no help there. The goal is to embed Python into a Carbonized C++ application which is a children's game. It wouldn't be the most popular game at CompUSA but you would find it there. But so far I am unable to get *anywhere* with this. I can't even get an answer as to whether I need Codewarrior 7. My machine does a hard-freeze (yes, even OS X) whenever I test embedded python using the headers from MacPython-src and the binary libs, which is why I got into trying to compile MacPython from source. Maybe I could ask my company to donate to MacPython in exchange for some support? Or maybe I could lobby to put "powered by MacPython" on the box or some such? What will it take to get some help? ################################################################### All I really need are the headers that go with the Carbon libs as well as the build settings / compiler version used to build them. ################################################################### But I can't even get this info yet. Sorry for the complaining nature into which this post has veered. I'm just surprised that so few people appear to be involved with MacPython. --Matt --- Donovan Preston wrote: > Hi, > Sorry I can't be a bit more helpful, but I haven't compiled using > CodeWarrior in quite a while (only using gcc)... > If I remember correctly, the build process for Python using > codewarrior is itself automated using Python (how's that for a > chicken and the egg?) :-) > You need to either 1) use an already-built python to build the new > python, or 2) Compile the minimal statically-linked interpreter, > then run the build script with this. > There should be documentation about the process somewhere... > Donovan > On Tuesday, April 9, 2002, at 05:13 PM, Matt Sykes wrote: > > Apologies if I am sounding naive; I am new to this SIG. > > The link to the MacPython SIG archives at > > http://www.python.org/sigs/pythonmac-sig/ is broken so I can't > > search to see if this is a FAQ. > > I am unable to compile MacPython (2.2 and the brand-new 2.2.1) > > from source with Codewarrior 6.1. Do I need Codewarrior 7? Are > > the docs that mention Codewarrior 6.1 out of date? > > When I open PythonCore.mcp it asks me if I wish to convert the > > file to a newer format. After I do this, it appears the project > > is *hosed*. I am unable to add or remove files from the project, > > among other problems which appear to be obvious bugs from the > > conversion. > > GUSI compiles without trouble for all targets. > > > > Thanks, > > --Matt __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From mmiller@adobe.com Wed Apr 10 18:40:00 2002 From: mmiller@adobe.com (Martin Miller) Date: Wed, 10 Apr 2002 10:40:00 -0700 Subject: [Pythonmac-SIG] compiling MacPython Message-ID: <3CB478F0.24CD17D5@adobe.com> Hi Matt, I think you do need Codewarrior 7. I personally have not had the problems you describe when building MacPython 2.2 from the source distribution using CW7. The MacPython webpage at says the following: In the "Current distribution" section: > Note 4: The extension module developer package in the MacPython > distribution assumes you use Metrowerks CodeWarrior Pro 7. If you > have CodeWarrior 5.3 you should get this patch provided by Tom Loredo. > patch and, in the "Source distributions" section: > The source distribution has built with CodeWarrior Pro 7. It is, > however, strongly suggested that if you want to contribute actively > to MacPython development you get source access through the public > CVS repository (see below), as this will ensure that you are always > working with the most recent version of the sources. Hope this helps, -Martin ========================================= Matt Sykes wrote: > > Apologies if I am sounding naive; I am new to this SIG. > > The link to the MacPython SIG archives at > http://www.python.org/sigs/pythonmac-sig/ is broken so I can't search > to see if this is a FAQ. > > I am unable to compile MacPython (2.2 and the brand-new 2.2.1) from > source with Codewarrior 6.1. Do I need Codewarrior 7? Are the docs > that mention Codewarrior 6.1 out of date? > > When I open PythonCore.mcp it asks me if I wish to convert the file to > a newer format. After I do this, it appears the project is *hosed*. > I am unable to add or remove files from the project, among other > problems which appear to be obvious bugs from the conversion. > > GUSI compiles without trouble for all targets. > > Thanks, > --Matt From mattmsykes@yahoo.co.uk Wed Apr 10 19:01:14 2002 From: mattmsykes@yahoo.co.uk (=?iso-8859-1?q?Matt=20Sykes?=) Date: Wed, 10 Apr 2002 19:01:14 +0100 (BST) Subject: [Pythonmac-SIG] compiling MacPython In-Reply-To: <3CB478F0.24CD17D5@adobe.com> Message-ID: <20020410180114.91889.qmail@web21005.mail.yahoo.com> Ok thanks. The Python 2.2.1 source says to look in Demo/building.html for instructions on building MacPython. There it says to use CW 6.1. This should be changed. --Matt --- Martin Miller wrote: > Hi Matt, > > I think you do need Codewarrior 7. I personally have not had the > problems you describe when building MacPython 2.2 from the source > distribution using CW7. > > The MacPython webpage at says > the following: > > In the "Current distribution" section: > > Note 4: The extension module developer package in the MacPython > > distribution assumes you use Metrowerks CodeWarrior Pro 7. If you > > have CodeWarrior 5.3 you should get this patch provided by Tom Loredo. > > patch > > > and, in the "Source distributions" section: > > The source distribution has built with CodeWarrior Pro 7. It is, > > however, strongly suggested that if you want to contribute actively > > to MacPython development you get source access through the public > > CVS repository (see below), as this will ensure that you are always > > working with the most recent version of the sources. > > Hope this helps, > -Martin > > > ========================================= > Matt Sykes wrote: > > > > Apologies if I am sounding naive; I am new to this SIG. > > > > The link to the MacPython SIG archives at > > http://www.python.org/sigs/pythonmac-sig/ is broken so I can't search > > to see if this is a FAQ. > > > > I am unable to compile MacPython (2.2 and the brand-new 2.2.1) from > > source with Codewarrior 6.1. Do I need Codewarrior 7? Are the docs > > that mention Codewarrior 6.1 out of date? > > > > When I open PythonCore.mcp it asks me if I wish to convert the file to > > a newer format. After I do this, it appears the project is *hosed*. > > I am unable to add or remove files from the project, among other > > problems which appear to be obvious bugs from the conversion. > > > > GUSI compiles without trouble for all targets. > > > > Thanks, > > --Matt > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From Jack.Jansen@oratrix.com Thu Apr 11 12:08:00 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 11 Apr 2002 13:08:00 +0200 Subject: [Pythonmac-SIG] compiling MacPython In-Reply-To: <20020410161150.71659.qmail@web21005.mail.yahoo.com> Message-ID: <62B429A7-4D3C-11D6-936C-003065517236@oratrix.com> Matt, I'm really busy (that's why I didn't reply before) but here's a few hints. - Read Mac/build.html, this is all the documentation there is. This also explains about using PythonStandSmall.mcp to create a small Python that will enable you to use the automatic scripts to build the rest. Alternatively you can also install a Python binary installation alongside your source tree. - You need CodeWarrior, and preferrably CW 7. The docs stating CW6 are wrong. But you can probably build with CW6 if you get the libraries right. Metrowerks changed them between 6 and 7. Alternatively, get the Mac/Build folder from CVS, and get the final_CW6_projects. The should work almost out of the box with the Python 2.2 sources. On woensdag, april 10, 2002, at 06:11 , Matt Sykes wrote: > > Thanks for replying. > > There is no configure script in the MacPython source, so I assume you > are using the python distribution from python.org/sourceforge? > > Are you able to build Carbon MacPython with gcc, or just the 'bare > darwin' command-line version? > > As far as I know, I'm stuck with Codewarrior if I need a Carbon > MacPython. > > Yes I've tried buildfull.py and other python build scripts; they > always launch the PythonCore.mcp project file which is the root of my > problem as I've described below. > > The MacPython-SIG archive is unavailable so no help there. > > The goal is to embed Python into a Carbonized C++ application which is > a children's game. It wouldn't be the most popular game at CompUSA > but you would find it there. > > But so far I am unable to get *anywhere* with this. I can't even get > an answer as to whether I need Codewarrior 7. > > My machine does a hard-freeze (yes, even OS X) whenever I test > embedded python using the headers from MacPython-src and the binary > libs, which is why I got into trying to compile MacPython from source. > > Maybe I could ask my company to donate to MacPython in exchange for > some support? Or maybe I could lobby to put "powered by MacPython" on > the box or some such? > > What will it take to get some help? > > ################################################################### > All I really need are the headers that go with the Carbon libs as well > as the build settings / compiler version used to build them. > ################################################################### > > But I can't even get this info yet. > > Sorry for the complaining nature into which this post has veered. I'm > just surprised that so few people appear to be involved with > MacPython. > > --Matt > > --- Donovan Preston wrote: > Hi, > >> Sorry I can't be a bit more helpful, but I haven't compiled using >> CodeWarrior in quite a while (only using gcc)... > >> If I remember correctly, the build process for Python using >> codewarrior is itself automated using Python (how's that for a >> chicken and the egg?) :-) > >> You need to either 1) use an already-built python to build the new >> python, or 2) Compile the minimal statically-linked interpreter, >> then run the build script with this. > >> There should be documentation about the process somewhere... > >> Donovan > >> On Tuesday, April 9, 2002, at 05:13 PM, Matt Sykes wrote: > > >>> Apologies if I am sounding naive; I am new to this SIG. > >>> The link to the MacPython SIG archives at >>> http://www.python.org/sigs/pythonmac-sig/ is broken so I can't >>> search to see if this is a FAQ. > >>> I am unable to compile MacPython (2.2 and the brand-new 2.2.1) >>> from source with Codewarrior 6.1. Do I need Codewarrior 7? Are >>> the docs that mention Codewarrior 6.1 out of date? > >>> When I open PythonCore.mcp it asks me if I wish to convert the >>> file to a newer format. After I do this, it appears the project >>> is *hosed*. I am unable to add or remove files from the project, >>> among other problems which appear to be obvious bugs from the >>> conversion. > >>> GUSI compiles without trouble for all targets. >>> >>> Thanks, >>> --Matt > > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com > > > _______________________________________________ > 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 pieter.claerhout@pandora.be Thu Apr 11 23:18:24 2002 From: pieter.claerhout@pandora.be (Pieter Claerhout) Date: Fri, 12 Apr 2002 00:18:24 +0200 Subject: [Pythonmac-SIG] Obtaining the hardware address of the first network card Message-ID: <000001c1e1a6$ccd0eef0$152b76d5@tsjernochill> Hi all, is there a way to obtain the hardware address of the built-in network card of your Mac using Python? I found way to get it under command line python in OS X, but it should work on all macintoshes... Anybody an idea? --Pieter From deirdre@deirdre.net Fri Apr 12 07:10:40 2002 From: deirdre@deirdre.net (Deirdre Saoirse Moen) Date: Thu, 11 Apr 2002 23:10:40 -0700 Subject: [Pythonmac-SIG] Obtaining the hardware address of the first network card In-Reply-To: <000001c1e1a6$ccd0eef0$152b76d5@tsjernochill> References: <000001c1e1a6$ccd0eef0$152b76d5@tsjernochill> Message-ID: At 12:18 AM +0200 4/12/02, Pieter Claerhout wrote: >is there a way to obtain the hardware address of the built-in network card >of your Mac using Python? I found way to get it under command line python in >OS X, but it should work on all macintoshes... In theory, there could be multiple addresses, so how do you presume to figure out which one? And some Macs don't have ethernet. :) -- _Deirdre Stash-o-Matic: http://fuzzyorange.com http://deirdre.net "I'm writing a book. I've got the page numbers done." - Steven Wright From csmith@blakeschool.org Fri Apr 12 05:05:58 2002 From: csmith@blakeschool.org (Christopher Smith) Date: Thu, 11 Apr 2002 23:05:58 -0500 Subject: [Pythonmac-SIG] Re: Console input in the IDE? Message-ID: > I'd like to avoid that awful Input window in the IDE that comes up > whenever I call raw_input(). The following is a step toward what you are looking for. It doesn't allow editing of the input line, but if that's not a problem then it will do the string input and echo the keypresses to the output window. When you hit a backspace a character is echoed to the screen and a character is subtracted from the string to be returned but the character is not erased on teh screen. Also, this prompt() function doesn't make the output window active so if you request input you have to make sure that the output window is visible before you do or else you won't be able to see that data is being requested. Below, inkey() is used by prompt() HTH, /c #### def inkey(): """ A function which returns the current ASCII key that is down; if no ASCII key is down, the null string is returned. The page http://www.mactech.com/macintosh-c/chap02-1.html was very helpful in figuring out how to do this. If cmd-. is pressed without the shift key a -1 is returned. """ #cps 4/2002 import Carbon if Carbon.Evt.EventAvail(0x0008)[0]==0: # 0x0008 is the keyDownMask return '' else: # # The event contains the following info: # (what,msg,when,where,mod)=Carbon.Evt.GetNextEvent(0x0008)[1] # # The message (msg) contains the ASCII char which is # extracted with the 0x000000FF charCodeMask; this # number is converted to an ASCII character with chr() and # returned # (what,msg,when,where,mod)=Carbon.Evt.GetNextEvent(0x0008)[1] if mod & 0x0100 and mod & 0x0200 == 0: #cmd and not shift return -1 return chr(msg & 0x000000FF) def prompt(say): """ A function that waits for a carriage return and concatenates keyboard presses in the mean time and returns these presses as a \n terminated string. If the user presses cmd-. without the shift key down, a null string is returned; if the user only typed chr(13) then a '\n' is returned. """ #cps 4/2002 import sys,Carbon sys.stdout._buf = say or '? ' sys.stdout.flush() ans='' x=inkey() while x<>-1 and x<>chr(13): if x: if ord(x)<>8: ans+=x else: ans=ans[:-1] x=inkey() if x<>-1 and x<>'': #don't know how to erase a character from the display, though. #I suppose that if you detect a backspace you could print on #a new line all the characters that have been entered so far. sys.stdout._buf=x sys.stdout.flush() if x == -1: return '' #got a user cancel else: return ans + '\n' #### From erik@letterror.com Fri Apr 12 08:24:52 2002 From: erik@letterror.com (Erik van Blokland) Date: Fri, 12 Apr 2002 09:24:52 +0200 Subject: [Pythonmac-SIG] MacPython Boutique In-Reply-To: <20010624203429.CF7EB120260@oratrix.oratrix.nl> Message-ID: <20020412092455-r01050000-62F1DDA7-4DE6-11D6-88A0-0050E4BA485B-1013-0108@10.0.0.11> MacPython opens first programming life-style boutique! http://www.letterror.com/projects/hack/macpython.jpg (An old picture I found whilst cleaning up.) Erik van Blokland From pieter.claerhout@pandora.be Fri Apr 12 08:33:23 2002 From: pieter.claerhout@pandora.be (Pieter Claerhout) Date: Fri, 12 Apr 2002 09:33:23 +0200 Subject: [Pythonmac-SIG] Obtaining the hardware address of the first network card In-Reply-To: Message-ID: <000001c1e1f4$542f7270$152b76d5@tsjernochill> I there are more, then I need only the first one that is found. AppleSystem Profiler is apparently able to find it out, but I can't seem to figure out how. I also looked on developer.apple.com for any samples, but most of the code samples there are targetted to Mac OS X :-( And yes, not every mac has a network card, but for me, this is a non-issue, since all the macs that are supposed to run this program do need a network card, since it's a program designed to be used over a network ;-) --Pieter -----Original Message----- From: pythonmac-sig-admin@python.org [mailto:pythonmac-sig-admin@python.org]On Behalf Of Deirdre Saoirse Moen Sent: Friday, April 12, 2002 8:11 AM To: pieter.claerhout@pandora.be; pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Obtaining the hardware address of the first network card At 12:18 AM +0200 4/12/02, Pieter Claerhout wrote: >is there a way to obtain the hardware address of the built-in network card >of your Mac using Python? I found way to get it under command line python in >OS X, but it should work on all macintoshes... In theory, there could be multiple addresses, so how do you presume to figure out which one? And some Macs don't have ethernet. :) -- _Deirdre Stash-o-Matic: http://fuzzyorange.com http://deirdre.net "I'm writing a book. I've got the page numbers done." - Steven Wright _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From dp@ulaluma.com Fri Apr 12 11:05:06 2002 From: dp@ulaluma.com (Donovan Preston) Date: Fri, 12 Apr 2002 03:05:06 -0700 Subject: [Pythonmac-SIG] ThreadSafety and Callbacks Message-ID: --Apple-Mail-1--503482814 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Jack and Just (and anyone else), As you know, I have been keenly interested in issues surrounding CarbonEvent programming for quite a while now, since I see the Carbon Event Manager as an elegant solution to event-based programming. Unfortunately, thread safety issues aren't quite as elegant. I hate to throw more unfinished patches onto the fire, but I have been working on exactly the issue you have been discussing in "Threading and FrameWork.Application", and also in the thread on Python-dev. I thought it would be better to submit my unfinished solution to share my learning experience than to try to finish it in silence while someone else did the same work in an unrelated way. Attached find some patches to pymactoolbox, mactoolboxglue, macmain, and CarbonEventsupport. Take a look at the attached patches first, they are quite short. Here's the basic theory behind it, currently: In reference to Martin v. Loewis' message, Very similar to the 1) _tkinter approach, where we guarantee that the call-back appears to come from within the context of the same thread that released the GIL. Within the context of my applications, RunApplicationEventLoop releases the GIL (by calling Py_BEGIN_ALLOW_THREADS) and any Carbon Event callback reacquires the GIL (By inserting the macro Py_GENERATE_THREAD_STATE_AND_ACQUIRE_LOCK (by lock I am referring to the GIL)), and releases it when done. Note that this code currently ensures that each callback will run to completion before a new callback begins by requiring each callback to first acquire a MPCriticalRegion mutex (MPEnterCriticalRegion(_criticalRegion, kDurationForever)) This may cause deadlocks in some situations where the Carbon Event calls back into the toolbox, thus generating another Callback which tries to acquire the critical region... (unless ALL toolbox calls release the GIL and the CriticalRegion, (and ALL callbacks acquire them) which I am currently thinking may be the best solution) Also note that since this code currently guarantees callback atomicity, it is NOT necessary to create a new PyThreadState every time a callback comes in, and this is a bunch of wasted effort and may be removed. However, not removing it leads to the next solution, which I have also tried, which is 2) the free threading approach: If you instead remove the MPCriticalRegion mutex, and leave the PyThreadState_New call, you will then get one new Python thread per Carbon Event callback. This works quite well in some cases, however, incurs the additional overhead of creating and destroying a thread state for every callback, and you have to be very careful if you want to be able to call Toolbox calls from an arbitrary event handler, especially when there is the potential for multiple event handler threads to be running at once. I'm sorry if this isn't incredibly coherent, I have just worked a 12 hour day and am composing this message at three in the morning. I will try to clarify both the code and my explanation tomorrow (I have the day off, woohoo!) Donovan --Apple-Mail-1--503482814 Content-Disposition: attachment; filename=mactoolboxglue.diff Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="mactoolboxglue.diff" Index: Python/mactoolboxglue.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/mactoolboxglue.c,v retrieving revision 1.9 diff -c -r1.9 mactoolboxglue.c *** Python/mactoolboxglue.c 4 Dec 2001 01:11:32 -0000 1.9 --- Python/mactoolboxglue.c 10 Apr 2002 05:40:23 -0000 *************** *** 29,35 **** --- 29,91 ---- #ifdef WITHOUT_FRAMEWORKS #include #include + #else + #include #endif + + #if TARGET_API_MAC_OSX + static PyThreadState *_savedThreadState = NULL; + static PyThreadState *_originalThreadState = NULL; + static PyInterpreterState *_savedInterpreterState = NULL; + static MPCriticalRegionID _criticalRegion = NULL; + + static pthread_t currentThreadID = NULL; + static int recursiveCount = 0; + + void PyMac_SetupCallbackThreadGeneration(void) { + PyEval_InitThreads(); + _originalThreadState = PyThreadState_Get(); + _savedInterpreterState = _originalThreadState->interp; + _savedThreadState = PyThreadState_New(_savedInterpreterState); + MPCreateCriticalRegion(&_criticalRegion); + printf("hello threadstate original %d new %d\n", _originalThreadState, _savedThreadState); + } + + void PyMac_DestroyCallbackThreadGeneration(void) { + printf("Acquire lock to destroy lock %d\n", _originalThreadState); + MPEnterCriticalRegion(_criticalRegion, kDurationForever); + PyThreadState_Swap(_originalThreadState); + MPExitCriticalRegion(_criticalRegion); + } + + PyThreadState* PyMac_GenerateThreadStateAndAcquireInterpreterLock() { + PyThreadState *newCallbackThreadState; + + printf("Acquiring Critical Region: "); + + MPEnterCriticalRegion(_criticalRegion, kDurationForever); + PyEval_AcquireLock(); + newCallbackThreadState = PyThreadState_New(_savedInterpreterState); + _savedThreadState = PyThreadState_Swap(newCallbackThreadState); + printf("Saved: %d, New: %d\n", _savedThreadState, newCallbackThreadState); + return newCallbackThreadState; + } + + void PyMac_DestroyThreadStateAndReleaseInterpreterLock(PyThreadState *inState) { + printf("Exiting Critical Region: "); + if (_savedThreadState != inState) { + printf("Restored: %d, Destroyed: %d\n", _savedThreadState, inState); + PyThreadState_Swap(_savedThreadState); + PyThreadState_Clear(inState); + PyThreadState_Delete(inState); + } else { + printf("xxx exited thread recursion\n"); + } + PyEval_ReleaseLock(); + MPExitCriticalRegion(_criticalRegion); + } + #endif /* TARGET_API_MAC_OSX */ + /* ** Find out what the current script is. --Apple-Mail-1--503482814 Content-Disposition: attachment; filename=pymactoolbox.diff Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="pymactoolbox.diff" Index: Include/pymactoolbox.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/pymactoolbox.h,v retrieving revision 1.4 diff -c -r1.4 pymactoolbox.h *** Include/pymactoolbox.h 5 Nov 2001 14:39:22 -0000 1.4 --- Include/pymactoolbox.h 10 Apr 2002 05:40:15 -0000 *************** *** 26,31 **** --- 26,54 ---- #include #endif + #if TARGET_API_MAC_OSX + /* Prototypes */ + void PyMac_SetupCallbackThreadGeneration(void); + void PyMac_DestroyCallbackThreadGeneration(void); + PyThreadState* PyMac_GenerateThreadStateAndAcquireInterpreterLock(void); + void PyMac_DestroyThreadStateAndReleaseInterpreterLock(PyThreadState *inState); + + /* Macros */ + #define PYMAC_SETUP_CALLBACK_THREAD_GENERATION PyMac_SetupCallbackThreadGeneration(); + #define PYMAC_DESTROY_CALLBACK_THREAD_GENERATION PyMac_DestroyCallbackThreadGeneration(); + #define PYMAC_GENERATE_THREAD_STATE_AND_ACQUIRE_LOCK { \ + PyThreadState *_save; \ + _save = PyMac_GenerateThreadStateAndAcquireInterpreterLock(); + #define PYMAC_DESTROY_THREAD_STATE_AND_RELEASE_LOCK PyMac_DestroyThreadStateAndReleaseInterpreterLock(_save); \ + } + #else + /* On OS 9, these get reduced to nothing */ + #define PYMAC_SETUP_CALLBACK_THREAD_GENERATION + #define PYMAC_DESTROY_CALLBACK_THREAD_GENERATION + #define PYMAC_GENERATE_THREAD_STATE_AND_ACQUIRE_LOCK(x) + #define PYMAC_DESTROY_THREAD_STATE_AND_RELEASE_LOCK + #endif + /* ** Helper routines for error codes and such. */ --Apple-Mail-1--503482814 Content-Disposition: attachment; filename=macmain.diff Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="macmain.diff" Index: Mac/Python/macmain.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Python/macmain.c,v retrieving revision 1.75 diff -c -r1.75 macmain.c *** Mac/Python/macmain.c 29 Mar 2002 14:43:50 -0000 1.75 --- Mac/Python/macmain.c 12 Apr 2002 09:56:26 -0000 *************** *** 24,36 **** /* Python interpreter main program */ #include "Python.h" #include "pythonresources.h" #include "import.h" #include "marshal.h" #include "macglue.h" - - #ifdef WITHOUT_FRAMEWORKS #include #include #include --- 24,35 ---- /* Python interpreter main program */ + #ifdef WITHOUT_FRAMEWORKS #include "Python.h" #include "pythonresources.h" #include "import.h" #include "marshal.h" #include "macglue.h" #include #include #include *************** *** 51,56 **** --- 50,60 ---- #endif /* USE_APPEARANCE */ #else #include + #include + #include + #include + #include + #include #endif /* WITHOUT_FRAMEWORKS */ #ifdef __MWERKS__ *************** *** 655,660 **** --- 659,666 ---- #endif Py_Initialize(); + + PYMAC_SETUP_CALLBACK_THREAD_GENERATION PyUnicode_SetDefaultEncoding(PyMac_getscript()); *************** *** 675,680 **** --- 681,688 ---- if ( filename != NULL || command != NULL ) sts = (run_inspect() || sts); + + PYMAC_DESTROY_CALLBACK_THREAD_GENERATION Py_Exit(sts); /*NOTREACHED*/ --Apple-Mail-1--503482814 Content-Disposition: attachment; filename=CarbonEvtsupport.diff Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="CarbonEvtsupport.diff" Index: Mac/Modules/carbonevt/CarbonEvtsupport.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/carbonevt/CarbonEvtsupport.py,v retrieving revision 1.10 diff -c -r1.10 CarbonEvtsupport.py *** Mac/Modules/carbonevt/CarbonEvtsupport.py 8 Jan 2002 11:49:31 -0000 1.10 --- Mac/Modules/carbonevt/CarbonEvtsupport.py 12 Apr 2002 09:27:58 -0000 *************** *** 89,102 **** return; \ }} while(0) - - #define USE_MAC_MP_MULTITHREADING 0 - - #if USE_MAC_MP_MULTITHREADING - static PyThreadState *_save; - static MPCriticalRegionID reentrantLock; - #endif /* USE_MAC_MP_MULTITHREADING */ - extern int CFStringRef_New(CFStringRef *); extern int CFStringRef_Convert(PyObject *, CFStringRef *); --- 89,94 ---- *************** *** 172,181 **** PyObject *retValue; int status; ! #if USE_MAC_MP_MULTITHREADING ! MPEnterCriticalRegion(reentrantLock, kDurationForever); ! PyEval_RestoreThread(_save); ! #endif /* USE_MAC_MP_MULTITHREADING */ retValue = PyObject_CallFunction((PyObject *)outPyObject, "O&O&", EventHandlerCallRef_New, handlerRef, --- 164,170 ---- PyObject *retValue; int status; ! PYMAC_GENERATE_THREAD_STATE_AND_ACQUIRE_LOCK retValue = PyObject_CallFunction((PyObject *)outPyObject, "O&O&", EventHandlerCallRef_New, handlerRef, *************** *** 194,203 **** Py_DECREF(retValue); } ! #if USE_MAC_MP_MULTITHREADING ! _save = PyEval_SaveThread(); ! MPExitCriticalRegion(reentrantLock); ! #endif /* USE_MAC_MP_MULTITHREADING */ return status; } --- 183,189 ---- Py_DECREF(retValue); } ! PYMAC_DESTROY_THREAD_STATE_AND_RELEASE_LOCK return status; } *************** *** 337,357 **** EventRefobject.add(f) runappeventloop = """ ! #if USE_MAC_MP_MULTITHREADING ! if (MPCreateCriticalRegion(&reentrantLock) != noErr) { ! PySys_WriteStderr("lock failure\\n"); ! return NULL; ! } ! _save = PyEval_SaveThread(); ! #endif /* USE_MAC_MP_MULTITHREADING */ RunApplicationEventLoop(); ! #if USE_MAC_MP_MULTITHREADING ! PyEval_RestoreThread(_save); ! ! MPDeleteCriticalRegion(reentrantLock); ! #endif /* USE_MAC_MP_MULTITHREADING */ Py_INCREF(Py_None); --- 323,333 ---- EventRefobject.add(f) runappeventloop = """ ! Py_BEGIN_ALLOW_THREADS RunApplicationEventLoop(); ! Py_END_ALLOW_THREADS Py_INCREF(Py_None); --Apple-Mail-1--503482814-- From Thanks4asking@alliedmarketing.net Sat Apr 13 03:10:04 2002 From: Thanks4asking@alliedmarketing.net (Thanks4asking@alliedmarketing.net) Date: Fri, 12 Apr 2002 22:10:04 -0400 Subject: [Pythonmac-SIG] Webmaster Information Message-ID: <4D4508F7-4E5A-11D6-8F4E-00500471CA25@UrcTmcgT> ------=_NextPart_000_00V8_70Y81A1C.C1122H33 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCiAgPFRJVExFPlRoYW5rcy00LUFza2luZzwvVElUTEU+DQogIDxMSU5L IHJlbD0ic3R5bGVzaGVldCIgaHJlZj0iaHR0cDovL2NvZ25pZ2VuLm5ldC9jb3Jwb3JhdGUvY29n bmlnZW4uY3NzIj4NCjwvSEVBRD4NCjxCT0RZIEJHQ09MT1I9IiNmZmZmZmYiPg0KPENFTlRFUj4N CiAgPFRBQkxFIENFTExTUEFDSU5HPSIwIiBDRUxMUEFERElORz0iMCIgQUxJR049IkNlbnRlciJ3 aWR0aD01MDA+DQogICAgPFRSPg0KICAgICAgPFREPjxUQUJMRSBDRUxMU1BBQ0lORz0iMCIgQ0VM TFBBRERJTkc9IjAiPg0KCSAgPFRSPg0KCSAgICA8VEQgYmdjb2xvcj0jMDAwMDAwPjxQIEFMSUdO PUNlbnRlcj4NCgkgICAgICA8SU1HIFNSQz0icGljdDQ1LmpwZyIgQUxJR049IkJvdHRvbSIgQUxU PSJbSW1hZ2VdIiBXSURUSD0iMzY1IiBIRUlHSFQ9IjcyIj48L1REPg0KCSAgPC9UUj4NCgkgIDxU Uj4NCgkgICAgPFREPjxUQUJMRSBDRUxMU1BBQ0lORz0iMCIgQ0VMTFBBRERJTkc9IjAiPg0KCQk8 VFI+DQoJCSAgPFREPjxUQUJMRSBDRUxMU1BBQ0lORz0iMCIgQ0VMTFBBRERJTkc9IjAiPg0KCQkg ICAgICA8VFI+DQoJCQk8VEQ+PFRBQkxFIENFTExTUEFDSU5HPSIwIiBDRUxMUEFERElORz0iMCI+ DQoJCQkgICAgPFRSPg0KCQkJICAgICAgPFREPg0KCQkJCSAgPEhSPg0KCQkJICAgICAgPC9URD4N CgkJCSAgICA8L1RSPg0KCQkJICAgIDxUUj4NCgkJCSAgICAgIDxURD48VEFCTEUgQ0VMTFNQQUNJ Tkc9IjAiIENFTExQQURESU5HPSIwIj4NCgkJCQkgIDxUUj4NCgkJCQkgICAgPFREPjxUQUJMRSBD RUxMU1BBQ0lORz0iMCIgQ0VMTFBBRERJTkc9IjAiPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PEI+ PFNQQU4gY2xhc3M9ImdlbmVyYWwiPjxCSUc+PEJJRz48QklHPkludGVybmV0IFdlYiBUcmFmZmlj IEZvcg0KCQkJCQkgIFNhbGU8L0JJRz48L0JJRz48L0JJRz48L1NQQU4+PC9CPjwvVEQ+DQoJCQkJ CTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEk+U3Bl Y2lhbCBQcmljaW5nIEZvciBUcmFmZmljIFRvIFlvdXIgV2ViDQoJCQkJCSAgU2l0ZTo8L0k+PC9T UEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD4mbmJzcDs8L1REPg0K CQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9ImdlbmVyYWwiPjxC Pk1haW5zdHJlYW0gU2l0ZXMgRXhpdCBvciBQb3B1bmRlcg0KCQkJCQkgIFRyYWZmaWM6PC9CPjwv U1BBTj48L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9 ImdlbmVyYWwiPjxJPkdlbmVyaWMgVHJhZmZpYyAtICQzLjI1IENQTTwvST48L1NQQU4+PC9URD4N CgkJCQkJPC9UUj4NCgkJCQkJPFRSPg0KCQkJCQkgPFREPjxTUEFOIGNsYXNzPSJnZW5lcmFsIj48 ST5DYXRlZ29yeSBTcGVjaWZpYyBUcmFmZmljIC0gJDUuMDAgQ1BNPC9JPjwvU1BBTj48L1REPg0K CQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+Jm5ic3A7PC9URD4NCgkJCQkJPC9UUj4N CgkJCQkJPFRSPg0KCQkJCQkgPFREPjxTUEFOIGNsYXNzPSJnZW5lcmFsIj48Qj5BZHVsdCBTaXRl cyBFeGl0IG9yIFBvcHVuZGVyIFRyYWZmaWM6PC9CPjwvU1BBTj48L1REPg0KCQkJCQk8L1RSPg0K CQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9ImdlbmVyYWwiPjxJPkZyb20gUGF5c2l0 ZXMgLSAkNS4wMCBDUE08L0k+PC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJ CQkJIDxURD48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEk+RnJvbSBGcmVlc2l0ZXMgLSAkNC4wMCBD UE08L0k+PC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD4mbmJz cDs8L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9Imdl bmVyYWwiPjxCPlNlYXJjaCBFbmdpbmUgVHJhZmZpYyBBdmFpYWxibGUgVXBvbiBSZXF1ZXN0Lg0K CQkJCQkgIEZvciBBIFF1b3RlIE9uIFNlYXJjaCBFbmdpbmUgVHJhZmZpYyBQbGVhc2UgY2FsbCB1 cyBhdCA5NzMuOTkyLjM5ODUgb3IgZW1haWwNCgkJCQkJICA8QSBIUkVGPSJtYWlsdG86dHJhZmZp Y0BhbGxpZWRtYXJrZXRpbmcubmV0Ij50cmFmZmljQGFsbGllZG1hcmtldGluZy5uZXQ8L0E+PC9C PjwvU1BBTj48L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+Jm5ic3A7PC9U RD4NCgkJCQkJPC9UUj4NCgkJCQkJPFRSPg0KCQkJCQkgPFREPjxTUEFOIGNsYXNzPSJnZW5lcmFs Ij48Qj5Gb3IgQWRkaXRpb25hbCBJbmZvcm1hdGlvbiBBYm91dCBQdXJjaGFzaW5nDQoJCQkJCSAg VHJhZmZpYyBUaHJvdWdoIEFsbGllZCBJbnRlcm5ldCBNYXJrZXRpbmcgUGxlYXNlIFZpc2l0DQoJ CQkJCSAgPEEgSFJFRj0iaHR0cDovL3RyYWZmaWMuYWxsaWVkbWFya2V0aW5nLm5ldCIgVEFSR0VU PSJfYmxhbmsiPmh0dHA6Ly90cmFmZmljLmFsbGllZG1hcmtldGluZy5uZXQ8L0E+PC9CPjwvU1BB Tj48L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+DQoJCQkJCSAgIDxIUj4N CgkJCQkJIDwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD4mbmJzcDs8L1RE Pg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PEI+PFNQQU4gY2xhc3M9ImdlbmVy YWwiPjxCSUc+PEJJRz48QklHPk9wdC1JbiBFbWFpbCBUcmFmZmljIEZvcg0KCQkJCQkgIFNhbGU8 L0JJRz48L0JJRz48L0JJRz48L1NQQU4+PC9CPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4N CgkJCQkJIDxURD48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEk+U3BlY2lhbCBQcmljaW5nIEZvciBF bWFpbCBUcmFmZmljIFRvIFlvdXIgV2ViDQoJCQkJCSAgU2l0ZTo8L0k+PC9TUEFOPjwvVEQ+DQoJ CQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD4mbmJzcDsgJm5ic3A7PC9URD4NCgkJCQkJ PC9UUj4NCgkJCQkJPFRSPg0KCQkJCQkgPFREPjxTUEFOIGNsYXNzPSJnZW5lcmFsIj48Qj5XZSBo YXZlIDcgZGlmZmVyZW50IE5ld3NsZXR0ZXJzIHRvIHNlbGVjdA0KCQkJCQkgIGZyb206PC9CPjwv U1BBTj48L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9 ImdlbmVyYWwiPjxJPlV0aWxpemUgb3VyIG1haW5zdHJlYW0gYW5kIGFkdWx0IG5ld3NsZXR0ZXJz DQoJCQkJCSAgdG8gYnJvYWRjYXN0IHlvdXIgbWVzc2FnZSBvdXQgdG8gb3ZlciAxMiBtaWxsaW9u IE9wdC1pbiBNZW1iZXJzLiBQcmljZXMgYXJlDQoJCQkJCSAgYXMgbG93IGFzICQxLjAwIHBlciAx LDAwMCBkZWxpdmVyZWQgZW1haWxzLjwvST48L1NQQU4+PC9URD4NCgkJCQkJPC9UUj4NCgkJCQkJ PFRSPg0KCQkJCQkgPFREPiZuYnNwOzwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJ IDxURD48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEI+Rm9yIEFkZGl0aW9uYWwgSW5mb3JtYXRpb24g QWJvdXQgUHVyY2hhc2luZw0KCQkJCQkgIEVtYWlsIFRyYWZmaWMgVGhyb3VnaCBBbGxpZWQgSW50 ZXJuZXQgTWFya2V0aW5nIFBsZWFzZSBWaXNpdA0KCQkJCQkgIDxBIEhSRUY9Imh0dHA6Ly9idWxr ZW1haWwuYWxsaWVkbWFya2V0aW5nLm5ldCIgVEFSR0VUPSJfYmxhbmsiPmh0dHA6Ly9idWxrZW1h aWwuYWxsaWVkbWFya2V0aW5nLm5ldDwvQT48L0I+PC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJ CQkJCTxUUj4NCgkJCQkJIDxURD4NCgkJCQkJICAgPEhSPg0KCQkJCQkgPC9URD4NCgkJCQkJPC9U Uj4NCgkJCQkJPFRSPg0KCQkJCQkgPFREPiZuYnNwOzwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxU Uj4NCgkJCQkJIDxURD48Qj48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEJJRz48QklHPjxCSUc+Tm9u LU9wdC1JbiBFbWFpbA0KCQkJCQkgIExpc3RzPC9CSUc+PC9CSUc+PC9CSUc+PC9TUEFOPjwvQj48 L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9ImdlbmVy YWwiPjxJPlNwZWNpYWwgUHJpY2luZyBGb3IgRW1haWwgVHJhZmZpYyBUbyBZb3VyIFdlYg0KCQkJ CQkgIFNpdGU6PC9JPjwvU1BBTj48L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8 VEQ+Jm5ic3A7PC9URD4NCgkJCQkJPC9UUj4NCgkJCQkJPFRSPg0KCQkJCQkgPFREPjxTUEFOIGNs YXNzPSJnZW5lcmFsIj48Qj5XZSBoYXZlIHZhcmlvdXMgZGlmZmVyZW50IG5vbi1PcHQtSW4gTGlz dHMgZm9yDQoJCQkJCSAgc2FsZS4gVmlzaXQgb3VyIGVtYWlsIHNpdGUgYXQNCgkJCQkJICA8QSBI UkVGPSJodHRwOi8vYnVsa2VtYWlsLmFsbGllZG1hcmtldGluZy5uZXQiIFRBUkdFVD0iX2JsYW5r Ij5odHRwOi8vYnVsa2VtYWlsLmFsbGllZG1hcmtldGluZy5uZXQ8L0E+DQoJCQkJCSAgZm9yIGFk ZGl0aW9uYWwgZGV0YWlscy48L0I+PC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4N CgkJCQkJIDxURD4NCgkJCQkJICAgPEhSPg0KCQkJCQkgPC9URD4NCgkJCQkJPC9UUj4NCgkJCQkJ PFRSPg0KCQkJCQkgPFREPiZuYnNwOzwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJ IDxURD48Qj48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEJJRz48QklHPjxCSUc+U0VDVVJFDQoJCQkJ CSAgRU1BSUxJTkc8L0JJRz48L0JJRz48L0JJRz48L1NQQU4+PC9CPjwvVEQ+DQoJCQkJCTwvVFI+ DQoJCQkJCTxUUj4NCgkJCQkJIDxURD48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+RG8geW91IGhhdmUg YSBsaXN0IGFuZCBuZWVkIHVzIHRvIHNlbmQgb3V0IHlvdXINCgkJCQkJICBlbWFpbHMgdGhyb3Vn aCBvdXIgc2VydmVyPyBObyBwcm9ibGVtISBXZSBjYW4gZG8gaXQgZm9yIG9ubHkgNTAgY2VudHMg cGVyDQoJCQkJCSAgMSwwMDAuPC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJ CQkJIDxURD4mbmJzcDs8L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQ QU4gY2xhc3M9ImdlbmVyYWwiPjxCPmNhbGwgdXMgYXQgOTczLjk5Mi4zOTg1IG9yIGVtYWlsDQoJ CQkJCSAgPEEgSFJFRj0ibWFpbHRvOnRyYWZmaWNAYWxsaWVkbWFya2V0aW5nLm5ldCI+dHJhZmZp Y0BhbGxpZWRtYXJrZXRpbmcubmV0PC9BPjwvQj48L1NQQU4+PC9URD4NCgkJCQkJPC9UUj4NCgkJ CQkJPFRSPg0KCQkJCQkgPFREPg0KCQkJCQkgICA8SFI+DQoJCQkJCSA8L1REPg0KCQkJCQk8L1RS Pg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+Jm5ic3A7PC9URD4NCgkJCQkJPC9UUj4NCgkJCQkJPFRS Pg0KCQkJCQkgPFREPjxCPjxTUEFOIGNsYXNzPSJnZW5lcmFsIj48QklHPjxCSUc+PEJJRz5GdXR1 cmVIaXRzIFRyYWZmaWMgLSA0DQoJCQkJCSAgRlJFRSE8L0JJRz48L0JJRz48L0JJRz48L1NQQU4+ PC9CPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD48U1BBTiBjbGFzcz0i Z2VuZXJhbCI+RnV0dXJlSGl0cyBpcyBhIHNvZnR3YXJlIHByb2dyYW0gaG9zdGVkIG9uIG91cg0K CQkJCQkgIHNlcnZlciB0aGF0Jm5ic3A7cGxhY2VzIGEgJm5ic3A7SUNPTiBvbiB5b3VyIHVzZXJz IGRlc2t0b3AsIGZhdm9yaXRlcywNCgkJCQkJICBsaW5rcywmbmJzcDtzdGFydCBidXR0b24gYW5k IGNoYW5nZXMgdGhlaXIgaG9tZXBhZ2UuIFRoaXMgaXMgZG9uZSBlaXRoZXINCgkJCQkJICBhdXRv bWF0aWNhbGx5IG9yIHdpdGggYWxlcnQuIFRoaXMgcHJvZHVjdCBpcyBmcmVlIGFuZCBpcyBsb2Nh dGVkIG9uIG91cg0KCQkJCQkgIDxBIEhSRUY9Imh0dHA6Ly93d3cuYWxsaWVkbWFya2V0aW5nLm5l dCI+Y29ycG9yYXRlIHdlYiBzaXRlPC9BPiBvciBvbg0KCQkJCQkgIDxBIEhSRUY9Imh0dHA6Ly9m dXR1cmVoaXRzLmFsbGllZG1hcmtldGluZy5uZXQiPmh0dHA6Ly9mdXR1cmVoaXRzLmFsbGllZG1h cmtldGluZy5uZXQ8L0E+PC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJ IDxURD4mbmJzcDs8L1REPg0KCQkJCQk8L1RSPg0KCQkJCSAgICAgIDwvVEFCTEU+DQoJCQkJICAg IDwvVEQ+DQoJCQkJICA8L1RSPg0KCQkJCTwvVEFCTEU+DQoJCQkgICAgICA8L1REPg0KCQkJICAg IDwvVFI+DQoJCQkgICAgPFRSPg0KCQkJICAgICAgPFREPg0KCQkJCSAgPEhSPg0KCQkJICAgICAg PC9URD4NCgkJCSAgICA8L1RSPg0KCQkJICAgIDxUUj4NCgkJCSAgICAgIDxURD48U1BBTiBjbGFz cz0iZ2VuZXJhbCI+VG8gcmVtb3ZlIHlvdXIgZW1haWwgYWRkcmVzcyBmcm9tIHRoaXMgbGlzdCBh bmQNCgkJCQlhbnkgb3RoZXIgbGlzdHMgYXNzb2NpYXRlZCB0byBUaGUtRW1haWwtSW5mb3JtYXRv cnkNCgkJCQk8QSBIUkVGPSJodHRwOi8vYWRzZXJ2ZXIuY3liZXJzdWJzY3JpYmVyLmNvbS9yZW1v dmUuaHRtbCI+Q0xJQ0sNCgkJCQlIRVJFPC9BPjwvU1BBTj48L1REPg0KCQkJICAgIDwvVFI+DQoJ CQkgIDwvVEFCTEU+DQoJCQk8L1REPg0KCQkgICAgICA8L1RSPg0KCQkgICAgPC9UQUJMRT4NCgkJ ICAgIDxQPg0KCQkgIDwvVEQ+DQoJCTwvVFI+DQoJICAgICAgPC9UQUJMRT4NCgkgICAgPC9URD4N CgkgIDwvVFI+DQoJPC9UQUJMRT4NCiAgICAgIDwvVEQ+DQogICAgPC9UUj4NCiAgPC9UQUJMRT4N CjwvQ0VOVEVSPg0KPFA+DQo8L0JPRFk+PC9IVE1MPg0K From bob@redivi.com Sat Apr 13 15:16:41 2002 From: bob@redivi.com (Bob Ippolito) Date: Sat, 13 Apr 2002 10:16:41 -0400 Subject: [Pythonmac-SIG] Obtaining the hardware address of the first network card In-Reply-To: Message-ID: <13648B97-4EE9-11D6-ABDC-0003938210D6@redivi.com> Each ethernet controller in every OS I've ever used has an index number (thats where en0, en1,.. enX come from), in OS X it's the order in which they're detected by the kernel. You can find it out with sysctl and ioctl (I don't remember if you need to use ioctl for reading network info though, but you definitely do for writing).. they're both more or less talking to the kernel "directly". afaik there isn't a more high level way other than spawning a copy of ifconfig or maybe nidump (theoretically, but i dont think that ethers is populated in NetInfo yet) or something. You could of course always look at the source for ifconfig if you were stumped, it is readily available in the Darwin CVS repository (which can probably even be browsed online). I actually think Apple may have written a tutorial on this I have no idea how you would do it on OS9. man 3 sysctl and man 3 ioctl should tell you most of what you need to know for OS X, unfortunately these aren't available from python and aren't cross-platform (for doing what you want to do) anyways. Basically you're either going to have to write a C module to do it (especially, I would think, for OS9) that you could actually adapt to other platforms (the other unix-likes and win32) or find some nasty set of kludges. I'm guessing he's looking for a "serial number" for the computer for some sort of authentication or verification, in which case the ethernet adapter with the lowest index makes the most sense, since it is most likely (especially with modern macs) to be grafted onto the motherboard and reporting its unique MAC address whether or not the user wants it to. -bob On Friday, April 12, 2002, at 02:10 AM, Deirdre Saoirse Moen wrote: > At 12:18 AM +0200 4/12/02, Pieter Claerhout wrote: >> is there a way to obtain the hardware address of the built-in network >> card >> of your Mac using Python? I found way to get it under command line >> python in >> OS X, but it should work on all macintoshes... > > In theory, there could be multiple addresses, so how do you presume to > figure out which one? And some Macs don't have ethernet. :) From bob@redivi.com Sat Apr 13 15:29:54 2002 From: bob@redivi.com (Bob Ippolito) Date: Sat, 13 Apr 2002 10:29:54 -0400 Subject: [Pythonmac-SIG] Obtaining the hardware address of the first network card In-Reply-To: Message-ID: http://developer.apple.com/techpubs/mac/Networking/Networking-262.html That should have enough info for you to do it on OS9, either that or one of the techpubs it links to. No idea how to do it from pure python, it's probably not quite so possible. On Friday, April 12, 2002, at 02:10 AM, Deirdre Saoirse Moen wrote: > At 12:18 AM +0200 4/12/02, Pieter Claerhout wrote: >> is there a way to obtain the hardware address of the built-in network >> card >> of your Mac using Python? I found way to get it under command line >> python in >> OS X, but it should work on all macintoshes... > > In theory, there could be multiple addresses, so how do you presume to > figure out which one? And some Macs don't have ethernet. :) > -- _Deirdre Stash-o-Matic: http://fuzzyorange.com > http://deirdre.net > "I'm writing a book. I've got the page numbers done." - Steven Wright > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From csmith@blakeschool.org Sat Apr 13 20:01:02 2002 From: csmith@blakeschool.org (Christopher Smith) Date: Sat, 13 Apr 2002 14:01:02 -0500 Subject: [Pythonmac-SIG] ResolveAliasFile/macfs problems Message-ID: ResolveAliasFile (and other macfs functions) are not as robust as macpath functions when it comes to testing a path containing an alias. For example, path 'macintosh hd:desktop folder:f:h:ka:' is the path to the file 'macintosh hd:desktop folder:k:' generated during a walk of folder f. h is an alias in f that points to a desktop folder named h; ka is an alias within h that points to the folder k on the desktop. {Is there any nice way to write what I just said??} While exists() can tell that it exists, an alias resolution fails as the following interactive sessions shows: >>> s 'macintosh hd:desktop folder:f:h:ka:' >>> macpath.exists(s) 1 >>> macpath.isdir(s) 1 >>> macpath.isfile(s) 0 >>> macfs.ResolveAliasFile(s) Traceback (most recent call last): File "", line 1, in ? MacOS.Error: (-120, 'Directory not found') The folder does exist, though, and can be resolved if the reference to f is bypassed in the path: >>> macfs.ResolveAliasFile('macintosh hd:desktop folder:k') (FSSpec((-1, 16, 'K')), 1, 0) The resolution of anything in folder h fails. Here I try to resolve the fss to the file h1 that exists in h: >>> macfs.ResolveAliasFile('macintosh hd:desktop folder:f:h:h1') Traceback (most recent call last): File "", line 1, in ? MacOS.Error: (-120, 'Directory not found') When I bypass folder f in the path, the fss is returned: >>> macfs.ResolveAliasFile('macintosh hd:desktop folder:h:h1') (FSSpec((-1, 184613, 'h1')), 0, 0) The same trouble plagues macfs.copy: >>> p='macintosh hd:desktop folder:' >>> macostools.copy(p+'k:jnk',p+'test') #this works >>> macostools.copy(p+"h:ka:jnk",p+'test') #fails Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Applications (Mac OS 9):Python 2.2:Mac:Lib:macostools.py", line 85, in copy srcfss = macfs.FSSpec(src) MacOS.Error: (-120, 'Directory not found') A workaround that I have used is to create a resolve() function (below) that rebuilds the path one element at a time, resolving elements along the way so a valid path is finally obtained. I'm not sure which module should be improved: macpath.walk() so it doesn't pass on bogus paths (but would the corrected paths be undesireable in some cases?); macfs so it always resolves paths no matter how convoluted; macfs so it contains a new function that will provide a tool to do the de-mangling of the paths received from walk. Any ideas? I submitted this as a bug to sourceforge as 543464. /c #### def resolve(s, justPath=0): """Get an absolute path from this possibly convoluted path that would give ResolveAliasFile problems. If justPath=1 then only the path up to the last entity in the path will be resolved, otherwise the whole path will be resolved and you will have the actual path to the item if it exists on disk. If the file does not exist, an error is raised.""" # # If you resolve all but the last item in the s then you will be able to call # resolveAliasFile and find out if the thing is an alias or not otherwise # you will have resolved the entire path to a real item if it exists. # p=abspath(s).split(":") # Define the indice to use so slices below will (or will not) include # the last element in the path. if justPath: last=-1 else: last=len(p) rv=p[0]+":" for pi in p[1:last]: try: d=join(rv,pi) rv=macfs.ResolveAliasFile(d)[0].as_pathname() except: raise "File not found." return join(rv,p[last:]) #### From Jack.Jansen@oratrix.com Sat Apr 13 22:53:28 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 13 Apr 2002 23:53:28 +0200 Subject: [Pythonmac-SIG] ResolveAliasFile/macfs problems In-Reply-To: Message-ID: On zaterdag, april 13, 2002, at 09:01 , Christopher Smith wrote: > ResolveAliasFile (and other macfs functions) are not as robust as macpath > functions when it comes to testing a path containing an alias. Chris, this isn't a bug, it's the way pathname work for MacOS toolbox routines. You cannot use aliases within them. GUSI works around this, resolving aliases along the way, but macfs and such give you the bare toolbox API. But I'd like to put your routine in macostools, is that okay? (in the SF bug reply I asked for you to re-upload it, but that isn't needed as the copy in this email isn't mangled as the one in the sf bug report was). -- - 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@cwi.nl Mon Apr 15 09:28:07 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 15 Apr 2002 10:28:07 +0200 Subject: [Pythonmac-SIG] Re: ThreadSafety and Callbacks In-Reply-To: Message-ID: [Martin: I hope you don't mind that I'm bringing you in on this discussion] On Friday, April 12, 2002, at 12:05 , Donovan Preston wrote: > Jack and Just (and anyone else), > > As you know, I have been keenly interested in issues surrounding > CarbonEvent programming for quite a while now, since I see the Carbon > Event Manager as an elegant solution to event-based programming. > Unfortunately, thread safety issues aren't quite as elegant. > > I hate to throw more unfinished patches onto the fire, but I have been > working on exactly the issue you have been discussing in "Threading and > FrameWork.Application", and also in the thread on Python-dev. I thought > it would be better to submit my unfinished solution to share my > learning experience than to try to finish it in silence while someone > else did the same work in an unrelated way. Donovan, I'm in the process of climbing up a whole different tree. I'm posting this here just in case you've been up this tree as well and found out it doesn't lead anywhere. What I want to do is the following: - Store the Python thread state pointer in pthread per-thread data (with pthread_setspecific and friends). - Release the GIL when we do a toolbox call. *BUT* this works only for toolbox calls under our control. If some library we call (Tk, for instance) does a toolbox call we may end up in a callback routine while still holding the GIL. - When we enter a callback determine whether the GIL is held. If it is not held we simply acquire it and arrange for it to be released when we're returning from the callback. - If the GIL is held we determine who holds it (through the per-thread stored value). If it is us then there's no problem and we do the callback, making sure we don't release te GIL at the end. - If the GIL is held by someone else we also attempt to obtain it, blocking us until the other thread releases it. Again we free it at the end of the callback. For the Carbon event callbacks this should be good enough, I 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 Benjamin.Schollnick@usa.xerox.com Mon Apr 15 17:09:02 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Mon, 15 Apr 2002 12:09:02 -0400 Subject: [Pythonmac-SIG] Internet Config Message-ID: I've noticed a small issue, that maybe intentional in the IC module. Internet_config = ic.IC() .... .... Internet_config.settypecreator ( filename ) will return with a MacOS.Error (-666) if the filename's (extension) it is passed is not registered in the Control Panels --> Internet --> Advanced pane. For example, until I registered python as .py / .pyo / .pyc, it would die with a -666 when I attempted to run a IC modified version of fixfiletypes.... Until I modified my Internet configuration. Is this intentional? Shouldn't the error be more informative? (i.e. MacOs.File_Extension_Not_Registered ?) I didn't do any serious investigation, but at first glance: Mac:Lib:IC.py def settypecreator (self, file): .... .... fss.SetCreatorType (record[2], record[1]) .... .... Should probably have a Try / Except block, with the except containing a "return MacOs.Whatever_we_name_the_exception". - Benjamin From csmith@blakeschool.org Mon Apr 15 22:41:55 2002 From: csmith@blakeschool.org (Christopher Smith) Date: Mon, 15 Apr 2002 16:41:55 -0500 Subject: [Pythonmac-SIG] recursive memory Message-ID: I'm making a modification to the walk() function on the Mac so it avoids getting caught in an alias loop between folders (i.e. walking a folder which has an alias to another folder which has an alias of the first folder). The way I do this is store the file specs in a dictionary. I have two questions. 1) Here's what I'm doing: macpath module -------------- def walk(t, f, a, visited={}): . . . for file in listOfFiles: . . . if visited.has_key(filespec): continue visited[filespec]='' t=join(t,file) walk(t, f, a, visited) # I pass the modified dictionary #demo walk(t, f, a) #no dictionary sent so it should start at {} I need the dictionary to start at {} every time I first give the walk, but then want it updated as I go deeper in the walk--so the main script call leaves the dictionary off but recursive calls send the modified dictionary. Is this the right way to go about this? 2) I would also like to find out if an alias points to another (unmounted) volume. The only problem is that if the volume is unmounted, the ResolveAliasFile routine (or other routines that will give file information, like mac.stat()) will prompt me to insert the volume; I would like to have the walk be unattended and so would like a way to override the insert volume reaction and just know that the alias points to an unmounted volume and just skip it. Is there another way to detect this condition without being asked to insert the missing volume? /c From junkster@rochester.rr.com Mon Apr 15 23:20:39 2002 From: junkster@rochester.rr.com (Benjamin Schollnick) Date: Mon, 15 Apr 2002 18:20:39 -0400 Subject: [Pythonmac-SIG] Fixfiletypes via IC (first draft) In-Reply-To: Message-ID: Folks, This is not the finished version, but it's a start.... This absolutely requires v2.21, due to the IC issues in v2.2 (& lower?). First of all, I dislike the -666 issue (if the extension/filetype is not registered in the Internet Control panel, it dies with a fatal exception.... unless caught with a try/except). And second, It blindly tries to change every file, even if it's already set correctly. I'm going to change this to use another more similar scheme. Check the existing mapping vs. IC, and only change if needed. But this is the first attempt. If anyone has any suggestions to streamline this, please let me know. BTW-> Adding the progress bar was rather annoying, any suggestions on simplifying it, without using GLOBALs? (I dislike globals, and even this method stinks too much like a global...) - Benjamin # # Fixfiletypes - Set mac filetypes to something sensible, # recursively down a directory tree. # # It will only touch extensions it feels pretty sure about. # This script is useful after copying files from unix. # # Jack Jansen, CWI, 1995. # import os import ic import MacOS import macfs import sys import macostools import string import EasyDialogs class GUI_Features : def __init__(self): self.max_file_count = 0 self.current_file_count = 0 self.Progress_Bar = None def set_max_files (self, count ): self.max_file_count = count def return_max_files (self): return self.max_file_count def increment_file_count (self, increment = 1 ): self.current_file_count = self.current_file_count + increment def return_incremental ( self ): return self.current_file_count def init_progress_bar ( self, text ): self.Progress_Bar = EasyDialogs.ProgressBar ( text, self.max_file_count ) def change_pb_text ( self, text ): self.Progress_Bar.label ( text ) def refresh_progress_bar (self): self.Progress_Bar.set ( self.current_file_count, max=self.max_file_count) class tree_file_count: def __init__ ( self ): self.file_count = 0 def walktree_count (self, args, dirname, names): self.file_count = self.file_count + len(names) def directory_to_count (self, pathname ): os.path.walk ( pathname, self.walktree_count, None) def total_files ( self ): return self.file_count def reset_to_zero ( self ): self.file_count = 0 def walktree(name, change, g_app, total, IC): # # Walk file by file through the listings of each sub directory # if os.path.isfile(name) and not os.path.isdir (name): try: # # Skip .DS_Store files # if name.endswith (".DS_Store"): return # # Automatic IC mapper.... (Last touched isn't really needed, # settypecreator automatically does it) # IC.settypecreator ( name ) fs = macfs.FSSpec(name) macostools.touched (fs) except MacOS.Error: # # This file type is not defined in the Internet Control Panel, skip. # print "%s is not registered in Internet Control Panel" % name elif os.path.isdir(name): # print '->', name files = os.listdir(name) for f in files: g_app.increment_file_count () g_app.change_pb_text ( "\t%s of %s" % ( g_app.return_incremental (), total.total_files () ) ) g_app.refresh_progress_bar ( ) walktree(os.path.join(name, f), change, g_app, total, IC ) def run( change ): fss, ok = macfs.GetDirectory('Folder to search:') if not ok: sys.exit(0) GUI = GUI_Features() total_count = tree_file_count () total_count.directory_to_count ( fss.as_pathname() ) Internet_config = ic.IC () GUI.init_progress_bar ( "Files to Process" ) GUI.set_max_files ( total_count.total_files() ) walktree(fss.as_pathname(), change, GUI, total_count, Internet_config) if __name__ == '__main__': run(1) From pythontutor@venix.com Mon Apr 15 23:54:29 2002 From: pythontutor@venix.com (Lloyd Kvam) Date: Mon, 15 Apr 2002 18:54:29 -0400 Subject: [Pythonmac-SIG] Re: [Tutor] recursive memory (for Q 1) References: Message-ID: <3CBB5A25.5050402@venix.com> I have made this same mistake. def walk(t, f, a, visited={}): visited is given a clean dictionary only ONCE, when the function is defined. If you call walk a second time, without specifying visited, you will simply default to using the same dictionary again. One solution is: def walk(t, f, a, visited=None): if visited is None: visited = {} This provides a clean dictionary everytime walk is called without the visited argument. I can't help on Q2. Christopher Smith wrote: > I'm making a modification to the walk() function on the Mac so it avoids > getting caught in an alias loop between folders (i.e. walking a folder > which has an alias to another folder which has an alias of the first > folder). The way I do this is store the file specs in a dictionary. I > have two questions. > > 1) > Here's what I'm doing: > > macpath module > -------------- > def walk(t, f, a, visited={}): > . > . > . > for file in listOfFiles: > . > . > . > if visited.has_key(filespec): continue > visited[filespec]='' > t=join(t,file) > walk(t, f, a, visited) # I pass the modified dictionary > > #demo > walk(t, f, a) #no dictionary sent so it should start at {} > > I need the dictionary to start at {} every time I first give the walk, but > then want it updated as I go deeper in the walk--so the main script call > leaves the dictionary off but recursive calls send the modified > dictionary. Is this the right way to go about this? > > 2) > I would also like to find out if an alias points to another (unmounted) > volume. The only problem is that if the volume is unmounted, the > ResolveAliasFile routine (or other routines that will give file > information, like mac.stat()) will prompt me to insert the volume; I would > like to have the walk be unattended and so would like a way to override > the insert volume reaction and just know that the alias points to an > unmounted volume and just skip it. Is there another way to detect this > condition without being asked to insert the missing volume? > > /c > > > > > _______________________________________________ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > > -- Lloyd Kvam Venix Corp. 1 Court Street, Suite 378 Lebanon, NH 03766-1358 voice: 603-443-6155 fax: 801-459-9582 From Jack.Jansen@cwi.nl Tue Apr 16 10:03:10 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 16 Apr 2002 11:03:10 +0200 Subject: [Pythonmac-SIG] Internet Config In-Reply-To: Message-ID: On Monday, April 15, 2002, at 06:09 , Schollnick, Benjamin wrote: > I've noticed a small issue, that maybe intentional in the IC module. > > Internet_config = ic.IC() > .... > > .... > > Internet_config.settypecreator ( filename ) > > will return with a MacOS.Error (-666) if the filename's (extension) it > is > passed > is not registered in the Control Panels --> Internet --> Advanced pane. That's not a bug, that's a feature:-) The lowlevel IC routines returns that OSErr code. The only problem is that the number "-666" is not known to the code that creates the string for the error, because it (apparently) isn't an official Apple error. I'll see if I can add it manually somehow ("Unknown extension"). You should simply put a try/except around the call. -- - 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@cwi.nl Tue Apr 16 10:03:36 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 16 Apr 2002 11:03:36 +0200 Subject: [Pythonmac-SIG] recursive memory In-Reply-To: Message-ID: On Monday, April 15, 2002, at 11:41 , Christopher Smith wrote: > I'm making a modification to the walk() function on the Mac so it avoids > getting caught in an alias loop between folders (i.e. walking a folder > which has an alias to another folder which has an alias of the first > folder). The way I do this is store the file specs in a dictionary. I > have two questions. macpath.walk() (or actually os.path.walk) is explicitly define *not* to do special things for symlinks or aliases. But still: the functionality is nice, so maybe we should put it in a new function macostools.walk. > walk(t, f, a) #no dictionary sent so it should start at {} > > I need the dictionary to start at {} every time I first give the walk, > but > then want it updated as I go deeper in the walk--so the main script call > leaves the dictionary off but recursive calls send the modified > dictionary. Is this the right way to go about this? Yes, don't pass visited={}, because it's going to be the visited *object* that is modified, so the next call will use the last value of visited (as you've undoubtedly noticed:-). The idiom is to do def walk(..., visited=None): if visited is None: visited = {} > 2) > I would also like to find out if an alias points to another (unmounted) > volume. The only problem is that if the volume is unmounted, the > ResolveAliasFile routine (or other routines that will give file > information, like mac.stat()) will prompt me to insert the volume; I > would > like to have the walk be unattended and so would like a way to override > the insert volume reaction and just know that the alias points to an > unmounted volume and just skip it. Is there another way to detect this > condition without being asked to insert the missing volume? I can't find anything, also not in the lower level alias handling routines (i.e. what is partially exposed via macfs.Alias methods). -- - 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@cwi.nl Tue Apr 16 10:03:47 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 16 Apr 2002 11:03:47 +0200 Subject: [Pythonmac-SIG] recursive memory In-Reply-To: Message-ID: On Monday, April 15, 2002, at 11:41 , Christopher Smith wrote: > I'm making a modification to the walk() function on the Mac so it avoids > getting caught in an alias loop between folders (i.e. walking a folder > which has an alias to another folder which has an alias of the first > folder). The way I do this is store the file specs in a dictionary. I > have two questions. macpath.walk() (or actually os.path.walk) is explicitly define *not* to do special things for symlinks or aliases. But still: the functionality is nice, so maybe we should put it in a new function macostools.walk. > walk(t, f, a) #no dictionary sent so it should start at {} > > I need the dictionary to start at {} every time I first give the walk, > but > then want it updated as I go deeper in the walk--so the main script call > leaves the dictionary off but recursive calls send the modified > dictionary. Is this the right way to go about this? Yes, don't pass visited={}, because it's going to be the visited *object* that is modified, so the next call will use the last value of visited (as you've undoubtedly noticed:-). The idiom is to do def walk(..., visited=None): if visited is None: visited = {} > 2) > I would also like to find out if an alias points to another (unmounted) > volume. The only problem is that if the volume is unmounted, the > ResolveAliasFile routine (or other routines that will give file > information, like mac.stat()) will prompt me to insert the volume; I > would > like to have the walk be unattended and so would like a way to override > the insert volume reaction and just know that the alias points to an > unmounted volume and just skip it. Is there another way to detect this > condition without being asked to insert the missing volume? I can't find anything, also not in the lower level alias handling routines (i.e. what is partially exposed via macfs.Alias methods). -- - 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 junkster@rochester.rr.com Tue Apr 16 11:02:59 2002 From: junkster@rochester.rr.com (Benjamin Schollnick) Date: Tue, 16 Apr 2002 06:02:59 -0400 Subject: [Pythonmac-SIG] Internet Config In-Reply-To: Message-ID: on 4/16/02 5:03 AM, Jack Jansen at Jack.Jansen@cwi.nl wrote: >> >> Internet_config.settypecreator ( filename ) >> >> will return with a MacOS.Error (-666) if the filename's (extension) it >> is >> passed >> is not registered in the Control Panels --> Internet --> Advanced pane. > > That's not a bug, that's a feature:-) > > The lowlevel IC routines returns that OSErr code. The only problem is > that the number "-666" is not known to the code that creates the string > for the error, because it (apparently) isn't an official Apple error. > I'll see if I can add it manually somehow ("Unknown extension"). > > You should simply put a try/except around the call. Already did.... It's just such a generic error though, I can't be positive that it wasn't caused by something else... (i.e. just at that moment the universe has been destroyed?) Hopefully Mark II will be ready tonight.. - Benjamin From csmith@blakeschool.org Tue Apr 16 14:56:08 2002 From: csmith@blakeschool.org (Christopher Smith) Date: Tue, 16 Apr 2002 08:56:08 -0500 Subject: [Pythonmac-SIG] Re: recursive memory In-Reply-To: References: Message-ID: This is a multi-part message in MIME format. ----=_--0094bd9f.0094bc9b.b8e197a8 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Jack.Jansen@cwi.nl writes: > >On Monday, April 15, 2002, at 11:41 , Christopher Smith wrote: > >> I'm making a modification to the walk() function on the Mac so it avoids >> getting caught in an alias loop between folders (i.e. walking a folder >> which has an alias to another folder which has an alias of the first >> folder). The way I do this is store the file specs in a dictionary. I >> have two questions. > >macpath.walk() (or actually os.path.walk) is explicitly define *not* to >do special things for symlinks or aliases. But still: the functionality >is nice, so maybe we should put it in a new function macostools.walk. By "special things" you don't mean that walk() is suppose to skip over aliases, do you? Because as it is right now, aliases are walked. And if they are walked they can lead to two problems: 1) an infinite loop between two folders 2) bad pathnames being passed to the walkfunc (which is the issue that resolve() was written to address). If these undesirable behaviors were deemed bugs then the macpath.walk() function could just be modified. I have attached a version which has the same behavior as the original but now has 3 optional arguments to handle walking aliases, other volumes, and a dictionary to prevent walking previously walked folders. Also, I made the modification to islink() so it would return a 1 if a file is an alias and 0 if it is not (or if it can't be resolved, perhaps because someone else's walk gave it a path with multiple aliases in it, in which case the resolve function that you have could be used by that person to demangle the path first). /c ----=_--0094bd9f.0094bc9b.b8e197a8 Content-Type: multipart/appledouble; boundary="--=_--b8e197a9.0d740840.0000008b"; x-mac-type="54455854"; x-mac-creator="50797468" Content-Disposition: attachment; filename="macpath_new.py" ----=_--b8e197a9.0d740840.0000008b Content-Type: application/applefile; name="macpath_new.py" Content-Transfer-Encoding: base64 AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAADAAAASgAAAA4AAAAIAAAAWAAA ABAAAAAJAAAAaAAAACAAAAACAAAAiAAAAhxtYWNwYXRoX25ldy5weQROnwUETqHP CAAAAAgAAABURVhUUHl0aAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAHa AAAA2gAAAEIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADWe3MLAAAAcnVuX2FzX21haW5pAQAAAHMJAAAAc2VsZWN0aW9u KAIAAABpxyEAAGnHIQAAcwcAAAB0YWJzaXplKAIAAABpCAAAAGkBAAAAcwwAAAB3 aW5kb3dib3VuZHMoBAAAAGkJAAAAaSsAAABpNwIAAGlOAgAAcwwAAABmb250c2V0 dGluZ3MoBAAAAHMGAAAAR2VuZXZhaQAAAABpCgAAACgDAAAAaQAAAABpAAAAAGkA AAAAcxQAAABydW5fd2l0aF9pbnRlcnByZXRlcmkAAAAAMAAAAQAAAAHaAAAA2gAA AEJTT1JUBbIAgAAcADIAAFB5V1MAAAAKAIAAAAAAAAAKRgGwD3dpbmRvdyBzZXR0 aW5ncw== ----=_--b8e197a9.0d740840.0000008b Content-Type: text/plain; name="macpath_new.py" Content-Transfer-Encoding: base64 IiIiUGF0aG5hbWUgYW5kIHBhdGgtcmVsYXRlZCBvcGVyYXRpb25zIGZvciB0aGUg TWFjaW50b3NoLiIiIg0NaW1wb3J0IG9zDWZyb20gc3RhdCBpbXBvcnQgKg1pbXBv cnQgbWFjZnMgI2Nwcw0NX19hbGxfXyA9IFsibm9ybWNhc2UiLCJpc2FicyIsImpv aW4iLCJzcGxpdGRyaXZlIiwic3BsaXQiLCJzcGxpdGV4dCIsDSAgICAgICAgICAg ImJhc2VuYW1lIiwiZGlybmFtZSIsImNvbW1vbnByZWZpeCIsImdldHNpemUiLCJn ZXRtdGltZSIsDSAgICAgICAgICAgImdldGF0aW1lIiwiaXNsaW5rIiwiZXhpc3Rz IiwiaXNkaXIiLCJpc2ZpbGUiLA0gICAgICAgICAgICJ3YWxrIiwiZXhwYW5kdXNl ciIsImV4cGFuZHZhcnMiLCJub3JtcGF0aCIsImFic3BhdGgiXQ0NIyBOb3JtYWxp emUgdGhlIGNhc2Ugb2YgYSBwYXRobmFtZS4gIER1bW15IGluIFBvc2l4LCBidXQg PHM+Lmxvd2VyKCkgaGVyZS4NDWRlZiBub3JtY2FzZShwYXRoKToNICAgIHJldHVy biBwYXRoLmxvd2VyKCkNDQ1kZWYgaXNhYnMocyk6DSAgICAiIiJSZXR1cm4gdHJ1 ZSBpZiBhIHBhdGggaXMgYWJzb2x1dGUuDSAgICBPbiB0aGUgTWFjLCByZWxhdGl2 ZSBwYXRocyBiZWdpbiB3aXRoIGEgY29sb24sDSAgICBidXQgYXMgYSBzcGVjaWFs IGNhc2UsIHBhdGhzIHdpdGggbm8gY29sb25zIGF0IGFsbCBhcmUgYWxzbyByZWxh dGl2ZS4NICAgIEFueXRoaW5nIGVsc2UgaXMgYWJzb2x1dGUgKHRoZSBzdHJpbmcg dXAgdG8gdGhlIGZpcnN0IGNvbG9uIGlzIHRoZQ0gICAgdm9sdW1lIG5hbWUpLiIi Ig0NICAgIHJldHVybiAnOicgaW4gcyBhbmQgc1swXSAhPSAnOicNDQ1kZWYgam9p bihzLCAqcCk6DSAgICBwYXRoID0gcw0gICAgZm9yIHQgaW4gcDoNICAgICAgICBp ZiAobm90IHMpIG9yIGlzYWJzKHQpOg0gICAgICAgICAgICBwYXRoID0gdA0gICAg ICAgICAgICBjb250aW51ZQ0gICAgICAgIGlmIHRbOjFdID09ICc6JzoNICAgICAg ICAgICAgdCA9IHRbMTpdDSAgICAgICAgaWYgJzonIG5vdCBpbiBwYXRoOg0gICAg ICAgICAgICBwYXRoID0gJzonICsgcGF0aA0gICAgICAgIGlmIHBhdGhbLTE6XSAh PSAnOic6DSAgICAgICAgICAgIHBhdGggPSBwYXRoICsgJzonDSAgICAgICAgcGF0 aCA9IHBhdGggKyB0DSAgICByZXR1cm4gcGF0aA0NDWRlZiBzcGxpdChzKToNICAg ICIiIlNwbGl0IGEgcGF0aG5hbWUgaW50byB0d28gcGFydHM6IHRoZSBkaXJlY3Rv cnkgbGVhZGluZyB1cCB0byB0aGUgZmluYWwNICAgIGJpdCwgYW5kIHRoZSBiYXNl bmFtZSAodGhlIGZpbGVuYW1lLCB3aXRob3V0IGNvbG9ucywgaW4gdGhhdCBkaXJl Y3RvcnkpLg0gICAgVGhlIHJlc3VsdCAocywgdCkgaXMgc3VjaCB0aGF0IGpvaW4o cywgdCkgeWllbGRzIHRoZSBvcmlnaW5hbCBhcmd1bWVudC4iIiINDSAgICBpZiAn Oicgbm90IGluIHM6IHJldHVybiAnJywgcw0gICAgY29sb24gPSAwDSAgICBmb3Ig aSBpbiByYW5nZShsZW4ocykpOg0gICAgICAgIGlmIHNbaV0gPT0gJzonOiBjb2xv biA9IGkgKyAxDSAgICBwYXRoLCBmaWxlID0gc1s6Y29sb24tMV0sIHNbY29sb246 XQ0gICAgaWYgcGF0aCBhbmQgbm90ICc6JyBpbiBwYXRoOg0gICAgICAgIHBhdGgg PSBwYXRoICsgJzonDSAgICByZXR1cm4gcGF0aCwgZmlsZQ0NDWRlZiBzcGxpdGV4 dChwKToNICAgICIiIlNwbGl0IGEgcGF0aCBpbnRvIHJvb3QgYW5kIGV4dGVuc2lv bi4NICAgIFRoZSBleHRlbnNpb24gaXMgZXZlcnl0aGluZyBzdGFydGluZyBhdCB0 aGUgbGFzdCBkb3QgaW4gdGhlIGxhc3QNICAgIHBhdGhuYW1lIGNvbXBvbmVudDsg dGhlIHJvb3QgaXMgZXZlcnl0aGluZyBiZWZvcmUgdGhhdC4NICAgIEl0IGlzIGFs d2F5cyB0cnVlIHRoYXQgcm9vdCArIGV4dCA9PSBwLiIiIg0NICAgIHJvb3QsIGV4 dCA9ICcnLCAnJw0gICAgZm9yIGMgaW4gcDoNICAgICAgICBpZiBjID09ICc6JzoN ICAgICAgICAgICAgcm9vdCwgZXh0ID0gcm9vdCArIGV4dCArIGMsICcnDSAgICAg ICAgZWxpZiBjID09ICcuJzoNICAgICAgICAgICAgaWYgZXh0Og0gICAgICAgICAg ICAgICAgcm9vdCwgZXh0ID0gcm9vdCArIGV4dCwgYw0gICAgICAgICAgICBlbHNl Og0gICAgICAgICAgICAgICAgZXh0ID0gYw0gICAgICAgIGVsaWYgZXh0Og0gICAg ICAgICAgICBleHQgPSBleHQgKyBjDSAgICAgICAgZWxzZToNICAgICAgICAgICAg cm9vdCA9IHJvb3QgKyBjDSAgICByZXR1cm4gcm9vdCwgZXh0DQ0NZGVmIHNwbGl0 ZHJpdmUocCk6DSAgICAiIiJTcGxpdCBhIHBhdGhuYW1lIGludG8gYSBkcml2ZSBz cGVjaWZpY2F0aW9uIGFuZCB0aGUgcmVzdCBvZiB0aGUNICAgIHBhdGguICBVc2Vm dWwgb24gRE9TL1dpbmRvd3MvTlQ7IG9uIHRoZSBNYWMsIHRoZSBkcml2ZSBpcyBh bHdheXMNICAgIGVtcHR5IChkb24ndCB1c2UgdGhlIHZvbHVtZSBuYW1lIC0tIGl0 IGRvZXNuJ3QgaGF2ZSB0aGUgc2FtZQ0gICAgc3ludGFjdGljIGFuZCBzZW1hbnRp YyBvZGRpdGllcyBhcyBET1MgZHJpdmUgbGV0dGVycywgc3VjaCBhcyB0aGVyZQ0g ICAgYmVpbmcgYSBzZXBhcmF0ZSBjdXJyZW50IGRpcmVjdG9yeSBwZXIgZHJpdmUp LiIiIg0NICAgIHJldHVybiAnJywgcA0NDSMgU2hvcnQgaW50ZXJmYWNlcyB0byBz cGxpdCgpDQ1kZWYgZGlybmFtZShzKTogcmV0dXJuIHNwbGl0KHMpWzBdDWRlZiBi YXNlbmFtZShzKTogcmV0dXJuIHNwbGl0KHMpWzFdDQ0NDWRlZiBpc2RpcihzKToN ICAgICIiIlJldHVybiB0cnVlIGlmIHRoZSBwYXRobmFtZSByZWZlcnMgdG8gYW4g ZXhpc3RpbmcgZGlyZWN0b3J5LiIiIg0NICAgIHRyeToNICAgICAgICBzdCA9IG9z LnN0YXQocykNICAgIGV4Y2VwdCBvcy5lcnJvcjoNICAgICAgICByZXR1cm4gMA0g ICAgcmV0dXJuIFNfSVNESVIoc3RbU1RfTU9ERV0pDQ0NIyBHZXQgc2l6ZSwgbXRp bWUsIGF0aW1lIG9mIGZpbGVzLg0NZGVmIGdldHNpemUoZmlsZW5hbWUpOg0gICAg IiIiUmV0dXJuIHRoZSBzaXplIG9mIGEgZmlsZSwgcmVwb3J0ZWQgYnkgb3Muc3Rh dCgpLiIiIg0gICAgc3QgPSBvcy5zdGF0KGZpbGVuYW1lKQ0gICAgcmV0dXJuIHN0 W1NUX1NJWkVdDQ1kZWYgZ2V0bXRpbWUoZmlsZW5hbWUpOg0gICAgIiIiUmV0dXJu IHRoZSBsYXN0IG1vZGlmaWNhdGlvbiB0aW1lIG9mIGEgZmlsZSwgcmVwb3J0ZWQg Ynkgb3Muc3RhdCgpLiIiIg0gICAgc3QgPSBvcy5zdGF0KGZpbGVuYW1lKQ0gICAg cmV0dXJuIHN0W1NUX01USU1FXQ0NZGVmIGdldGF0aW1lKGZpbGVuYW1lKToNICAg ICIiIlJldHVybiB0aGUgbGFzdCBhY2Nlc3MgdGltZSBvZiBhIGZpbGUsIHJlcG9y dGVkIGJ5IG9zLnN0YXQoKS4iIiINICAgIHN0ID0gb3Muc3RhdChmaWxlbmFtZSkN ICAgIHJldHVybiBzdFtTVF9BVElNRV0NDWRlZiBpc2xpbmsocyk6DSAgICAiIiJS ZXR1cm4gdHJ1ZSBpZiB0aGUgcGF0aG5hbWUgcmVmZXJzIHRvIGEgc3ltYm9saWMg bGluay4NICAgIEFsd2F5cyBmYWxzZSBvbiB0aGUgTWFjLCB1bnRpbCB3ZSB1bmRl cnN0YW5kIEFsaWFzZXMuKSIiIg0NICAgIHRyeToNICAgICAgICByZXR1cm4gbWFj ZnMuUmVzb2x2ZUFsaWFzRmlsZShzKVsyXSAjdXNlIHRvIGJlIDAgYWxsIHRoZSB0 aW1lDSAgICBleGNlcHQ6DSAgICAgICAgcmV0dXJuIDANDWRlZiBpc2ZpbGUocyk6 DSAgICAiIiJSZXR1cm4gdHJ1ZSBpZiB0aGUgcGF0aG5hbWUgcmVmZXJzIHRvIGFu IGV4aXN0aW5nIHJlZ3VsYXIgZmlsZS4iIiINDSAgICB0cnk6DSAgICAgICAgc3Qg PSBvcy5zdGF0KHMpDSAgICBleGNlcHQgb3MuZXJyb3I6DSAgICAgICAgcmV0dXJu IDANICAgIHJldHVybiBTX0lTUkVHKHN0W1NUX01PREVdKQ0NDWRlZiBleGlzdHMo cyk6DSAgICAiIiJSZXR1cm4gdHJ1ZSBpZiB0aGUgcGF0aG5hbWUgcmVmZXJzIHRv IGFuIGV4aXN0aW5nIGZpbGUgb3IgZGlyZWN0b3J5LiIiIg0NICAgIHRyeToNICAg ICAgICBzdCA9IG9zLnN0YXQocykNICAgIGV4Y2VwdCBvcy5lcnJvcjoNICAgICAg ICByZXR1cm4gMA0gICAgcmV0dXJuIDENDSMgUmV0dXJuIHRoZSBsb25nZXN0IHBy ZWZpeCBvZiBhbGwgbGlzdCBlbGVtZW50cy4NDWRlZiBjb21tb25wcmVmaXgobSk6 DSAgICAiR2l2ZW4gYSBsaXN0IG9mIHBhdGhuYW1lcywgcmV0dXJucyB0aGUgbG9u Z2VzdCBjb21tb24gbGVhZGluZyBjb21wb25lbnQiDSAgICBpZiBub3QgbTogcmV0 dXJuICcnDSAgICBwcmVmaXggPSBtWzBdDSAgICBmb3IgaXRlbSBpbiBtOg0gICAg ICAgIGZvciBpIGluIHJhbmdlKGxlbihwcmVmaXgpKToNICAgICAgICAgICAgaWYg cHJlZml4WzppKzFdICE9IGl0ZW1bOmkrMV06DSAgICAgICAgICAgICAgICBwcmVm aXggPSBwcmVmaXhbOmldDSAgICAgICAgICAgICAgICBpZiBpID09IDA6IHJldHVy biAnJw0gICAgICAgICAgICAgICAgYnJlYWsNICAgIHJldHVybiBwcmVmaXgNDWRl ZiBleHBhbmR2YXJzKHBhdGgpOg0gICAgIiIiRHVtbXkgdG8gcmV0YWluIGludGVy ZmFjZS1jb21wYXRpYmlsaXR5IHdpdGggb3RoZXIgb3BlcmF0aW5nIHN5c3RlbXMu IiIiDSAgICByZXR1cm4gcGF0aA0NDWRlZiBleHBhbmR1c2VyKHBhdGgpOg0gICAg IiIiRHVtbXkgdG8gcmV0YWluIGludGVyZmFjZS1jb21wYXRpYmlsaXR5IHdpdGgg b3RoZXIgb3BlcmF0aW5nIHN5c3RlbXMuIiIiDSAgICByZXR1cm4gcGF0aA0Nbm9y bV9lcnJvciA9ICdtYWNwYXRoLm5vcm1fZXJyb3I6IHBhdGggY2Fubm90IGJlIG5v cm1hbGl6ZWQnDQ1kZWYgbm9ybXBhdGgocyk6DSAgICAiIiJOb3JtYWxpemUgYSBw YXRobmFtZS4gIFdpbGwgcmV0dXJuIHRoZSBzYW1lIHJlc3VsdCBmb3INICAgIGVx dWl2YWxlbnQgcGF0aHMuIiIiDQ0gICAgaWYgIjoiIG5vdCBpbiBzOg0gICAgICAg IHJldHVybiAiOiIrcw0NICAgIGNvbXBzID0gcy5zcGxpdCgiOiIpDSAgICBpID0g MQ0gICAgd2hpbGUgaSA8IGxlbihjb21wcyktMToNICAgICAgICBpZiBjb21wc1tp XSA9PSAiIiBhbmQgY29tcHNbaS0xXSAhPSAiIjoNICAgICAgICAgICAgaWYgaSA+ IDE6DSAgICAgICAgICAgICAgICBkZWwgY29tcHNbaS0xOmkrMV0NICAgICAgICAg ICAgICAgIGkgPSBpIC0gMQ0gICAgICAgICAgICBlbHNlOg0gICAgICAgICAgICAg ICAgIyBiZXN0IHdheSB0byBoYW5kbGUgdGhpcyBpcyB0byByYWlzZSBhbiBleGNl cHRpb24NICAgICAgICAgICAgICAgIHJhaXNlIG5vcm1fZXJyb3IsICdDYW5ub3Qg dXNlIDo6IGltbWVkaWF0ZWx5IGFmdGVyIHZvbHVtZSBuYW1lJw0gICAgICAgIGVs c2U6DSAgICAgICAgICAgIGkgPSBpICsgMQ0NICAgIHMgPSAiOiIuam9pbihjb21w cykNDSAgICAjIHJlbW92ZSB0cmFpbGluZyAiOiIgZXhjZXB0IGZvciAiOiIgYW5k ICJWb2x1bWU6Ig0gICAgaWYgc1stMV0gPT0gIjoiIGFuZCBsZW4oY29tcHMpID4g MiBhbmQgcyAhPSAiOiIqbGVuKHMpOg0gICAgICAgIHMgPSBzWzotMV0NICAgIHJl dHVybiBzDQ0NZGVmIHdhbGsodG9wLCBmdW5jLCBhcmcsd2Fsa0FsaWFzPTEsd2Fs a090aGVyVm9sdW1lcz0xLHdhbGtlZD17fSk6DSAgICAiIiJEaXJlY3RvcnkgdHJl ZSB3YWxrIHdpdGggY2FsbGJhY2sgZnVuY3Rpb24uDQ0gICAgRm9yIGVhY2ggZGly ZWN0b3J5IGluIHRoZSBkaXJlY3RvcnkgdHJlZSByb290ZWQgYXQgdG9wIChpbmNs dWRpbmcgdG9wDSAgICBpdHNlbGYsIGJ1dCBleGNsdWRpbmcgJy4nIGFuZCAnLi4n KSwgY2FsbCBmdW5jKGFyZywgZGlybmFtZSwgZm5hbWVzKS4NICAgIGRpcm5hbWUg aXMgdGhlIG5hbWUgb2YgdGhlIGRpcmVjdG9yeSwgYW5kIGZuYW1lcyBhIGxpc3Qg b2YgdGhlIG5hbWVzIG9mDSAgICB0aGUgZmlsZXMgYW5kIHN1YmRpcmVjdG9yaWVz IGluIGRpcm5hbWUgKGV4Y2x1ZGluZyAnLicgYW5kICcuLicpLiAgZnVuYw0gICAg bWF5IG1vZGlmeSB0aGUgZm5hbWVzIGxpc3QgaW4tcGxhY2UgKGUuZy4gdmlhIGRl bCBvciBzbGljZSBhc3NpZ25tZW50KSwNICAgIGFuZCB3YWxrIHdpbGwgb25seSBy ZWN1cnNlIGludG8gdGhlIHN1YmRpcmVjdG9yaWVzIHdob3NlIG5hbWVzIHJlbWFp biBpbg0gICAgZm5hbWVzOyB0aGlzIGNhbiBiZSB1c2VkIHRvIGltcGxlbWVudCBh IGZpbHRlciwgb3IgdG8gaW1wb3NlIGEgc3BlY2lmaWMNICAgIG9yZGVyIG9mIHZp c2l0aW5nLiAgTm8gc2VtYW50aWNzIGFyZSBkZWZpbmVkIGZvciwgb3IgcmVxdWly ZWQgb2YsIGFyZywNICAgIGJleW9uZCB0aGF0IGFyZyBpcyBhbHdheXMgcGFzc2Vk IHRvIGZ1bmMuICBJdCBjYW4gYmUgdXNlZCwgZS5nLiwgdG8gcGFzcw0gICAgYSBm aWxlbmFtZSBwYXR0ZXJuLCBvciBhIG11dGFibGUgb2JqZWN0IGRlc2lnbmVkIHRv IGFjY3VtdWxhdGUNICAgIHN0YXRpc3RpY3MuICBQYXNzaW5nIE5vbmUgZm9yIGFy ZyBpcyBjb21tb24uDQ0gICAgaWYgd2Fsa0FsaWFzIGlzIDAsIG5vIGFsaWFzIGZv bGRlcnMgd2lsbCBiZSBmb2xsb3dlZDsgZnVydGhlcm1vcmUsDSAgICBpZiB3YWxr T3RoZXJWb2x1bWVzIGlzIDAgdGhlbiBvbmx5IGZvbGRlcnMgb24gdGhlIHNhbWUg dm9sdW1lDSAgICBhcyB0aGUgaW5pdGlhbCBvbmUgd2lsbCBiZSB3YWxrZWQuICBU aGUgZGljdGlvbmFyeSAid2Fsa2VkIiBpcyB1c2VkDSAgICB0byBrZWVwIHRyYWNr IG9mIHRoZSBmc3MncyB0aGF0IGhhdmUgYmVlbiB3YWxrZWQgYWxyZWFkeSB0byBh dm9pZCB3YWxraW5nDSAgICB0aHJvdWdoIGEgZm9sZGVyIHRoYXQgaGFzIGFscmVh ZHkgYmVlbiB3YWxrZWQuDQ0gICAgQ2F1dGlvbjogIGlzIHlvdSB3YWxrIGFsaWFz ZXMgYW5kIHlvdSBlbmNvdW50ZXIgYW4gYWxpYXMgdG8gYW4gdW5tb3VudGVkDSAg ICB2b2x1bWUsIHlvdSB3aWxsIGJlIGFza2VkIHRvIG1vdW50IHRoZSB2b2x1bWUg KGUuZyBpbnNlcnQgdGhlIG1pc3NpbmcgZGlzaykNICAgIHdoZXRoZXIgb3Igbm90 IHlvdSB3YW50IHRvIHdhbGsgb3RoZXIgdm9sdW1lcy4gIEkgZG9uJ3Qga25vdyBo b3cgdG8gZGV0ZWN0DSAgICB0aGlzIGNvbmRpdGlvbiBiZWZvcmUgdGhlIHJlcXVl c3QgdG8gaW5zZXJ0IHRoZSBkaXNrIGlzIG1hZGUuICBSaWdodCBub3cgdGhlIA0g ICAgd2Fsa090aGVyVm9sdW1lcyBvcHRpb24gd2lsbCBhbGxvdyB5b3UgdG8ga2Vl cCB5b3VyIHdhbGsgdG8gYSBzaW5nbGUgdm9sdW1lLiIiIg0NICAgIHRyeToNICAg ICAgICBuYW1lcyA9IG9zLmxpc3RkaXIodG9wKQ0gICAgZXhjZXB0IG9zLmVycm9y Og0gICAgICAgIHJldHVybg0gICAgZnVuYyhhcmcsIHRvcCwgbmFtZXMpDQ0jIGlu aXRpYWxpemUgdGhlIHdhbGsgcmVjb3JkDSAgICBpZiB3YWxrQWxpYXM6DSAgICAg ICAgZnNzLCBpc0RpciwgaXNBbGlhcz1tYWNmcy5SZXNvbHZlQWxpYXNGaWxlKHRv cCkNICAgICAgICBrPWZzcy5hc190dXBsZSgpDSAgICAgICAgd2Fsa2VkW2tdPScn DSAgICAgICAgaWYgbm90IHdhbGtlZC5oYXNfa2V5KCd0b3Bfdm9sdW1lJyk6DSAg ICAgICAgICAgIHdhbGtlZFsndG9wX3ZvbHVtZSddPWtbMF0NDSMgd2FsayB0aGUg c3ViLWl0ZW1zIGluIHRoaXMgZGlyZWN0b3J5IGlmIHRoZXkgYXJlIGRpcmVjdG9y aWVzDSAgICBmb3IgbmFtZSBpbiBuYW1lczoNICAgICAgICBuYW1lID0gam9pbih0 b3AsIG5hbWUpDQ0gICAgICAgIHRyeTogCQkJCSNnZXQgdGhlIGluZm9ybWF0aW9u IGFib3V0IHRoaXMgbmFtZQ0gICAgICAgICAgICBmc3MsIGlzRGlyLCBpc0FsaWFz PW1hY2ZzLlJlc29sdmVBbGlhc0ZpbGUobmFtZSkNICAgICAgICBleGNlcHQ6DSAg ICAgICAgICAgIGNvbnRpbnVlIAkJI2RpcmVjdG9yeSBkb2Vzbid0IGV4aXN0DQ0g ICAgICAgIGlmIGlzRGlyOg0gICAgICAgICAgICBpZiBpc0FsaWFzIGFuZCBub3Qg d2Fsa0FsaWFzOiBjb250aW51ZQ0gICAgICAgICAgICBpZiB3YWxrQWxpYXM6DSAg ICAgICAgICAgICAgICBrPWZzcy5hc190dXBsZSgpDSAgICAgICAgICAgICAgICBp ZiAobm90IHdhbGtPdGhlclZvbHVtZXMgYW5kIHdhbGtlZFsndG9wX3ZvbHVtZSdd PD5rWzBdKSBvciB3YWxrZWQuaGFzX2tleShrKTogY29udGludWUgDSAgICAgICAg ICAgICAgICB3YWxrZWRba109JycNICAgICAgICAgICAgICAgIGlmIGlzQWxpYXM6 CQkjcmVzb2x2ZSBub3cgb3IgZWxzZSBpdCB3b24ndCBiZSBlYXN5IGxhdGVyDSAg ICAgICAgICAgICAgICAgICAgbmFtZT1mc3MuYXNfcGF0aG5hbWUoKQ0JICAgIHdh bGsobmFtZSwgZnVuYywgYXJnLCB3YWxrQWxpYXMsIHdhbGtPdGhlclZvbHVtZXMs IHdhbGtlZCkNDQ0NZGVmIGFic3BhdGgocGF0aCk6DSAgICAiIiJSZXR1cm4gYW4g YWJzb2x1dGUgcGF0aC4iIiINICAgIGlmIG5vdCBpc2FicyhwYXRoKToNICAgICAg ICBwYXRoID0gam9pbihvcy5nZXRjd2QoKSwgcGF0aCkNICAgIHJldHVybiBub3Jt cGF0aChwYXRoKQ0NIyByZWFscGF0aCBpcyBhIG5vLW9wIG9uIHN5c3RlbXMgd2l0 aG91dCBpc2xpbmsgc3VwcG9ydA1yZWFscGF0aCA9IGFic3BhdGgNDWlmIF9fbmFt ZV9fID09ICdfX21haW5fXyc6DQlpbXBvcnQgdGltZQ0JZGVmIHdhbGtmdW5jKGFy ZywgZGlyLG5hbWVzKToNCQlmb3IgbmFtZSBpbiBuYW1lczoNCQkJcz1qb2luKGRp cixuYW1lKQ0JCQlwcmludCBuYW1lDQ0JdG9wPW1hY2ZzLkdldERpcmVjdG9yeSgp WzBdLmFzX3BhdGhuYW1lKCkNCXQ9dGltZS50aW1lKCkNCXByaW50DQlhcmc9W10N CXdhbGtBbGlhc2VzPTANCXdhbGtPdGhlclZvbHVtZXM9MA0Jd2Fsayh0b3Asd2Fs a2Z1bmMsYXJnLHdhbGtBbGlhc2VzLHdhbGtPdGhlclZvbHVtZXMpDQlwcmludCAi U2Vjb25kcyB0YWtlbjoiLHRpbWUudGltZSgpLXQN ----=_--b8e197a9.0d740840.0000008b-- ----=_--0094bd9f.0094bc9b.b8e197a8-- From junkster@rochester.rr.com Tue Apr 16 21:58:25 2002 From: junkster@rochester.rr.com (Benjamin Schollnick) Date: Tue, 16 Apr 2002 16:58:25 -0400 Subject: [Pythonmac-SIG] Fixfiletypes via IC (FC?) In-Reply-To: Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3101821105_32195_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit This is what I would consider to be a final draft.... Or at least a early final candidate... Suggestions, improvements, etc.... Are more than welcome... I've actually rolled back time a little bit, with a "fall back" table, so that Python code can "always" be recognized, even if it's not in the internet control panel.... - Benjamin # # Fixfiletypes - Set mac filetypes to something sensible, # recursively down a directory tree. # # It will only touch extensions it feels pretty sure about. # This script is useful after copying files from unix. # # Jack Jansen, CWI, 1995. # # # Rewritten to use the IC module, and add progress meter, etc... # Introduced for feedback & comments. # # Benjamin Schollnick, 4/16/2002 import os import ic import MacOS import macfs import sys import macostools import string import EasyDialogs on = 1 off = 0 # # If "on", fixfile will warn if it needed to use the default/fallback list. # default_warnings = on # # if "on", fixfile will warn if it was unable to match the file's extension. # no_match_warnings = on # # Hardcoded Defaults for # # File Extension # Creator Code # Type Code fallback_list = [ ('.C', 'CWIE', 'TEXT'), ('.H', 'CWIE', 'TEXT'), ('.PY', 'Pyth', 'TEXT'), ('.PYC', 'Pyth', 'PYC '), ('.PYO', 'Pyth', 'PYC '), ] class GUI_Features : def __init__(self): self.max_file_count = 0 self.current_file_count = 0 self.Progress_Bar = None def set_max_files (self, count ): self.max_file_count = count def return_max_files (self): return self.max_file_count def increment_file_count (self, increment = 1 ): self.current_file_count = self.current_file_count + increment def return_incremental ( self ): return self.current_file_count def init_progress_bar ( self, text ): self.Progress_Bar = EasyDialogs.ProgressBar ( text, self.max_file_count ) def change_pb_text ( self, text ): self.Progress_Bar.label ( text ) def refresh_progress_bar (self): self.Progress_Bar.set ( self.current_file_count, max=self.max_file_count) class tree_file_count: def __init__ ( self ): self.file_count = 0 def walktree_count (self, args, dirname, names): self.file_count = self.file_count + len(names) def directory_to_count (self, pathname ): os.path.walk ( pathname, self.walktree_count, None) def total_files ( self ): return self.file_count def reset_to_zero ( self ): self.file_count = 0 def walktree(name, change, g_app, total, IC): if os.path.isfile(name) and not os.path.isdir (name): try: if name.endswith (".DS_Store"): return if os.path.splitext (name)[1] == "": # # There is no extension on this file... # return fs = macfs.FSSpec(name) creatorcode, typecode = fs.GetCreatorType () new_mapping = IC.mapfile ( name ) if (creatorcode <> new_mapping[2]) and (typecode <> new_mapping[1]): print "Reseting creator/type for: %s" % os.path.split(name)[1] IC.settypecreator ( name ) except MacOS.Error: changed = 0 file_ext = os.path.splitext (name)[1].upper() for ext, cr, tp in fallback_list: if file_ext == ext: fs = macfs.FSSpec(name) if (creatorcode, typecode) <> (cr.upper(), tp.upper() ): changed = 1 fs.SetCreatorType(cr, tp) macostools.touched(fs) if default_warnings: print 'Used defaults: ', os.path.split(name)[1] else: print "Reseting creator/type for: %s" % os.path.split(name)[1] if changed == 0 and no_match_warnings==on: print "Unable to match via IC Panel (%s)" % os.path.split(name)[1] elif os.path.isdir(name): # print '->', name files = os.listdir(name) for f in files: g_app.increment_file_count () g_app.change_pb_text ( "\t%s of %s" % ( g_app.return_incremental (), total.total_files () ) ) g_app.refresh_progress_bar ( ) walktree(os.path.join(name, f), change, g_app, total, IC ) def run( change ): fss, ok = macfs.GetDirectory('Folder to search:') if not ok: sys.exit(0) GUI = GUI_Features() total_count = tree_file_count () total_count.directory_to_count ( fss.as_pathname() ) Internet_config = ic.IC () GUI.init_progress_bar ( "Files to Process" ) GUI.set_max_files ( total_count.total_files() ) walktree(fss.as_pathname(), change, GUI, total_count, Internet_config) if __name__ == '__main__': run(1) --MS_Mac_OE_3101821105_32195_MIME_Part Content-type: text/plain; name="ic_fixfile.py"; x-mac-creator="50797468"; x-mac-type="54455854" Content-disposition: attachment Content-transfer-encoding: base64 Iw0jIEZpeGZpbGV0eXBlcyAtIFNldCBtYWMgZmlsZXR5cGVzIHRvIHNvbWV0aGluZyBzZW5z aWJsZSwNIyAgcmVjdXJzaXZlbHkgZG93biBhIGRpcmVjdG9yeSB0cmVlLg0jDSMgSXQgd2ls bCBvbmx5IHRvdWNoIGV4dGVuc2lvbnMgaXQgZmVlbHMgcHJldHR5IHN1cmUgYWJvdXQuDSMg VGhpcyBzY3JpcHQgaXMgdXNlZnVsIGFmdGVyIGNvcHlpbmcgZmlsZXMgZnJvbSB1bml4Lg0j DSMgSmFjayBKYW5zZW4sIENXSSwgMTk5NS4NIw0NIw0jCVJld3JpdHRlbiB0byB1c2UgdGhl IElDIG1vZHVsZSwgYW5kIGFkZCBwcm9ncmVzcyBtZXRlciwgZXRjLi4uDSMJSW50cm9kdWNl ZCBmb3IgZmVlZGJhY2sgJiBjb21tZW50cy4NIw0jCUJlbmphbWluIFNjaG9sbG5pY2ssIDQv MTYvMjAwMg0NaW1wb3J0IG9zDWltcG9ydCBpYw1pbXBvcnQgTWFjT1MNaW1wb3J0IG1hY2Zz DWltcG9ydCBzeXMNaW1wb3J0IG1hY29zdG9vbHMNaW1wb3J0IHN0cmluZw1pbXBvcnQgRWFz eURpYWxvZ3MNDW9uIAk9IDENb2ZmID0gMA0NIw0jCUlmICJvbiIsIGZpeGZpbGUgd2lsbCB3 YXJuIGlmIGl0IG5lZWRlZCB0byB1c2UgdGhlIGRlZmF1bHQvZmFsbGJhY2sgbGlzdC4NIw1k ZWZhdWx0X3dhcm5pbmdzID0gb24NDSMNIwlpZiAib24iLCBmaXhmaWxlIHdpbGwgd2FybiBp ZiBpdCB3YXMgdW5hYmxlIHRvIG1hdGNoIHRoZSBmaWxlJ3MgZXh0ZW5zaW9uLg0jDW5vX21h dGNoX3dhcm5pbmdzID0gb24NDQ0jDSMJSGFyZGNvZGVkIERlZmF1bHRzIGZvciANIw0JIyBG aWxlIEV4dGVuc2lvbg0JCQkJIyBDcmVhdG9yIENvZGUNCQkJCQkJIyBUeXBlIENvZGUNZmFs bGJhY2tfbGlzdCA9IFsNCSgnLkMnLCAJCSdDV0lFJywgJ1RFWFQnKSwNCSgnLkgnLCAJCSdD V0lFJywgJ1RFWFQnKSwNCSgnLlBZJywgCSdQeXRoJywgJ1RFWFQnKSwNCSgnLlBZQycsIAkn UHl0aCcsICdQWUMgJyksDQkoJy5QWU8nLCAJJ1B5dGgnLCAnUFlDICcpLA1dDQ1jbGFzcwkJ R1VJX0ZlYXR1cmVzIDoNCWRlZgkJX19pbml0X18oc2VsZik6DQkJc2VsZi5tYXhfZmlsZV9j b3VudAkJPSAwDQkJc2VsZi5jdXJyZW50X2ZpbGVfY291bnQJPSAwDQkJc2VsZi5Qcm9ncmVz c19CYXIJCT0gTm9uZQ0JCQ0JZGVmCQlzZXRfbWF4X2ZpbGVzIChzZWxmLCBjb3VudCApOg0J CXNlbGYubWF4X2ZpbGVfY291bnQJCT0gY291bnQNCQkNCWRlZgkJcmV0dXJuX21heF9maWxl cyAoc2VsZik6DQkJcmV0dXJuIHNlbGYubWF4X2ZpbGVfY291bnQNCQkNCWRlZgkJaW5jcmVt ZW50X2ZpbGVfY291bnQgKHNlbGYsIGluY3JlbWVudCA9IDEgKToNCQlzZWxmLmN1cnJlbnRf ZmlsZV9jb3VudCA9IHNlbGYuY3VycmVudF9maWxlX2NvdW50ICsgaW5jcmVtZW50DQkJDQlk ZWYJCXJldHVybl9pbmNyZW1lbnRhbCAoIHNlbGYgKToNCQlyZXR1cm4gc2VsZi5jdXJyZW50 X2ZpbGVfY291bnQNCQkNCWRlZglpbml0X3Byb2dyZXNzX2JhciAoIHNlbGYsIHRleHQgKToN CQlzZWxmLlByb2dyZXNzX0JhciA9IEVhc3lEaWFsb2dzLlByb2dyZXNzQmFyICggdGV4dCwg c2VsZi5tYXhfZmlsZV9jb3VudCApDQkNCWRlZgljaGFuZ2VfcGJfdGV4dCAgKCBzZWxmLCB0 ZXh0ICk6DQkJc2VsZi5Qcm9ncmVzc19CYXIubGFiZWwgKCB0ZXh0ICkNCQkNCWRlZglyZWZy ZXNoX3Byb2dyZXNzX2JhciAoc2VsZik6DQkJc2VsZi5Qcm9ncmVzc19CYXIuc2V0ICggc2Vs Zi5jdXJyZW50X2ZpbGVfY291bnQsIG1heD1zZWxmLm1heF9maWxlX2NvdW50KQ0NY2xhc3MJ dHJlZV9maWxlX2NvdW50Og0JZGVmCV9faW5pdF9fICggc2VsZiApOg0JCXNlbGYuZmlsZV9j b3VudCA9IDANDQlkZWYJd2Fsa3RyZWVfY291bnQgKHNlbGYsIGFyZ3MsIGRpcm5hbWUsIG5h bWVzKToNCQlzZWxmLmZpbGVfY291bnQgPSBzZWxmLmZpbGVfY291bnQgKyBsZW4obmFtZXMp DQ0JZGVmCWRpcmVjdG9yeV90b19jb3VudCAoc2VsZiwgcGF0aG5hbWUgKToNCQlvcy5wYXRo LndhbGsgKCBwYXRobmFtZSwgc2VsZi53YWxrdHJlZV9jb3VudCwgTm9uZSkNDQlkZWYJdG90 YWxfZmlsZXMgKCBzZWxmICk6DQkJcmV0dXJuIHNlbGYuZmlsZV9jb3VudA0JCQ0JZGVmCXJl c2V0X3RvX3plcm8gKCBzZWxmICk6DQkJc2VsZi5maWxlX2NvdW50ID0gMA0JCQ0JCQ1kZWYg d2Fsa3RyZWUobmFtZSwgY2hhbmdlLCBnX2FwcCwgdG90YWwsIElDKToNCWlmIG9zLnBhdGgu aXNmaWxlKG5hbWUpIGFuZCBub3Qgb3MucGF0aC5pc2RpciAobmFtZSk6DQkJdHJ5Og0JCQlp ZiBuYW1lLmVuZHN3aXRoICgiLkRTX1N0b3JlIik6DQkJCQlyZXR1cm4NDQkJCWlmIG9zLnBh dGguc3BsaXRleHQgKG5hbWUpWzFdID09ICIiOg0JCQkJIw0JCQkJIwlUaGVyZSBpcyBubyBl eHRlbnNpb24gb24gdGhpcyBmaWxlLi4uDQkJCQkjDQkJCQlyZXR1cm4NCQkJDQkJCWZzID0g bWFjZnMuRlNTcGVjKG5hbWUpDQkJCWNyZWF0b3Jjb2RlLCB0eXBlY29kZSA9IGZzLkdldENy ZWF0b3JUeXBlICgpDQ0JCQluZXdfbWFwcGluZyA9IElDLm1hcGZpbGUgKCBuYW1lICkNCQkJ DQkJCWlmIChjcmVhdG9yY29kZSA8PiBuZXdfbWFwcGluZ1syXSkgYW5kICh0eXBlY29kZSA8 PiBuZXdfbWFwcGluZ1sxXSk6DQkJCQlwcmludCAiUmVzZXRpbmcgY3JlYXRvci90eXBlIGZv cjogJXMiICUgb3MucGF0aC5zcGxpdChuYW1lKVsxXQ0JCQkJDQkJCUlDLnNldHR5cGVjcmVh dG9yICggbmFtZSApDQkJZXhjZXB0IE1hY09TLkVycm9yOg0NCQkJY2hhbmdlZCA9IDANCQkJ ZmlsZV9leHQgPSBvcy5wYXRoLnNwbGl0ZXh0IChuYW1lKVsxXS51cHBlcigpDQkJCWZvciBl eHQsIGNyLCB0cCBpbiBmYWxsYmFja19saXN0Og0JCQkJaWYgZmlsZV9leHQgPT0gZXh0Og0J CQkJCWZzID0gbWFjZnMuRlNTcGVjKG5hbWUpDQkJCQkJaWYgKGNyZWF0b3Jjb2RlLCB0eXBl Y29kZSkgPD4gKGNyLnVwcGVyKCksIHRwLnVwcGVyKCkgKToNCQkJCQkJY2hhbmdlZCA9IDEN CQkJCQkJZnMuU2V0Q3JlYXRvclR5cGUoY3IsIHRwKQ0JCQkJCQltYWNvc3Rvb2xzLnRvdWNo ZWQoZnMpDQkJCQkJCWlmIGRlZmF1bHRfd2FybmluZ3M6DQkJCQkJCQlwcmludCAnVXNlZCBk ZWZhdWx0czogJywgb3MucGF0aC5zcGxpdChuYW1lKVsxXQ0JCQkJCQllbHNlOg0JCQkJCQkJ cHJpbnQgIlJlc2V0aW5nIGNyZWF0b3IvdHlwZSBmb3I6ICVzIiAlIG9zLnBhdGguc3BsaXQo bmFtZSlbMV0NDQkJCWlmIGNoYW5nZWQgPT0gMCBhbmQgbm9fbWF0Y2hfd2FybmluZ3M9PW9u Og0JCQkJcHJpbnQgIlVuYWJsZSB0byBtYXRjaCB2aWEgSUMgUGFuZWwgKCVzKSIgJSBvcy5w YXRoLnNwbGl0KG5hbWUpWzFdDQ0JCQkJDQ0JZWxpZiBvcy5wYXRoLmlzZGlyKG5hbWUpOg0j CQlwcmludCAnLT4nLCBuYW1lDQkJZmlsZXMgPSBvcy5saXN0ZGlyKG5hbWUpDQkJZm9yIGYg aW4gZmlsZXM6DQkJCWdfYXBwLmluY3JlbWVudF9maWxlX2NvdW50ICgpDQkJCWdfYXBwLmNo YW5nZV9wYl90ZXh0ICAoICJcdCVzIG9mICVzIiAlICggZ19hcHAucmV0dXJuX2luY3JlbWVu dGFsICgpLCB0b3RhbC50b3RhbF9maWxlcyAoKSApICkNCQkJZ19hcHAucmVmcmVzaF9wcm9n cmVzc19iYXIgKCApDQ0JCQl3YWxrdHJlZShvcy5wYXRoLmpvaW4obmFtZSwgZiksIGNoYW5n ZSwgZ19hcHAsIHRvdGFsLCBJQyApDQkJDQkJDQkJCQkJDWRlZiBydW4oIGNoYW5nZSApOg0J DQlmc3MsIG9rID0gbWFjZnMuR2V0RGlyZWN0b3J5KCdGb2xkZXIgdG8gc2VhcmNoOicpDQlp ZiBub3Qgb2s6DQkJc3lzLmV4aXQoMCkNDQkNCUdVSSAJCQk9IEdVSV9GZWF0dXJlcygpDQl0 b3RhbF9jb3VudCAJPSB0cmVlX2ZpbGVfY291bnQgKCkNCXRvdGFsX2NvdW50LmRpcmVjdG9y eV90b19jb3VudCAoIGZzcy5hc19wYXRobmFtZSgpICkNCUludGVybmV0X2NvbmZpZyA9IGlj LklDICgpDQkNCUdVSS5pbml0X3Byb2dyZXNzX2JhciAoICJGaWxlcyB0byBQcm9jZXNzIiAp DQlHVUkuc2V0X21heF9maWxlcyAoIHRvdGFsX2NvdW50LnRvdGFsX2ZpbGVzKCkgKQ0JDQl3 YWxrdHJlZShmc3MuYXNfcGF0aG5hbWUoKSwgY2hhbmdlLCBHVUksIHRvdGFsX2NvdW50LCBJ bnRlcm5ldF9jb25maWcpDQkNaWYgX19uYW1lX18gPT0gJ19fbWFpbl9fJzoNCXJ1bigxKQ0J DQkN --MS_Mac_OE_3101821105_32195_MIME_Part-- From ashearer@lifespan.org Tue Apr 16 22:10:05 2002 From: ashearer@lifespan.org (Andrew Shearer) Date: Tue, 16 Apr 2002 17:10:05 -0400 Subject: [Pythonmac-SIG] Alias files, was Re: recursive memory Message-ID: <534C7BD8-517E-11D6-BBDB-003065499C70@lifespan.org> > > 2) > > I would also like to find out if an alias points to another > (unmounted) > > volume. The only problem is that if the volume is unmounted, the > > ResolveAliasFile routine (or other routines that will give file > > information, like mac.stat()) will prompt me to insert the volume; I > > would > > like to have the walk be unattended and so would like a way to > override > > the insert volume reaction and just know that the alias points to an > > unmounted volume and just skip it. Is there another way to detect > this > > condition without being asked to insert the missing volume? > > I can't find anything, also not in the lower level alias handling > routines (i.e. what is partially exposed via macfs.Alias methods). > There is a variant of ResolveAliasFile called ResolveAliasFileWithMountFlags that does this, but it's not exposed in macfs. Set the added mountFlags parameter to kResolveAliasFileNoUI (aka 1) to disallow user interaction. See technote 1142 for details. The call was introducted with Mac OS 8.5, but similar code for older systems is provided in technote FL30, Resolving Alias Files Quietly . There's also a Carbon call with an even more promising name, to the point of redundancy: ResolveAliasFileWithMountFlagsNoUI. I don't have documentation beyond that included below. == OSErr ResolveAliasFileWithMountFlagsNoUI ( FSSpec *theSpec, Boolean resolveAliasChains, Boolean *targetIsFolder, Boolean *wasAliased, UInt32 mountFlags ); function result A result code. Availability Supported in Carbon. Available in Carbon 1.0.2 and later when running Mac OS 8.1 or later. == Andrew Shearer Web Infrastructure Analyst, Medical Computing ashearer@lifespan.org From Jack.Jansen@cwi.nl Wed Apr 17 09:54:56 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 17 Apr 2002 10:54:56 +0200 Subject: [Pythonmac-SIG] Re: recursive memory In-Reply-To: Message-ID: On Tuesday, April 16, 2002, at 03:56 , Christopher Smith wrote: >> macpath.walk() (or actually os.path.walk) is explicitly define *not* to >> do special things for symlinks or aliases. But still: the functionality >> is nice, so maybe we should put it in a new function macostools.walk. > > By "special things" you don't mean that walk() is suppose to skip over > aliases, do you? Yes, that's what I mean. Do I understand from your comment that it walks aliases? That would be a bug, please file it at sourceforge. (Look at posixpath, for instance: it doesn't do a straight isdir() because that would return true for a symlink pointing to a directory. It does an explicit lstat() and looks at the mode bits). > -- - 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@cwi.nl Wed Apr 17 09:57:42 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 17 Apr 2002 10:57:42 +0200 Subject: [Pythonmac-SIG] Re: recursive memory In-Reply-To: Message-ID: <2D72D39E-51E1-11D6-BA96-0030655234CE@cwi.nl> Sorry, hit send too quickly. On Tuesday, April 16, 2002, at 03:56 , Christopher Smith wrote: > If these undesirable behaviors were deemed bugs then the macpath.walk() > function could just be modified. I have attached a version which has > the > same behavior as the original but now has 3 optional arguments to handle > walking aliases, other volumes, and a dictionary to prevent walking > previously walked folders. Hmm. I don't think this is a good idea, because macpath == os.path. And the API of all the os.path modules (macpath, winpath, posixpath) is kept the same (with some historic exceptions:-). I will pick up the islink() mod, though. -- - 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@cwi.nl Wed Apr 17 10:45:45 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 17 Apr 2002 11:45:45 +0200 Subject: [Pythonmac-SIG] Alias files, was Re: recursive memory In-Reply-To: <534C7BD8-517E-11D6-BBDB-003065499C70@lifespan.org> Message-ID: On Tuesday, April 16, 2002, at 11:10 , Andrew Shearer wrote: > There is a variant of ResolveAliasFile called > ResolveAliasFileWithMountFlags that does this, but it's not exposed in > macfs. Set the added mountFlags parameter to kResolveAliasFileNoUI (aka > 1) to disallow user interaction. Ah, great! If someone wants this please file a feature request or patch at sourceforge. If a patch to macfsmodule.c is supplied too it will greatly speed up acceptance:-) -- - 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 lists@netelligent.biz Wed Apr 17 11:19:11 2002 From: lists@netelligent.biz (tmk) Date: Wed, 17 Apr 2002 12:19:11 +0200 Subject: [Pythonmac-SIG] Using StandaloneZODB on MOSX Message-ID: <8F97F450-51EC-11D6-9721-003065C18BA0@netelligent.biz> Yo, Has anybody successfully used StandaloneZODB from http://www.zope.org/Products/StandaloneZODB on Mac OS X? It seems to compile without a problem (I just followed the instructions in the README) but when I try to run the test "python test.py" I get a "Bus error" I don't have a clue as to where to start looking for the problem. FWIW, I'm including the crash log below. Any help would be much appreciated. = tmk = --- cut Date/Time: 2002-04-17 07:32:08 +0200 OS Version: 10.1.3 (Build 5Q110) Host: localhost Command: python PID: 1773 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000010 Thread 0 Crashed: #0 0x001aaef0 in initializeBaseExtensionClass #1 0x001b2348 in export_type #2 0x00403e90 in type_call #3 0x003d5d30 in PyObject_Call #4 0x00426624 in PyEval_CallObjectWithKeywords #5 0x003d5e80 in PyObject_CallFunction #6 0x00427c44 in build_class #7 0x00422eec in eval_frame #8 0x004253d8 in PyEval_EvalCodeEx #9 0x004205bc in PyEval_EvalCode #10 0x004394d4 in PyImport_ExecCodeModuleEx #11 0x00439bd4 in load_source_module #12 0x0043a5c0 in load_module #13 0x0043b690 in import_submodule #14 0x0043b0dc in load_next #15 0x0043ac24 in import_module_ex #16 0x0043ae00 in PyImport_ImportModuleEx #17 0x0041ab7c in builtin___import__ #18 0x003f5fb0 in PyCFunction_Call #19 0x003d5d30 in PyObject_Call #20 0x00426624 in PyEval_CallObjectWithKeywords #21 0x00423a40 in eval_frame #22 0x004253d8 in PyEval_EvalCodeEx #23 0x004205bc in PyEval_EvalCode #24 0x004394d4 in PyImport_ExecCodeModuleEx #25 0x00439bd4 in load_source_module #26 0x0043a5c0 in load_module #27 0x00439d7c in load_package #28 0x0043a5ec in load_module #29 0x0043b690 in import_submodule #30 0x0043b130 in load_next #31 0x0043ac24 in import_module_ex #32 0x0043ae00 in PyImport_ImportModuleEx #33 0x0041ab7c in builtin___import__ #34 0x003f5fb0 in PyCFunction_Call #35 0x003d5d30 in PyObject_Call #36 0x00426624 in PyEval_CallObjectWithKeywords #37 0x00423a40 in eval_frame #38 0x004253d8 in PyEval_EvalCodeEx #39 0x004205bc in PyEval_EvalCode #40 0x004394d4 in PyImport_ExecCodeModuleEx #41 0x00439bd4 in load_source_module #42 0x0043a5c0 in load_module #43 0x00439d7c in load_package #44 0x0043a5ec in load_module #45 0x0043b690 in import_submodule #46 0x0043b0dc in load_next #47 0x0043ac24 in import_module_ex #48 0x0043ae00 in PyImport_ImportModuleEx #49 0x0041ab7c in builtin___import__ #50 0x003f5fb0 in PyCFunction_Call #51 0x00423ef8 in eval_frame #52 0x004253d8 in PyEval_EvalCodeEx #53 0x004269c0 in fast_function #54 0x00423ffc in eval_frame #55 0x004253d8 in PyEval_EvalCodeEx #56 0x004269c0 in fast_function #57 0x00423ffc in eval_frame #58 0x004253d8 in PyEval_EvalCodeEx #59 0x004269c0 in fast_function #60 0x00423ffc in eval_frame #61 0x004253d8 in PyEval_EvalCodeEx #62 0x004205bc in PyEval_EvalCode #63 0x00443480 in run_node #64 0x00443424 in run_err_node #65 0x004433f0 in PyRun_FileExFlags #66 0x0044246c in PyRun_SimpleFileExFlags #67 0x00441e84 in PyRun_AnyFileExFlags #68 0x0044c650 in Py_Main #69 0x00001e1c in _start #70 0x00001c4c in start PPC Thread State: srr0: 0x001aaef0 srr1: 0x0200f030 vrsave: 0x00000000 xer: 0x0000001c lr: 0x001aaee0 ctr: 0x001b231c mq: 0x00000000 r0: 0x4402828f r1: 0xbfffb1a0 r2: 0x001178a3 r3: 0x00000000 r4: 0x000fb110 r5: 0x00000000 r6: 0x00117880 r7: 0x00117880 r8: 0x0000000c r9: 0x001b54cc r10: 0x004963b4 r11: 0x44028242 r12: 0x001b231c r13: 0x000d578c r14: 0x00000059 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x000535b0 r20: 0x0011a6e8 r21: 0x000d5794 r22: 0x00000000 r23: 0x000d5640 r24: 0x00000000 r25: 0x00109fc0 r26: 0x00109fc0 r27: 0x00000000 r28: 0x00114fa0 r29: 0x00000000 r30: 0x001b54cc r31: 0x001aaee0 ********** Date/Time: 2002-04-17 07:33:51 +0200 OS Version: 10.1.3 (Build 5Q110) Host: localhost Command: python PID: 1779 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000010 Thread 0 Crashed: #0 0x001aaef0 in initializeBaseExtensionClass #1 0x001b2348 in export_type #2 0x00403e90 in type_call #3 0x003d5d30 in PyObject_Call #4 0x00426624 in PyEval_CallObjectWithKeywords #5 0x003d5e80 in PyObject_CallFunction #6 0x00427c44 in build_class #7 0x00422eec in eval_frame #8 0x004253d8 in PyEval_EvalCodeEx #9 0x004205bc in PyEval_EvalCode #10 0x004394d4 in PyImport_ExecCodeModuleEx #11 0x00439bd4 in load_source_module #12 0x0043a5c0 in load_module #13 0x0043b690 in import_submodule #14 0x0043b0dc in load_next #15 0x0043ac24 in import_module_ex #16 0x0043ae00 in PyImport_ImportModuleEx #17 0x0041ab7c in builtin___import__ #18 0x003f5fb0 in PyCFunction_Call #19 0x003d5d30 in PyObject_Call #20 0x00426624 in PyEval_CallObjectWithKeywords #21 0x00423a40 in eval_frame #22 0x004253d8 in PyEval_EvalCodeEx #23 0x004205bc in PyEval_EvalCode #24 0x004394d4 in PyImport_ExecCodeModuleEx #25 0x00439bd4 in load_source_module #26 0x0043a5c0 in load_module #27 0x00439d7c in load_package #28 0x0043a5ec in load_module #29 0x0043b690 in import_submodule #30 0x0043b130 in load_next #31 0x0043ac24 in import_module_ex #32 0x0043ae00 in PyImport_ImportModuleEx #33 0x0041ab7c in builtin___import__ #34 0x003f5fb0 in PyCFunction_Call #35 0x003d5d30 in PyObject_Call #36 0x00426624 in PyEval_CallObjectWithKeywords #37 0x00423a40 in eval_frame #38 0x004253d8 in PyEval_EvalCodeEx #39 0x004205bc in PyEval_EvalCode #40 0x004394d4 in PyImport_ExecCodeModuleEx #41 0x00439bd4 in load_source_module #42 0x0043a5c0 in load_module #43 0x00439d7c in load_package #44 0x0043a5ec in load_module #45 0x0043b690 in import_submodule #46 0x0043b0dc in load_next #47 0x0043ac24 in import_module_ex #48 0x0043ae00 in PyImport_ImportModuleEx #49 0x0041ab7c in builtin___import__ #50 0x003f5fb0 in PyCFunction_Call #51 0x00423ef8 in eval_frame #52 0x004253d8 in PyEval_EvalCodeEx #53 0x004269c0 in fast_function #54 0x00423ffc in eval_frame #55 0x004253d8 in PyEval_EvalCodeEx #56 0x004269c0 in fast_function #57 0x00423ffc in eval_frame #58 0x004253d8 in PyEval_EvalCodeEx #59 0x004269c0 in fast_function #60 0x00423ffc in eval_frame #61 0x004253d8 in PyEval_EvalCodeEx #62 0x004205bc in PyEval_EvalCode #63 0x00443480 in run_node #64 0x00443424 in run_err_node #65 0x004433f0 in PyRun_FileExFlags #66 0x0044246c in PyRun_SimpleFileExFlags #67 0x00441e84 in PyRun_AnyFileExFlags #68 0x0044c650 in Py_Main #69 0x00001e1c in _start #70 0x00001c4c in start PPC Thread State: srr0: 0x001aaef0 srr1: 0x0200f030 vrsave: 0x00000000 xer: 0x0000001c lr: 0x001aaee0 ctr: 0x001b231c mq: 0x00000000 r0: 0x4402828f r1: 0xbfffb1a0 r2: 0x00112f83 r3: 0x00000000 r4: 0x000fb110 r5: 0x00000000 r6: 0x00112f60 r7: 0x00112f60 r8: 0x0000000c r9: 0x001b54cc r10: 0x004963b4 r11: 0x44028242 r12: 0x001b231c r13: 0x000d578c r14: 0x00000059 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x000535b0 r20: 0x00111bb8 r21: 0x000d5794 r22: 0x00000000 r23: 0x000d5640 r24: 0x00000000 r25: 0x00102de0 r26: 0x00102de0 r27: 0x00000000 r28: 0x00112e10 r29: 0x00000000 r30: 0x001b54cc r31: 0x001aaee0 ********** From just@letterror.com Wed Apr 17 11:25:49 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 17 Apr 2002 12:25:49 +0200 Subject: [Pythonmac-SIG] Using StandaloneZODB on MOSX In-Reply-To: <8F97F450-51EC-11D6-9721-003065C18BA0@netelligent.biz> Message-ID: tmk wrote: > It seems to compile without a problem (I just followed the > instructions in the README) but when I try to run the test "python > test.py" I get a "Bus error" FWIW, I saw the same thing last time I tried. I wasn't motivated enough to file a bug though :-( Just From loredo@astrosun.astro.cornell.edu Wed Apr 17 19:32:14 2002 From: loredo@astrosun.astro.cornell.edu (Tom Loredo) Date: Wed, 17 Apr 2002 14:32:14 -0400 (EDT) Subject: [Pythonmac-SIG] Re: Using StandaloneZODB on MOSX Message-ID: <200204171832.g3HIWEn28636@laplace.astro.cornell.edu> Hi- This isn't exactly what you asked for, but FWIW.... I put together a "Zope Components" package for MacPython (Classic) a year or so ago that included ZODB, ZPT, DTML and one or two other things. I got it to compile and to run some simple scripts I wrote exercising ZODB and ZPT, but ended up not having the time to carefully test it. I updated it through a few versions of Zope, which was slightly painful (having to select out all the right files by hand) but worked. Until the last version, which is also the version based used for the official StandaloneZODB release. Not only do I get crashes when I build and run StandaloneZODB, but I also get them when I put the files by hand into my own previous ZopeComponents. I've tracked down the problem to two modules, but the real problem could be in other modules they call. At this point it would require someone with knowledge of the guts of ZODB to figure out what's up. Alas, that's not me. I was hoping that the 2.2.1 release might fix this, since I believe some of the fixes were Zope-inspired. But I haven't had the time to check this. I have to say that Zope interest in the Mac seems nonexistent. I've pointed out some problems a couple times, with no result. I submitted some minor patches (some missing casts) that I thought got checked into CVS, but they didn't show up in the final release. I think they just don't care. Maybe OS X will change that. It's really a shame, because something like ZODB should be in the Standard Library in my opinion. -Tom Loredo From Jack.Jansen@oratrix.com Wed Apr 17 21:37:53 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 17 Apr 2002 22:37:53 +0200 Subject: [Pythonmac-SIG] Re: Using StandaloneZODB on MOSX In-Reply-To: <200204171832.g3HIWEn28636@laplace.astro.cornell.edu> Message-ID: On woensdag, april 17, 2002, at 08:32 , Tom Loredo wrote: > I was hoping that the 2.2.1 release might fix this, since I believe > some of the fixes were Zope-inspired. But I haven't had the time to > check this. I think Zope prefers 2.1 over 2.2. That's why there's a 2.1.3 release, really, to satisfy Zope users. So, for MacPython you're stuck, but for Mac OS X you could try 2.1.3. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Ludger Humbert Wed Apr 17 21:48:44 2002 From: Ludger Humbert (Ludger Humbert) Date: Wed, 17 Apr 2002 22:48:44 +0200 Subject: [Pythonmac-SIG] [PyKDE] ANN: PyQt v3.2rc1 for MacOS X Message-ID: <3CBDDFAC.4040801@hagen.de> Hi MacPythonier, the following message was just posted to the PyKDE Mailing-list ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PyQt v3.2rc1 for MacOS X is available in http://www.riverbankcomputing.co.uk/download/snaphots/. This is completely untested as I don't have the necessary hardware or software. Phil _______________________________________________ PyKDE mailing list PyKDE@mats.gmd.de http://mats.gmd.de/mailman/listinfo/pykde ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I am not able to install it on Mac OS X, because I am not able to install sip. Anyone out there to gimme some hints? Ludger Humbert From martin@v.loewis.de Thu Apr 18 07:25:16 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 18 Apr 2002 08:25:16 +0200 Subject: [Pythonmac-SIG] Re: ThreadSafety and Callbacks In-Reply-To: References: Message-ID: Jack Jansen writes: > - Release the GIL when we do a toolbox call. *BUT* this works only for > toolbox calls under our control. If some library we call (Tk, for > instance) does a toolbox call we may end up in a callback routine > while still holding the GIL. Doesn't the callback for Tk come out in Tcl first, with Tcl then dispatching to _tkinter? Also, inside _tkinter, you do *not* hold the GIL, only the Tcl lock. > - When we enter a callback determine whether the GIL is held. If it is > not held we simply acquire it and arrange for it to be released when > we're returning from the callback. That shouldn't be necessary, IMO: you should always know inside the callback whether you hold the GIL. > - If the GIL is held we determine who holds it (through the per-thread > stored value). If it is us then there's no problem and we do the > callback, making sure we don't release te GIL at the end. > - If the GIL is held by someone else we also attempt to obtain it, > blocking us until the other thread releases it. Again we free it at > the end of the callback. I would think just acquiring the GIL in any case should be enough. Regards, Martin From karl.grammer@univie.ac.at Thu Apr 18 16:16:34 2002 From: karl.grammer@univie.ac.at (grammer) Date: Thu, 18 Apr 2002 17:16:34 +0200 Subject: [Pythonmac-SIG] Picture on canvas Message-ID: Hi: Is there a way to bring a picture (bmp, jpg, tif) on a canvas ? When I do it via PIL and then try to wrap it for TK, I get an error. My interimsolution is to convert the picture via PIL to a gif and then loading it with Photoimage fronm TK - the problem is that the quality drops considerably. Has anybody any idea or solution for this problem ? Greetings Karl --------------------------------------------------------------------------- Follow the duck, not the theory of the duck - WRC --------------------------------------------------------------------------- Prof. Karl Grammer Institute for Urban Ethology at the Institute for Antropology Althanstrasse 14 A-1090 Vienna/Austria Tel: +43-1-4277-54766 Fax: +43-1-4277-9547 http://evolution.anthro.univie.ac.at/lbi.html From eric@enthought.com Thu Apr 18 15:37:57 2002 From: eric@enthought.com (eric) Date: Thu, 18 Apr 2002 10:37:57 -0400 Subject: [Pythonmac-SIG] info on CoreGraphics Message-ID: <081601c1e6e6$a2460950$6b01a8c0@ericlaptop> Hello group, Within the last couple of days, I've gotten an iMac with OSX on my desk, and am feeling my way around in the dark so to speak. Getting up to speed on a new platform is always a disorienting experience. The sole reason for getting the iMac was to experiment with the CoreGraphics library and DisplayPDF (ok, so they look cool too.) We (Enthought) are writing an open source, cross platform drawing library using DisplayPDF as a general model. The beginnings of the (un-announced shhhh.) project, called Chaco, are available through CVS from the SciPy repository. It is supported by the Space Telescope Science Institute (think Hubble...) and will be the foundation for a scientific plotting library (the real reason for this project). I have a rough set of routines that can draw paths (no bezier stuff) and text written in wxPython (the first target platform). I'm to the point where I need to start testing "corners" of the design, and I'd like to compare with how quartz handles them. So, to this point, I've been writing little routines in C using Project Builder to generate a PDF file that I can look at to see what Quartz does (I've attached one at the end). I'd really rather write these in (Mac)Python, and it seems like it should be possible. I see a Carbon.CoreGraphics module, but I didn't find anything but constants in it. Am I looking in the wrong place for the CoreGraphics routines, or have they just not made it into the package yet? The best scenario would be to get a version of Chaco that sits directly on CoreGraphics so I can do one-to-one comparisons with other platforms. Any pointers are appreciated. As a last resort, I can try to wrapper some of these puppies on my own. But I'm a stranger in a foreign land right now, and hardly know which end is "up" on the compiler tools. It doesn't even look like I have the recommended setup (Code Warrior). thanks, eric ////////////////////////////////////////// // example C code of what I'm playing with ////////////////////////////////////////// #include "draw.h" CGContextRef CreatePDFContext( const CGRect * inMediaBox, CFStringRef inFileName ) { CGContextRef outContext = NULL; CFURLRef url; CGDataConsumerRef dataConsumer; // Generate PDF to a file using a data consumer. // Use CoreFoundation's URL object to represent the file url = CFURLCreateWithFileSystemPath(NULL, /* use default allocator */ inFileName, kCFURLPOSIXPathStyle, FALSE /* == not a directory*/ ); // Create the data consumer if( url != NULL ) { dataConsumer = CGDataConsumerCreateWithURL( url ); if( dataConsumer != NULL ) { // Create the context outContext = CGPDFContextCreate( dataConsumer, inMediaBox, NULL ); // The context retains a reference to the data consumer, // so we can (and should) release our reference to it to // avoid a memory leak CGDataConsumerRelease( dataConsumer ); } } return outContext; } int angle() { const float kMediaHeight = 100.0; const float kMediaWidth = 100.0; CGContextRef context; CGRect mediaBox; // Create the context mediaBox = CGRectMake( 0, 0, kMediaWidth, kMediaHeight ); context = CreatePDFContext( &mediaBox, CFSTR("Star1.pdf") ); if( context != NULL ) { // We must begin a new page before drawing to a PDF context CGContextBeginPage( context, &mediaBox ); CGContextSaveGState(context); CGContextTranslateCTM( context, 5.0, 5.0 ); //CGContextRotateCTM( context, 0.1 ); // first line // This is an unscaled line that should provide a gage for other // lines to be compared to. // CGContextScaleCTM(context, .2, .2); // CGContextSetRGBStrokeColor(context, 0,0,0,1.0); CGContextBeginPath(context); CGContextMoveToPoint(context, 0,0); CGContextAddLineToPoint(context, 10, 0); CGContextStrokePath( context ); CGContextRestoreGState(context); // second line // This is two lines at a right angle. The second line has been // scaled by 5. It demonstrates that, even though the lines are // drawn with different scales, both lines have their width scaled // equivalently using the scaling value in affect when StrokePath // is called. CGContextSaveGState(context); CGContextTranslateCTM( context, 0.0, 20.0 ); CGContextBeginPath(context); CGContextMoveToPoint(context, 0,0); CGContextAddLineToPoint(context, 10, 0); CGContextScaleCTM(context, 5, 5); CGContextSetRGBStrokeColor(context, .5,.5,.5,.5); // based on scaling, this should end up being a vertical line. CGContextAddLineToPoint(context, 2, 2); CGContextStrokePath( context ); CGContextRestoreGState(context); // third line // how are line widths scaled when the scaling of x and y are different? CGContextSaveGState(context); CGContextTranslateCTM( context, 0.0, 40.0 ); CGContextBeginPath(context); CGContextMoveToPoint(context, 0,0); CGContextAddLineToPoint(context, 10, 0); CGContextScaleCTM(context, 2.5, 5); CGContextRotateCTM(context, 3.14159/4.); CGContextSetRGBStrokeColor(context, .5,.5,.5,.5); // based on scaling, this should end up being a vertical line. //CGContextAddLineToPoint(context, 4, 2); CGContextAddLineToPoint(context, 8, 2); CGContextStrokePath( context ); CGContextRestoreGState(context); // We've finished rendering the page CGContextEndPage( context ); // Release any objects we explicitly allocated CGContextRelease( context ); } return 0; } int main() { angle(); return 0; } -- Eric Jones Enthought, Inc. [www.enthought.com and www.scipy.org] (512) 536-1057 From dan@grassi.org Thu Apr 18 17:10:34 2002 From: dan@grassi.org (Dan Grassi) Date: Thu, 18 Apr 2002 12:10:34 -0400 Subject: [Pythonmac-SIG] OS X Python mkdir() In-Reply-To: <3CBDDFAC.4040801@hagen.de> Message-ID: Hi, It seems that mkdir() does not support the second argument (mode). I am using Python 2.2 (#11, Jan 6 2002, 01:00:42) [GCC 2.95.2 19991024 (release)] on darwin Is this true and if so has it been fixed in the latest 2.2.3? I looked in cvs and did not find any notes about mkdir being changed. I added a comment to bug 539942. Thanks, Dan From just@letterror.com Thu Apr 18 18:38:46 2002 From: just@letterror.com (Just van Rossum) Date: Thu, 18 Apr 2002 19:38:46 +0200 Subject: [Pythonmac-SIG] info on CoreGraphics In-Reply-To: <081601c1e6e6$a2460950$6b01a8c0@ericlaptop> Message-ID: eric wrote: > I have a rough set of routines that can draw paths (no bezier stuff) and text > written in wxPython (the first target platform). I'm to the point where I > need to start testing "corners" of the design, and I'd like to compare with > how quartz handles them. > > So, to this point, I've been writing little routines in C using Project > Builder to generate a PDF file that I can look at to see what Quartz does > (I've attachedone at the end). I'd really rather write these in (Mac)Python, > and it seems like it should be possible. I see a Carbon.CoreGraphics module, > but I didn't find anything but constants in it. Am I looking in the wrong > place for the CoreGraphics routines, or have they just not made it into the > package yet? Carbon.CoreGraphics is the constants module, the funcitonality is in Carbon.CG. The wrapper is by no means complete (eg. CGPDFContextCreate() isn't there yet...), but your input and contributions are very welcome! Just From just@letterror.com Thu Apr 18 18:49:44 2002 From: just@letterror.com (Just van Rossum) Date: Thu, 18 Apr 2002 19:49:44 +0200 Subject: [Pythonmac-SIG] OS X Python mkdir() In-Reply-To: Message-ID: Dan Grassi wrote: > It seems that mkdir() does not support the second argument (mode). > > I am using > > Python 2.2 (#11, Jan 6 2002, 01:00:42) > [GCC 2.95.2 19991024 (release)] on darwin > > Is this true and if so has it been fixed in the latest 2.2.3? I looked > in cvs and did not find any notes about mkdir being changed. > > I added a comment to bug 539942. I can't reproduce what you say in the comment ("mod completely ignored"), but something is ignored indeed: - os.mkdir(path, 0777) results in drwxr-xr-x - os.mkdir(path, 0) results in d--------- - os.chmod(path, 0777) results in drwxrwxrwx Just From landauer@got.net Thu Apr 18 18:54:12 2002 From: landauer@got.net (Doug Landauer) Date: Thu, 18 Apr 2002 10:54:12 -0700 Subject: [Pythonmac-SIG] OS X Python mkdir() In-Reply-To: References: Message-ID: At 7:49 PM +0200 4/18/02, Just van Rossum wrote: >I can't reproduce what you say in the comment ("mod completely ignored"), but >something is ignored indeed: > > - os.mkdir(path, 0777) results in drwxr-xr-x Did you check your umask? A umask of 022 would correctly result in this behavior. -- Doug > - os.mkdir(path, 0) results in d--------- > - os.chmod(path, 0777) results in drwxrwxrwx From just@letterror.com Thu Apr 18 18:59:26 2002 From: just@letterror.com (Just van Rossum) Date: Thu, 18 Apr 2002 19:59:26 +0200 Subject: [Pythonmac-SIG] OS X Python mkdir() In-Reply-To: Message-ID: Doug Landauer wrote: > Did you check your umask? A umask of 022 would correctly > result in this behavior. Heh, I learn something every day... Thanks! Sooo: I can't reproduce Dan's problem at all, in both CVS Python and 2.1.1. Just From aparente@adobe.com Thu Apr 18 20:11:02 2002 From: aparente@adobe.com (Alexandre Parenteau) Date: Thu, 18 Apr 2002 12:11:02 -0700 Subject: [Pythonmac-SIG] Python defaulting as a framework for OSX/Mach-O Message-ID: Folks, The primary reason of my email is to push for defaulting the compilation of Python-Mach-O as a framework, so application on OSX can embed Python easily. It would be nice also to provide an installer of Python this way. In the current MacCvs CVS (cvsgui on SourceForge), I have now a MacCvsX (Mach-O) loading dynamically Python (Mach-O) to handle the Macros of MacCvsX. Previously the same thing was working in CFM with MacCvs (CFM) and MacPython (CFM). The step is important for me : I can check-out Python code using OpenSSH, with Unix line feed, ISO text encoding, cvs-MachO spawned by MacCvsX. All is now functional under Mach-O. I can compile the Mach-O and CFM Python with the same sandbox (one using gcc, the other one CodeWarrior), which is even better. So except for CodeWarrior, I never quit Mach-O for the whole process. [I guess some still wonder why I want so much to use Mach-O and not CFM, that is because under CFM you don't have a good PosIX layer, only an emulation named "GUSI"] But using Mach-O/OSX you are more or less required to use the Frameworks mechanism for dynamic loading Python (I didn't find a way to deal with dlopen, I suspect only .so object can be loaded thru this mechanism). So what prevent from defaulting to Framework and distributing it this way ? I guess it has some impacts on distutils. Is that working with Python installed as a Framework (I never tried ) ? I wanted also to point out that people who want to embed dynamically Python in either a Classic, CFM-Carbon, Mach-O-Carbon or Win32 platform can find a complete example inside the MacCvs/WinCvs source code. Regards, Alex. -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From eric@enthought.com Thu Apr 18 19:09:39 2002 From: eric@enthought.com (eric) Date: Thu, 18 Apr 2002 14:09:39 -0400 Subject: [Pythonmac-SIG] info on CoreGraphics References: Message-ID: <087b01c1e704$3569dbe0$6b01a8c0@ericlaptop> Hey Just, > > > I have a rough set of routines that can draw paths (no bezier stuff) and text > > written in wxPython (the first target platform). I'm to the point where I > > need to start testing "corners" of the design, and I'd like to compare with > > how quartz handles them. > > > > So, to this point, I've been writing little routines in C using Project > > Builder to generate a PDF file that I can look at to see what Quartz does > > (I've attachedone at the end). I'd really rather write these in (Mac)Python, > > and it seems like it should be possible. I see a Carbon.CoreGraphics module, > > but I didn't find anything but constants in it. Am I looking in the wrong > > place for the CoreGraphics routines, or have they just not made it into the > > package yet? > > Carbon.CoreGraphics is the constants module, the funcitonality is in Carbon.CG. > The wrapper is by no means complete (eg. CGPDFContextCreate() isn't there > yet...), but your input and contributions are very welcome! I'm using MacPython 2.2.1, and Carbon.CG only appears to have 2 methods, CGContextRefType and CreateCGContextForPort. Are things like CGContextRotateCTM and CGContextAddLines supported somewhere yet? Also, I didn't see a CoreGraphics demo running around. If you have some code that excercises these routines, I'd appreciate the example. thanks, eric From just@letterror.com Thu Apr 18 20:21:47 2002 From: just@letterror.com (Just van Rossum) Date: Thu, 18 Apr 2002 21:21:47 +0200 Subject: [Pythonmac-SIG] info on CoreGraphics In-Reply-To: <087b01c1e704$3569dbe0$6b01a8c0@ericlaptop> Message-ID: --2958805-2675965952-3228153710=:9000 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit eric wrote: > I'm using MacPython 2.2.1, and Carbon.CG only appears to have 2 methods, > CGContextRefType and CreateCGContextForPort. Are things like > CGContextRotateCTM > and CGContextAddLines supported somewhere yet? Those are methods of the CGContext object, which you'll get by doing CreateCGContextForPort()... (As in: the othe CGContext constructors aren't there yet.) > Also, I didn't see a CoreGraphics demo running around. If you have some code > that > excercises these routines, I'd appreciate the example. See attached file for a very crude experiment. Run in the IDE. Just --2958805-2675965952-3228153710=:9000 Content-Type: application/octet-stream; Name="Wquartz.py"; X-Mac-Type="54455854"; X-Mac-Creator="50696465" Content-Transfer-Encoding: base64 Content-Disposition: attachment; Filename="Wquartz.py" aW1wb3J0IFcNZnJvbSBDYXJib24gaW1wb3J0IENHLCBRZA0NX25hbWVzID0gWw0J IyBvZmZpY2lhbCBRdWFydHogQVBJIG5hbWUsICJuaWNlTmFtZSIsIF9fZG9jX18N CSgiQ0dDb250ZXh0U2V0TGluZVdpZHRoIiwgInNldExpbmVXaWR0aCIsICIoZmxv YXQgd2lkdGgpIC0+IE5vbmUiKSwNCSgiQ0dDb250ZXh0Q29uY2F0Q1RNIiwgImNv bmNhdENUTSIsICIoQ0dBZmZpbmVUcmFuc2Zvcm0gdHJhbnNmb3JtKSAtPiBOb25l IiksDQkoIkNHQ29udGV4dEdldFBhdGhDdXJyZW50UG9pbnQiLCAiZ2V0UGF0aEN1 cnJlbnRQb2ludCIsICIoKSAtPiAoQ0dQb2ludCBfcnYpIiksDQkoIkNHQ29udGV4 dEFkZEFyY1RvUG9pbnQiLCAiYWRkQXJjVG9Qb2ludCIsICIoZmxvYXQgeDEsIGZs b2F0IHkxLCBmbG9hdCB4MiwgZmxvYXQgeTIsIGZsb2F0IHJhZGl1cykgLT4gTm9u ZSIpLA0JKCJDR0NvbnRleHRBZGRRdWFkQ3VydmVUb1BvaW50IiwgImFkZFF1YWRD dXJ2ZVRvUG9pbnQiLCAiKGZsb2F0IGNweCwgZmxvYXQgY3B5LCBmbG9hdCB4LCBm bG9hdCB5KSAtPiBOb25lIiksDQkoIkNHQ29udGV4dENsZWFyUmVjdCIsICJjbGVh clJlY3QiLCAiKENHUmVjdCByZWN0KSAtPiBOb25lIiksDQkoIkNHQ29udGV4dFNl dFNob3VsZEFudGlhbGlhcyIsICJzZXRTaG91bGRBbnRpYWxpYXMiLCAiKGludCBz aG91bGRBbnRpYWxpYXMpIC0+IE5vbmUiKSwNCSgiQ0dDb250ZXh0TW92ZVRvUG9p bnQiLCAibW92ZVRvUG9pbnQiLCAiKGZsb2F0IHgsIGZsb2F0IHkpIC0+IE5vbmUi KSwNCSgiQ0dDb250ZXh0U2V0Q2hhcmFjdGVyU3BhY2luZyIsICJzZXRDaGFyYWN0 ZXJTcGFjaW5nIiwgIihmbG9hdCBzcGFjaW5nKSAtPiBOb25lIiksDQkoIkNHQ29u dGV4dFJlc3RvcmVHU3RhdGUiLCAicmVzdG9yZUdTdGF0ZSIsICIoKSAtPiBOb25l IiksDQkoIkNHQ29udGV4dElzUGF0aEVtcHR5IiwgImlzUGF0aEVtcHR5IiwgIigp IC0+IChpbnQgX3J2KSIpLA0JKCJDR0NvbnRleHRDbG9zZVBhdGgiLCAiY2xvc2VQ YXRoIiwgIigpIC0+IE5vbmUiKSwNCSgiQ0dDb250ZXh0Rmx1c2giLCAiZmx1c2gi LCAiKCkgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRFbmRQYWdlIiwgImVuZFBhZ2Ui LCAiKCkgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRHZXRUZXh0TWF0cml4IiwgImdl dFRleHRNYXRyaXgiLCAiKCkgLT4gKENHQWZmaW5lVHJhbnNmb3JtIF9ydikiKSwN CSgiQ0dDb250ZXh0QWRkUmVjdCIsICJhZGRSZWN0IiwgIihDR1JlY3QgcmVjdCkg LT4gTm9uZSIpLA0JKCJDR0NvbnRleHRFT0ZpbGxQYXRoIiwgImVvRmlsbFBhdGgi LCAiKCkgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRDbGlwVG9SZWN0IiwgImNsaXBU b1JlY3QiLCAiKENHUmVjdCByZWN0KSAtPiBOb25lIiksDQkoIkNHQ29udGV4dFNl dEdyYXlTdHJva2VDb2xvciIsICJzZXRHcmF5U3Ryb2tlQ29sb3IiLCAiKGZsb2F0 IGdyYXksIGZsb2F0IGFscGhhKSAtPiBOb25lIiksDQkoIkNHQ29udGV4dFNldE1p dGVyTGltaXQiLCAic2V0TWl0ZXJMaW1pdCIsICIoZmxvYXQgbGltaXQpIC0+IE5v bmUiKSwNCSgiQ0dDb250ZXh0RmlsbFBhdGgiLCAiZmlsbFBhdGgiLCAiKCkgLT4g Tm9uZSIpLA0JKCJDR0NvbnRleHRTdHJva2VSZWN0V2l0aFdpZHRoIiwgInN0cm9r ZVJlY3RXaXRoV2lkdGgiLCAiKENHUmVjdCByZWN0LCBmbG9hdCB3aWR0aCkgLT4g Tm9uZSIpLA0JKCJDR0NvbnRleHRTZXRHcmF5RmlsbENvbG9yIiwgInNldEdyYXlG aWxsQ29sb3IiLCAiKGZsb2F0IGdyYXksIGZsb2F0IGFscGhhKSAtPiBOb25lIiks DQkoIkNHQ29udGV4dFNldEZvbnRTaXplIiwgInNldEZvbnRTaXplIiwgIihmbG9h dCBzaXplKSAtPiBOb25lIiksDQkoIkNHQ29udGV4dFNob3dUZXh0IiwgInNob3dU ZXh0IiwgIihCdWZmZXIgY3N0cmluZykgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRT Y2FsZUNUTSIsICJzY2FsZUNUTSIsICIoZmxvYXQgc3gsIGZsb2F0IHN5KSAtPiBO b25lIiksDQkoIkNHQ29udGV4dFN5bmNocm9uaXplIiwgInN5bmNocm9uaXplIiwg IigpIC0+IE5vbmUiKSwNCSgiQ0dDb250ZXh0U2V0TGluZUNhcCIsICJzZXRMaW5l Q2FwIiwgIihpbnQgY2FwKSAtPiBOb25lIiksDQkoIkNHQ29udGV4dFNldFRleHRE cmF3aW5nTW9kZSIsICJzZXRUZXh0RHJhd2luZ01vZGUiLCAiKGludCBtb2RlKSAt PiBOb25lIiksDQkoIkNHQ29udGV4dFNldEZsYXRuZXNzIiwgInNldEZsYXRuZXNz IiwgIihmbG9hdCBmbGF0bmVzcykgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRDbGlw IiwgImNsaXAiLCAiKCkgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRTZXRDTVlLU3Ry b2tlQ29sb3IiLCAic2V0Q01ZS1N0cm9rZUNvbG9yIiwgIihmbG9hdCBjLCBmbG9h dCBtLCBmbG9hdCB5LCBmbG9hdCBrLCBmbG9hdCBhbHBoYSkgLT4gTm9uZSIpLA0J KCJDR0NvbnRleHRBZGRMaW5lVG9Qb2ludCIsICJhZGRMaW5lVG9Qb2ludCIsICIo ZmxvYXQgeCwgZmxvYXQgeSkgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRTaG93VGV4 dEF0UG9pbnQiLCAic2hvd1RleHRBdFBvaW50IiwgIihmbG9hdCB4LCBmbG9hdCB5 LCBCdWZmZXIgY3N0cmluZykgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRHZXRUZXh0 UG9zaXRpb24iLCAiZ2V0VGV4dFBvc2l0aW9uIiwgIigpIC0+IChDR1BvaW50IF9y dikiKSwNCSgiQ0dDb250ZXh0VHJhbnNsYXRlQ1RNIiwgInRyYW5zbGF0ZUNUTSIs ICIoZmxvYXQgdHgsIGZsb2F0IHR5KSAtPiBOb25lIiksDQkoIkNHQ29udGV4dEFk ZEFyYyIsICJhZGRBcmMiLCAiKGZsb2F0IHgsIGZsb2F0IHksIGZsb2F0IHJhZGl1 cywgZmxvYXQgc3RhcnRBbmdsZSwgZmxvYXQgZW5kQW5nbGUsIGludCBjbG9ja3dp c2UpIC0+IE5vbmUiKSwNCSgiQ0dDb250ZXh0U2V0TGluZUpvaW4iLCAic2V0TGlu ZUpvaW4iLCAiKGludCBqb2luKSAtPiBOb25lIiksDQkoIkNHQ29udGV4dEZpbGxS ZWN0IiwgImZpbGxSZWN0IiwgIihDR1JlY3QgcmVjdCkgLT4gTm9uZSIpLA0JKCJD R0NvbnRleHRTZXRBbHBoYSIsICJzZXRBbHBoYSIsICIoZmxvYXQgYWxwaGEpIC0+ IE5vbmUiKSwNCSgiQ0dDb250ZXh0R2V0UGF0aEJvdW5kaW5nQm94IiwgImdldFBh dGhCb3VuZGluZ0JveCIsICIoKSAtPiAoQ0dSZWN0IF9ydikiKSwNCSgiQ0dDb250 ZXh0U2V0UkdCU3Ryb2tlQ29sb3IiLCAic2V0UkdCU3Ryb2tlQ29sb3IiLCAiKGZs b2F0IHIsIGZsb2F0IGcsIGZsb2F0IGIsIGZsb2F0IGFscGhhKSAtPiBOb25lIiks DQkoIkNHQ29udGV4dEdldENUTSIsICJnZXRDVE0iLCAiKCkgLT4gKENHQWZmaW5l VHJhbnNmb3JtIF9ydikiKSwNCSgiQ0dDb250ZXh0U3Ryb2tlUmVjdCIsICJzdHJv a2VSZWN0IiwgIihDR1JlY3QgcmVjdCkgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRB ZGRDdXJ2ZVRvUG9pbnQiLCAiYWRkQ3VydmVUb1BvaW50IiwgIihmbG9hdCBjcDF4 LCBmbG9hdCBjcDF5LCBmbG9hdCBjcDJ4LCBmbG9hdCBjcDJ5LCBmbG9hdCB4LCBm bG9hdCB5KSAtPiBOb25lIiksDQkoIkNHQ29udGV4dFJvdGF0ZUNUTSIsICJyb3Rh dGVDVE0iLCAiKGZsb2F0IGFuZ2xlKSAtPiBOb25lIiksDQkoIkNHQ29udGV4dFNl dENNWUtGaWxsQ29sb3IiLCAic2V0Q01ZS0ZpbGxDb2xvciIsICIoZmxvYXQgYywg ZmxvYXQgbSwgZmxvYXQgeSwgZmxvYXQgaywgZmxvYXQgYWxwaGEpIC0+IE5vbmUi KSwNCSgiQ0dDb250ZXh0RHJhd1BhdGgiLCAiZHJhd1BhdGgiLCAiKGludCBtb2Rl KSAtPiBOb25lIiksDQkoIkNHQ29udGV4dFN0cm9rZVBhdGgiLCAic3Ryb2tlUGF0 aCIsICIoKSAtPiBOb25lIiksDQkoIkNHQ29udGV4dFNhdmVHU3RhdGUiLCAic2F2 ZUdTdGF0ZSIsICIoKSAtPiBOb25lIiksDQkoIkNHQ29udGV4dEJlZ2luUGF0aCIs ICJiZWdpblBhdGgiLCAiKCkgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRTZXRUZXh0 TWF0cml4IiwgInNldFRleHRNYXRyaXgiLCAiKENHQWZmaW5lVHJhbnNmb3JtIHRy YW5zZm9ybSkgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRTZWxlY3RGb250IiwgInNl bGVjdEZvbnQiLCAiKGNoYXIgKiBuYW1lLCBmbG9hdCBzaXplLCBpbnQgdGV4dEVu Y29kaW5nKSAtPiBOb25lIiksDQkoIkNHQ29udGV4dFNldFJHQkZpbGxDb2xvciIs ICJzZXRSR0JGaWxsQ29sb3IiLCAiKGZsb2F0IHIsIGZsb2F0IGcsIGZsb2F0IGIs IGZsb2F0IGFscGhhKSAtPiBOb25lIiksDQkoIkNHQ29udGV4dEVPQ2xpcCIsICJl b0NsaXAiLCAiKCkgLT4gTm9uZSIpLA0JKCJDR0NvbnRleHRTZXRUZXh0UG9zaXRp b24iLCAic2V0VGV4dFBvc2l0aW9uIiwgIihmbG9hdCB4LCBmbG9hdCB5KSAtPiBO b25lIiksDV0NDQ1jbGFzcyBRdWFydHpXcmFwcGVyOg0JIiIiUHJvdmlkZSBuaWNl IG5hbWVzIHZvciBRdWFydHogQVBJJ3MuIiIiDQlkZWYgX19pbml0X18oc2VsZiwg Y3R4KToNCQlmb3IgbiwgbSwgZCBpbiBfbmFtZXM6DQkJCXNldGF0dHIoc2VsZiwg bSwgZ2V0YXR0cihjdHgsIG4pKQ0NDWNsYXNzIFF1YXJ0eldpZGdldChXLldpZGdl dCk6DQlfY3R4ID0gTm9uZQ0JZGVmIGRyYXcoc2VsZiwgdmlzUmduPU5vbmUpOg0J CWlmIG5vdCBzZWxmLl92aXNpYmxlOg0JCQlyZXR1cm4NCQlsLCB0LCByLCBiID0g c2VsZi5fYm91bmRzDQkJd2lkdGggPSByIC0gbA0JCWhlaWdodCA9IGIgLSB0DQkJ eCwgeSA9IGwsIGINCQljdHggPSBDRy5DcmVhdGVDR0NvbnRleHRGb3JQb3J0KHNl bGYuX3BhcmVudHdpbmRvdy53aWQpDQkJc2VsZi5fY3R4ID0gY3R4ID0gUXVhcnR6 V3JhcHBlcihjdHgpDQkJd3gsIHd5LCB3d2lkdGgsIHdoZWlnaHQgPSBzZWxmLl9w YXJlbnR3aW5kb3cuX2JvdW5kcw0JCWN0eC50cmFuc2xhdGVDVE0oeCwgd2hlaWdo dCAtIHkpDQkJc2VsZi5fbWVkaWFib3ggPSBib3ggPSAoMCwgMCwgd2lkdGgsIGhl aWdodCkNCQljdHguY2xpcFRvUmVjdChib3gpDQkJY3R4LnNhdmVHU3RhdGUoKQ0J CXNlbGYucXVhcnR6RHJhdyhjdHgsIGJveCkNCQljdHgucmVzdG9yZUdTdGF0ZSgp DQkNCWRlZiBxdWFydHpEcmF3KHNlbGYsIGN0eCwgYm94KToNCQljdHguc3Ryb2tl UmVjdFdpdGhXaWR0aChib3gsIDAuNSkNCQ0JX2FuZ2xlID0gMA0JX3NjYWxlID0g MQ0JDQlkZWYgaWRsZWZ1bmMoc2VsZiwgKmFyZ3MpOg0JCWlmIG5vdCBoYXNhdHRy KHNlbGYsICJfbWVkaWFib3giKToNCQkJcmV0dXJuDQkJaW1wb3J0IHJhbmRvbQ0J CWN0eCwgYm94ID0gc2VsZi5fY3R4LCBzZWxmLl9tZWRpYWJveA0JCSNjdHguc2V0 UkdCRmlsbENvbG9yKDAuNywgMCwgMC4zLCAwLjA0KQ0JCSNjdHguZmlsbFJlY3Qo Ym94KQ0JCXgsIHksIHdpZHRoLCBoZWlnaHQgPSBib3gNCQljdHguc2F2ZUdTdGF0 ZSgpDQkJY3R4LnNlbGVjdEZvbnQoIkdhZGdldCIsIDYwLCAxKQ0JCWN0eC5zZXRD aGFyYWN0ZXJTcGFjaW5nKDEpDQkJY3R4LnRyYW5zbGF0ZUNUTSgwLjUgKiB3aWR0 aCwgMC41ICogaGVpZ2h0KQ0JCXIgPSByYW5kb20ucmFuZG9tKCkNCQlyMiA9IHJh bmRvbS5yYW5kb20oKQ0JCSNjdHgucm90YXRlQ1RNKHIgKiAzLjE0ICogMikNCQlj dHgucm90YXRlQ1RNKHNlbGYuX2FuZ2xlKQ0JCWN0eC5zY2FsZUNUTShzZWxmLl9z Y2FsZSwgc2VsZi5fc2NhbGUpDQkJI2N0eC5jb25jYXRDVE0oWzEsIChyMiAtIDAu NSkgKiAwLjMsIDAsIDEsIDAsIDBdKQ0JCXNlbGYuX2FuZ2xlICs9IDAuMQ0JCXNl bGYuX3NjYWxlICo9IDAuOTk5OA0JCWN0eC5zZXRSR0JGaWxsQ29sb3IociwgcjIs IDEsIDAuMikNCQljdHguc2hvd1RleHRBdFBvaW50KDAsIDAsICJIYWxsbyB3ZXJl bGQuLi4iKQ0JCWN0eC5zeW5jaHJvbml6ZSgpDQkJI2N0eC5mbHVzaCgpDQkJY3R4 LnJlc3RvcmVHU3RhdGUoKQ0NDWlmIF9fbmFtZV9fID09ICJfX21haW5fXyI6DQl3 ID0gVy5XaW5kb3coKDMwMCwgMzAwKSwgIlF1YXJ0eiIsIG1pbnNpemU9KDEwMCwg MTAwKSkNCXcucSA9IFF1YXJ0eldpZGdldCgoMTAsIDEwLCAtMTAsIC0zMCkpDQl3 LmJpbmQoIjxpZGxlPiIsIHcucS5pZGxlZnVuYykNCXcub3BlbigpDQ0N --2958805-2675965952-3228153710=:9000-- From just@letterror.com Thu Apr 18 20:37:05 2002 From: just@letterror.com (Just van Rossum) Date: Thu, 18 Apr 2002 21:37:05 +0200 Subject: [Pythonmac-SIG] MacPython 2.2.1 after 10.1.4 update? Message-ID: My MacPython 2.2.1 install suddenly broke: the IDE showed the SIOUX window end the interpreter crashed. When I tossed the prefs everything was fine again. I *did* update to 10.1.4 last night, so maybe that caused it. Stupid enough I simply tossed both the MacPython 2.2.1 pref as well as the l.plist, so I don't know which one was the cause. I presume not the .plist. Did anyone else notice the same thing? (Hm, my CVS install didn't seem to be affected.) Just From humbert@hagen.de Fri Apr 19 14:18:29 2002 From: humbert@hagen.de (Ludger Humbert) Date: Fri, 19 Apr 2002 15:18:29 +0200 Subject: [Pythonmac-SIG] [PyKDE] Building SIP + PyQt on Mac OS X Message-ID: <3CC01925.10701@hagen.de> Hi, Dimitri Papadopoulos wrote a mail, which hopeful solves my problems installing PyQt/sip on Mac OS X and posted it to the PyKDE-Maillist You find it at http://mats.gmd.de/pipermail/pykde/2002-April/002309.html TNX Ludger Humbert From Jack.Jansen@cwi.nl Fri Apr 19 14:30:40 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 19 Apr 2002 15:30:40 +0200 Subject: [Pythonmac-SIG] Python defaulting as a framework for OSX/Mach-O In-Reply-To: Message-ID: On Thursday, April 18, 2002, at 09:11 , Alexandre Parenteau wrote: > The primary reason of my email is to push for defaulting the > compilation of > Python-Mach-O as a framework, so application on OSX can embed Python > easily. > It would be nice also to provide an installer of Python this way. I don't want to scare the unix users too much, that's the main reason for having the default build be the non-framework built. This results in a Python installation that's 100% familiar to them. Also, the framework build is still too convoluted ("make frameworkinstall" in stead of "make install", plus running make in Mac/OSX to create the .app and a few other things). I do, however, think that an installer with a framework-based Python would be a very good idea. I think the wxPython folks have one on their sourceforge download area, but I haven't tried it yet. And distutils works fine for framework builds. Note that distutils is used during the core installation as well, to create the standard dynamic modules. -- - 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@cwi.nl Fri Apr 19 14:45:03 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 19 Apr 2002 15:45:03 +0200 Subject: [Pythonmac-SIG] MacPython 2.2.1 after 10.1.4 update? In-Reply-To: Message-ID: On Thursday, April 18, 2002, at 09:37 , Just van Rossum wrote: > My MacPython 2.2.1 install suddenly broke: the IDE showed the SIOUX > window > end the interpreter crashed. When I tossed the prefs > everything was > fine again. Same thing happened to me, but on the second run it worked fine. I've had this happen to me before very occasionally, and always with the IDE. Usually something is "new", either it's a freshly installed Python or a fresh MacOSX version or ... And I can't debug this: IDE fails, I option-start IDE and select "interactive after script", IDE works again I don't know how to make it fail again. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mjb@uma.pt Fri Apr 19 16:51:51 2002 From: mjb@uma.pt (Michael J. Barber) Date: Fri, 19 Apr 2002 16:51:51 +0100 Subject: [Pythonmac-SIG] MacPython 2.2.1 after 10.1.4 update? In-Reply-To: Message-ID: <5D4D164E-53AD-11D6-B098-0050E4794D0F@uma.pt> On Friday, April 19, 2002, at 02:45 PM, Jack Jansen wrote: > > On Thursday, April 18, 2002, at 09:37 , Just van Rossum wrote: > >> My MacPython 2.2.1 install suddenly broke: the IDE showed the SIOUX >> window >> end the interpreter crashed. When I tossed the prefs >> everything was >> fine again. > > Same thing happened to me, but on the second run it worked fine. > I've had this happen to me before very occasionally, and always with > the IDE. Usually something is "new", either it's a freshly installed > Python or a fresh MacOSX version or ... > > And I can't debug this: IDE fails, I option-start IDE and select > "interactive after script", IDE works again I don't know how to make it > fail again. > I have not (yet) upgraded to 10.1.4. Actually, I haven't installed MacPython 2.2.1 yet, either, since I'm mainly using a Unix Python now. Is there any information I can record before and after the upgrades that would be helpful in tracking this down? Or maybe it is too small of a problem to worry about... -- Michael From Chris.Barker@noaa.gov Fri Apr 19 17:24:47 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Fri, 19 Apr 2002 09:24:47 -0700 Subject: [Pythonmac-SIG] Getting Piddle to work with Python 2.2 References: Message-ID: <3CC044CF.E70FE158@noaa.gov> Jack Jansen wrote: > I don't want to scare the unix users too much, that's the main reason > for having the default build be the non-framework built. This results in > a Python installation that's 100% familiar to them. As a Unix user, thanks! For those of us that still don't "get" OS-X, what are the implications of a framework-build? Will it still operate as a command line program? Why, as a Unix user, should I be afraid of frameworks? Can a framework build and regular Unix build co-exist? Also, the framework > build is still too convoluted ("make frameworkinstall" in stead of "make > install", plus running make in Mac/OSX to create the .app and a few > other things). That sure sounds like a few short steps that could be put into a script to me. A lot of folks complain about "hard to install" programs, but frankly, I don't think most people really have that much trouble with an istall that take a few command to do, as long as it is well documented, and it works. Also, if one of the motivations is to make an embeddable Python, anyone that is embedding Python should be able to handle a build that requies a few steps. -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 tony@metanet.com Fri Apr 19 17:42:58 2002 From: tony@metanet.com (Tony Lownds) Date: Fri, 19 Apr 2002 09:42:58 -0700 Subject: [Pythonmac-SIG] Python defaulting as a framework for OSX/Mach-O In-Reply-To: References: Message-ID: At 3:30 PM +0200 4/19/02, Jack Jansen wrote: >On Thursday, April 18, 2002, at 09:11 , Alexandre Parenteau wrote: > >>The primary reason of my email is to push for defaulting the compilation of >>Python-Mach-O as a framework, so application on OSX can embed Python easily. >>It would be nice also to provide an installer of Python this way. > >I don't want to scare the unix users too much, that's the main >reason for having the default build be the non-framework built. This >results in a Python installation that's 100% familiar to them. Couldn't those UNIX users use ./configure --without-framework ? Shouldn't the default build sequence of ./configure; make; make install result in a Python that's as useful as possible? > Also, the framework build is still too convoluted ("make >frameworkinstall" in stead of "make install", plus running make in >Mac/OSX to create the .app and a few other things). Yeah, it's pretty convoluted. Perhaps the real reason for a non-framework default build is not so much scaring the UNIX users but scaring the maintainers of other UNIX build processes... every change seems to convolute things a bit more. I'd really like to have the Mac/OSX/Makefile integrated into one build command even if it's not "make install". >I do, however, think that an installer with a framework-based Python >would be a very good idea. Yes! For 2.3! -Tony -- From Chris.Barker@noaa.gov Fri Apr 19 19:02:55 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Fri, 19 Apr 2002 11:02:55 -0700 Subject: [Pythonmac-SIG] Python defaulting as a framework for OSX/Mach-O References: Message-ID: <3CC05BCF.453A16B4@noaa.gov> OOPS: posted previously under the wrong topic. Jack Jansen wrote: > I don't want to scare the unix users too much, that's the main reason > for having the default build be the non-framework built. This results in > a Python installation that's 100% familiar to them. As a Unix user, thanks! For those of us that still don't "get" OS-X, what are the implications of a framework-build? Will it still operate as a command line program? Why, as a Unix user, should I be afraid of frameworks? Can a framework build and regular Unix build co-exist? Also, the framework > build is still too convoluted ("make frameworkinstall" in stead of "make > install", plus running make in Mac/OSX to create the .app and a few > other things). That sure sounds like a few short steps that could be put into a script to me. A lot of folks complain about "hard to install" programs, but frankly, I don't think most people really have that much trouble with an istall that take a few command to do, as long as it is well documented, and it works. Also, if one of the motivations is to make an embeddable Python, anyone that is embedding Python should be able to handle a build that requies a few steps. -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 ldanielburr@earthlink.net Fri Apr 19 20:25:17 2002 From: ldanielburr@earthlink.net (Daniel Burr) Date: Fri, 19 Apr 2002 12:25:17 -0700 Subject: [Pythonmac-SIG] Problems with urllib2 and MacPython2.2.1 Message-ID: Greetings, I've just recently switched from Windows to Mac OS X, and am having some problems with both urllib and urllib2 on OS 10.1.3. The problem occurs both with MacPython2.2.1 and with Python2.2.1 compiled from the Unix sources. Basically, urlopen() does not work for me with either urllib or urllib2, as the file-like object being returned throws errors when I try to call readlines(). The code below works perfectly with the python2.1_macosx.tgz distribution from Tony Lownds' site. I have not yet installed and tested against MacPython2.1. Example: import urllib f = urllib.urlopen('http://www.google.com/') print f.headers print f.readlines() f.close() The example above will throw an error as soon as it hits the readlines() call. Any ideas? I have not heard any mention of this problem prior to now, so I am thinking I must be doing something very wrong. Any advice gratefully accepted. Daniel Burr From just@letterror.com Fri Apr 19 20:31:49 2002 From: just@letterror.com (Just van Rossum) Date: Fri, 19 Apr 2002 21:31:49 +0200 Subject: [Pythonmac-SIG] Problems with urllib2 and MacPython2.2.1 In-Reply-To: Message-ID: Daniel Burr wrote: > The example above will throw an error as soon as it hits the readlines() call. > Any ideas? How about a traceback? Just From tony@metanet.com Fri Apr 19 20:51:19 2002 From: tony@metanet.com (Tony Lownds) Date: Fri, 19 Apr 2002 12:51:19 -0700 Subject: [Pythonmac-SIG] Problems with urllib2 and MacPython2.2.1 In-Reply-To: References: Message-ID: FYI: works from CVS too ironchef:~% python Python 2.3a0 (#5, Apr 15 2002, 14:24:59) [GCC 2.95.2 19991024 (release)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> f = urllib.urlopen('http://www.google.com/') >>> print f.headers Content-Length: 2402 Connection: Close Server: GWS/2.0 Date: Fri, 19 Apr 2002 19:37:43 GMT Content-Type: text/html Cache-control: private Set-Cookie: PREF=ID=550613584a737c73:TM=1019245063:LM=1019245063:S=wtOcPy0G6Q0; domain=.google.com; path=/; expires=Sun, 17-Jan-2038 19:14:07 GMT >>> print f.readlines() [...snip...] >>> f.close() -Tony At 12:25 PM -0700 4/19/02, Daniel Burr wrote: >Greetings, > >I've just recently switched from Windows to Mac OS X, and am having >some problems with both urllib and urllib2 on OS 10.1.3. The >problem occurs both with MacPython2.2.1 and with Python2.2.1 >compiled from the Unix sources. > >Basically, urlopen() does not work for me with either urllib or >urllib2, as the file-like object being returned throws errors when I >try to call readlines(). The code below works perfectly with the >python2.1_macosx.tgz distribution from Tony Lownds' site. I have >not yet installed and tested against MacPython2.1. > >Example: >import urllib >f = urllib.urlopen('http://www.google.com/') >print f.headers >print f.readlines() >f.close() > >The example above will throw an error as soon as it hits the >readlines() call. Any ideas? I have not heard any mention of this >problem prior to now, so I am thinking I must be doing something >very wrong. > >Any advice gratefully accepted. > >Daniel Burr > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- From ldanielburr@earthlink.net Fri Apr 19 21:02:08 2002 From: ldanielburr@earthlink.net (Daniel Burr) Date: Fri, 19 Apr 2002 13:02:08 -0700 Subject: [Pythonmac-SIG] Problems with urllib2 and MacPython2.2.1 Message-ID: On Fri, 19 Apr 2002 21:31:49 +0200 Just van Rossum wrote: Daniel Burr wrote: > The example above will throw an error as soon as it hits the readlines() call. > Any ideas? How about a traceback? Just Doh, my mistake. Traceback follows: Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 67] Internal mapping for kOTLookErr, don't return to client Thanks for your help, Daniel Burr ldanielburr@earthlink.net From ewmc@ncol.net Fri Apr 19 22:28:43 2002 From: ewmc@ncol.net (Anonymous) Date: Fri, 19 Apr 2002 16:28:43 -0500 Subject: [Pythonmac-SIG] idle Message-ID: I have MacPython 2.2.1. installed on PB G3 w/ OS 9. How do I start IDLE? Thank you Regards Frank A. From hansv@net4all.be Fri Apr 19 23:06:35 2002 From: hansv@net4all.be (Hans verschooten) Date: Sat, 20 Apr 2002 00:06:35 +0200 Subject: [Pythonmac-SIG] Executing Python on mac os X Message-ID: What am I doing wrong? I want to make python files executable on mac os X. By executable I mean, I'm trying to run .py files from the terminal by issuing ./mac.py. If I try this with a Perl file it works. What do I need to do? Python 2.2 (#11, Jan 6 2002, 01:00:42) [GCC 2.95.2 19991024 (release)] on darwin Any help is appreciated, Hans From rdacker@pacbell.net Sat Apr 20 00:12:19 2002 From: rdacker@pacbell.net (bob ackerman) Date: Fri, 19 Apr 2002 16:12:19 -0700 Subject: [Pythonmac-SIG] Executing Python on mac os X In-Reply-To: Message-ID: works for me. i assume you have made the file have executable permission with 'chmod'. what do you have as first line of file? i have: #! /usr/local/bin/python On Friday, April 19, 2002, at 03:06 PM, Hans verschooten wrote: > What am I doing wrong? > I want to make python files executable on mac os X. By executable I mean, > I'm trying to run .py files from the terminal by issuing ./mac.py. If I > try this with a Perl file it works. > > What do I need to do? > > Python 2.2 (#11, Jan 6 2002, 01:00:42) > [GCC 2.95.2 19991024 (release)] on darwin > > Any help is appreciated, > Hans > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From hansv@net4all.be Sat Apr 20 00:31:45 2002 From: hansv@net4all.be (Hans verschooten) Date: Sat, 20 Apr 2002 01:31:45 +0200 Subject: [Pythonmac-SIG] Executing Python on mac os X In-Reply-To: Message-ID: <9CE24746-53ED-11D6-8B9D-0030654E4A4C@net4all.be> On zaterdag, april 20, 2002, at 12:22 , Bob Ippolito wrote: > make the first line of mac.py: > #!/usr/bin/env python > then chmod +x mac.py Works for me! Thanks, Hans From lists@netelligent.biz Sat Apr 20 16:32:52 2002 From: lists@netelligent.biz (tmk) Date: Sat, 20 Apr 2002 17:32:52 +0200 Subject: [Soldved]: [Pythonmac-SIG] Using StandaloneZODB on MOSX In-Reply-To: <8F97F450-51EC-11D6-9721-003065C18BA0@netelligent.biz> Message-ID: On Wednesday, April 17, 2002, at 12:19 PM, tmk wrote: > Yo, > > Has anybody successfully used StandaloneZODB from > http://www.zope.org/Products/StandaloneZODB on Mac OS X? > > It seems to compile without a problem (I just followed the > instructions in the README) but when I try to run the test "python > test.py" I get a "Bus error" The problem turned out to be very stupid... Since some suggested that Zope "preferred" 2.1.3 I,I compiled and installed 2.1.3 and it seems to work with it. (I read somewhere on the Zope site that Zope is not and apparently will not be compatible w/ 2.2x Here the sequence of steps I performed --- cut cd into the python 2.1.3 directory ./configure --with-suffix=.exe --with-dyld make sudo make install cd /usr/local/bin mv python.exe zython # This is zope python ;-)... mv python2.1.exe zython2.1.3 Open a new shell window # The shell doesn't immediately # findprograms newly installed # in its path cd to the StandaloneZODB folder zython setup.py build zython test.py -v -v # Takes some time to finish #(321.460s on my cube) zython setup.py install Test the installation Open a new shell window # See above for the reason why # There must be a more clever way cd ~ zython >>> import ZODB >>> import ZODB.FileStorage >>> ZODB.FileStorage.__version__ '1.75.16.8' >>> OMM 3 tests fail (see below) doesn't seem to be a major bug (floating point date arithmetics?) so I'll look into it later. HTH = tmk = --- cut [localhost:~/Documents/tmp/StandaloneZODB-1.0] tmk% python21 test.py ====================================================================== FAIL: checkFullTimeStamp (ZODB.tests.testTimeStamp.TimeStampTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "lib.darwin-5.4-Power Macintosh-2.1/ZODB/tests/testTimeStamp.py", line 35, in checkFullTimeStamp self.assertEquals(ts.timeTime() + time.timezone, time.mktime(t)) File "/usr/local/lib/python2.1/unittest.py", line 273, in failUnlessEqual raise self.failureException, (msg or '%s != %s' % (first, second)) AssertionError: 1019306940.0 != 1019310540.0 ====================================================================== FAIL: checkFullTimeStamp (ZODB.tests.testTimeStamp.TimeStampTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "lib.darwin-5.4-Power Macintosh-2.1/ZODB/tests/testTimeStamp.py", line 35, in checkFullTimeStamp self.assertEquals(ts.timeTime() + time.timezone, time.mktime(t)) File "/usr/local/lib/python2.1/unittest.py", line 273, in failUnlessEqual raise self.failureException, (msg or '%s != %s' % (first, second)) AssertionError: 1019307055.0 != 1019310655.0 ====================================================================== FAIL: checkFullTimeStamp (ZODB.tests.testTimeStamp.TimeStampTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "lib.darwin-5.4-Power Macintosh-2.1/ZODB/tests/testTimeStamp.py", line 35, in checkFullTimeStamp self.assertEquals(ts.timeTime() + time.timezone, time.mktime(t)) File "/usr/local/lib/python2.1/unittest.py", line 273, in failUnlessEqual raise self.failureException, (msg or '%s != %s' % (first, second)) AssertionError: 1019307168.0 != 1019310768.0 ---------------------------------------------------------------------- Ran 1899 tests in 323.890s FAILED (failures=3) From Jack.Jansen@oratrix.com Sun Apr 21 22:17:45 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 21 Apr 2002 23:17:45 +0200 Subject: [Pythonmac-SIG] idle In-Reply-To: Message-ID: <394E36B4-556D-11D6-AFDE-003065517236@oratrix.com> On vrijdag, april 19, 2002, at 11:28 , Anonymous wrote: > I have MacPython 2.2.1. installed on PB G3 w/ OS 9. > How do I start IDLE? I'm not sure whether Idle will work in MacPython: Tkinter on the mac is very shaky. But, if you want to give it a try: configure MacPython in classic PPC mode (run ConfigurePythonClassic) and double-click idle.py (in :Tools:idle) -- - 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 kevino@tulane.edu Tue Apr 23 22:29:04 2002 From: kevino@tulane.edu (Kevin Ollivier) Date: Tue, 23 Apr 2002 17:29:04 -0400 Subject: [Pythonmac-SIG] [MachOPython] starting an application from a Python script? Message-ID: <00ac01c1eb0d$e58538a0$6d01a8c0@kevinnew> Hi all, I'm using the 2.3 version of MachOPython downloaded from CVS. I have a wxPython script which allows users to specify a "preferred" web browser and HTML editor and then uses those preferred editors to preview/edit HTML files. In Windows and Linux/UNIX, I call os.spawnv and pass in the program location and filename to open. On Mac, however, this seems not to be implemented. (There is no error message, but the call is not executed. Online Mac library documentation does not list it as a supported method.) What would be the equivalent way of doing this in MachOPython? I can use the webbrowser module as a workaround for the browser, but that still leaves the editor. Would I use something like AppleEvents for this? Thanks for your help! Kevin From Pieter.Claerhout@Creo.com Wed Apr 24 08:33:49 2002 From: Pieter.Claerhout@Creo.com (Pieter Claerhout) Date: Wed, 24 Apr 2002 09:33:49 +0200 Subject: [Pythonmac-SIG] [MachOPython] starting an application from a Python script? Message-ID: <490316A24CC5D411ACD700B0D078F7F0020A598B@cseexch01.cse.creoscitex.com> You basically will have to use the findertools.launch function. It takes one argument, which is the path of the application. If you know the creator code of the application, you can do the following thing: f = macfs.FindApplication('8BIM') fPhotoshop = findertools.launch(f) This example will launch Photoshop after it found the path based on the creator code of Photoshop, which is 8BIM. Hope this answers your question. Cheers, Pieter -----Original Message----- From: Kevin Ollivier [mailto:kevino@tulane.edu] Sent: Tuesday, April 23, 2002 23:29 To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] [MachOPython] starting an application from a Python script? Hi all, I'm using the 2.3 version of MachOPython downloaded from CVS. I have a wxPython script which allows users to specify a "preferred" web browser and HTML editor and then uses those preferred editors to preview/edit HTML files. In Windows and Linux/UNIX, I call os.spawnv and pass in the program location and filename to open. On Mac, however, this seems not to be implemented. (There is no error message, but the call is not executed. Online Mac library documentation does not list it as a supported method.) What would be the equivalent way of doing this in MachOPython? I can use the webbrowser module as a workaround for the browser, but that still leaves the editor. Would I use something like AppleEvents for this? Thanks for your help! Kevin _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From fpierfed@eso.org Wed Apr 24 09:10:37 2002 From: fpierfed@eso.org (Francesco Pierfederici) Date: Wed, 24 Apr 2002 10:10:37 +0200 Subject: [Pythonmac-SIG] Status of wxPython Message-ID: Hi everybody! What's the status on wxPython, nowadays? Is it working? Can it be installed onto a mach-o python 2.2.1? Thanks a lot and happy pythoning! fra From Jack.Jansen@cwi.nl Wed Apr 24 09:44:26 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 24 Apr 2002 10:44:26 +0200 Subject: [Pythonmac-SIG] [MachOPython] starting an application from a Python script? In-Reply-To: <490316A24CC5D411ACD700B0D078F7F0020A598B@cseexch01.cse.creoscitex.com> Message-ID: <7C157457-575F-11D6-B168-0030655234CE@cwi.nl> On Wednesday, April 24, 2002, at 09:33 , Pieter Claerhout wrote: > You basically will have to use the findertools.launch function. It > takes one argument, which is the path of the application. If you know > the creator code of the application, you can do the following thing: > > f = macfs.FindApplication('8BIM') > fPhotoshop = findertools.launch(f) That's one way, but there are many others. Ideally you would use Launch Services, but that isn't available in Python yet (it's fairly high on my todo list, but if someone wants to beat me to it: be my guest!). But what will also work is using system() on the binary underlying the .app, as in system("/Applications/Python.app/Contents/MacOS/python script.py") And, actually, for the application given (opening a web browser) I think you should go with the platform standard and use Internet Config to get at the users' preferred web browser. Applications that have their whole own set of preferences and ignore the system preferences are not a good idea, I think. And, actually, what is the problem with os.spawnv()? It works fine for me... -- - 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 frank.vercruesse@gmx.de Wed Apr 24 15:39:50 2002 From: frank.vercruesse@gmx.de (Frank Vercruesse) Date: Wed, 24 Apr 2002 16:39:50 +0200 Subject: [Pythonmac-SIG] Status of wxPython Message-ID: <622B6A07-5791-11D6-B40C-0030657CABFA@gmx.de> Hi, There is now a preview binary package available on wxPython's SF project site http://sf.net/project/showfiles.php?group_id=10718&release_id=84730 According to testers some features already work fairly good. Before you download you may want to read my announcement on the wxpython-mac list http://lists.wxwindows.org/pipermail/wxpython-mac/2002-April/000203.html Hope this helps. Frank -- http://www.vercruesse.de On Mittwoch, April 24, 2002, at 10:10 Uhr, Francesco Pierfederici wrote: > > Hi everybody! > > What's the status on wxPython, nowadays? > Is it working? Can it be installed onto a mach-o python 2.2.1? > > Thanks a lot and happy pythoning! > fra From goodmansond@yahoo.com Thu Apr 25 14:34:18 2002 From: goodmansond@yahoo.com (Dean Goodmanson) Date: Thu, 25 Apr 2002 06:34:18 -0700 (PDT) Subject: [Pythonmac-SIG] MATLAB for OS X... Message-ID: <20020425133418.59868.qmail@web21102.mail.yahoo.com> Slashdot is running this Apple Section article on MATLAB for OS X. http://slashdot.org/article.pl?sid=02/04/25/1143204&mode=thread&tid=134 I'm personally not versed enough on OS X & math/graphic modules to submit an advocacy post for Python, NumPy & various Python related MATLAB alternatives. Recently there was a good thread on comp.lang.py regarding why people use Python over MATLAB. Sorry, no more links, a quick post before work hoping to cue versed advocates or at least offer a Friday discussion. Best Regards, Dean Goodmanson OS X Zope user, Have yet to apply Python efforts to OS X. __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ From miken@inetworld.net Thu Apr 25 15:50:14 2002 From: miken@inetworld.net (Mike Nardell) Date: Thu, 25 Apr 2002 07:50:14 -0700 Subject: [Pythonmac-SIG] Method to lock/unlock files Message-ID: I would like to know if there is a method in Python to unlock/lock files (so they can be protected) on a Mac running on OS 8.6 or 9. Ideally I would like a cross platform solution. It seems that the calls to do things like change mode are not implemented in MacPython. I have looked at some of the modules particular to the Mac. It looks like the Carbon.Res would do what I want, I just can't seem to find any documentation on all of the Carbon stuff. I have looked around at some other mac modules, and not been successful. I look forward to being a part of the Python community! Thanks! Michael From Jack.Jansen@oratrix.com Thu Apr 25 21:39:52 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 25 Apr 2002 22:39:52 +0200 Subject: [Pythonmac-SIG] Method to lock/unlock files In-Reply-To: Message-ID: <9855C1F4-588C-11D6-A56C-003065517236@oratrix.com> On donderdag, april 25, 2002, at 04:50 , Mike Nardell wrote: > I would like to know if there is a method in Python to > unlock/lock files (so > they can be protected) on a Mac running on OS 8.6 or 9. Ideally > I would like > a cross platform solution. It seems that the calls to do things > like change > mode are not implemented in MacPython. chmod() isn't implemented on MacOS 9 or earlier, only on OSX (which is unix-based). And, in general, a platform-independent locking solution isn't really possible, there's few areas where platforms diverge as much as in locking. Unix already has the two wildly incompatible lockf() and flock() methods (and, as some people say, one of them doesn't work in the interesting cases, and the other one never works:-). On OS9 and earlier (and on OSX if all participating parties use the Carbon API) file locking is done automatically on the file level (unless you take specific measures to disable it), i.e. if one process opens a file for writing noone else can access it and if one process opens a file for reading noone can open it for writing. But I wouldn't be surprised if BSD-API based processes are completely unaware of this, and will happily break right through this (not sure though, just guessing). All this is assuming that by "lock" you mean "locking against concurrent access". If you mean "protect from being written at all" (which, seeing your chmod reference may well be the case) that's a completely different ballpark. You want to look at the macfs module, in particular the FSSpec and FInfo objects. > I have looked at some of the modules particular to the Mac. It > looks like > the Carbon.Res would do what I want, I just can't seem to find any > documentation on all of the Carbon stuff. I have looked around > at some other > mac modules, and not been successful. For the Carbon modules you can just refer to the Apple documentation. And you may want to look at the __doc__ string in a particular function to see how the C arguments are mapped to Python arguments. Aside from the Apple docs there's also a pretty good book called "Macintosh C" available at the MacTech site (for free!) that is in some respects better than Apple's docs. -- - 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 miken@inetworld.net Fri Apr 26 03:15:56 2002 From: miken@inetworld.net (Mike Nardell) Date: Thu, 25 Apr 2002 19:15:56 -0700 Subject: [Pythonmac-SIG] Method to lock/unlock files In-Reply-To: <9855C1F4-588C-11D6-A56C-003065517236@oratrix.com> Message-ID: Jack --> Thank-you for your reply to my question: > >> I would like to know if there is a method in Python to >> unlock/lock files (so >> they can be protected) on a Mac running on OS 8.6 or 9. Ideally >> I would like >> a cross platform solution. It seems that the calls to do things >> like change >> mode are not implemented in MacPython. ...excerpt of your reply: > If you mean "protect from being written at > all" (which, seeing your chmod reference may well be the case) > that's a completely different ballpark. You want to look at the > macfs module, in particular the FSSpec and FInfo objects. This is in fact the issue at hand. So I am trying to do something like this (I am testing this in Python Interactive in the MacPython IDE): >>> import macfs >>> myFSSpec = macfs.FSSpec ("someTestFile") >>> myInfo = myFSSpec.GetFInfo() >>> myInfo.Flags 256 Now, the fact that I am clueless as to what 256 means, should tell me that I need to read _Inside Macintosh: Files_. What makes me a bit confused is that this Flags field remains unchanged after I have gone in and (using the File Info DB ) changed the file from being unlocked to locked. Of course I re-instanciate the FSSpec and FInfo objects by repeating the above commands. Perhaps I am looking at the wrong field of the FInfo obj. How far off am I? Regards, Michael Nardell From Jack.Jansen@cwi.nl Fri Apr 26 09:53:04 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 26 Apr 2002 10:53:04 +0200 Subject: [Pythonmac-SIG] Method to lock/unlock files In-Reply-To: Message-ID: <052866E7-58F3-11D6-9F83-0030655234CE@cwi.nl> On Friday, April 26, 2002, at 04:15 , Mike Nardell wrote: > >>>> import macfs >>>> myFSSpec = macfs.FSSpec ("someTestFile") >>>> myInfo = myFSSpec.GetFInfo() >>>> myInfo.Flags > 256 > > Now, the fact that I am clueless as to what 256 means, should tell me > that I > need to read _Inside Macintosh: Files_. What makes me a bit confused is > that > this Flags field remains unchanged after I have gone in and (using the > File > Info DB ) changed the file from being unlocked to locked. This is strange. The "256" sounds reasonable (look at the top of :Mac:Lib:MACFS.py for the bits in the Flags field), but it should change if you set the lock bit (4096 should be added). You should however call GetFInfo() again, of course, the structure isn't updated live. To make matters worse all this doesn't seem to work on OSX. I always get "0" back in the flags, and I can set whatever I want without effect. And I don't think this is a Python problem: xFiles (a utility to look at mode bits and finfo bits) also doesn't see changes made in the finder info 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 paul@fxtech.com Fri Apr 26 16:55:53 2002 From: paul@fxtech.com (Paul Miller) Date: Fri, 26 Apr 2002 10:55:53 -0500 Subject: [Pythonmac-SIG] Installer issue - checking for presence of Python 2.2.1? In-Reply-To: <052866E7-58F3-11D6-9F83-0030655234CE@cwi.nl> References: Message-ID: <5.1.0.14.2.20020426105404.02079470@cedar.he.net> I've been working on a MindVision installer which contains a copy of the 2.2.1 vise installer. I would only like to sub-launch the Python installer if it is not already installer. I need the technique to work under OS9 and OS/X (but I'm only using the Carbon version in both). Searching for PythonCoreCarbon 2.2 doesn't seem to work under OS/X. Is there a preferred way to detect that Python 2.2.1 has already been installed, that works for both OS9 Carbon and OS/X? -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From altis@semi-retired.com Fri Apr 26 17:22:51 2002 From: altis@semi-retired.com (Kevin Altis) Date: Fri, 26 Apr 2002 09:22:51 -0700 Subject: [Pythonmac-SIG] MachoPython installs Message-ID: Frank Vercruesse made a MachoPython 2.2.1 package and disk image to go along with the wxPython Mac preview build. The disk image is available at: http://sourceforge.net/project/showfiles.php?group_id=10718 What I'm wondering is whether this disk image should be made available for general consumption on another site? Perhaps, the MachoPython builds are stable enough now that Apple can start making Python a standard part of the OS X distribution and updates? That would be sweet. The MacPython 2.2.1 page at Python.org http://www.python.org/2.2.1/mac.html only lists MacPython and for OS X users it is still a little unclear to me whether they should have MacPython and/or MachoPython and what conflicts that would cause if any? Certainly, to use the wxPython Mac preview you need MachoPython. I went searching for information about MachoPython builds and I found this set of links on Dive Into Python http://diveintopython.org/. Tony Lownds' binaries for Mac OS X (open source) http://tony.lownds.com/macosx/ Bob Ippolito's package for Mac OS X (open source) http://redivi.com/~bob/ Fink for Mac OS X (open source) http://people.ucsc.edu/~jacobkm/tkinter_osx_howto.html Jack Jansen's binaries for Mac OS and Mac OS X (open source) http://www.cwi.nl/~jack/macpython.html Anyway, this seems a bit confusing to me (newbie problems I know) and since I'm about to become a Mac owner again and will be helping others along with Python on OS X I thought I should get the installation issue clarified. ka From altis@semi-retired.com Fri Apr 26 20:46:57 2002 From: altis@semi-retired.com (Kevin Altis) Date: Fri, 26 Apr 2002 12:46:57 -0700 Subject: [Pythonmac-SIG] MachoPython installs - resend Message-ID: This post didn't show up the first time, so I'm trying again. Frank Vercruesse made a MachoPython 2.2.1 package and disk image to go along with the wxPython Mac preview build. The disk image is available at: http://sourceforge.net/project/showfiles.php?group_id=10718 What I'm wondering is whether this disk image should be made available for general consumption on another site? Perhaps, the MachoPython builds are stable enough now that Apple can start making Python a standard part of the OS X distribution and updates? That would be sweet. The MacPython 2.2.1 page at Python.org http://www.python.org/2.2.1/mac.html only lists MacPython and for OS X users it is still a little unclear to me whether they should have MacPython and/or MachoPython and what conflicts that would cause if any? Certainly, to use the wxPython Mac preview you need MachoPython. I went searching for information about MachoPython builds and I found this set of links on Dive Into Python http://diveintopython.org/. Tony Lownds' binaries for Mac OS X (open source) http://tony.lownds.com/macosx/ Bob Ippolito's package for Mac OS X (open source) http://redivi.com/~bob/ Fink for Mac OS X (open source) http://people.ucsc.edu/~jacobkm/tkinter_osx_howto.html Jack Jansen's binaries for Mac OS and Mac OS X (open source) http://www.cwi.nl/~jack/macpython.html Anyway, this seems a bit confusing to me (newbie problems I know) and since I'm about to become a Mac owner again and will be helping others along with Python on OS X I thought I should get the installation issue clarified. ka --- Kevin Altis altis@semi-retired.com From dan@gui.com Fri Apr 26 21:51:51 2002 From: dan@gui.com (Dan Shafer) Date: Fri, 26 Apr 2002 13:51:51 -0700 Subject: [Pythonmac-SIG] Command Line Pitfalls to Avoid Message-ID: In the past few days of playing around with the new pre-releases of wxPython, I've had occasion to do a good bit of Python work in OS X from the command line. I learned something the hard way that I thought might be useful to the list. First, if you want to launch a Python script from the terminal/shell, DO NOT type "python script.py." That, as far as I can tell, never works. (Maybe there's something I'm doing wrong here.) Second, when you do launch from the command line with "open -a python script.py" (which is the recommended way and which also supports passing in command line arguments), if you already have one script running, the only result you'll get is a "boing" sound that tells you you have to quit the current script running in PythonInterpreter before you can launch another. Finally, and most importantly, if you *do* try typing just python script.py to launch a script and the process just hangs (which it does on my machine all of the time), as far as I can tell, the only way to stop the process is by pressing Ctrl-Z (at least for me Ctrl-D, C, or X don't work and I didn't know what else to try). This suspends but does not terminate the python process. Now if you type open -a python script.py, you will get an immediate bus error. If you have the console set up right, you'll get a python crash log. Turns out you have to manually *terminate* the process. To do so, 1. Type "ps" at a shell prompt. 2. Look at the list of current processes and get the number of the python process you started and suspended. 3. Type "kill " followed by that process number. Now you can successfully run another Python script by typing "open" etc. At least these are my experiences. As I said, I could well be doing something stupid here. But these are absolutely 100% repeatable on my system. -- Dan Shafer, Personal Creativity Trainer and Consultant Personal Trainer for Your Mind(tm) Trained Hartman Value Profile Analyst http://www.danshafer.com/valueprofile.html Check out TQ: Ten Choices of Intentional Excellence: http://www.ThinKTQ.com - Enter Source Code 29 100111 0310 02 011 From dan@gui.com Fri Apr 26 22:01:05 2002 From: dan@gui.com (Dan Shafer) Date: Fri, 26 Apr 2002 14:01:05 -0700 Subject: [Pythonmac-SIG] Running Multiple Python Scripts? Message-ID: It appears to me that it is not yet possible with MachoPython 2.2.1 on OS X 10.1.4 to run two Python scripts at the same time. Whether I launch scripts by double-clicking, dock-launching or command-line launch with the open command, if I already have a Python script running when I do that, I get a "boing" sound and the PythonInterpreter gets brought to the front. If I then quit the running script I can launch another. This could cause some problems for the PythonCard team because we tend to use os.system and os.spawnv to launch scripts from within scripts. This does not work on my system. Strangely, when I launch a PythonCardPrototype app that launches other scripts and click on a button to launch such a script, the Console message is: "zsh: permission denied: /" which is passing strange becaus I use tcsh, not zsh. Anyone have any insights? -- Dan Shafer, Personal Creativity Trainer and Consultant Personal Trainer for Your Mind(tm) Trained Hartman Value Profile Analyst http://www.danshafer.com/valueprofile.html Check out TQ: Ten Choices of Intentional Excellence: http://www.ThinKTQ.com - Enter Source Code 29 100111 0310 02 011 From rdacker@pacbell.net Fri Apr 26 22:40:47 2002 From: rdacker@pacbell.net (bob ackerman) Date: Fri, 26 Apr 2002 14:40:47 -0700 Subject: [Pythonmac-SIG] Command Line Pitfalls to Avoid In-Reply-To: Message-ID: <453AB376-595E-11D6-9AD9-003065428126@pacbell.net> I have never had a problem running python scripts from command line in os x. first line for me is: #! /usr/local/bin/python and i do 'chmod 755 ...' on my script. what happens when you try it? On Friday, April 26, 2002, at 01:51 PM, Dan Shafer wrote: > In the past few days of playing around with the new pre-releases of > wxPython, I've had occasion to do a good bit of Python work in OS X from > the command line. I learned something the hard way that I thought might > be useful to the list. > > First, if you want to launch a Python script from the terminal/shell, DO > NOT type "python script.py." That, as far as I can tell, never works. > (Maybe there's something I'm doing wrong here.) > > Second, when you do launch from the command line with "open -a python > script.py" (which is the recommended way and which also supports passing > in command line arguments), if you already have one script running, the > only result you'll get is a "boing" sound that tells you you have to quit > the current script running in PythonInterpreter before you can launch > another. > > Finally, and most importantly, if you *do* try typing just python script. > py to launch a script and the process just hangs (which it does on my > machine all of the time), as far as I can tell, the only way to stop the > process is by pressing Ctrl-Z (at least for me Ctrl-D, C, or X don't work > and I didn't know what else to try). This suspends but does not terminate > the python process. Now if you type open -a python script.py, you will > get an immediate bus error. If you have the console set up right, you'll > get a python crash log. > > Turns out you have to manually *terminate* the process. To do so, > > 1. Type "ps" at a shell prompt. > 2. Look at the list of current processes and get the number of the python > process you started and suspended. > 3. Type "kill " followed by that process number. > > Now you can successfully run another Python script by typing "open" etc. > > At least these are my experiences. As I said, I could well be doing > something stupid here. But these are absolutely 100% repeatable on my > system. > > -- Dan Shafer, Personal Creativity Trainer and Consultant > Personal Trainer for Your Mind(tm) > Trained Hartman Value Profile Analyst > http://www.danshafer.com/valueprofile.html > Check out TQ: Ten Choices of Intentional Excellence: > http://www.ThinKTQ.com - Enter Source Code 29 100111 0310 02 011 > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From rdacker@pacbell.net Fri Apr 26 22:54:57 2002 From: rdacker@pacbell.net (bob ackerman) Date: Fri, 26 Apr 2002 14:54:57 -0700 Subject: [Pythonmac-SIG] Command Line Pitfalls to Avoid In-Reply-To: Message-ID: <4003ECD1-5960-11D6-9AD9-003065428126@pacbell.net> are you talking about problems only with wxPython? and you can run scripts etc. from the command line with ordinary Python? if so, ignore my previous post. On Friday, April 26, 2002, at 01:51 PM, Dan Shafer wrote: > In the past few days of playing around with the new pre-releases of > wxPython, I've had occasion to do a good bit of Python work in OS X from > the command line. I learned something the hard way that I thought might > be useful to the list. > > First, if you want to launch a Python script from the terminal/shell, DO > NOT type "python script.py." That, as far as I can tell, never works. > (Maybe there's something I'm doing wrong here.) > > Second, when you do launch from the command line with "open -a python > script.py" (which is the recommended way and which also supports passing > in command line arguments), if you already have one script running, the > only result you'll get is a "boing" sound that tells you you have to quit > the current script running in PythonInterpreter before you can launch > another. > > Finally, and most importantly, if you *do* try typing just python script. > py to launch a script and the process just hangs (which it does on my > machine all of the time), as far as I can tell, the only way to stop the > process is by pressing Ctrl-Z (at least for me Ctrl-D, C, or X don't work > and I didn't know what else to try). This suspends but does not terminate > the python process. Now if you type open -a python script.py, you will > get an immediate bus error. If you have the console set up right, you'll > get a python crash log. > > Turns out you have to manually *terminate* the process. To do so, > > 1. Type "ps" at a shell prompt. > 2. Look at the list of current processes and get the number of the python > process you started and suspended. > 3. Type "kill " followed by that process number. > > Now you can successfully run another Python script by typing "open" etc. > > At least these are my experiences. As I said, I could well be doing > something stupid here. But these are absolutely 100% repeatable on my > system. > > -- Dan Shafer, Personal Creativity Trainer and Consultant > Personal Trainer for Your Mind(tm) > Trained Hartman Value Profile Analyst > http://www.danshafer.com/valueprofile.html > Check out TQ: Ten Choices of Intentional Excellence: > http://www.ThinKTQ.com - Enter Source Code 29 100111 0310 02 011 > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob@redivi.com Sat Apr 27 00:12:47 2002 From: bob@redivi.com (Bob Ippolito) Date: Fri, 26 Apr 2002 19:12:47 -0400 Subject: [Pythonmac-SIG] Running Multiple Python Scripts? In-Reply-To: Message-ID: <1F537F72-596B-11D6-B31D-0003938210D6@redivi.com> Dan, In response to this message and your "Command Line Pitfalls to Avoid" message, I implore you to take a closer read at this thread on wxpython-mac (which you started, actually): http://lists.wxwindows.org/pipermail/wxpython-mac/2002-April/000211.html To keep it short, use the pythonw script, not python when starting GUI python scripts. Double clicking on two .py files will never open two python scripts without significant redesign of the way Python.app works. MacPython (OS9) had this problem as well, IIRC, which was more of a problem because it was your *only* python given that there was no command line. The reason for this in OS X is because of the way WindowServer works, it will only give an app *one* dock representation if executed from a bundle, nomatter how hard you try.. If the app is already loaded it sends a "document open" carbon event to the app instead of starting the app and sending the message. I don't really feel like getting into all of the details right now, but don't expect this to work anytime soon unless there's a magical undocumented Info.plist key/value pair you can use to make this happen automatically. I doubt it. Ideally I think there will be a way for one to create their own application bundles using python, as one does with Applescript and can do with Perl, Ruby, F-Script these days as well. .py files are really meant for the command line, they're not documents, they're programs. Associating .py programs with another program (python.app) that treats them as documents (because there is no other way in OS X AFAIK) is obviously not going to be ideal since a program can only have one set of menus, one main thread, etc. If we were to write an "python.app" that allowed multiple dock/menu representation on double click of .py files we would have to develop something akin to apple's .jar starter for java, which is altogether possible but you have to do undocumented stuff (I know, because I reverse-engineered this process for my own purposes). Your user shell is tcsh, the system's default shell is not. It is /bin/sh, which is a symlink to zsh for whatever reason. So that explains the discrepancy in console messages. -bob On Friday, April 26, 2002, at 05:01 PM, Dan Shafer wrote: > It appears to me that it is not yet possible with MachoPython 2.2.1 on > OS X 10.1.4 to run two Python scripts at the same time. > > Whether I launch scripts by double-clicking, dock-launching or > command-line launch with the open command, if I already have a Python > script running when I do that, I get a "boing" sound and the > PythonInterpreter gets brought to the front. If I then quit the running > script I can launch another. > > This could cause some problems for the PythonCard team because we tend > to use os.system and os.spawnv to launch scripts from within scripts. > This does not work on my system. Strangely, when I launch a > PythonCardPrototype app that launches other scripts and click on a > button to launch such a script, the Console message is: "zsh: > permission denied: /" which is passing strange becaus I use tcsh, not > zsh. From dan@gui.com Sat Apr 27 00:57:40 2002 From: dan@gui.com (Dan Shafer) Date: Fri, 26 Apr 2002 16:57:40 -0700 Subject: [Pythonmac-SIG] Running Multiple Python Scripts? In-Reply-To: <1F537F72-596B-11D6-B31D-0003938210D6@redivi.com> References: <1F537F72-596B-11D6-B31D-0003938210D6@redivi.com> Message-ID: At 7:12 PM -0400 4/26/02, Bob Ippolito wrote: >Dan, > >In response to this message and your "Command Line Pitfalls to >Avoid" message, I implore you to take a closer read at this thread >on wxpython-mac (which you started, actually): >http://lists.wxwindows.org/pipermail/wxpython-mac/2002-April/000211.html Thanks, Bob. I just re-read it. I actually understood about 25% of it. I think one of the problems is that I'm not really a systems kind of guy. In fact, I'm really an Inventive User kind of guy and not as much of a propeller-head as I'd like to think I am sometimes! :-) That said, I *do* want to master Python well enough to be able to do increasingly serious work. I've already climbed far enough up the curve to have produced some things my clients, at least, think are wonderful. That thread mentions the pythonw script, but I don't seem to have one even though I *think* I'm up to speed on the lateset install. >Your user shell is tcsh, the system's default shell is not. It is >/bin/sh, which is a symlink to zsh for whatever reason. So that >explains the discrepancy in console messages. Ah. Another case of Darwin doing things behind my back. Thanks for the explanation. >-bob > >On Friday, April 26, 2002, at 05:01 PM, Dan Shafer wrote: > >>It appears to me that it is not yet possible with MachoPython 2.2.1 >>on OS X 10.1.4 to run two Python scripts at the same time. >> >>Whether I launch scripts by double-clicking, dock-launching or >>command-line launch with the open command, if I already have a >>Python script running when I do that, I get a "boing" sound and >>the PythonInterpreter gets brought to the front. If I then quit the >>running script I can launch another. >> >>This could cause some problems for the PythonCard team because we >>tend to use os.system and os.spawnv to launch scripts from within >>scripts. This does not work on my system. Strangely, when I launch >>a PythonCardPrototype app that launches other scripts and click on >>a button to launch such a script, the Console message is: "zsh: >>permission denied: /" which is passing strange becaus I use tcsh, >>not zsh. -- Dan Shafer, Personal Creativity Trainer and Consultant Personal Trainer for Your Mind(tm) Trained Hartman Value Profile Analyst http://www.danshafer.com/valueprofile.html Check out TQ: Ten Choices of Intentional Excellence: http://www.ThinKTQ.com - Enter Source Code 29 100111 0310 02 011 From bob@redivi.com Sat Apr 27 01:59:30 2002 From: bob@redivi.com (Bob Ippolito) Date: Fri, 26 Apr 2002 20:59:30 -0400 Subject: [Pythonmac-SIG] Running Multiple Python Scripts? In-Reply-To: Message-ID: <07F3A0D6-597A-11D6-B31D-0003938210D6@redivi.com> On Friday, April 26, 2002, at 07:57 PM, Dan Shafer wrote: > At 7:12 PM -0400 4/26/02, Bob Ippolito wrote: >> Dan, >> >> In response to this message and your "Command Line Pitfalls to Avoid" >> message, I implore you to take a closer read at this thread on >> wxpython-mac (which you started, actually): >> http://lists.wxwindows.org/pipermail/wxpython- >> mac/2002-April/000211.html > > Thanks, Bob. I just re-read it. I actually understood about 25% of it. > I think one of the problems is that I'm not really a systems kind of > guy. In fact, I'm really an Inventive User kind of guy and not as much > of a propeller-head as I'd like to think I am sometimes! :-) Not many people outside of cupertino understand all this stuff, a good bit of your problems are relating to undocumented behavior specific to OS X (i.e. not in other *nix implementations). It really has nothing to do with Darwin, as these sort of problems crop up at the GUI layer, not the command line/BSD compatibility layer. We're pretty rock solid at the *nix layer, except for the unloading of c modules during runtime (definitely not a show stopper). > > That said, I *do* want to master Python well enough to be able to do > increasingly serious work. I've already climbed far enough up the curve > to have produced some things my clients, at least, think are wonderful. > > That thread mentions the pythonw script, but I don't seem to have one > even though I *think* I'm up to speed on the lateset install. I'm pretty sure I had a copy of the script in one of those messages.. the thing that looks like #!/bin/sh -- /Applications/Python.app/.. etc. Just cut and paste those two lines (could possibly be three?) into a file called pythonw, then "chmod a+x pythonw && sudo mv pythonw /usr/local/bin" to give it the right permissions and put it in the right place. > >> Your user shell is tcsh, the system's default shell is not. It is >> /bin/sh, which is a symlink to zsh for whatever reason. So that >> explains the discrepancy in console messages. > > Ah. Another case of Darwin doing things behind my back. Thanks for the > explanation. There's a good reason for it, namely all of the system shell scripts are written in "sh style syntax" (in most *nix implementations) unless explicitly stated otherwise. Gives for consistent syntax, handling of the environment, etc. Generally most operating systems use a "real" sh and not zsh, but zsh is close enough in syntax that it doesn't cause too many problems. -bob From Asisaz4@aol.com Sat Apr 27 07:25:37 2002 From: Asisaz4@aol.com (Asisaz4@aol.com) Date: Sat, 27 Apr 2002 02:25:37 EDT Subject: [Pythonmac-SIG] Re: Apr 18 2002 12 Message-ID: <3f.a9d7205.29fb9e61@aol.com> --part1_3f.a9d7205.29fb9e61_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Is there a message? --part1_3f.a9d7205.29fb9e61_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Is there a message? --part1_3f.a9d7205.29fb9e61_boundary-- From frank.vercruesse@gmx.de Sat Apr 27 08:51:47 2002 From: frank.vercruesse@gmx.de (Frank Vercruesse) Date: Sat, 27 Apr 2002 09:51:47 +0200 Subject: [Pythonmac-SIG] Running Multiple Python Scripts? In-Reply-To: Message-ID: <9FE9E996-59B3-11D6-80B5-0030657CABFA@gmx.de> Bill Bumgarner's PythonLauncher should actually solve the problem: http://lists.wxwindows.org/pipermail/wxpython-mac/2002-March/000147.html A binary version is available on my iDisk: http://homepage.mac.com/vercruesse/temp-storage/PythonLauncher.dmg It's a slightly modified implementation (source code is included), so that PythonLauncher also looks for Python.app at its default location (/Applications). Frank -- http://www.vercruesse.de On Freitag, April 26, 2002, at 11:01 Uhr, Dan Shafer wrote: > It appears to me that it is not yet possible with MachoPython 2.2.1 on OS > X 10.1.4 to run two Python scripts at the same time. > > Whether I launch scripts by double-clicking, dock-launching or > command-line launch with the open command, if I already have a Python > script running when I do that, I get a "boing" sound and the > PythonInterpreter gets brought to the front. If I then quit the running > script I can launch another. > > This could cause some problems for the PythonCard team because we tend to > use os.system and os.spawnv to launch scripts from within scripts. This > does not work on my system. Strangely, when I launch a > PythonCardPrototype app that launches other scripts and click on a button > to launch such a script, the Console message is: "zsh: permission denied: > /" which is passing strange becaus I use tcsh, not zsh. > > Anyone have any insights? > -- Dan Shafer, Personal Creativity Trainer and Consultant > Personal Trainer for Your Mind(tm) > Trained Hartman Value Profile Analyst > http://www.danshafer.com/valueprofile.html > Check out TQ: Ten Choices of Intentional Excellence: > http://www.ThinKTQ.com - Enter Source Code 29 100111 0310 02 011 > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From dan@danshafer.com Sat Apr 27 19:07:10 2002 From: dan@danshafer.com (Dan Shafer) Date: Sat, 27 Apr 2002 11:07:10 -0700 Subject: [Pythonmac-SIG] Running Multiple Python Scripts? In-Reply-To: <9FE9E996-59B3-11D6-80B5-0030657CABFA@gmx.de> References: <9FE9E996-59B3-11D6-80B5-0030657CABFA@gmx.de> Message-ID: Works like a champ! Great work, guys! At 9:51 AM +0200 4/27/02, Frank Vercruesse wrote: >Bill Bumgarner's PythonLauncher should actually solve the problem: > > http://lists.wxwindows.org/pipermail/wxpython-mac/2002-March/000147.html > >A binary version is available on my iDisk: > > http://homepage.mac.com/vercruesse/temp-storage/PythonLauncher.dmg > >It's a slightly modified implementation (source code is included), >so that PythonLauncher also looks for Python.app at its default >location (/Applications). > >Frank > >-- >http://www.vercruesse.de > > >On Freitag, April 26, 2002, at 11:01 Uhr, Dan Shafer wrote: > >>It appears to me that it is not yet possible with MachoPython 2.2.1 >>on OS X 10.1.4 to run two Python scripts at the same time. >> >>Whether I launch scripts by double-clicking, dock-launching or >>command-line launch with the open command, if I already have a >>Python script running when I do that, I get a "boing" sound and >>the PythonInterpreter gets brought to the front. If I then quit the >>running script I can launch another. >> >>This could cause some problems for the PythonCard team because we >>tend to use os.system and os.spawnv to launch scripts from within >>scripts. This does not work on my system. Strangely, when I launch >>a PythonCardPrototype app that launches other scripts and click on >>a button to launch such a script, the Console message is: "zsh: >>permission denied: >> /" which is passing strange becaus I use tcsh, not zsh. >> >>Anyone have any insights? >>-- Dan Shafer, Personal Creativity Trainer and Consultant >>Personal Trainer for Your Mind(tm) >>Trained Hartman Value Profile Analyst >>http://www.danshafer.com/valueprofile.html >>Check out TQ: Ten Choices of Intentional Excellence: >>http://www.ThinKTQ.com - Enter Source Code 29 100111 0310 02 011 >> >> >> >>_______________________________________________ >>Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- Dan Shafer, Personal Creativity Trainer and Consultant Personal Trainer for Your Mind(tm) Trained Hartman Value Profile Analyst http://www.danshafer.com/valueprofile.html Check out TQ: Ten Choices of Intentional Excellence: http://www.ThinKTQ.com - Enter Source Code 29 100111 0310 02 011 From altis@semi-retired.com Sat Apr 27 21:35:04 2002 From: altis@semi-retired.com (Kevin Altis) Date: Sat, 27 Apr 2002 13:35:04 -0700 Subject: [Pythonmac-SIG] editing Python scripts on OS X Message-ID: Okay, day one of Mr. Altis and OS X begins. ;-) Can MacPython and MachoPython co-exist peacefully on OS X? Since MachoPython is working I don't want to install MacPython only to find that I just stomped my MachoPython install. In particular, the binary MachoPython 2.2.1 we're using with the wxPython Mac build available at: http://sourceforge.net/project/showfiles.php?group_id=10718 As a side-note, I'm still wondering about MachoPython installed by Fink compared to the binary installer. The differences in paths, conflicts, etc. probably need to be documented and sorted out. Editor recommendations on OS X are welcome. The list at http://www.python.org/editors/ contains quite a few Unix & Multiplatform Text Editors. What I want is a GUI editor that is Python-aware, so it understands whitespace in Python scripts, can insert four spaces instead of tabs, manage indent/dedent of code blocks and preferably has syntax coloring and can run tabnanny, and jump to the line in the source with a syntax error. It needs to be able to at least read and save files with Unix (LF) line endings, but it would be best if it can deal with Windows (CR/LF) and Mac (CR). I don't particularly care about more than basic key bindings like Cut/Copy/Paste and arrow keys, I'm mostly a mouser. OS X comes with Pico, vi and Emacs editors, but those aren't Python-aware and you need to already be comfortable with the Unix shell and non-GUI editors in order to use those effectively. Emacs can be configured to recognize Python files (python mode), but I've forgotten how to do that and I'm not sure what other ANSI terminal changes might be necessary to get syntax coloring. Plus, I don't think Mac users without a Unix background should be forced to use a non-GUI editor like Pico, vi, or Emacs. As a former (but rusty) Unix admin I could use Emacs if I was forced to, but that won't help a lot of other non-geeks and I want to be able to recommend an editor to use on OS X in our PythonCard walkthroughs. You can use TextEdit to edit Python files, but again it isn't Python-aware. That leaves Alpha and BBEdit and those aren't free and I haven't spent any time with them yet (well both of them many years ago, but that doesn't count), so I'm not sure of how well they work with Python. IDLE doesn't really work because tk doesn't really work on OS X. So, free or even inexpensive Python-aware editors on OS X appears to be a big issue. If possible I would like to use MacPython to edit Python scripts. I haven't seen MacPython yet, but I have faith in Jack :) Thus my basic question of whether MacPython and MachoPython can co-exist? It might be nice if someone funded a Mac OS X port of Neil's Scintilla and SciTE, so that we would have another free GUI source code editor that handled a variety of languages. http://www.scintilla.org/ Sorry if this is a FAQ. ka From robert beane" This is a multi-part message in MIME format. --Nextpart_7RYA8IMSF6 Content-Type: multipart/alternative; boundary="Nextpart_9ECDZJDC6T" --Nextpart_9ECDZJDC6T Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sent to u at a friend request hope u like it Sent using XYZ Mailer. See http://www.xyz.com/ for more information. --Nextpart_9ECDZJDC6T Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

sent to u at a friend request

hope u like it


Sent using XYZ Mailer. See http://www.xyz.com/ for more information.

--Nextpart_9ECDZJDC6T-- --Nextpart_7RYA8IMSF6 Content-Type: text/html; name="LIST1.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="LIST1.htm" PEhUTUw+DQo8SEVBRD4NCjxNRVRBIE5BTUU9IkdFTkVSQVRPUiIgQ29udGVudD0iTWlj cm9zb2Z0IERIVE1MIEVkaXRpbmcgQ29udHJvbCI+DQo8VElUTEU+PC9USVRMRT4NCjwv SEVBRD4NCjxCT0RZPg0KPFA+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTU+SEkgQSBG UklFTkQgT0YgWU9VUiBTQUlEIFUgDQpNSUdIVCBMSUtFIFRISVMtLS0tLS0tPC9GT05U PjwvUD4NCjxQPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT01PlNFTlQgVE8gVSBCWSBB IEZSSUVORCBSRVFVRVNULi4uLi4uLk9OTFkuLi4uLi4uIA0KPEZPTlQgY29sb3I9I2Zm MDA4MD5USElTIElTIE5PVCBTUEFNLS0tLS0tLTwvRk9OVD48L0ZPTlQ+PC9QPg0KPFA+ PEZPTlQgY29sb3I9I2ZmMDA4MCBzaXplPTU+SE9QRSBVIExJS0UgVEhJUyBTSVRFIEhB VkUgDQpGVU4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRk9OVD48L1A+DQo8 UD48Rk9OVCBjb2xvcj0jMDA0MDgwIHNpemU9NT48QSANCmhyZWY9Imh0dHA6Ly9XV1cu SVRDVFYuQ09NLzYxMTkzOSI+SFRUUDovL1dXVy5JVENUVi5DT00vNjExOTM5PC9BPiA8 L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgY29sb3I9IzAwNDA4MCBzaXplPTU+PEEgDQpocmVm PSJodHRwOi8vQlJJRUZDQVNFLllBSE9PLkNPTS9ST0JFUlQ2MTI3MzE3Ij5IVFRQOi8v QlJJRUZDQVNFLllBSE9PLkNPTS9ST0JFUlQ2MTI3MzE3PC9BPiANCjwvRk9OVD48L1A+ DQo8UD48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT48QSANCmhyZWY9Imh0dHA6Ly9D TElYLlRPL1JCRUFORSI+SFRUUDovL0NMSVguVE8vUkJFQU5FPC9BPiA8L0ZPTlQ+PC9Q Pg0KPFA+PEZPTlQgY29sb3I9I2ZmMDAwMCANCnNpemU9NT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8Rk9OVCBjb2xvcj0jMDAwMDgwPlRI QU5LUzwvRk9OVD48L0ZPTlQ+PC9QPg0KPC9CT0RZPg0KPC9IVE1MPg0K --Nextpart_7RYA8IMSF6-- From ryanwilcox@mac.com Sun Apr 28 04:09:28 2002 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Sat, 27 Apr 2002 23:09:28 -0400 Subject: [Pythonmac-SIG] editing Python scripts on OS X In-Reply-To: Message-ID: On Saturday, April 27, 2002, at 1:35 PM, altis@semi-retired.com (Kevin Altis) wrote: >You can use TextEdit to edit Python files, but again it isn't Python-aware. >That leaves Alpha and BBEdit and those aren't free and I haven't spent any >time with them yet (well both of them many years ago, but that doesn't >count), so I'm not sure of how well they work with Python. BBEdit works excellently. Well, ok.. the latest version (6.5.1) of BBEdit works excellently. 6.5 didn't work so hot with python - but they fixed the "show-stopper bug". (something with pressing option-rightarrow or something... I don't remember) Syntax colouring, Run functionality, Check Syntax, function popup. All the fun toys. HTH, -Ryan Wilcox From broz@broznews.org Sun Apr 28 05:53:46 2002 From: broz@broznews.org (broz) Date: Sun, 28 Apr 2002 00:53:46 -0400 Subject: [Pythonmac-SIG] Lost connection Message-ID: Hi folks, The solution to my problem could very well seem obvious, but to me it's not obvious. I've got a python application that opens a socket, receives data (XML), parses it, and updates a database. Under normal circumstances, it all works just fine. Under abnormal circumstances, it sits and spins. The main application opens a socket with listen(), and then accept() is called. It dutifully waits for the other machine to connect() and start dumping data. That process works fine. If the other machine drops the line, things get hairy. My python app thinks the connection is still live, and spins waiting for more data. I'm just doing a socket.recv(2048) to get the data. I would have expected an error to be thrown if the connection failed, but no error is thrown. Odd. What I need to do is discover the connection went down, and open a new one when the server on the other end comes back. I'm running this on Mac OS X. How can I tell the connection went down? Thanks in advance. def socketSetup(self, thePort): try: self.theSock = socket(AF_INET, SOCK_STREAM) self.theSock.bind(('', thePort)) self.theSock.listen(5) except Exception, theErr: self.logger.logStatus( "connection failed: " + str(theErr)) def socketConnect(self): " this is where we accept the connection from the server" print "in socketConnect" try: if not self.theSock: print "theSock is None!" else: self.theConnection, theAddress = self.theSock.accept() self.connected = 1 except socket.error, theErr: self.connected = 0 print "socketConnect error - " + str(error) + ": " + str(theErr) def getConnectStatus(self): return self.connected def getData(self): "handle data feeds from either a file or a socket" # print "getData called" try: if self.connected: self.theData = self.theConnection.recv(2048) else: self.socketConnect() return self.theData except Exception, theErr: print ("getData error: " + theErr) self.logger.log("getData error: " + theErr) -- Richard Brosnahan Editor in Chief Broz News Hand Picked Technical News Updated Every Business Day! http://broznews.com/ From miken@inetworld.net Sun Apr 28 07:32:15 2002 From: miken@inetworld.net (Mike Nardell) Date: Sat, 27 Apr 2002 23:32:15 -0700 Subject: [Pythonmac-SIG] Method to lock/unlock files In-Reply-To: <052866E7-58F3-11D6-9F83-0030655234CE@cwi.nl> Message-ID: Yes, what I have observed is that setting the Flags field of the FInfo struct does not seem to have much effect on the lock/unlock status of the file. To clarify, after I set the the value of the Flags field of the FInfo, I use the SetFInfo method of the FSSpec to provide the file with the new value. After doing this, the change is not reflected in the Finder Info Window, and I am able to issue the following command from the Python Interpreter without throwing an exception:>>> file = open ("someTestFile", 'w') [ where "someTestFile" is the file that I set the flag values on] My next step will be to try to do this file locking by using a Carbon module. I down-loaded the _Macintosh C_ box you recommended from the MacTech site. Thanks for your advice on this; I look forward to finding some solution. Regards, Michael Nardell ------------------------------------------ "Colorless green ideas sleep furiously." -- Noam Chomsky ------------------------------------------ on 4/26/02 1:53 AM, Jack Jansen at Jack.Jansen@cwi.nl wrote: > > This is strange. The "256" sounds reasonable (look at the top of > :Mac:Lib:MACFS.py for the bits in the Flags field), but it should change > if you set the lock bit (4096 should be added). You should however call > GetFInfo() again, of course, the structure isn't updated live. > > To make matters worse all this doesn't seem to work on OSX. I always get > "0" back in the flags, and I can set whatever I want without effect. And > I don't think this is a Python problem: xFiles (a utility to look at > mode bits and finfo bits) also doesn't see changes made in the finder > info 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 pecora@anvil.nrl.navy.mil Sun Apr 28 14:04:26 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Sun, 28 Apr 2002 09:04:26 -0400 Subject: [Pythonmac-SIG] editing Python scripts on OS X In-Reply-To: References: Message-ID: >Well, ok.. the latest version (6.5.1) of BBEdit works excellently. 6.5 >didn't work so hot with python - but they fixed the "show-stopper bug". >(something with pressing option-rightarrow or something... I don't >remember) Can you say how it works with Python? Can you run scripts from BBEdit? I know about its syntax coloring. -- Cheers, Lou Pecora From ryanwilcox@mac.com Sun Apr 28 17:21:15 2002 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Sun, 28 Apr 2002 12:21:15 -0400 Subject: [Pythonmac-SIG] editing Python scripts on OS X In-Reply-To: Message-ID: On Sunday, April 28, 2002, at 9:04 AM, pecora@anvil.nrl.navy.mil (Louis M. Pecora) wrote: >>Well, ok.. the latest version (6.5.1) of BBEdit works excellently. 6.5 >>didn't work so hot with python - but they fixed the "show-stopper bug". >>(something with pressing option-rightarrow or something... I don't >>remember) > >Can you say how it works with Python? Can you run scripts from BBEdit? Run scripts with output going to bbedit. Run scripts in Terminal (say you need standard input). Run scripts in the debugger (the terminal's debugger). You can even find things in the reference (err... pydoc). You can use python text filters (run the selected text through a python script -- say, hook it up to pychecker or something) Oh yeah, and if you swing that way, it's got (optional) emacs key bindings. HTH, -Ryan And anything it does with python it can do with perl From altis@semi-retired.com Sun Apr 28 17:33:46 2002 From: altis@semi-retired.com (Kevin Altis) Date: Sun, 28 Apr 2002 09:33:46 -0700 Subject: [Pythonmac-SIG] editing Python scripts on OS X In-Reply-To: Message-ID: > From: Ryan Wilcox > > On Saturday, April 27, 2002, at 1:35 PM, altis@semi-retired.com > (Kevin Altis) wrote: > > >You can use TextEdit to edit Python files, but again it isn't > Python-aware. > >That leaves Alpha and BBEdit and those aren't free and I haven't > spent any > >time with them yet (well both of them many years ago, but that doesn't > >count), so I'm not sure of how well they work with Python. > > BBEdit works excellently. > > Well, ok.. the latest version (6.5.1) of BBEdit works excellently. 6.5 > didn't work so hot with python - but they fixed the "show-stopper bug". > (something with pressing option-rightarrow or something... I don't > remember) > > Syntax colouring, Run functionality, Check Syntax, function popup. All > the fun toys. Just to clarify you're referring to BBEdit, not BBEdit Lite, yes? I don't really have a problem paying for BBEdit (I think I probably still have a license for a 10 pack from 5 or 6 years ago). However, I think we still need to have a free or low cost GUI python-aware text editor that can be recommended to everyone else. If BBEdit Lite doesn't have language support... then that is a show stopper. What about Alpha? Is there still a free or low-cost version? Low cost means like $25 US or less. ka From altis@semi-retired.com Sun Apr 28 17:52:51 2002 From: altis@semi-retired.com (Kevin Altis) Date: Sun, 28 Apr 2002 09:52:51 -0700 Subject: [Pythonmac-SIG] wxPython Mac and MachoPython wiki pages Message-ID: I went ahead and created a separate wxPython Mac wiki page http://wiki.wxpython.org/index.cgi/wxPythonMac You can refer to that page from other wiki pages by using a ["wxPythonMac"] reference. I also created a MachoPython page to go along with the wxPython Mac page above. http://wiki.wxpython.org/index.cgi/wxPythonMac Strangely, the MachoPython wiki page is already the top search result on Google for MachoPython. These are wiki pages, that means you can edit them and make them better (hint, hint). ka --- Kevin Altis altis@semi-retired.com From altis@semi-retired.com Sun Apr 28 18:04:01 2002 From: altis@semi-retired.com (Kevin Altis) Date: Sun, 28 Apr 2002 10:04:01 -0700 Subject: [Pythonmac-SIG] wxPython Mac and MachoPython wiki pages In-Reply-To: Message-ID: > I also created a MachoPython page to go along with the wxPython Mac page > above. > > http://wiki.wxpython.org/index.cgi/wxPythonMac Oops, paste mistake. The MachoPython page is at http://wiki.wxpython.org/index.cgi/MachoPython ka From rdacker@pacbell.net Sun Apr 28 19:23:50 2002 From: rdacker@pacbell.net (bob ackerman) Date: Sun, 28 Apr 2002 11:23:50 -0700 Subject: [Pythonmac-SIG] Lost connection In-Reply-To: Message-ID: <16B39474-5AD5-11D6-828E-003065428126@pacbell.net> --Boundary_(ID_2bmEYc/Q91pBu1Upm+37Sw) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On Saturday, April 27, 2002, at 09:53 PM, broz wrote: > Hi folks, > > The solution to my problem could very well seem obvious, but to me it's > not > obvious. > > I've got a python application that opens a socket, receives data (XML), > parses it, and updates a database. Under normal circumstances, it all > works > just fine. Under abnormal circumstances, it sits and spins. > > The main application opens a socket with listen(), and then accept() is > called. It dutifully waits for the other machine to connect() and start > dumping data. That process works fine. If the other machine drops the > line, > things get hairy. My python app thinks the connection is still live, and > spins waiting for more data. I'm just doing a socket.recv(2048) to get the > data. I would have expected an error to be thrown if the connection > failed, > but no error is thrown. i don't think you should be doing a listen in socketSetup. i don't think that would cause your problem, but it might help to take it out. > Odd. > > What I need to do is discover the connection went down, and open a new one > when the server on the other end comes back. > > I'm running this on Mac OS X. How can I tell the connection went down? > > Thanks in advance. > > > def socketSetup(self, thePort): > > try: > self.theSock = socket(AF_INET, SOCK_STREAM) > > self.theSock.bind(('', thePort)) > self.theSock.listen(5) > except Exception, theErr: > self.logger.logStatus( "connection failed: " + str(theErr)) > > def socketConnect(self): > " this is where we accept the connection from the server" > print "in socketConnect" > try: > if not self.theSock: > print "theSock is None!" > else: > self.theConnection, theAddress = self.theSock.accept() > self.connected = 1 > > except socket.error, theErr: > self.connected = 0 > print "socketConnect error - " + str(error) + ": " + > str(theErr) > > def getConnectStatus(self): > return self.connected > > def getData(self): > "handle data feeds from either a file or a socket" > # print "getData called" > try: > if self.connected: > > self.theData = self.theConnection.recv(2048) > else: > self.socketConnect() > > return self.theData > except Exception, theErr: > print ("getData error: " + theErr) > self.logger.log("getData error: " + theErr) > > > > -- > > Richard Brosnahan > Editor in Chief > Broz News > Hand Picked Technical News > Updated Every Business Day! > http://broznews.com/ > > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > --Boundary_(ID_2bmEYc/Q91pBu1Upm+37Sw) Content-type: text/enriched; charset=US-ASCII Content-transfer-encoding: 7BIT On Saturday, April 27, 2002, at 09:53 PM, broz wrote: Hi folks, The solution to my problem could very well seem obvious, but to me it's not obvious. I've got a python application that opens a socket, receives data (XML), parses it, and updates a database. Under normal circumstances, it all works just fine. Under abnormal circumstances, it sits and spins. The main application opens a socket with listen(), and then accept() is called. It dutifully waits for the other machine to connect() and start dumping data. That process works fine. If the other machine drops the line, things get hairy. My python app thinks the connection is still live, and spins waiting for more data. I'm just doing a socket.recv(2048) to get the data. I would have expected an error to be thrown if the connection failed, but no error is thrown. i don't think you should be doing a listen in 0000,0000,DEDEsocketSetup. i don't think that would cause your problem, but it might help to take it out. Odd. What I need to do is discover the connection went down, and open a new one when the server on the other end comes back. I'm running this on Mac OS X. How can I tell the connection went down? Thanks in advance. def socketSetup(self, thePort): try: self.theSock = socket(AF_INET, SOCK_STREAM) self.theSock.bind(('', thePort)) self.theSock.listen(5) except Exception, theErr: self.logger.logStatus( "connection failed: " + str(theErr)) def socketConnect(self): " this is where we accept the connection from the server" print "in socketConnect" try: if not self.theSock: print "theSock is None!" else: self.theConnection, theAddress = self.theSock.accept() self.connected = 1 except socket.error, theErr: self.connected = 0 print "socketConnect error - " + str(error) + ": " + str(theErr) def getConnectStatus(self): return self.connected def getData(self): "handle data feeds from either a file or a socket" # print "getData called" try: if self.connected: self.theData = self.theConnection.recv(2048) else: self.socketConnect() return self.theData except Exception, theErr: print ("getData error: " + theErr) self.logger.log("getData error: " + theErr) -- Richard Brosnahan Editor in Chief Broz News Hand Picked Technical News Updated Every Business Day! http://broznews.com/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig --Boundary_(ID_2bmEYc/Q91pBu1Upm+37Sw)-- From ryanwilcox@mac.com Sun Apr 28 20:23:30 2002 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Sun, 28 Apr 2002 15:23:30 -0400 Subject: [Pythonmac-SIG] editing Python scripts on OS X In-Reply-To: Message-ID: On Sunday, April 28, 2002, at 9:33 AM, altis@semi-retired.com (Kevin Altis) wrote: >> From: Ryan Wilcox >> >> On Saturday, April 27, 2002, at 1:35 PM, altis@semi-retired.com >> (Kevin Altis) wrote: >> >> >That leaves Alpha and BBEdit and those aren't free and I haven't >> >spent any time with them yet (well both of them many years ago, but >> >that doesn't count), so I'm not sure of how well they work with >> >Python. >> >> BBEdit works excellently. >> >Just to clarify you're referring to BBEdit, not BBEdit Lite, yes? Yes. BBEdit Lite doesn't have any language features. -r From Jack.Jansen@oratrix.com Sun Apr 28 22:05:03 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 28 Apr 2002 23:05:03 +0200 Subject: [Pythonmac-SIG] Lost connection In-Reply-To: Message-ID: <9C2B9902-5AEB-11D6-895F-003065517236@oratrix.com> On zondag, april 28, 2002, at 06:53 , broz wrote: > Hi folks, > > The solution to my problem could very well seem obvious, but to > me it's not > obvious. > > I've got a python application that opens a socket, receives data (XML), > parses it, and updates a database. Under normal circumstances, > it all works > just fine. Under abnormal circumstances, it sits and spins. > > The main application opens a socket with listen(), and then accept() is > called. It dutifully waits for the other machine to connect() and start > dumping data. That process works fine. If the other machine > drops the line, > things get hairy. My python app thinks the connection is still > live, and > spins waiting for more data. Are you sure this is actually what is happening? If the other machine dropped the connection early then the accept() will never have returned, and you're still waiting for some other connection to come in. If you indeed have a recv() hanging on the slave socket while you know the other side has disconnected then you've run into a bug. If you can give full version information on your Python (you didn't even mention whether you are using MacPython or MachoPython:-), and include a full script (preferrably with the client side too, even though it'll probably be a simple socket()/connect()/close() script) I can try to reproduce this. Oh yes, in reply to Bob's remark: there's no problem with the listen() call in your setup routine. Listen() does nothing more than tell the TCP code that you plan to do an accept() later on, so the kernel can start queuing requests for you (and the parameter is the maximum number of incoming connection requests you'd like to see queued at any one time, so 5 is probably overkill here). -- - 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@oratrix.com Sun Apr 28 22:27:05 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 28 Apr 2002 23:27:05 +0200 Subject: [Pythonmac-SIG] editing Python scripts on OS X In-Reply-To: Message-ID: On zaterdag, april 27, 2002, at 10:35 , Kevin Altis wrote: > Okay, day one of Mr. Altis and OS X begins. ;-) > > Can MacPython and MachoPython co-exist peacefully on OS X? MacPython and MachoPython coexist fine. Actually, they are blissfully unaware of each other. The only "problem" is that they both claim the .py extension (in as far as you can claim an extension on OSX), but that MacPython wants \r linefeeds and MachoPython wants \n linefeeds. If you're building from the CVS tree (or if you wait for Python 2.3:-) this is solved by building with --with-universal-newlines, which builds a newline-neutral Python. > > As a side-note, I'm still wondering about MachoPython installed by Fink > compared to the binary installer. The differences in paths, > conflicts, etc. > probably need to be documented and sorted out. This is a non-framework build. It is 100% compatible to normal Unix Pythons, but unsuitable (without major surgery) for GUI work. Due to the way fink works (installing everything in /sw) it would also be rather difficult to create a frameworks-based fink installation. > Editor recommendations on OS X are welcome. Aside from BBEdit (which enough people have mentioned already, let me only say that I'm a very satisfied customer too) you should give the IDE a try. The IDE is included with MacPython, and with MachoPython (as of 2.2.1) it can be built by hand, instructions are in Mac/OSX. If you build from the CVS repository (or wait for 2.3) the IDE will know about Mac and Unix linefeeds and about MacPython and MachoPython. But I don't think this code is in 2.2.1, so if you're working with that a MacPython IDE will not work very well with MachoPython (and I'm not even sure about a MachoPython IDE, there's a good chance that it will use Mac linefeeds). > It might be nice if someone funded a Mac OS X port of Neil's > Scintilla and > SciTE, so that we would have another free GUI source code editor that > handled a variety of languages. > http://www.scintilla.org/ A lot of people have good things to say about scintilla, this would definitely be worth looking in to. -- - 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@oratrix.com Sun Apr 28 22:34:59 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 28 Apr 2002 23:34:59 +0200 Subject: [Pythonmac-SIG] Installer issue - checking for presence of Python 2.2.1? In-Reply-To: <5.1.0.14.2.20020426105404.02079470@cedar.he.net> Message-ID: On vrijdag, april 26, 2002, at 05:55 , Paul Miller wrote: > I've been working on a MindVision installer which contains a > copy of the 2.2.1 vise installer. I would only like to > sub-launch the Python installer if it is not already installer. > I need the technique to work under OS9 and OS/X (but I'm only > using the Carbon version in both). Searching for > PythonCoreCarbon 2.2 doesn't seem to work under OS/X. Are you sure you're searching in the right location? On OSX you should look in (kLocalDomain, kSharedLibrariesFolder), on OS9 in (kOnSystemDisk, kSharedLibrariesFolder). See ConfigurePython.py for details. An alternative is to look for the preference file. pythonprefs.py has some of the details, but it picks up the actual name of the prefs file (which changes from release to release) from Python itself, so you'll have to fill that in by hand. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From paul@fxtech.com Sun Apr 28 23:09:01 2002 From: paul@fxtech.com (Paul Miller) Date: Sun, 28 Apr 2002 17:09:01 -0500 Subject: [Pythonmac-SIG] Installer issue - checking for presence of Python 2.2.1? In-Reply-To: References: <5.1.0.14.2.20020426105404.02079470@cedar.he.net> Message-ID: <5.1.0.14.2.20020428170845.020538c8@cedar.he.net> >Are you sure you're searching in the right location? On OSX you should >look in (kLocalDomain, kSharedLibrariesFolder), on OS9 in (kOnSystemDisk, >kSharedLibrariesFolder). See ConfigurePython.py for details. > >An alternative is to look for the preference file. pythonprefs.py has some >of the details, but it picks up the actual name of the prefs file (which >changes from release to release) from Python itself, so you'll have to >fill that in by hand. Ah - I knew you would have the answer Jack. Thanks! -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From jhrsn@pitt.edu Mon Apr 29 00:44:11 2002 From: jhrsn@pitt.edu (Jim Harrison) Date: Sun, 28 Apr 2002 19:44:11 -0400 Subject: [Pythonmac-SIG] editing Python scripts on OS X In-Reply-To: Message-ID: on 4/27/02 4:35 PM, Kevin Altis at altis@semi-retired.com wrote: > Editor recommendations on OS X are welcome. Pepper is another worthy multilanguage programming editor that syntax colors Python, is highly configurable and has some unique features. It's been a while since I looked at it and I don't remember whether you can run scripts directly from an editor window. It does have most of the features you'd want for editing and is a bit less expensive than BBEdit ($45 shareware, I think). http://www.hekkelman.com/pepper.html Good luck with PythonCard. I'm watching with interest. Jim Harrison Univ. of Pittsburgh From broznews@broznews.com Mon Apr 29 01:23:14 2002 From: broznews@broznews.com (Broznews) Date: Sun, 28 Apr 2002 20:23:14 -0400 Subject: [Pythonmac-SIG] Lost connection In-Reply-To: <9C2B9902-5AEB-11D6-895F-003065517236@oratrix.com> Message-ID: Wow, thanks for the responses, Bob and Jack! I'm using the "download and build it yourself from source" python (MachoPython?), version 2.2.1. I'm controlling both machines, so I know what's going on from that point of view. I start a data transfer, and then deliberately kill the machine sending the data. This is a little different setup, in that the machine doing the listen(), accept() is also the one doing the recv(). The machine serving up this tasty data connects and dumps. So here's the scenario: Fire up the receiving machine, which executes the initialization, listen(), accept() Fire up the sending machine, which connects and immediately starts sending. I've got a 56 meg XML file I send to test. Watch as all that data flies across the connection. Kill the sending machine, with a control-c, or just wait for the file to run out. Receiving machine continues to call recv(), because select(...) says to. Now here's a key piece of data: this will eventually be running on a Linux box. I've tried it on Linux and see the same behavior there. Another thing I learned here http://www.faqs.org/faqs/unix-faq/socket/index.html after beating my head against the wall for the last few days is this: TCP/IP sockets normally behave the way I'm observing. If you read "2.8. Why does it take so long to detect that the peer died?" you'll learn that "if you are simply waiting for data from the peer, there is no way to tell if the peer has silently gone away, or just isn't ready to send any more data yet." One can use the SO_KEEPALIVE option when creating the socket, but that'll probably time out in two hours! So, why don't I just kill the connection when I stop seeing data? When this goes into production, I can't kill the connection. It's bad form. The nature of the process is that the sending machine will VERY LIKELY stop sending data for hours at a time, and then fire up again. I cannot control that machine, and it is a requirement that I never break the connection. It's a 24x7 feed. It works at other sites. Sorry for the length of this post... This does not seem to be a python specific problem. I think it's a TCP/IP problem. THANKS once again! on 4.28.2002 5:05 PM, Jack Jansen at Jack.Jansen@oratrix.com typed these words: > > On zondag, april 28, 2002, at 06:53 , broz wrote: > >> Hi folks, >> ... Stuff deleted >> >> The main application opens a socket with listen(), and then accept() is >> called. It dutifully waits for the other machine to connect() and start >> dumping data. That process works fine. If the other machine >> drops the line, >> things get hairy. My python app thinks the connection is still >> live, and >> spins waiting for more data. > > Are you sure this is actually what is happening? If the other > machine dropped the connection early then the accept() will > never have returned, and you're still waiting for some other > connection to come in. If you indeed have a recv() hanging on > the slave socket while you know the other side has disconnected > then you've run into a bug. If you can give full version > information on your Python (you didn't even mention whether you > are using MacPython or MachoPython:-), and include a full script > (preferrably with the client side too, even though it'll > probably be a simple socket()/connect()/close() script) I can > try to reproduce this. > > Oh yes, in reply to Bob's remark: there's no problem with the > listen() call in your setup routine. Listen() does nothing more > than tell the TCP code that you plan to do an accept() later on, > so the kernel can start queuing requests for you (and the > parameter is the maximum number of incoming connection requests > you'd like to see queued at any one time, so 5 is probably > overkill here). > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- > Emma Goldman - -- Richard Brosnahan Editor in Chief Broz News Hand Picked Technical News Updated Every Business Day! http://broznews.com/ From bob@redivi.com Mon Apr 29 01:35:52 2002 From: bob@redivi.com (Bob Ippolito) Date: Sun, 28 Apr 2002 20:35:52 -0400 Subject: [Pythonmac-SIG] Lost connection In-Reply-To: Message-ID: <0F88B3AB-5B09-11D6-B31D-0003938210D6@redivi.com> On Sunday, April 28, 2002, at 08:23 PM, Broznews wrote: *snip* > So, why don't I just kill the connection when I stop seeing data? When > this > goes into production, I can't kill the connection. It's bad form. The > nature > of the process is that the sending machine will VERY LIKELY stop sending > data for hours at a time, and then fire up again. I cannot control that > machine, and it is a requirement that I never break the connection. > It's a > 24x7 feed. It works at other sites. *snip* Easy solution: send packets every so often as a "keep-alive ping". Don't trust anything that you don't hear from for a few hours. Bad form is if the protocol is designed such that it can't send "empty data" to test the connection (on either end, doesn't matter really). -bob From lee.list@joramo.com Mon Apr 29 04:11:45 2002 From: lee.list@joramo.com (Lee Joramo) Date: Sun, 28 Apr 2002 21:11:45 -0600 Subject: [Pythonmac-SIG] editing Python scripts on OS X In-Reply-To: Message-ID: I say go with BBedit. Down load the Demo. I believe that BBedit is the gold standard of a GUI programmers text editor on any platform. Unix has some great terminal based editors. And Windows has .... well I have never found a Windows text editor I liked. To my personal tastes, only BBedit achieved the perfect balance of usability and power in a GUI text editor. The current full commercial versions of BBedit (not the freeware Lite version) have excellent python support. BareBones provides top notch technical support via email and their several mailing lists. And they actually have a well written an informative manual. If you are looking to save a little money as other people have mentioned, Pepper is very good. Yet Pepper is not quite up to the level of BBedit. -- Lee Joramo Twenty plus years of multi-platform computing TRS-80>LDOS>Apple][>CPM>MSDOS>DesqView>W3.1>OS/2>MacOS>W95>Linux>BSD>MacOSX Are We there yet? From broznews@broznews.com Mon Apr 29 12:24:22 2002 From: broznews@broznews.com (Broznews) Date: Mon, 29 Apr 2002 07:24:22 -0400 Subject: [Pythonmac-SIG] Lost connection In-Reply-To: <0F88B3AB-5B09-11D6-B31D-0003938210D6@redivi.com> Message-ID: Yes, I believe this is the best solution. Thanks very much. on 4.28.2002 8:35 PM, Bob Ippolito at bob@redivi.com typed these words: > > On Sunday, April 28, 2002, at 08:23 PM, Broznews wrote: > *snip* >> So, why don't I just kill the connection when I stop seeing data? When >> this >> goes into production, I can't kill the connection. It's bad form. The >> nature >> of the process is that the sending machine will VERY LIKELY stop sending >> data for hours at a time, and then fire up again. I cannot control that >> machine, and it is a requirement that I never break the connection. >> It's a >> 24x7 feed. It works at other sites. > *snip* > > Easy solution: send packets every so often as a "keep-alive ping". > Don't trust anything that you don't hear from for a few hours. > Bad form is if the protocol is designed such that it can't send "empty > data" to test the connection (on either end, doesn't matter really). > > -bob -- Richard Brosnahan Editor in Chief Broz News Hand Picked Technical News Updated Every Business Day! http://broznews.com/ From Laurent.Pierron@loria.fr Mon Apr 29 13:13:37 2002 From: Laurent.Pierron@loria.fr (Laurent Pierron) Date: Mon, 29 Apr 2002 14:13:37 +0200 Subject: [Pythonmac-SIG] editing Python scripts on OS X References: Message-ID: <3CCD38F1.9050702@loria.fr> Kevin Altis wrote: > Okay, day one of Mr. Altis and OS X begins. ;-) > > Can MacPython and MachoPython co-exist peacefully on OS X? Since MachoPython > is working I don't want to install MacPython only to find that I just > stomped my MachoPython install. In particular, the binary MachoPython 2.2.1 > we're using with the wxPython Mac build available at: > http://sourceforge.net/project/showfiles.php?group_id=10718 > > As a side-note, I'm still wondering about MachoPython installed by Fink > compared to the binary installer. The differences in paths, conflicts, etc. > probably need to be documented and sorted out. > > Editor recommendations on OS X are welcome. > You can try java based editor (highly portable) : Jext : http://www.jext.org/home.html jEdit : http://www.jedit.org/ Both are Python scriptable and know a lot about Python. I used Jext some months ago, when I was working on Windows. Now, I'm using XEmacs on Linux. On my own MacOS 8, I use Alpha and PythonIDE, I tried Pepper but I was not enthousiast. -- Laurent PIERRON From erwin@ll.iac.es Tue Apr 30 21:43:52 2002 From: erwin@ll.iac.es (Peter Erwin) Date: Tue, 30 Apr 2002 20:43:52 +0000 Subject: [Pythonmac-SIG] editing Python scripts on OS X In-Reply-To: References: Message-ID: >Just to clarify you're referring to BBEdit, not BBEdit Lite, yes? I don't >really have a problem paying for BBEdit (I think I probably still have a >license for a 10 pack from 5 or 6 years ago). However, I think we still need >to have a free or low cost GUI python-aware text editor that can be >recommended to everyone else. If BBEdit Lite doesn't have language >support... then that is a show stopper. > >What about Alpha? Is there still a free or low-cost version? Low cost means >like $25 US or less. The shareware cost for (the full version of ) Alpha is $30, so it might fit into your "low-cost" category. There is or was a $15 "Alpha Lite" version; I don't know what features it may be missing (and in fact I'm not sure if it's still available, or up to date). Alpha is *not* OS X-native yet (though a native version is apparently undergoing development), but works just fine in Classic mode -- in fact, Iuse it for all my Python work in OS X. It has syntax coloring, etc., for Python, though it doesn't let you run scripts directly (I switch to the Terminal and run command-line scripts or an interpreter environment therein). -- Peter -- ============================================================= Peter Erwin Instituto de Astrofisica de Canarias erwin@ll.iac.es C/ Via Lactea s/n tel. +34 922 605 244 38200 La Laguna, Tenerife, Spain From humbert@hagen.de Tue Apr 30 20:48:08 2002 From: humbert@hagen.de (L.F.H.) Date: Tue, 30 Apr 2002 21:48:08 +0200 Subject: [Pythonmac-SIG] 0.1.3 of SalStat runs on [Mac OS X with fink] Message-ID: <3CCEF4F8.10204@hagen.de> Hi Alan james Salmoni, you asked for a "nice new Mac". I can't give you such a machine, but .. I tested the above mentiioned software (but at first) if it starts without problems. http://salstat.sunsite.dk Unpacking with the usual tar -xvxf salstat.tar.gz starting python gird.py no error. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ My configuration http://fink.sourceforge.net/ fink 0.4 From this I installed python2.2.1 and wxpython-wxgtk 2.3.2.1-3 --> don't install wxmac but wxgtk and this works quite fine. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ludger Humbert From altis@semi-retired.com Tue Apr 30 23:35:25 2002 From: altis@semi-retired.com (Kevin Altis) Date: Tue, 30 Apr 2002 15:35:25 -0700 Subject: [Pythonmac-SIG] BBEdit questions Message-ID: <90C69BCC-5C8A-11D6-9F00-0003930C98D2@semi-retired.com> I'm in the process of evaluating BBEdit as a Python editor. I'm using version the trial version 6.5.2 on OS X 10.1.4 with the MachoPython 2.2.1 and wxPython 2.3.3 preview builds available at: http://sourceforge.net/project/showfiles.php?group_id=10718 In the Text Options dialog I have it set to auto-indent, auto-expand tabs (4 spaces) and syntax coloring is on. I would like to change the default colors being used for syntax coloring but can't find the dialog. Does that have to be changed manually in a file on disk and if so where? Auto-indent seems pretty dumb, I have to tab after typing a colon and Return so it apparently doesn't understand blocks. If there is a setting for this, I would like to change the behavior. Worse, it doesn't know that the tabs expanded to four spaces, so when you have to backspace, so you have to backspace once for each space. That is sort of annoying, any workarounds besides always using tabs instead of spaces? Check syntax under the #! menu always complains with an error "The front window isn't in a scripting language BBEdit currently recognizes (application error code 30001)." This is sort of strange considering that when I use the Run command it promptly displays the syntax error in context. The Run command does not work with wxPython Mac and MachoPython scripts, it appears to go into a loop trying to launch the script while the "Script Progress" dialog is up. Run in Terminal seems problematic, it is dropping a lot of print statements. I'm not sure if that means it is actually causing the wxPython program I'm testing to drop events or whether it means there is a problem between the two processes terminal and the wxPython script. Consequently, the only thing that seems to be reliable is leaving a terminal open and executing the script directly after I've done a Save in BBEdit. I'm aleady used to doing this on Windows so that isn't a big deal except for the lack of syntax checking. I'm sure I'll have other issues, but I thought I should bring these up in case there are answers before I post a message to the BBEdit folks. A wiki or other help page on editing Python scripts on the Mac might be helpful to capture some of this knowledge. ka