From bobsavage@mac.com Sun Apr 1 00:27:40 2001 From: bobsavage@mac.com (Bob Savage) Date: Sat, 31 Mar 2001 16:27:40 -0800 Subject: [Pythonmac-SIG] Python embedded in Cocoa In-Reply-To: Message-ID: on 3/31/01 10:32 AM, Jonathan Wight wrote: > This isn't necessarily a Mac Python question but I know there's enough > combined knowledge here to help... We don't have a separate list for Python on Mac other than Mac-Python, so this is a good place for this discussion. > I've created a rather basic Cocoa application (ObjC not Java) that has > Python 2.1b2 (not MacPython) embedded in it. I'm hoping to make a primitive > but useable Python IDE for OSX. > > It actually works quite well - the user can edit, open and save .py text > files. When he/she clicks the "Run" button the python script executes. > Unfortunately all output goes to stdout which isn't very desirable in a GUI > application. Cool. I'm certainly not the most knowledgeable of folks on the list, but I don't think you need a whole Python extension for this purpose; I believe you can redirect this from within Cocoa fairly easily. You need to create an NSPipe to receive the output. Then you simply append that to the bottom of a text widget. Caveat: I haven't done it, but I looked at an application that did something like this (I think it was a GUI for wget). Best of luck! Make sure to announce the release here :) Bob From JWight@bigfoot.com Sun Apr 1 03:35:11 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Sat, 31 Mar 2001 20:35:11 -0600 Subject: [Pythonmac-SIG] Python embedded in Cocoa In-Reply-To: Message-ID: On 03/31/2001 18:27, "Bob Savage" wrote: >> I've created a rather basic Cocoa application (ObjC not Java) that has >> Python 2.1b2 (not MacPython) embedded in it. I'm hoping to make a primitive >> but useable Python IDE for OSX. >> >> It actually works quite well - the user can edit, open and save .py text >> files. When he/she clicks the "Run" button the python script executes. >> Unfortunately all output goes to stdout which isn't very desirable in a GUI >> application. > > Cool. I'm certainly not the most knowledgeable of folks on the list, but I > don't think you need a whole Python extension for this purpose; I believe > you can redirect this from within Cocoa fairly easily. You need to create an > NSPipe to receive the output. Then you simply append that to the bottom of a > text widget. Caveat: I haven't done it, but I looked at an application that > did something like this (I think it was a GUI for wget). Thanks for the tip. Had a quick look at the docs at developer.apple.com for NSPipe. Unfortunately NSPipe merely wraps Unix pipes in a nice ObjC object. I really don't want to talk to a separate Python process with a pipe - mainly for performance reasons, but also I want a little more control over the python environment (later on I hope to use the same code for un-trusted Python code inside a protected sandbox). I think a nice Cocoa application that talks to any arbitrary console command (like the wget GUI you mentioned) via pipes and presents it in a friendly-ish GUI might be a cool little side project. I guess I'm going to have to replace sys.stdout with an object that talks to my ObjC GUI anyways. > Make sure to announce the release here :) If it ever gets out of the crufty test toy stage I will... Jon. From jack@oratrix.nl Sun Apr 1 21:09:19 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 01 Apr 2001 22:09:19 +0200 Subject: [Pythonmac-SIG] Python embedded in Cocoa In-Reply-To: Message by Jonathan Wight , Sat, 31 Mar 2001 12:32:12 -0600 , Message-ID: <20010401200924.557C6EA11D@oratrix.oratrix.nl> It shouldn't be necessary to write any C code, I think. You can catch sys.stdout in Python and redirect it. You can look at IDE (included with MacPython, in :Mac:Tools:IDE) or Idle (included with all Pythons, in :Tools:Idle) for example code. The only thing you need then is access from Python to the specific widget you want to put the output in, but if I understand the ObjC/Python bridge stuff (which I haven't used, so this is all from what I've read here) that should all be in place. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From pf@artcom-gmbh.de Sun Apr 1 21:50:30 2001 From: pf@artcom-gmbh.de (Peter Funk) Date: Sun, 1 Apr 2001 22:50:30 +0200 (MEST) Subject: example Tk_Console.py (was Re: [Pythonmac-SIG] Python embedded in Cocoa) In-Reply-To: <20010401200924.557C6EA11D@oratrix.oratrix.nl> from Jack Jansen at "Apr 1, 2001 10: 9:19 pm" Message-ID: Hi, Jack Jansen: > It shouldn't be necessary to write any C code, I think. You can catch > sys.stdout in Python and redirect it. You can look at IDE (included > with MacPython, in :Mac:Tools:IDE) or Idle (included with all Pythons, > in :Tools:Idle) for example code. I would like to point out, that Ka-Ping Yee has written a small selfcontained utility called 'Console.py', which is only round about 800 lines of Python code: http://www.lfw.org/python/Console.py This might be easier to read than having to do a search for the example code in Idle or the Mac IDE. I must admit, that I've never tried this Tk based Console on the Mac, but the IO redirection code seems to be all in there. Hope this helps, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany) From JWight@bigfoot.com Mon Apr 2 00:27:55 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Sun, 01 Apr 2001 18:27:55 -0500 Subject: [Pythonmac-SIG] Python embedded in Cocoa In-Reply-To: <20010401200924.557C6EA11D@oratrix.oratrix.nl> Message-ID: Well I've got the python extension code that I originally had in mind in place now. Just need to do a bit of ObjC coding now and I should have a nice little Cocoa Python IDE working. I'll post the code somewhere when it's done. I was hoping that somewhere there was a C mechanism to change what Python thinks is stdout, ideally a callback. Seems that it doesn't though and the only way to do it is actually changing the sys.stdout object. Doing it this way is a whole lot of work for someone who is embeddeding Python in another app. Thanks for the help though. Jon. On 04/01/2001 15:09, "Jack Jansen" wrote: > It shouldn't be necessary to write any C code, I think. You can catch > sys.stdout in Python and redirect it. You can look at IDE (included > with MacPython, in :Mac:Tools:IDE) or Idle (included with all Pythons, > in :Tools:Idle) for example code. > > The only thing you need then is access from Python to the specific > widget you want to put the output in, but if I understand the > ObjC/Python bridge stuff (which I haven't used, so this is all from > what I've read here) that should all be in place. From JWight@bigfoot.com Mon Apr 2 03:24:24 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Sun, 01 Apr 2001 21:24:24 -0500 Subject: [Pythonmac-SIG] Python embedded in Cocoa In-Reply-To: Message-ID: Well I got it working. A very very basic Python IDE for Mac OS X (10.0) is available at: (600KB download) I'm guessing you'll need a Mac OS X install of Python 2.1b2 installed on your system to access the standard Python modules. But it might work without Python being installer just so long as you don't import any modules that aren't built into Python. As I said, it's very very basic - but I wrote it to help improve my Objective C skills and help me brush up on embedding Python. Good luck. Any feedback most welcome. And if it eats your computer it's not my fault. Thanks for the help guys. Jon. From JWight@bigfoot.com Mon Apr 2 06:25:03 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Mon, 02 Apr 2001 00:25:03 -0500 Subject: [Pythonmac-SIG] Embedded Python Weirdness Message-ID: Hey, In my Cocoa mini-Python IDE I've got a bit of a weird problem. If I run a python script that imports the string module it'll work fine. If I run it a second time without quitting and re-running the app it dies painfully with the following output on stderr: dyld: ./ToxicEdit multiple definitions of symbol _initstrop /usr/local/lib/python2.1/lib-dynload/strop.so definition of _initstrop /usr/local/lib/python2.1/lib-dynload/strop.so definition of _initstrop The initstrop symbol is the function that sets up the strop module - which is used inside the string module. Now this is obviously a problem with my code but might be a sign of a problem with the MacOS X implementation of Python. I think the problem stems from the fact that every time the user executes the Python code I Initialize and Finalize the python interpreter. I'm guessing that the second time Python imports the string module (and therefore the strop module) it tries to load the strop.so shared library for a second time and died horribly. The solution here is to only call Py_Initialize and Py_Terminate once, at the beginning and end of program executation respectively. But theoretically using Initialize and Terminate the way that I am is legal. So is anyone here actually familiar with the way Python imports modules in a shared library? Especially on Mac OS X? I know this is the Mac Python mailing list but I thought I'd try there list first in the hopes that the people who got Python working on Mac OS X were lurking here. If I don't get any response I'll find a better forum for this question. Thanks. Jon. From jack@oratrix.nl Mon Apr 2 14:04:33 2001 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 02 Apr 2001 15:04:33 +0200 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree Message-ID: <20010402130433.EC20D312BA0@snelboot.oratrix.nl> Has anyone tried (on OSX) using a Unix Python with a MacPython Lib tree? From what I've read on CR/LF translation and such it might just work. If someone could give it a try (probably putting your unix-Python binary in the MacPython toplevel directory is good enough) and let me know the results I'd be interested in hearing them. If this works, or if there's an easy way to make this work, we could have a single distribution that contains classic MacPython, Carbon MacPython and BSD Python in one package. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From sdm7g@Virginia.EDU Mon Apr 2 16:47:54 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Mon, 2 Apr 2001 11:47:54 -0400 (EDT) Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: <20010402130433.EC20D312BA0@snelboot.oratrix.nl> Message-ID: On Mon, 2 Apr 2001, Jack Jansen wrote: > Has anyone tried (on OSX) using a Unix Python with a MacPython Lib tree? From > what I've read on CR/LF translation and such it might just work. > > If someone could give it a try (probably putting your unix-Python binary in > the MacPython toplevel directory is good enough) and let me know the results > I'd be interested in hearing them. > > If this works, or if there's an easy way to make this work, we could have a > single distribution that contains classic MacPython, Carbon MacPython and BSD > Python in one package. I thought I had already found (accidently) that that doesn't work. Just in case I was confused, I tried it again, and it still doesn't work. Some import fail silently (probably there's a comment char that kills the whole "line" (that is, the whole file) and others give a syntax error. -- Steve From sdm7g@Virginia.EDU Mon Apr 2 18:19:00 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Mon, 2 Apr 2001 13:19:00 -0400 (EDT) Subject: [Pythonmac-SIG] Python embedded in Cocoa In-Reply-To: <20010401200924.557C6EA11D@oratrix.oratrix.nl> Message-ID: On Sun, 1 Apr 2001, Jack Jansen wrote: > The only thing you need then is access from Python to the specific > widget you want to put the output in, but if I understand the > ObjC/Python bridge stuff (which I haven't used, so this is all from > what I've read here) that should all be in place. I've been having some problems doing some things in Cocoa from python which seem to be due to running from a command line app rather than a bundled application (with resources and Nibs,etc.). I'm beginning to think "you can't get there from here!" It will be interesting to see if those problems go away running python from a Cocoa console. BTW: There is a neat demo app in the Darwin CVS (although it's really a OSX app) called DropScript, which takes a script makes another app bundle that launches that script with whatever filenames are dropped on it. It works with python scripts. It still doesn't solve my bundle problem, because it's actually launched as a separate process with NSTask ( and stdout goes to the console window ), but the source code is definitely worth a read! -- Steve Majewski From adv.files@robbstucky.com Mon Apr 2 19:42:12 2001 From: adv.files@robbstucky.com (Advertising) Date: Mon, 2 Apr 2001 14:42:12 -0400 Subject: [Pythonmac-SIG] FileMaker Pro and Python Message-ID: <200104021835.LAA20784@swan.prod.itd.earthlink.net> Confused about Python and FileMaker Pro. Would somebody please correct me... FileMakerPro conforms to AppleEvent and has an AETE, therefore we should be able to use Mac:Scripts:getsuitemodule.py to build an AppleEventOSA package for us to use in Python. It seems there is also an independent module to work with FileMaker named "FMPro" from erik. It started its life out as a separate access method from the getsuitemodule, and therefore should be independent of the FileMaker package that may (or may not) have been created by using getsuitemodule? Unfortunately I can't seem to get either method to work. --------------------------------------------------------------------------- ---------------- boring newbie details follow --------------------------------------------------------------------------- ---------------- I attempted to start by using the lib-scriptpackage created by MacPython2.0's getsuitemodule.py Unfortunately it created so much code, I couldn't tell how to access anything. (This is much, much, deeper than my beginner Python Books cover) Using AppleScript I would..... Tell Application "FileMakerProv4.1" set myVar to cell 21 of record 1 of database 1 show (every record of database 1 whose cell "modificationDate" is greater than myVar) end tell Using macPython I tried....... import FileMaker dataPuller = FileMaker.FileMaker(start=1) listOitems = dataPuller.database ##doesn't work, Can't even get access to the database listOitems = dataPuller.database[] listOitems = dataPuller.database() listOitems = dataPuller.Subset_of_the_Core_2c__Tabl.database ....and any combination of the dotted name access I could think of. Since I couldn't figure out how to access the objects of the getsuitemodulegeneratedpackage, - - - - - - - - - - - - - I started reading the mail archive and noticed most of the traffic on FileMaker concerned using Erik's FMPro Module. Since Erik promises this module is "very easy to develop with," I downloaded version .53 and put the uncompressed directory in my "scripts" directory. :Python 2.0:Scripts:FMPro_v0.53 Unfortunately I can't even run the demo, FMProDemo_test.py by dropping it on the interpreter, File "Python Development:Development:Python 2.0:Scripts:FMPro_v0.53:FMPro.py", line 60, in ? import Required_Suite ImportError: No module named Required_Suite Gee, there are only 7 of them on my HD, how do I know which one it wants? I also tried moving my FMPro_v0.53 folder over into the lib-scripting directory along with the other AppleEventPackages. (Thinking It might figure out the hierarchy) No Help. I also tried copying the Required_Suite from my getsuitemodulegeneratedpackage for FileMaker Pro into Erik's FMPromodule folder. It then started asking for lots more items that were missing. (assumed from the getsuitemodulegeneratedpackage) --------------------------------------------------------------------------- ---------------- newbie's actual questions, after previous rantings --------------------------------------------------------------------------- ---------------- Should we be using Erik's FMProModule or the getsuitemodule.py generated package to control FileMaker Pro? How does a Python Beginner install Erik's FMPro module into their virgin MacPython dist? Put it where, Do what to keep it from asking for the Required_Suite? Do I need a FileMakerPackage generated by getsuitemodule.py if I'm using Erik's FMProModule? I'm using MacPython2.0, is this some compatibility vs older MacPython distribution? Thanks muchly, Lane From erik@letterror.com Mon Apr 2 23:02:35 2001 From: erik@letterror.com (Erik van Blokland) Date: Mon, 2 Apr 2001 23:02:35 +0100 Subject: [Pythonmac-SIG] FileMaker Pro and Python In-Reply-To: <200104021835.LAA20784@swan.prod.itd.earthlink.net> Message-ID: <20010402230237-r01010600-e832bf7d@192.168.128.7> adv.files@robbstucky.com (Advertising): [4/2/01 at 14:42] > Should we be using Erik's FMProModule or the getsuitemodule.py generated > package to control FileMaker Pro? Sorry, I hadn't checked to see if FMPro works in Python 2.0, I was too busy tinkering with X (like how do I even install 2.1 beta!?) I seem to understand that all gensuite code now get their own Standard and Required suites? I took the ones that work with 1.5.2, renamed them to FM_Required_Suite and FM_Standard_Suite to be on the safe side. And changed the imports respectively. Just to be on the safe side. Moved the new and improved code to a freshly installed 2.0, added the folder name to the prefs with EditPythonPrefs (this is important!) and ran the test file successfully. Under MacOS 904. My 9.1 is out of commission for some reason. If you plant the FMPro folder in the Python folder, on the same level as the IDE applet, the entry for EditPythonPrefs should read: $(PYTHON):FMPro_v0.54 Of course you can put the folder anywhere, regular python rules apply. Did the same for a clean 1.5.2 install and it worked as well. So. The new modules can be picked up at http://www.letterror.com/code/fmpro/ Or if you want the file directly: http://www.letterror.com/code/fmpro/FMPro.hqx Let me know how you fare. Erik van Blokland -- www.letterror.com Type & Typography From JWight@bigfoot.com Mon Apr 2 23:30:29 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Mon, 02 Apr 2001 17:30:29 -0500 Subject: [Pythonmac-SIG] FileMaker Pro and Python In-Reply-To: <20010402230237-r01010600-e832bf7d@192.168.128.7> Message-ID: On 04/02/2001 17:02, "Erik van Blokland" wrote: > Sorry, I hadn't checked to see if FMPro works in Python 2.0, I was too busy > tinkering with X (like how do I even install 2.1 beta!?) Aha! A question I can answer. All the information you need is oddly enough located in the README file. Mac OS X: You need to add the "-traditional-cpp" option to the compiler command line for the Mac OS X Public Beta. This is appearantly a bug in the default pre-processor, and is expected not to be a problem with future versions. Run configure with "OPT='-g -traditional-cpp' ./configure --with-suffix=.exe --with-dyld" to add this option. One of the regular expression tests fails due to the small stack size used by default (how to change this?), and the test_largefile test is only expected to work on a Unix UFS filesystem (how to check for this on Mac OS X?). cd into your python directory OPT='-g -traditional-cpp' ./configure \ --with-suffix=.exe --with-dyld make sudo make install This will create files in /usr/local/bin called python.exe and python2.1.exe, you'll want to make a symlink without the annoying '.exe': ln -s /usr/local/bin/python2.1.exe /usr/local/bin/python2.1 ln -s /usr/local/bin/python2.1 /usr/local/bin/python Works like a treat. Jon. From JWight@bigfoot.com Tue Apr 3 07:18:40 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Tue, 03 Apr 2001 01:18:40 -0500 Subject: [Pythonmac-SIG] Toxic Edit / Cocoa 'IDE' Message-ID: For anyone who's interested there's a new version of 'ToxicEdit' (a very basic Cocoa Python IDE). It's at . Changes include: totally rewritten after an accident involving the 'cp' command, gui tidy ups, errors from Python are now display (so you're not coding blind), fixes a problem with Mac OS X shared library importing where running this code twice would cause a crash: "import string; print string.split('foo bar');". That's about it. Oh and source code (such as it is) is available too. On 04/02/2001 12:19, "Steven D. Majewski" wrote: > BTW: There is a neat demo app in the Darwin CVS (although it's > really a OSX app) called DropScript, which takes a script makes > another app bundle that launches that script with whatever filenames > are dropped on it. It works with python scripts. > > It still doesn't solve my bundle problem, because it's actually > launched as a separate process with NSTask ( and stdout goes to > the console window ), but the source code is definitely worth > a read! Hey Steve, you might want to use ToxicEdit to play about with Python on OSX as you'd be running the Python scripts directly in the Cocoa process (ToxicEdit doesn't fork - it currently uses PyRun_String() to execute the Python scripts). It might help with the bundle problem? Jon. From jack@oratrix.nl Tue Apr 3 15:26:22 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 03 Apr 2001 16:26:22 +0200 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message by "Steven D. Majewski" , Mon, 2 Apr 2001 11:47:54 -0400 (EDT) , Message-ID: <20010403142622.E53D9312BA0@snelboot.oratrix.nl> > > Has anyone tried (on OSX) using a Unix Python with a MacPython Lib tree? > > Some import fail silently (probably there's a comment char that kills > the whole "line" (that is, the whole file) and others give a syntax > error. Have you tried it on a UFS filesystem or on a HFS+ filesystem? I was hoping that on HFS+ MacOSX would be smart enough to do CR->LF translation for files with filetype TEXT. But, if you tried this on HFS+ then apparently we have no such luck:-( For MacPython I could hack the low-level stdio routine that does CR->LF conversion, which would treat both CR and LF as line-end. Note that this is different from trying to fix it in MacPython itself, which I've always been reluctant to do because of various side-effects. On output \n would be translated to \r, as happens now, on input both \r and \n would be mapped to \n. If the same could be done for BSD-Python The any text file should be readable as text from both runtimemodels. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From Benjamin.Schollnick@usa.xerox.com Tue Apr 3 15:28:56 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Tue, 03 Apr 2001 10:28:56 -0400 Subject: [Pythonmac-SIG] BuildApplication Error with Python 2.0 (#65) Message-ID: I'm attempting to build an application with Python 2.0, and receiving an strange error: ValueError: Unpack sequence of wrong size This is being raised in module BuildApplication, in line 147 (?), 51 (main), 73 (BuildApplication). Is there a patch to fix this? I'd rather not use a beta version of python at work. - Benjamin From sdm7g@Virginia.EDU Tue Apr 3 19:47:55 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Tue, 3 Apr 2001 14:47:55 -0400 (EDT) Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: <20010403142622.E53D9312BA0@snelboot.oratrix.nl> Message-ID: On Tue, 3 Apr 2001, Jack Jansen wrote: > > > > Has anyone tried (on OSX) using a Unix Python with a MacPython Lib tree? > > > > Some import fail silently (probably there's a comment char that kills > > the whole "line" (that is, the whole file) and others give a syntax > > error. > > Have you tried it on a UFS filesystem or on a HFS+ filesystem? I was hoping > that on HFS+ MacOSX would be smart enough to do CR->LF translation for files > with filetype TEXT. But, if you tried this on HFS+ then apparently we have no > such luck:-( > I'm using HFS+ I do recall hearing something about some automatic line ending translation being done SOMEWHERE, but I'm pretty sure it's not in the unix I/O libs, which are pretty standard BSD unix. More likely, they put the translation into Carbon/Cocoa/or-some-lower- level-framework so that Mac Applications can handle unix text files. However, I just tried the reverse experiment: I prepended OSX:usr:local:lib:python2.1: to sys.path in Carbon MacPython, and tried importing a module, but it complains about the line endings and then gives a syntax error. But maybe the way they are read in MacPython this rumored hack. > For MacPython I could hack the low-level stdio routine that does CR->LF > conversion, which would treat both CR and LF as line-end. Note that this is > different from trying to fix it in MacPython itself, which I've always been > reluctant to do because of various side-effects. On output \n would be > translated to \r, as happens now, on input both \r and \n would be mapped to > \n. > > If the same could be done for BSD-Python The any text file should be readable > as text from both runtimemodels. It would be nice if we could coax at least one of them to be more liberal in what it accepts. Probably, the stdio lib sources are in the open source Darwin -- we could probably hack that into a replacement lib that takes both line endings. [ Long delay in answering caused by termial app hanging up after trying to past the python traceback (with one really humongous line in it) from that experiment in an earlier attempt to reply. Killing pine wasn't enough -- I had to kill and restart terminal.app ] -- Steve Majewski From brm@ecklesarchitecture.com Tue Apr 3 21:54:59 2001 From: brm@ecklesarchitecture.com (Brian R. Melcer) Date: Tue, 03 Apr 2001 16:54:59 -0400 Subject: [Pythonmac-SIG] Zope Message-ID: Has there been any significant work (or success) in building Zope with MacPython? If so (or not), is there any groups out there who are working on it (although it may now not have the interest due to OSX) Keep up the good work everybody! Brian Melcer Eckles Architecture, Inc. New Castle, PA From sdm7g@Virginia.EDU Tue Apr 3 22:23:22 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Tue, 3 Apr 2001 17:23:22 -0400 (EDT) Subject: [Pythonmac-SIG] Toxic Edit / Cocoa 'IDE' In-Reply-To: Message-ID: On Tue, 3 Apr 2001, Jonathan Wight wrote: > For anyone who's interested there's a new version of 'ToxicEdit' (a very > basic Cocoa Python IDE). It's at . > Changes include: totally rewritten after an accident involving the 'cp' > command, gui tidy ups, errors from Python are now display (so you're not > coding blind), fixes a problem with Mac OS X shared library importing where > running this code twice would cause a crash: "import string; print > string.split('foo bar');". Just a quick report on trying this out: On first try it didn't appear to be working but it works fine now that I figured out the "gotchas" : Console output is just output -- there's no "listener window". Instead use "New" from the file menu, type python commands in the window and click "run" . ( BTW: What's the other button mean ? "DNGN" ? ) Since it's running as a file, it doesn't echo returned values -- you need to explicitly print the values. 'RUN' doesn't seem to run them as __main__ . None of my scripts seemed to work until, for example, after the line: if __name__ == '__main__' : main() I added: else: main() My Nib loading code didn't appear to work any better under Toxic Edit than under Terminal.app command lines. Since it uses the normal "/use/local/lib/python2.1" paths, it was able to see and import my previously installed ObjC & Carbon modules. ( Eventually, we ought to figure out how to make a real Python.framework! ) > Hey Steve, you might want to use ToxicEdit to play about with Python on OSX > as you'd be running the Python scripts directly in the Cocoa process > (ToxicEdit doesn't fork - it currently uses PyRun_String() to execute the > Python scripts). It might help with the bundle problem? Thanks. I had started to look at the NSText* docs in AppKit just before you posted this -- I was thinking along the same lines, and I was trying to figure out one of the missing pieces in your code -- how to grab a line after and make an in/out console window. I'm going to take a peek at your sources next and see if I can catch up! FYI: The following code works fine from Toxic Edit with ObjC installed. -- Steve. (PS. I just set up an iDisk & home page at mac.com. I'm going to put binaries on ObjCmodule.so & Carbonmodule.so there for folks who don't want to attempt the whole build. ) #!/usr/local/bin/python # # Heavily modified following an example by Lele Gaifax # that no longer works under OSX. # This seems to work under 'gdb python', but not without the debugger. (?) # # -- Steve Majewski # from time import sleep import ObjC rt = ObjC.runtime _AppKit = None _Pool = None def Pool(): global _Pool POOL = rt.NSAutoreleasePool _Pool = POOL() return _Pool def Load(): global _AppKit _AppKit = rt.NSBundle.bundleWithPath_('/System/Library/Frameworks/AppKit.framework' ) _AppKit.load() def run(): NSApp = rt.NSApplication.sharedApplication() win = rt.NSWindow.alloc() frame = ((200.0, 300.0), (250.0, 100.0)) win.initWithContentRect_styleMask_backing_defer_ (frame, 15, 2, 0) win.setTitle_ ('Little.Button.Window') win.setLevel_ (3) # floating window but = rt.NSButton.alloc().initWithFrame_ (((10.0, 10.0), (80.0,80.0))) win.contentView().addSubview_ (but) but.setBezelStyle_( 4 ) but.setTarget_ (NSApp) but.setAction_ ('stop:') but.setEnabled_ ( 1 ) win.display() # win.makeKeyAndOrderFront_ (NSApp) ## This doesn't seem to work win.orderFrontRegardless() ## but this one does NSApp.run() def main(): if not _Pool: Pool() if not _AppKit: Load() run() if __name__ == '__main__' : main() From sdm7g@Virginia.EDU Tue Apr 3 22:37:22 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Tue, 3 Apr 2001 17:37:22 -0400 (EDT) Subject: [Pythonmac-SIG] Toxic Edit / Cocoa 'IDE' In-Reply-To: Message-ID: PS. sticking in a "print __name__" gives me: "__builtin__" ( Why none of the if __name__ == '__main__' lines worked. ) A few other thinks weren't working for me. import os print os.getcwd() gives "/" -- not the directory of either the App or any of the scripts. I'm guessing some of the other problems are due to relative paths being wrong. -- Steve From JWight@bigfoot.com Wed Apr 4 00:11:48 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Tue, 03 Apr 2001 18:11:48 -0500 Subject: [Pythonmac-SIG] Toxic Edit / Cocoa 'IDE' In-Reply-To: Message-ID: On 04/03/2001 16:23, "Steven D. Majewski" wrote: > Just a quick report on trying this out: > > On first try it didn't appear to be working but it works fine now > that I figured out the "gotchas" : There are going to be lots of gotchas. It really is a toy application at the moment. > Console output is just output -- there's no "listener window". > Instead use "New" from the file menu, type python commands in > the window and click "run" . ( BTW: What's the other button > mean ? "DNGN" ? ) "Does Nothing Goes Nowhere". It's just a placeholder at the moment. I was experimenting with controls embedded in a NSMatrix. > Since it's running as a file, it doesn't echo returned values -- > you need to explicitly print the values. Which is fine for files. I'll add a true console mode later. > 'RUN' doesn't seem to run them as __main__ . None of my scripts > seemed to work until, for example, after the line: > if __name__ == '__main__' : main() > I added: > else: main() Yeah the code for setting up the namespace is wrong. I'll improve that tonight - I'll just rip the what code I need from the PyRun_String() function. > My Nib loading code didn't appear to work any better under Toxic Edit > than under Terminal.app command lines. That's a shame. > I had started to look at the NSText* docs in AppKit just before you > posted this -- I was thinking along the same lines, and I was trying > to figure out one of the missing pieces in your code -- how to grab > a line after and make an in/out console window. > > I'm going to take a peek at your sources next and see if I can > catch up! Cool. I'll probably be putting a new version on http://toxicsoftware.com/ToxicEdit/ tonight with some fixes. > (PS. I just set up an iDisk & home page at mac.com. > I'm going to put binaries on ObjCmodule.so & Carbonmodule.so > there for folks who don't want to attempt the whole build. ) Cool. Be great to write ToxicEdit in Python instead of ObjC some day. There's only so many [[[[nexted square] braces] I can] take]. > sticking in a "print __name__" gives me: "__builtin__" > ( Why none of the if __name__ == '__main__' lines worked. ) > > A few other thinks weren't working for me. > > import os > print os.getcwd() > > gives "/" -- not the directory of either the App or any of the > scripts. I'm guessing some of the other problems are due to > relative paths being wrong. More than likely. I'll fix it tonight. That'll teach me for following the examples in Programming Python. I think the cwd == '/' is a Cocoa problem though - I'll see what I can do to fix it. Jon. From sdm7g@Virginia.EDU Wed Apr 4 01:13:42 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Tue, 3 Apr 2001 20:13:42 -0400 (EDT) Subject: [Pythonmac-SIG] Toxic Edit / Cocoa 'IDE' In-Reply-To: Message-ID: On Tue, 3 Apr 2001, Jonathan Wight wrote: > > Cool. I'll probably be putting a new version on > http://toxicsoftware.com/ToxicEdit/ tonight with some fixes. > I'll be sure to check it out later. > > import os > > print os.getcwd() > > > > gives "/" -- not the directory of either the App or any of the > > scripts. I'm guessing some of the other problems are due to > > relative paths being wrong. > > More than likely. I'll fix it tonight. That'll teach me for following the > examples in Programming Python. I think the cwd == '/' is a Cocoa problem > though - I'll see what I can do to fix it. > I was guessing that it makes sense that a program launched from double clicking in the finder doesn't have a current working directory of it's own. I tried the script at bottom from ToxicEdit after launching it: [1] from the finder, and [2] by "open ToxicEdit.app" from the unix shell command line in Terminal.app. ( You don't usually need the ".app" extension, but I had the unpacked source directory in the same path, and "open ToxicEdit" instead opened that directory in the finder -- which by itself is a cool trick to discover! ) For both methods, getcwd() always returns "/" and bundlePath() always returns the Application bundle pathname. environment variable $HOME is set in both methods. But only when launched by method 2 ( 'open ToxicEdit.app' ) does it inherit a $PWD environment var from the parent shell. ( Trying to run it from the finder gave a KeyError, which is why I added those 'try's to the code. ) Just as in Classic MacOS, the system also seems to track the last folder visited for the file selection dialogs. ( Not sure if you can access that the same way under OSX -- I *think* I recall it used to be thru a global in pre-Carbon MacOS, so there must be a new method for Carbon. ) Out of all of those, I'm not quite sure what the "Right" thing to do is: maybe check for $PWD and if not set, fall back to $HOME or parent dir or bundlePath. 'open -a ToxicEdit.app script.py' did launch the app but it didn't open the document. ( see: 'man open' ) 'open script.py' *DID* launch the app with the document. ( It would be cool if there was a way to have an option to automatically run the script without clicking RUN. ) -- Steve ##### import pyobjc import os print 'Module name:',__name__ try: print 'Module file:', __file__ except: print print os.environ print 'cwd:', os.getcwd() try: print '$PWD:', os.environ['PWD'] except KeyError: print 'No $PWD' try: print '$HOME:', os.environ['HOME'] except KeyError: print 'No $HOME' _Pool = pyobjc.runtime.NSAutoreleasePool() print "BundlePath:", print pyobjc.runtime.NSBundle.mainBundle().bundlePath() From vincem@en.com Wed Apr 4 02:30:05 2001 From: vincem@en.com (Vincent Marchetti) Date: Tue, 3 Apr 2001 21:30:05 -0400 Subject: [Pythonmac-SIG] Re: FileMaker Pro and Python Message-ID: Reply to Lane concerning scripting FileMaker Pro from Python. -- I do not use FileMaker Pro, and know nothing about the module FMPro, but I have some suggestions for working with the Python module generated by gensuitemod.py: At 2:42 PM -0400 4/2/01, Advertising wrote: >I attempted to start by using the lib-scriptpackage created by >MacPython2.0's getsuitemodule.py >Unfortunately it created so much code, I couldn't tell how to access >anything. >(This is much, much, deeper than my beginner Python Books cover) > >Using AppleScript I would..... > > Tell Application "FileMakerProv4.1" > set myVar to cell 21 of record 1 of database 1 > show (every record of database 1 whose >cell "modificationDate" >is greater than myVar) > end tell At 2:42 PM -0400 4/2/01, Advertising wrote: >Using macPython I tried....... > > import FileMaker > dataPuller = FileMaker.FileMaker(start=1) This looks OK , I assume that at this point the FileMaker Pro app has launched. At 2:42 PM -0400 4/2/01, Advertising wrote: > listOitems = dataPuller.database ##doesn't work, Can't even get >access to the database Try: listOitems = dataPuller._get(FileMaker.database()) ## you are 'getting' the object database. However, it is up to the app FMPro as to what you get ## back, you may get an object reference or you may get a ton of data in a mysterious format For the equivalent of the AppleScript set myVar to cell 21 of record 1 of database 1 try in Python from FileMaker import cell, record, database myVar = dataPuller._get(cell(21, record(1, database()))) This MIGHT also work myVar = dataPuller._get(database().record(1).cell(21)) If this appears to work for you, and you're interested, I can dig up my example code of how I passed the whose clause in an object reference, to implement the last line of your AppleScript. Vince Marchetti From JWight@bigfoot.com Wed Apr 4 05:51:08 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Tue, 03 Apr 2001 23:51:08 -0500 Subject: [Pythonmac-SIG] Toxic Edit / Cocoa 'IDE' In-Reply-To: Message-ID: On 04/03/2001 19:13, "Steven D. Majewski" wrote: >> Cool. I'll probably be putting a new version on >> http://toxicsoftware.com/ToxicEdit/ tonight with some fixes. It's online now. Nothing major in it - just some changes to the way it initializes the globals and locals before it executes the script. Now you have your __name__ == __main__ and sys isn't imported by default. There is a weirdness though and I haven't figured it out. If I run this code in the Terminal Python: print dir(__builtins__) I get something a lot like this. About 40 entries in the list. ['ArithmeticError', 'AssertionError', <--snipped--> 'vars', 'xrange', 'zip'] If I do the same inside ToxicEdit I get this: ['clear', 'copy', 'get', 'has_key', 'items', 'keys', 'popitem', 'setdefault', 'update', 'values'] Which looks like the methods of a dictionary item. The odd thing is is that seems to be correct (at least superficially). Because if I don't install the __builtins__ module commands like dir() wouldn't even work. Weird. > Out of all of those, I'm not quite sure what the "Right" thing to do > is: maybe check for $PWD and if not set, fall back to $HOME or > parent dir or bundlePath. How about setting the CWD to the parent directory of the open script? This would allow imports referring to the script's local siblings to work. > ( It would be cool if there was a way to have an option to > automatically run the script without clicking RUN. ) Don't know an friendly way to do that. Maybe add to the "#!/bin/python" mechanism so that if the second line is something like "# LaunchOnOpen" or similar ToxicEdit will execute the script. Suggestions? > (PS. I just set up an iDisk & home page at mac.com. > I'm going to put binaries on ObjCmodule.so & Carbonmodule.so > there for folks who don't want to attempt the whole build. ) Um, what's the iDisk name? From JWight@bigfoot.com Wed Apr 4 06:28:25 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Wed, 04 Apr 2001 00:28:25 -0500 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message-ID: On 04/03/2001 13:47, "Steven D. Majewski" wrote: >> For MacPython I could hack the low-level stdio routine that does CR->LF >> conversion, which would treat both CR and LF as line-end. Note that this is >> different from trying to fix it in MacPython itself, which I've always been >> reluctant to do because of various side-effects. On output \n would be >> translated to \r, as happens now, on input both \r and \n would be mapped to >> \n. >> >> If the same could be done for BSD-Python The any text file should be readable >> as text from both runtimemodels. > > It would be nice if we could coax at least one of them to be more liberal > in what it accepts. Probably, the stdio lib sources are in the open source > Darwin -- we could probably hack that into a replacement lib that takes > both line endings. I've hit upon a similar problem with my ToxicEdit project. By default sys.stdout and sys.stderr refer to the stdc stdout and stderr. So to get output go to my console window instead of the system's stdout/stderr I had to replace sys.stdout/sys.stderr with my own fake file objects. This would have been incredibly simplified if I could have registered my own C callbacks as the 'destination' of stdout/stderr. Unfortunately the Python source code is pretty dependent on the stdio functions and you'll see FILE * littered throughout the Python code. One idea that would have simplified my problem (and anyone else who is embedding Python) and can fix the LF/CR return problem is to replace the stdio FILE * and stdio function calls. On all platforms without the LF/CR problem you could just do something like: #define PYIO_FILE FILE #define PYIO_fprintf fprintf #define PYIO_fgets fgets And so on. All you'd need to do then is do a quick search/replace through the Python source code to update it. This would allow us to replace all the ascii IO code with code that handled the LF/CR problem transparently. And of course this would help me with my embedding problems. This would be a pretty big change to the Python source code though akin to the 'great renaming' of a few years ago. Jon. From jack@oratrix.nl Wed Apr 4 09:59:33 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 04 Apr 2001 10:59:33 +0200 Subject: [Pythonmac-SIG] Re: FileMaker Pro and Python In-Reply-To: Message by Vincent Marchetti , Tue, 3 Apr 2001 21:30:05 -0400 , Message-ID: <20010404085933.D7BBF312BA0@snelboot.oratrix.nl> > > listOitems = dataPuller.database ##doesn't work, Can't even get > >access to the database > > For the equivalent of the AppleScript > set myVar to cell 21 of record 1 of database 1 > > try in Python > from FileMaker import cell, record, database > myVar = dataPuller._get(cell(21, record(1, database()))) > > This MIGHT also work > myVar = dataPuller._get(database().record(1).cell(21)) I would really really like this last line to be written as myVar = dataPuller.database.record[1].cell[21]._get() I think that the current Python OSA setup has enough information to pull this off, in almost the right form. If the main class for an application (the one that is defined in the __init__.py module in the package) would include the "application" class (usually defined in the Standard_Suite submodule, I think) then we're half-way there. The one extra thing we need is a mixin class which allows attribute access to objects. It would have a __getattr__ method which would lookup the attributename in self._propdict. If the attribute is found it would instantiate the class (which will be a subclass of ObjectSpecifier and this same mixin class) with self as the "fr" parameter (which stands for "from"). If it isn't found it would retry the lookup in self._elemdict, and if the attribute was found there it would instantiate an ElementSelector object (this class is yet to be written) with parameters element class and self. The ElementSelector provides a __getitem__ method, which instantiates the element class object. All this would allow something like objref = dataPuller.database.record[1].cell[21] myVar = dataPuller._get(objref) To go the final bit the ObjectSpecifier class would also need a __getattr__ method. It would traverse the self.fr links up to the application object (dataPuller, in our case), lookup the attribute there and create a callable object that will pass self as first argument upon __call__. But as AppleScript isn't my primary focus right now if y'all wait for me to write this stuff it can be a while. Anyone care to step in? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Wed Apr 4 10:40:13 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 04 Apr 2001 11:40:13 +0200 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message by Jonathan Wight , Wed, 04 Apr 2001 00:28:25 -0500 , Message-ID: <20010404094013.B5F73312BA0@snelboot.oratrix.nl> > One idea that would have simplified my problem (and anyone else who is > embedding Python) and can fix the LF/CR return problem is to replace the > stdio FILE * and stdio function calls. On all platforms without the LF/CR > problem you could just do something like: > > #define PYIO_FILE FILE > #define PYIO_fprintf fprintf > #define PYIO_fgets fgets Unfortunately, this is blasphemy. The BDFL has announced that Python will be stdio-based. There is a pretty good reason for this: most similar language implementations (Perl, Tcl/Tk) at some point were lured into doing their own stdio-lookalike I/O system, but these were quickly extended with all sorts of nifty new features, thereby making an I/O system port a prerequisite before the languages in question could be ported to a new platform. Sticking with stdio is probably one of the main factors that makes Python ports easy, and therefore one of the main factors that contribute to Python being available on far more platforms (from IBM mainframes to Palm organisers) than similar languages. So, I think we're stuck with modifying stdio itself. But, the good news is that with many current stdio implementations this shouldn't be too hard, provided you have access to the source. Stdio will often have a per-FILE struct of function pointers to do lowlevel operations that you can plug into. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jmillr@umich.edu Wed Apr 4 16:53:24 2001 From: jmillr@umich.edu (John A. Miller) Date: Wed, 4 Apr 2001 11:53:24 -0400 (EDT) Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message-ID: I really don't know if this is relevant, an apologies if it isn't, but this discussion reminds me of an effort that may be related: Stackless Python: A Python Implementation That Does Not Use The C Stack: http://www.stackless.com/ with the main explanation here: http://www.stackless.com/spcpaper.htm HTH John Miller On Wed, 4 Apr 2001, Jonathan Wight wrote: > On 04/03/2001 13:47, "Steven D. Majewski" wrote: > > This would have been incredibly simplified if I could have registered my own > C callbacks as the 'destination' of stdout/stderr. Unfortunately the Python > source code is pretty dependent on the stdio functions and you'll see FILE * > littered throughout the Python code. > > This would be a pretty big change to the Python source code though akin to > the 'great renaming' of a few years ago. From sdm7g@Virginia.EDU Wed Apr 4 17:20:49 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Wed, 4 Apr 2001 12:20:49 -0400 (EDT) Subject: [Pythonmac-SIG] Toxic Edit / Cocoa 'IDE' In-Reply-To: Message-ID: On Tue, 3 Apr 2001, Jonathan Wight wrote: > On 04/03/2001 19:13, "Steven D. Majewski" wrote: > > > (PS. I just set up an iDisk & home page at mac.com. > > I'm going to put binaries on ObjCmodule.so & Carbonmodule.so > > there for folks who don't want to attempt the whole build. ) > > Um, what's the iDisk name? > I intentionally left that out -- I was going to wait until I put up ReadMe's, examples and other stuff and then announce it. But if you're that eager to grab it, just the .so files for Carbon and pyobjc are on: http://homepage.mac.com/sdm7g/FileSharing.html -- Steve From JWight@bigfoot.com Wed Apr 4 19:47:58 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Wed, 04 Apr 2001 13:47:58 -0500 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: <20010404094013.B5F73312BA0@snelboot.oratrix.nl> Message-ID: On 04/04/2001 04:40, "Jack Jansen" wrote: >> #define PYIO_FILE FILE >> #define PYIO_fprintf fprintf >> #define PYIO_fgets fgets > > Unfortunately, this is blasphemy. The BDFL has announced that Python will be > stdio-based. There is a pretty good reason for this: most similar language > implementations (Perl, Tcl/Tk) at some point were lured into doing their own > stdio-lookalike I/O system, but these were quickly extended with all sorts of > nifty new features, thereby making an I/O system port a prerequisite before > the languages in question could be ported to a new platform. Sticking with > stdio is probably one of the main factors that makes Python ports easy, and > therefore one of the main factors that contribute to Python being available on > far more platforms (from IBM mainframes to Palm organisers) than similar > languages. Well that argument makes little sense to me. Providing your own wrapper for stdio isn't technically challenging. Heck it's no harder than wrapping of the malloc code already in Python. And for most cases their wouldn't be any IO extensions. The only extensions to the IO system necessary are for people doing weird things - like the CR/LF swapping or re-routing output for embedded Python. Ah well, bummer. Back to doing things the cumbersome way... > So, I think we're stuck with modifying stdio itself. But, the good news is > that with many current stdio implementations this shouldn't be too hard, > provided you have access to the source. Stdio will often have a per-FILE > struct of function pointers to do lowlevel operations that you can plug into. I doubt you're going to be able to do this particularly easily on OSX. With MSL/GUSI on 9 you stand a better chance... Jon. From just@letterror.com Wed Apr 4 21:28:46 2001 From: just@letterror.com (Just van Rossum) Date: Wed, 4 Apr 2001 22:28:46 +0200 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message-ID: <20010404222848-r01010600-f1e8dc23@10.69.17.75> Jonathan Wight wrote: > The only extensions to the IO system necessary are for people > doing weird things - like the CR/LF swapping or re-routing output for > embedded Python. I may be missing something, but rerouting output is a matter of assigning a file-like object (any object with a write method actually) to sys.stdout and/or sys.stderr. All C code is supposed to call PySys_WriteStdout() instead of fwrite(stdout...), so this actually works. Just From JWight@bigfoot.com Wed Apr 4 21:38:40 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Wed, 04 Apr 2001 15:38:40 -0500 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: <20010404222848-r01010600-f1e8dc23@10.69.17.75> Message-ID: On 04/04/2001 15:28, "Just van Rossum" wrote: > I may be missing something, but rerouting output is a matter of assigning a > file-like object (any object with a write method actually) to sys.stdout > and/or > sys.stderr. All C code is supposed to call PySys_WriteStdout() instead of > fwrite(stdout...), so this actually works. Aha. Didn't know PySys_WriteStdout() existed. I guess Python does provide some stdio wrappers then. Yeah. The "assigning a file-like object" approach works fine. So I guess I'm just doing a bit of wishful thinking because the way I have to go about is kind of annoying: 1) Write a C callback function that displays output in my Cocoa NSTextView widget. 2) Wrap callback in a Python C module. 3) Before calling PyRun_String() import sys and replace std.stdout/sys.stderr with my C module. It would be nice if I could just do a PyXXX_SetStdoutCallback(MyCallback) or similar (eliminating steps 2 and 3). And I would like to use all the PyRun_InteractiveXXX stuff to provide a real Python console interpreter inside my Cocoa application. But I can't (without stealing the code and rewriting it) because all the Py_InteractiveXXX functions take a FILE * parameter. But hey, I've done the work, my code works so I should stop bitching. Jon. From just@letterror.com Wed Apr 4 22:17:19 2001 From: just@letterror.com (Just van Rossum) Date: Wed, 4 Apr 2001 23:17:19 +0200 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message-ID: <20010404231720-r01010600-e8a44d89@10.69.17.75> Jonathan Wight wrote: > Yeah. The "assigning a file-like object" approach works fine. So I guess I'm > just doing a bit of wishful thinking because the way I have to go about is > kind of annoying: > > 1) Write a C callback function that displays output in my Cocoa NSTextView > widget. > 2) Wrap callback in a Python C module. > 3) Before calling PyRun_String() import sys and replace > std.stdout/sys.stderr with my C module. > > It would be nice if I could just do a PyXXX_SetStdoutCallback(MyCallback) or > similar (eliminating steps 2 and 3). > > And I would like to use all the PyRun_InteractiveXXX stuff to provide a real > Python console interpreter inside my Cocoa application. But I can't (without > stealing the code and rewriting it) because all the Py_InteractiveXXX > functions take a FILE * parameter. I don't know the exact problems you're facing but it sure sounds like you should do more in Python! There are several console emulators out there, there's even one in the std lib: code.py. Assigning to sys.stdout is no effort from Python. All you need is _one_ wrapped C function that sends data to your console, the rest can all be done in Python. Just From JWight@bigfoot.com Wed Apr 4 22:27:52 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Wed, 04 Apr 2001 16:27:52 -0500 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: <20010404231720-r01010600-e8a44d89@10.69.17.75> Message-ID: On 04/04/2001 16:17, "Just van Rossum" wrote: > I don't know the exact problems you're facing but it sure sounds like you > should > do more in Python! There are several console emulators out there, there's even > one in the std lib: code.py. Assigning to sys.stdout is no effort from Python. > All you need is _one_ wrapped C function that sends data to your console, the > rest can all be done in Python. Well I was going to do more in Python. Originally I had just intended to extend python with single C function that sent it's input to the Cocoa NSTextView. And then create a Python file object to pipe data through that C function. But then I decided to have multiple NSTextViews so I had to store a pointer to the relevent NSTextView seperately inside my fake file objects. Anyway. It works, and that code.py looks like it's exactly what I need to implement a interactive mode. I promise I'll stop bitching now! :-) Thanks for the help. Jon. From jack@oratrix.nl Wed Apr 4 23:01:25 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 05 Apr 2001 00:01:25 +0200 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message by Jonathan Wight , Wed, 04 Apr 2001 16:27:52 -0500 , Message-ID: <20010404220130.0CD09E938F@oratrix.oratrix.nl> Recently, Jonathan Wight said: > Well I was going to do more in Python. Originally I had just intended to > extend python with single C function that sent it's input to the Cocoa > NSTextView. And then create a Python file object to pipe data through that C > function. > > But then I decided to have multiple NSTextViews so I had to store a pointer > to the relevent NSTextView seperately inside my fake file objects. Maybe this can be seen as proving Just's point (do more in Python): by the time you've finished all the odds and ends you may have been better off implementing W in Cocoa so that you get IDE for free (and a lot more besides). Hmm, on re-reading that paragraph: I definitely don't want to belittle your efforts, far from it! It's just that I tend to agree with Just: write as little C code as you possibly can, and use Python to glue it all together. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From sdm7g@Virginia.EDU Thu Apr 5 00:04:03 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Wed, 4 Apr 2001 19:04:03 -0400 (EDT) Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: <20010404220130.0CD09E938F@oratrix.oratrix.nl> Message-ID: On Thu, 5 Apr 2001, Jack Jansen wrote: > Maybe this can be seen as proving Just's point (do more in Python): by > the time you've finished all the odds and ends you may have been > better off implementing W in Cocoa so that you get IDE for free (and a > lot more besides). > > Hmm, on re-reading that paragraph: I definitely don't want to belittle > your efforts, far from it! It's just that I tend to agree with Just: > write as little C code as you possibly can, and use Python to glue it > all together. I certainly agree with the sentiment: do it in Python. In reality, neither Carbonmodule or PyObjC for Darwin-Python are quite up to it yet. But they are pretty darn close. Last time I tried it, W died on one of the Qd.GetCursor().data calls in Wbase.py -- I'm sure because it's a unix object image without any resource fork, so it only worked for the standard ones that were in the Carbon framework somewhere. The other missing bit for running any of the Mac Python GUI scripts is that MacOS module isn't ported, so there's no SchedParams() function. The problems with Cocoa have been more mysterious mainly because I've been learning Cocoa as I go along. You can do some simple GUI stuff now with PyObjC, but to get a real Cocoa Application from Python, the fatal bugs are that Delegates aren't working correctly, and that most of the methods that handle Nibs are all marked "Description Forthcoming" in the Docs! Johnathan -- after you've figured out Cocoa, I hope you'll sign up at Sourceforge.net/projects/pyobjc -- so far BBum and I have been the only ones that have taked a hack at it, and neither of us have been able to spend a lot of time on it. Jack -- I think your CVS is still missing a couple of files to be able to build Carbonmodule on OSX. I thought I had sent them to you, but I'll take a look again and do a diff between my sources and the CVS files. Later -- I've got to run. -- Steve From JWight@bigfoot.com Thu Apr 5 03:38:45 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Wed, 04 Apr 2001 21:38:45 -0500 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: <20010404220130.0CD09E938F@oratrix.oratrix.nl> Message-ID: On 04/04/2001 17:01, "Jack Jansen" wrote: > Maybe this can be seen as proving Just's point (do more in Python): by > the time you've finished all the odds and ends you may have been > better off implementing W in Cocoa so that you get IDE for free (and a > lot more besides). Well that would certainly defeat my point. I'm not writing a Python IDE in Cocoa for the sake of writing it. I'm doing it as an exercise to help teach myself the Cocoa Framework. The fact that it would be useful to at least myself is a side effect. Another reason is to re-familiarise myself with embedding Python - I have another future project in mind where an embedded Python would be very cool. Porting W to Cocoa (isn't it Carbonised already?) would defeat my purposes. Especially if the PyObjC project can access the Cocoa GUI framework pretty transparently. > Hmm, on re-reading that paragraph: I definitely don't want to belittle > your efforts, far from it! It's just that I tend to agree with Just: > write as little C code as you possibly can, and use Python to glue it > all together. If you look at the source code you'll see that I've not really written that much ObjC/C code just for accessing Python. My original complaints at the start of this thread were basically to do with how cumbersome it can be to for people embedding Python. Jon. From JWight@bigfoot.com Thu Apr 5 03:41:25 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Wed, 04 Apr 2001 21:41:25 -0500 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message-ID: On 04/04/2001 18:04, "Steven D. Majewski" wrote: > Jonathan -- after you've figured out Cocoa, I hope you'll sign up > at Sourceforge.net/projects/pyobjc -- so far BBum and I have been > the only ones that have taked a hack at it, and neither of us have > been able to spend a lot of time on it. I've signed up for the mailing list. Traffic so far has been, um, non-existsnt ;-) I'm also confused as to which version of PyObjC source code to grab. Is it safe to assume the code available from source forge is the latest and greatest? Jon. From chriss@dnastar.com Thu Apr 5 06:25:45 2001 From: chriss@dnastar.com (Christopher Stern) Date: Thu, 5 Apr 2001 00:25:45 -0500 Subject: [Pythonmac-SIG] BBEdit Python support (1.2) Message-ID: A new version (1.2) of The Python Language module is up at This version adds support for html embeded in python strings and imporoves the function-popup's handling of nested items as well as corectly indication what function the selection falls in. From sdm7g@minsky.med.virginia.edu Thu Apr 5 06:35:57 2001 From: sdm7g@minsky.med.virginia.edu (Steven D. Majewski) Date: Thu, 5 Apr 2001 01:35:57 -0400 (EDT) Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message-ID: On Wed, 4 Apr 2001, Jonathan Wight wrote: > On 04/04/2001 18:04, "Steven D. Majewski" wrote: > > > Jonathan -- after you've figured out Cocoa, I hope you'll sign up > > at Sourceforge.net/projects/pyobjc -- so far BBum and I have been > > the only ones that have taked a hack at it, and neither of us have > > been able to spend a lot of time on it. > > I've signed up for the mailing list. Traffic so far has been, um, > non-existsnt ;-) I'm also confused as to which version of PyObjC source code > to grab. Is it safe to assume the code available from source forge is the > latest and greatest? > Yes. The CVS is what's current. BBum did the last set of patches to change the build to use disutils. It would build under 2.1 except for one glitch -- it complains about not knowing what to do about ".m" files. You need to change Lib/distutils/unixccompiler.py : 70c70 < src_extensions = [".c",".C",".cc",".cxx",".cpp"] --- > src_extensions = [".c",".C",".cc",".cxx",".cpp",".m"] And this just reminded me to submit the patch! I have had some more SSH problems at SourceForge -- I finally gave up on IE and grabbed OmniWeb and it seems to be working I only just caught that the new build changed the name from ObjC.so to pyobjc.so -- so that binary I put on mac.com is actually the previous build. Once that patch goes into Python2.1, all of the known build problems for Python and PyObjC on OSX are fixed. I think we can finally have a release that doesn't require a bunch of patches to Python to be able to build/install/work. Maybe traffic will pick up as soon as we put up a release. -- Steve. From JWight@bigfoot.com Thu Apr 5 07:38:31 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Thu, 05 Apr 2001 01:38:31 -0500 Subject: [Pythonmac-SIG] __builtins__ a dictionary or a module? In-Reply-To: Message-ID: On 04/03/2001 23:51, "Jonathan Wight" wrote: > There is a weirdness though and I haven't figured it out. If I run this code > in the Terminal Python: > > print dir(__builtins__) > > I get something a lot like this. About 40 entries in the list. > > ['ArithmeticError', 'AssertionError', <--snipped--> 'vars', 'xrange', 'zip'] > > If I do the same inside ToxicEdit I get this: > > ['clear', 'copy', 'get', 'has_key', 'items', 'keys', 'popitem', > 'setdefault', 'update', 'values'] > > Which looks like the methods of a dictionary item. The odd thing is is that > seems to be correct (at least superficially). Because if I don't install the > __builtins__ module commands like dir() wouldn't even work. Weird. To follow this up... It turns out if I run ToxicEdit and do a 'print type(__builtins__)' I get the response of "". But from the BSD (and MacPython's) console the same query returns . If I run Just's Python IDE and run the same code it tells mes that __builtins__ is a module. And finally if I run the following code from within the Interactive console contained in standard 'code.py' file I get told __builtins__ is a dictionary. So what is it? Is __builtins__ a module or a dictionary? I know that they're essentially the same thing, but it unnerves me to have the same code produce different results in different platforms. Anyone know what is going on? (Should I send this query to the main python list?) Jon From just@letterror.com Thu Apr 5 07:53:02 2001 From: just@letterror.com (Just van Rossum) Date: Thu, 5 Apr 2001 08:53:02 +0200 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message-ID: <20010405085304-r01010600-d984d106@10.69.17.75> Jonathan Wight wrote: > My original complaints at the start of this thread were basically to do with > how cumbersome it can be to for people embedding Python. Embedding can indeed be a pain. Is it not an option to de the reverse, _extending_ Python? Often this is the more flexible solution, as it's easier to control things from Python. Just From just@letterror.com Thu Apr 5 07:57:01 2001 From: just@letterror.com (Just van Rossum) Date: Thu, 5 Apr 2001 08:57:01 +0200 Subject: [Pythonmac-SIG] \r vs. \n --> import hook? Message-ID: <20010405085703-r01010600-e2cafc62@10.69.17.75> I was thinking about the Unix/Carbon \n vs. \r issue: can't this be solved by an import hook? Maybe this is not the best thing in the long run, but it would allow us to get started quickly. Just From just@letterror.com Thu Apr 5 16:47:11 2001 From: just@letterror.com (Just van Rossum) Date: Thu, 5 Apr 2001 17:47:11 +0200 Subject: [Pythonmac-SIG] Using a unix Python with a MacPython Lib tree In-Reply-To: Message-ID: <20010405174714-r01010600-a8a15774@10.69.17.75> Steven D. Majewski wrote: > Last time I tried it, W died on one of the Qd.GetCursor().data > calls in Wbase.py -- I'm sure because it's a unix object image > without any resource fork, so it only worked for the standard > ones that were in the Carbon framework somewhere. Manyally opening the res fork of Widgets.rsrc should help. Or is there something more fundamentally wrong? > The other missing bit for running any of the Mac Python GUI scripts > is that MacOS module isn't ported, so there's no SchedParams() > function. Hm, the MacOS module doesn't seem that important: how about faking it with some dummy functions? Especially SchedParams() doesn't seem to make much sense under OS X. Just From jack@oratrix.nl Thu Apr 5 20:34:30 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 05 Apr 2001 21:34:30 +0200 Subject: [Pythonmac-SIG] Forwarded: Anthony Ingraldi: Gnuplot.py Message-ID: <20010405193435.9BEF4E9391@oratrix.oratrix.nl> --boogadaboogadabooga Content-Type: text/plain; charset="us-ascii" --boogadaboogadabooga Content-Type: message/rfc822 >From a.m.ingraldi@larc.nasa.gov Thu Apr 5 21: 07:27 2001 Return-Path: Delivered-To: jack@oratrix.nl Received: from post.larc.nasa.gov (post.larc.nasa.gov [128.155.4.45]) by oratrix.oratrix.nl (Postfix) with ESMTP id 42846E9391 for ; Thu, 5 Apr 2001 21:07:26 +0200 (MET DST ) Received: from localhost (runabout.larc.nasa.gov [128.155.21.135]) by post.larc.nasa.gov (pohub4.5) with ESMTP id PAA01831 for ; Thu, 5 Apr 2001 15:07:02 -0400 (EDT) Message-Id: <200104051907.PAA01831@post.larc.nasa.gov> Date: Thu, 5 Apr 2001 15:06:58 -0400 Content-Type: text/plain; format=flowed; charset=us-ascii X-Mailer: Apple Mail (2.387) From: Anthony Ingraldi To: Jack Jansen Mime-Version: 1.0 (Apple Message framework v387) In-Reply-To: <19991202145134.CBEC0370CF2@snelboot.oratrix.nl> Subject: Gnuplot.py Content-Transfer-Encoding: 7bit Jack, I've been disconnected from the Mac Python list for quite some time now but I wanted to pass some info on to you that may be of interest to the list members. I have updated the Mac support in the Gnuplot.py package so that it is now compatible with the latest version of gnuplot (3.7.1a) for Mac OS. The changes are in CVS on SourceForge. (See http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/gnuplot- py/?cvsroot=gnuplot-py) I don't know if and when the Gnuplot.py owner will package a new release that will include the updates. The changes consist of a new set of classes generated via gensuitemodule coupled with some minor edits to the output of gensuitemodule and the gp_mac.py file. -- Tony Ingraldi A.M.INGRALDI@LaRC.NASA.GOV Phone : (757) 864-3039 Fax : (757) 864-7892 --boogadaboogadabooga-- From jacobkm@cats.ucsc.edu Fri Apr 6 01:55:35 2001 From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss) Date: Thu, 5 Apr 2001 17:55:35 -0700 Subject: [Pythonmac-SIG] ctb broken on 2.1b2? Message-ID: I use the ctb (Communications Toolbox) module quite often, so you can imagine my dismay at the what I experienced after downloading 2.1b1: Python 2.1b2 (#90, Mar 26 2001, 21:47:17) [CW CARBON GUSI2 THREADS] on mac Type "copyright", "credits" or "license" for more information. >>> import ctb Traceback (most recent call last): File "", line 1, in ? ImportError: No module named ctb The ctb.ppc.shib is indeed where it should be (Mac:PlugIns) and I have Mac:Plugins in the path. Just to veryify that I wasn't smoking something rather strong, I went tried 2.0: Python 2.0 (#71, Oct 22 2000, 22:09:24) [CW PPC w/GUSI2 w/THREADS] on mac Type "copyright", "credits" or "license" for more information. >>> import ctb >>> ctb.available() 1 Can anyone figure this out? I'd like to use 2.1 if possible, but ctb is pretty much critical... TIA, Jacob From just@letterror.com Fri Apr 6 09:04:53 2001 From: just@letterror.com (Just van Rossum) Date: Fri, 6 Apr 2001 10:04:53 +0200 Subject: [Pythonmac-SIG] ctb broken on 2.1b2? In-Reply-To: Message-ID: <20010406100454-r01010600-18cbdae6@10.69.17.75> Jacob Kaplan-Moss wrote: > I use the ctb (Communications Toolbox) module quite often, so you can > imagine my dismay at the what I experienced after downloading 2.1b1: > > Python 2.1b2 (#90, Mar 26 2001, 21:47:17) [CW CARBON GUSI2 THREADS] on mac > Type "copyright", "credits" or "license" for more information. > >>> import ctb > Traceback (most recent call last): > File "", line 1, in ? > ImportError: No module named ctb > > The ctb.ppc.shib is indeed where it should be (Mac:PlugIns) and I > have Mac:Plugins in the path. Hm, in my install of 2.1b2 there is no ctb.ppc.slb in :Mac:PlugIns, so it looks like an omission. Just From jack@oratrix.nl Fri Apr 6 09:40:22 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 06 Apr 2001 10:40:22 +0200 Subject: [Pythonmac-SIG] \r vs. \n --> import hook? In-Reply-To: Message by Just van Rossum , Thu, 5 Apr 2001 08:57:01 +0200 , <20010405085703-r01010600-e2cafc62@10.69.17.75> Message-ID: <20010406084046.5F491312BA0@snelboot.oratrix.nl> > I was thinking about the Unix/Carbon \n vs. \r issue: can't this be solved by an > import hook? Maybe this is not the best thing in the long run, but it would > allow us to get started quickly. Yes, this sounds like a good idea! Actually, it may be possible to create an import hook that runs on any system, and imports any of \r, \n, \r\n files. This would be a really nice addition to the core Python, because it would not only solve our problems but it would also allow you to access unix files on Samba partitions from a PC, PCNFS files from unix, etc etc etc. Anyone want to pick this up? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Apr 6 09:50:24 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 06 Apr 2001 10:50:24 +0200 Subject: [Pythonmac-SIG] __builtins__ a dictionary or a module? In-Reply-To: Message by Jonathan Wight , Thu, 05 Apr 2001 01:38:31 -0500 , Message-ID: <20010406085024.7548A312BA0@snelboot.oratrix.nl> Python-devvers, can anyone help with this behaviour? > If I run Just's Python IDE and run the same code it tells mes that > __builtins__ is a module. > > And finally if I run the following code from within the Interactive console > contained in standard 'code.py' file I get told __builtins__ is a > dictionary. > > So what is it? Is __builtins__ a module or a dictionary? I know that they're > essentially the same thing, but it unnerves me to have the same code produce > different results in different platforms. Well, I've narrowed down the difference to the exec statement: >>> exec "print type(__builtins__)" >>> exec "print type(__builtins__)" in {} Can anyone explain what is going on here? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Apr 6 09:57:57 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 06 Apr 2001 10:57:57 +0200 Subject: [Pythonmac-SIG] ctb broken on 2.1b2? In-Reply-To: Message by Just van Rossum , Fri, 6 Apr 2001 10:04:53 +0200 , <20010406100454-r01010600-18cbdae6@10.69.17.75> Message-ID: <20010406085757.C4051312BA0@snelboot.oratrix.nl> There seem to be two problems here: 1. Ctb isn't supported under Carbon, Apple doesn't provide the ctb API there. This should be in the release notes, let me check... No, it wasn't there. But it is now, thanks! 2. The ctb module should be included for the ppc runtime model, if it is missing from 2.1b2 that's my mistake. I'll check tonight. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tim.one@home.com Fri Apr 6 10:06:02 2001 From: tim.one@home.com (Tim Peters) Date: Fri, 6 Apr 2001 05:06:02 -0400 Subject: [Python-Dev] Re: [Pythonmac-SIG] __builtins__ a dictionary or a module? In-Reply-To: <20010406085024.7548A312BA0@snelboot.oratrix.nl> Message-ID: Please read this the right way : it's none of your business whether __builtins__ is a module or a dictionary. __builtin__ (no trailing 's') is a module, but __builtins__ is a module attribute that can be either a module or a dictionary, depending on what Python feels like doing. Which it decides to do is an internal implementation detail of no material consequence to correct Python code. More info on why the two choices exist-- and documentation that __builtins__ *can* be either a dict or a module --can be found in the "Code blocks, execution frames, and namespaces" setion of the Language Reference manual. BTW, the primary reason __builtins__ is a module when bringing up a native command-line shell (I know that doesn't apply on a Mac Classic) is simply so that if a curious user types >>> __builtins__ they get instead of a giant dict dump. The primary use for making __builtins__ a dict is to support restricted execution modes. From fgranger@altern.org Fri Apr 6 14:36:22 2001 From: fgranger@altern.org (Francois Granger) Date: Fri, 6 Apr 2001 15:36:22 +0200 Subject: [Pythonmac-SIG] \r vs. \n --> import hook? In-Reply-To: <20010406084046.5F491312BA0@snelboot.oratrix.nl> References: <20010406084046.5F491312BA0@snelboot.oratrix.nl> Message-ID: At 10:40 +0200 6/04/01, in message Re: [Pythonmac-SIG] \r vs. \n --> import hook?, Jack Jansen wrote: >Yes, this sounds like a good idea! Actually, it may be possible to create an >import hook that runs on any system, and imports any of \r, \n, \r\n files. [...] >Anyone want to pick this up? I am not at that level ;-) But I did some simple routines for solving my own issues of reading mail messages in text format from various plateform. I added a simple class to handle it. But I don't know how to patch "import" or even if it needs to be done at the C source level ?? =========================================================== # python """ Simple set of function and object to unify the line ending issues Name: François Granger Home page: http://francois.granger.free.fr/macpython/ E-mail address: fgranger@altern.org E-mail address public: y 20010406 v0.0.1 rough start on it. Need testing and polishing. """ import string, os global lineEnd global osLineEnd osLineEnd = os.linesep() def lineEnding(str): global lineEnd global osLineEnd crNum = string.count(str, '\r') lfNum = string.count(str, '\n') if lfNum == crNum: # dos lineEnd = '\n\r' elif crNum: lineEnd = '\r' elif lfNum: lineEnd = '\n' else: lineEnd = '' return lineEnd def toLine(str): lineEnd = lineEnding(str) return string.split(str, lineEnd) def fromLine(lines): return string.join(lines, lineEnd) def getText(str): return string.replace(str, lineEnd, osLineEnd) def setText(str): return string.replace(str, osLineEnd, lineEnd) Class importconv(): """ to become a patch for importing modules with 'wrong' line ending for the plateform """ def __init__(self, str): """ constructor """ self.lineEnd = lineEnding(str) self.osLineEnd = os.linesep() pass def chgedLineEnd(self, str): return string.replace(str, self.lineEnd, self.oseLineEnd) -- "Faites des phrases courtes. Un sujet, un verbe, un complément. Quand vous voudrez ajouter un adjectif, vous viendrez me voir." - Georges Clemenceau, 1841-1929, médecin et homme politique français. Consignes aux journalistes de "L'Aurore". d'après From JWight@bigfoot.com Fri Apr 6 15:57:59 2001 From: JWight@bigfoot.com (Jonathan Wight) Date: Fri, 06 Apr 2001 09:57:59 -0500 Subject: [Python-Dev] Re: [Pythonmac-SIG] __builtins__ a dictionary or a module? In-Reply-To: Message-ID: On 4/6/01 4:06 AM, "Tim Peters" wrote: > Please read this the right way : it's none of your business whether > __builtins__ is a module or a dictionary. OK, I can live with that. I was wondering why it was 'magically just working' anyways. > BTW, the primary reason __builtins__ is a module when bringing up a native > command-line shell (I know that doesn't apply on a Mac Classic) is simply so > that if a curious user types > >>>> __builtins__ > > they get > > > > instead of a giant dict dump. The primary use for making __builtins__ a dict > is to support restricted execution modes. Well I'd like to make my code (a Python IDE) treat __builtins__ as a module so I'll look and see if there's a way of doing that. But it's not the end of the world if I can't. Thanks Tim providing the answers and Jack for investigating. Jon. From chrishbarker@home.net Fri Apr 6 17:27:26 2001 From: chrishbarker@home.net (Chris Barker) Date: Fri, 06 Apr 2001 09:27:26 -0700 Subject: [Pythonmac-SIG] \r vs. \n --> import hook? References: <20010406084046.5F491312BA0@snelboot.oratrix.nl> Message-ID: <3ACDEE6E.968FABCB@home.net> Jack Jansen wrote: > Yes, this sounds like a good idea! Actually, it may be possible to create an > import hook that runs on any system, and imports any of \r, \n, \r\n files. It's clearly possible, and a darn good idea. I used to use MATLAB a lot, and it could read code in text files of any of the three forms without problems (almost without problems, some dos editors put a "end of file" character at the end that it choked on). I've often wondered why Python didn't have that feature. It's really a pain that a module actually HAS to be different for each platform, just because of line ending issues. > This would be a really nice addition to the core Python, because it would not > only solve our problems but it would also allow you to access unix files on > Samba partitions from a PC, PCNFS files from unix, etc etc etc. I'm sorry that I simply don't have the skills to impliment it, but I very strongly support the idea. While we're at it, I would love it if when you opened a file as a text file, it could read any of the supported formats transparently as well. Has anyone on the Python development group commented on this? -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From sdm7g@Virginia.EDU Fri Apr 6 21:47:15 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Fri, 6 Apr 2001 16:47:15 -0400 (EDT) Subject: [Pythonmac-SIG] pyobjc-0.6 released for macosx Message-ID: There's finally a release of pyobjc for macosx on Source distribution should build against the current cvs of python2.1beta or the next release candidate. If you have the last beta distribution tarball, you need to add ".m" to the src_extensions assignment in distutils/unixccompiler.py: change: src_extensions = [".c",".C",".cc",".cxx",".cpp" ] to: src_extensions = [".c",".C",".cc",".cxx",".cpp",".m"] There is also a binary .so library -- If you have Python2.1 installed, you can just copy it into the python lib's site-packages directory. There are still some bugs, known and unknown, notably: Delegates don't seem to work -- which is very limiting in AppKit! You need to use the whole pathname of python when launching a script (or else use DropShell or gdb) or you may get a 'Error 1011 in _sendFinishLaunchingNotification' (This is probably an OSX bug.) There are some classes exposed in the pyobjc runtime that you really don't need and you really shouldn't try to access. If you do, you will crash. The classes are NSProxy and it's subclasses. These will be removed from visibility in the runtime eventually. NSWindow makeKeyAndOrderFront: doesn't seem to work from Python. No idea why. I'm sure there are others I haven't found. We need to get delegates working, and figure out how to load and animate Nib files from Python for pyobjc to be practical for writing a real Cocoa app in Python. In the mean time, here is a working sample using Cocoa AppKit. -- Steve Majewski # HelloWorld.py # # You have to run this script from the command line with # the full pathname for python: # /usr/local/bin/python HelloWorld.py # # or else run from DropShell or gdb. Anything else and you will get a: # Error 1011 in _sendFinishLaunchingNotification # and it wont work. # # -- Steve Majewski # # You can look up these classes and methods in the Cocoa docs. # A quick guide to runtime name mangling: # # ObjC becomes Python # [ obj method ] obj.method() # [ obj method: arg ] obj.method_(arg) # [ obj method: arg1 withOtherArgs: arg2 ] # obj.method_withOtherArgs_( arg1, arg2 ) import pyobjc rt = pyobjc.runtime # shorthand -- runtime gets used a lot! def main(): pool = rt.NSAutoreleasePool() # Load Application Framework: rt.NSBundle.bundleWithPath_( '/System/Library/Frameworks/AppKit.framework').load() NSApp = rt.NSApplication.sharedApplication() win = rt.NSWindow.alloc() frame = ((200.0, 300.0), (250.0, 100.0)) win.initWithContentRect_styleMask_backing_defer_ (frame, 15, 2, 0) win.setTitle_ ('HelloWorld') win.setLevel_ (3) # floating window hel = rt.NSButton.alloc().initWithFrame_ (((10.0, 10.0), (80.0, 80.0))) win.contentView().addSubview_ (hel) hel.setBezelStyle_( 4 ) hel.setTitle_( 'Hello!' ) beep = rt.NSSound.alloc() beep.initWithContentsOfFile_byReference_( '/System/Library/Sounds/tink.aiff', 1 ) hel.setSound_( beep ) bye = rt.NSButton.alloc().initWithFrame_ (((100.0, 10.0), (80.0, 80.0))) win.contentView().addSubview_ (bye) bye.setBezelStyle_( 4 ) bye.setTarget_ (NSApp) bye.setAction_ ('stop:') bye.setEnabled_ ( 1 ) bye.setTitle_( 'Goobye!' ) adios = rt.NSSound.alloc() adios.initWithContentsOfFile_byReference_( '/System/Library/Sounds/Basso.aiff', 1 ) bye.setSound_( adios ) win.display() # win.makeKeyAndOrderFront_ (NSApp) ## This doesn't seem to work win.orderFrontRegardless() ## but this one does NSApp.run() if __name__ == '__main__' : main() From jack@oratrix.nl Fri Apr 6 22:37:50 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 06 Apr 2001 23:37:50 +0200 Subject: [Pythonmac-SIG] Is ctb.ppc.slb really missing? Message-ID: <20010406213755.7E957EA11D@oratrix.oratrix.nl> Could someone who installed PPC-MacPython 2.1b2 (or both PPC and Carbon 2.1b2) check that ctb.ppc.slb is really missing, as was reported here earlier? On my machine it's there, and working fine (as long as I use PPC-MacPython, not Carbon-MacPython). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From just@letterror.com Fri Apr 6 22:50:54 2001 From: just@letterror.com (Just van Rossum) Date: Fri, 6 Apr 2001 23:50:54 +0200 Subject: [Pythonmac-SIG] Is ctb.ppc.slb really missing? In-Reply-To: <20010406213755.7E957EA11D@oratrix.oratrix.nl> Message-ID: <20010406235055-r01010600-adb93252@213.84.27.177> Jack Jansen wrote: > Could someone who installed PPC-MacPython 2.1b2 (or both PPC and > Carbon 2.1b2) check that ctb.ppc.slb is really missing, as was > reported here earlier? On my machine it's there, and working fine (as > long as I use PPC-MacPython, not Carbon-MacPython). I only have the Carbon version installed here, under 9.1, so maybe my comment was misleading? Just From tim.one@home.com Fri Apr 6 23:50:04 2001 From: tim.one@home.com (Tim Peters) Date: Fri, 6 Apr 2001 18:50:04 -0400 Subject: [Python-Dev] Re: [Pythonmac-SIG] __builtins__ a dictionary ora module? In-Reply-To: Message-ID: [Jonathan Wight] > Well I'd like to make my code (a Python IDE) treat __builtins__ as > a module so I'll look and see if there's a way of doing that. Here's the start of an IDLE session: Python 2.1b2 (#12, Mar 23 2001, 14:01:30) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> __builtins__ >>> So do what it does. we-can-both-search-the-source-code-but-you're-motivated-ly y'rs - tim From jack@oratrix.nl Sat Apr 7 12:57:12 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 07 Apr 2001 13:57:12 +0200 Subject: [Pythonmac-SIG] Import hook to do end-of-line conversion? Message-ID: <20010407115717.E46F0EA11D@oratrix.oratrix.nl> There's talk on the PythonMac-SIG to create an import hook that would read modules with either \r, \n or \r\n newlines and convert them to the local convention before feeding them to the rest of the import machinery. The reason this has become interesting is the mixed unixness/macness of MacOSX, where such an import hook could be used to share a Python tree between MacPython and bsd-Python. They would only need a different site.py (probably), living somehwere near the head of sys.path, that would be in local end of line convention and enable the hook. However, it seem that such a module would have a much more general scope, for instance if you're accessing samba partitions from windows, or other foreign file systems, etc. Does this sound like a good idea? And (even better:-) has anyone done this already? Would it be of enough interest to include it in the core Lib? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From jack@oratrix.nl Sat Apr 7 13:00:15 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 07 Apr 2001 14:00:15 +0200 Subject: [Pythonmac-SIG] Import hook to do end-of-line conversion? Message-ID: <20010407120021.5503DEA11D@oratrix.oratrix.nl> [Oops, try again] There's talk on the PythonMac-SIG to create an import hook that would read modules with either \r, \n or \r\n newlines and convert them to the local convention before feeding them to the rest of the import machinery. The reason this has become interesting is the mixed unixness/macness of MacOSX, where such an import hook could be used to share a Python tree between MacPython and bsd-Python. They would only need a different site.py (probably), living somehwere near the head of sys.path, that would be in local end of line convention and enable the hook. However, it seem that such a module would have a much more general scope, for instance if you're accessing samba partitions from windows, or other foreign file systems, etc. Does this sound like a good idea? And (even better:-) has anyone done this already? Would it be of enough interest to include it in the core Lib? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From fredrik@pythonware.com Sat Apr 7 17:25:52 2001 From: fredrik@pythonware.com (Fredrik Lundh) Date: Sat, 7 Apr 2001 18:25:52 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: <20010407120021.5503DEA11D@oratrix.oratrix.nl> Message-ID: <004c01c0bf7f$6b64e4e0$e46940d5@hagrid> jack wrote: > There's talk on the PythonMac-SIG to create an import hook that would > read modules with either \r, \n or \r\n newlines and convert them to > the local convention before feeding them to the rest of the import > machinery. why not fix the compiler instead? Cheers /F From gstein@lyra.org Sat Apr 7 17:21:14 2001 From: gstein@lyra.org (Greg Stein) Date: Sat, 7 Apr 2001 09:21:14 -0700 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <004c01c0bf7f$6b64e4e0$e46940d5@hagrid>; from fredrik@pythonware.com on Sat, Apr 07, 2001 at 06:25:52PM +0200 References: <20010407120021.5503DEA11D@oratrix.oratrix.nl> <004c01c0bf7f$6b64e4e0$e46940d5@hagrid> Message-ID: <20010407092114.E31832@lyra.org> On Sat, Apr 07, 2001 at 06:25:52PM +0200, Fredrik Lundh wrote: > jack wrote: > > There's talk on the PythonMac-SIG to create an import hook that would > > read modules with either \r, \n or \r\n newlines and convert them to > > the local convention before feeding them to the rest of the import > > machinery. > > why not fix the compiler instead? Exactly. That is where the correct fix should go. The compile can/should recognize all types of newlines as the NEWLINE token. Cheers, -g -- Greg Stein, http://www.lyra.org/ From just@letterror.com Sat Apr 7 17:40:02 2001 From: just@letterror.com (Just van Rossum) Date: Sat, 7 Apr 2001 18:40:02 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <20010407092114.E31832@lyra.org> Message-ID: <20010407184003-r01010600-1327fbb2@213.84.27.177> Greg Stein wrote: > On Sat, Apr 07, 2001 at 06:25:52PM +0200, Fredrik Lundh wrote: > > jack wrote: > > > There's talk on the PythonMac-SIG to create an import hook that would > > > read modules with either \r, \n or \r\n newlines and convert them to > > > the local convention before feeding them to the rest of the import > > > machinery. > > > > why not fix the compiler instead? > > Exactly. That is where the correct fix should go. The compile can/should > recognize all types of newlines as the NEWLINE token. The same goes for file objects in text mode... Just From fredrik@pythonware.com Sat Apr 7 17:54:28 2001 From: fredrik@pythonware.com (Fredrik Lundh) Date: Sat, 7 Apr 2001 18:54:28 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: <20010407184003-r01010600-1327fbb2@213.84.27.177> Message-ID: <00b901c0bf83$69b1e0e0$e46940d5@hagrid> Just wrote: > > > why not fix the compiler instead? > > > > Exactly. That is where the correct fix should go. The compile can/should > > recognize all types of newlines as the NEWLINE token. > > The same goes for file objects in text mode... probably -- but changing can break stuff (in theory, at least), and may require a PEP. changing the compiler is more of a bugfix, really... Cheers /F From just@letterror.com Sat Apr 7 18:26:26 2001 From: just@letterror.com (Just van Rossum) Date: Sat, 7 Apr 2001 19:26:26 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <00b901c0bf83$69b1e0e0$e46940d5@hagrid> Message-ID: <20010407192627-r01010600-b0457661@213.84.27.177> Fredrik Lundh wrote: > Just wrote: > > > > why not fix the compiler instead? > > > > > > Exactly. That is where the correct fix should go. The compile can/should > > > recognize all types of newlines as the NEWLINE token. > > > > The same goes for file objects in text mode... > > probably -- but changing can break stuff (in theory, at least), and > may require a PEP. changing the compiler is more of a bugfix, really... But if we only fix the compiler, we'll get complaints that other things don't work, eg. bogus tracebacks due to a non-fixed linecache.py, broken IDE's, etc. Btw. I can't seem to think of any examples that would break after such a change. I mean, who would depend on a \n text file with embedded \r's? Just From guido@digicool.com Sat Apr 7 19:43:45 2001 From: guido@digicool.com (Guido van Rossum) Date: Sat, 07 Apr 2001 13:43:45 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Sat, 07 Apr 2001 14:00:15 +0200." <20010407120021.5503DEA11D@oratrix.oratrix.nl> References: <20010407120021.5503DEA11D@oratrix.oratrix.nl> Message-ID: <200104071843.NAA23537@cj20424-a.reston1.va.home.com> > There's talk on the PythonMac-SIG to create an import hook that would > read modules with either \r, \n or \r\n newlines and convert them to > the local convention before feeding them to the rest of the import > machinery. The reason this has become interesting is the mixed > unixness/macness of MacOSX, where such an import hook could be used to > share a Python tree between MacPython and bsd-Python. They would only > need a different site.py (probably), living somehwere near the head of > sys.path, that would be in local end of line convention and enable the > hook. > > However, it seem that such a module would have a much more general > scope, for instance if you're accessing samba partitions from windows, > or other foreign file systems, etc. > > Does this sound like a good idea? And (even better:-) has anyone done > this already? Would it be of enough interest to include it in the > core Lib? I know that it's too late for 2.1, but for 2.2, I think we can do better: like Java, the import mechanism should accept all three line ending conventions on all platforms! It would also be nice if opening a file in text mode did this transformation, but alas, that would probably require more work on the file object than I care for. But import should be doable! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@digicool.com Sat Apr 7 19:57:10 2001 From: guido@digicool.com (Guido van Rossum) Date: Sat, 07 Apr 2001 13:57:10 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Sat, 07 Apr 2001 19:26:26 +0200." <20010407192627-r01010600-b0457661@213.84.27.177> References: <20010407192627-r01010600-b0457661@213.84.27.177> Message-ID: <200104071857.NAA23651@cj20424-a.reston1.va.home.com> > > > The same goes for file objects in text mode... Yes. > > probably -- but changing can break stuff (in theory, at least), and > > may require a PEP. changing the compiler is more of a bugfix, really... Yes. > But if we only fix the compiler, we'll get complaints that other > things don't work, eg. bogus tracebacks due to a non-fixed > linecache.py, broken IDE's, etc. Yes. > Btw. I can't seem to think of any examples that would break after > such a change. I mean, who would depend on a \n text file with > embedded \r's? On Unix, currently, tell() always give you a number that exactly matches the number of characters you've read since the beginning of the file. This would no longer be true. In general, code written on Unix with no expectation to ever leave Unix, can currently be sloppy about using binary mode, and open binary files in text mode. Such code could break. I'm sure there's plenty such code around (none written by me :-). --Guido van Rossum (home page: http://www.python.org/~guido/) From tim.one@home.com Sat Apr 7 22:15:30 2001 From: tim.one@home.com (Tim Peters) Date: Sat, 7 Apr 2001 17:15:30 -0400 Subject: [Pythonmac-SIG] RE: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <200104071843.NAA23537@cj20424-a.reston1.va.home.com> Message-ID: As Guido said, Java defines that source-code lines end with any of LF, CR, or CRLF, and that needn't even be consistent across lines. If source files are opened in C binary mode, this is easy enough to do but puts all the burden for line-end detection on Python. Opening source files in C text mode doesn't solve the problem either. For example, if you open a source file with CR endings in Windows C text mode, Windows thinks the entire file is "one line". I expect the same is true if CR files are opened in Unix text mode. So, in the end, binary mode appears to be better (more uniform code). But then what happens under oddball systems like OpenVMS, which seem to use radically different file structures for text and binary data? I've no idea what happens if you try to open a text file in binary mode under those. [Guido] > ... > It would also be nice if opening a file in text mode did this > transformation, but alas, that would probably require more work > on the file object than I care for. Well, Python source files aren't *just* read by "the compiler" in Python. For example, assorted tools in the std library analyze Python source files via opening as ordinary (Python) text files, and the runtime traceback mechanism opens Python source files in (C) text mode too. For that stuff to work correctly regardless of line ends is lots of work in lots of places. In the end I bet it would be easier to replace all direct references to C textfile operations with a "Python text file" abstraction layer. importing-is-only-the-start-of-the-battle-ly y'rs - tim From stefan.witzgall@online.de Sun Apr 8 07:24:33 2001 From: stefan.witzgall@online.de (Stefan Witzgall) Date: Sun, 8 Apr 2001 08:24:33 +0200 Subject: [Pythonmac-SIG] Problems with MacPython 2.1b1 and Tkinter etc. Message-ID: Hello, I installed MacPython 2.1b1. Now I am running into problems using tkinter: _tkinter could not be found. Also ped and example2 in the Mac:Demo-folder crash. Are there any hints or advices? I am using a PMac 8200 (similar to 7200, but in tower case) and MacOS 8.1. Can anyone give a recommendation what the latest version of MacPython is that would run fine on this system? Stefan P.S.: 1.5.2 did run with tkinter here, but I want to give the newer MP a try. From jack@oratrix.nl Sun Apr 8 20:09:10 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 08 Apr 2001 21:09:10 +0200 Subject: [Pythonmac-SIG] Problems with MacPython 2.1b1 and Tkinter etc. In-Reply-To: Message by Stefan Witzgall , Sun, 8 Apr 2001 08:24:33 +0200 , Message-ID: <20010408190915.DA266EA11D@oratrix.oratrix.nl> Recently, Stefan Witzgall said: > Hello, > > I installed MacPython 2.1b1. Now I am running into problems using tkinter: > _tkinter could not be found. Also ped and example2 in the Mac:Demo-folder > crash. > > Are there any hints or advices? Tkinter only works in the classic execution model. The newer 2.1b2 distribution has a better warning for this. Ped indeed has a problem, it uses the Scrap manager in a non-carbon-compatible way. I'll fix this. Example2 has no problems on my machine, so it could be that (a) the bug is fixed since 2.1b1 or (b) something is different on your machine from mine. Could you send me the stacktrace? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From greg@cosc.canterbury.ac.nz Mon Apr 9 02:26:47 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 09 Apr 2001 13:26:47 +1200 (NZST) Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <20010407120021.5503DEA11D@oratrix.oratrix.nl> Message-ID: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> Jack Jansen : > read modules with either \r, \n or \r\n newlines > Does this sound like a good idea? YES! It's always annoyed me that the Mac (seemingly without good reason) complains about sources with \n line endings. I have often shuttled code between Mac and Unix systems during development, and having to do \r/\n translations every time is a royal pain. > Would it be of enough interest to include it in the > core Lib? I'd vote for building it right into the interpreter! Is there any reason why anyone would want *not* to have it? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From cpsoct@lycos.com Mon Apr 9 08:48:50 2001 From: cpsoct@lycos.com (kevin parks) Date: Mon, 09 Apr 2001 16:48:50 +0900 Subject: [Pythonmac-SIG] Re: Python for OS X Message-ID: Is there another build of Python for OS X? I followed the links from the mac python page to the OS precomiled page and found a confusing page with three things that looked nearly identical, but being somewhat lucky got the thing i though i needed called Python-2.0-2.pkg.tgz I unziped and untared it and saw the old heartwarming NeXT-y box package icon. So i thought that i was home free, but no go. I logged in as root and tried to install. The installer launched, said the funny nonsense about it taking 0 MB (or 100 MB, seemingly random depending apon the disk i pointed it to) and then hit install. In said" unpacking..." for a long time and that was it. It never did anything else. I forced the installer to quit, tried again and the same deal. vitals: OS X Powerbook Pismo (firewire) G3 192 MB ram. Thanks, -kp-- Get 250 color business cards for FREE! at Lycos Mail http://mail.lycos.com/freemail/vistaprint_index.html From guido@digicool.com Mon Apr 9 14:41:22 2001 From: guido@digicool.com (Guido van Rossum) Date: Mon, 09 Apr 2001 08:41:22 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Mon, 09 Apr 2001 13:26:47 +1200." <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> Message-ID: <200104091341.IAA00888@cj20424-a.reston1.va.home.com> > I'd vote for building it right into the interpreter! Is > there any reason why anyone would want *not* to have it? No, but (as has been explained) fixing the parser isn't enough -- all tools dealing with source would have to be fixed. Or we would have to write our own C-level file object, which has its own drawbacks. --Guido van Rossum (home page: http://www.python.org/~guido/) From tony.mcdonald@ncl.ac.uk Mon Apr 9 13:47:32 2001 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Mon, 09 Apr 2001 13:47:32 +0100 Subject: [Pythonmac-SIG] Anyone got MySQLdb working under MacOS-X? Message-ID: Hi all, I've downloaded a Darwin binary release of MySQL (mysql-3.23.27-beta-apple-darwin1.2-powerpc) and he MySQLdb package from dustman.net. After fiddlng with the setup.py to point to where my mysql includes and libraries are, I got the thing to compile and install ok. Thing is when I try to use it... [localhost:~/software/MySQL-python-0.3.5] tonymcd% python Python 2.0 (#3, 10/22/00, 12:04:10) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> import MySQLdb dyld: python multiple definitions of symbol _strtol /System/Library/Frameworks/System.framework/Versions/B/System(strtol.o) definition of _strtol /usr/local/lib/python2.0/site-packages/_mysql.so definition of _strtol I've compiled the same under Solaris and LinuxPPC with no problems, but the MacOS-X stuff is very new to me. Does anyone have an idea of what I can try now? TIA Tone -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope From jack@oratrix.nl Mon Apr 9 15:10:28 2001 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 09 Apr 2001 16:10:28 +0200 Subject: [Pythonmac-SIG] Away for 10 days Message-ID: <20010409141029.2E3DB312BA0@snelboot.oratrix.nl> Folks, just so that you're not worrying yourself to death when you'll miss my wit and wisdom on the list, and don't see a MacPython 2.1 distribution quickly following the general 2.1 release: I'm off for a holiday, I'll be back around April 21. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From jbezos@wanadoo.es Mon Apr 9 16:57:41 2001 From: jbezos@wanadoo.es (Javier Bezos Lopez) Date: Mon, 9 Apr 2001 17:57:41 +0200 Subject: [Pythonmac-SIG] AppleScript -> Python Message-ID: <31399D7148E6D4119EC700D0B7A78DB743FD9D@SRVEXCH2UR28> Hi all, I'm converting some AppleScripts to Python, but I don't know how to translate some AppleScript idioms: - the selected folders, - every folder, - ignoring, - in front of, before, etc. Any help (or even better a pointer to a few sample files illustrating that) will be greatly appreciated. Thanks a lot in advance for the answers. ___________________________________________________________ Javier Bezos | TeX y tipografia jbezos at wanadoo dot es | http://perso.wanadoo.es/jbezos/ From sdm7g@Virginia.EDU Mon Apr 9 17:04:32 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Mon, 9 Apr 2001 12:04:32 -0400 (EDT) Subject: [Pythonmac-SIG] Re: Python for OS X In-Reply-To: Message-ID: On Mon, 9 Apr 2001, kevin parks wrote: > Is there another build of Python for OS X? I followed the links from > the mac python page to the OS precomiled page and found a confusing > page with three things that looked nearly identical, but being > somewhat lucky got the thing i though i needed called > > Python-2.0-2.pkg.tgz > Since both Python and OSX and especially Python on OSX have been moving targets, a buch of interim efforts were posted when folks had trouble getting it patched to build correctly. Right now, the current 2.1 beta builds "out-of-the-box" with a: ./configure --with-dyld --with-suffix=.x make make install (We really need to get rid of those obsolete binaries!) If you don't want to mess with compiling, I put up a binary distribution on -- it's a tar file that should unpack into /usr/local/bin & /usr/local/lib, so you should "cd /" and 'sudo' the tar command. That tarfile includes pyexpat, pyobjc and a very experimental Carbon module. If I can figure out how to build a proper package, I'll put one there soon. ( I see they fixed Package Builder so it will fit on the 800x600 screen on my iBook -- I couldn't run in on PublicBeta!) -- Steve Majewski From chrishbarker@home.net Mon Apr 9 19:47:25 2001 From: chrishbarker@home.net (Chris Barker) Date: Mon, 09 Apr 2001 11:47:25 -0700 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> <200104091341.IAA00888@cj20424-a.reston1.va.home.com> Message-ID: <3AD203BD.E544ED0F@home.net> Guido van Rossum wrote: > No, but (as has been explained) fixing the parser isn't enough -- all > tools dealing with source would have to be fixed. Or we would have to > write our own C-level file object, which has its own drawbacks. >From what people have posted, it seems clear that having our own C-level file object is the only reasonable choice. It would take care of all the issues that have been brought up (both code and other text files, etc). Even if people have been sloppy and used binary mode for text files under *nix, that code would still work with *nix text files, which is the only way it works now anyway. Given that something like this has been done in numerous places (JAVA, MATLAB, ???), It seems likely that there is some code out there that could be used. Hopefully there is some without licensing issues (Maybe Scilab or Octave, both are MATLAB clones) What are the drawbacks?? (besides the below example) I'm not sure who wrote: > what happens under oddball systems like OpenVMS, which seem to use > radically different file structures for text and binary data? I've no idea > what happens if you try to open a text file in binary mode under those. Would we have to? At the Python level, you would open a text file, and get what you expected. The "oddball" port would have to have some probably very different code for the C-level file object, but that's presumable the case anyway. what happens when you want to read a non-native text file on those systems now? So you have to read it as binary? By the way, does any of this tie in at all with trying to add Perl-like speed to processing text files? -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From tony@adam12.metanet.com Mon Apr 9 19:57:53 2001 From: tony@adam12.metanet.com (Tony Lownds) Date: Mon, 9 Apr 2001 11:57:53 -0700 Subject: [Pythonmac-SIG] Re: Python for OS X In-Reply-To: References: Message-ID: At 12:04 PM -0400 4/9/01, Steven D. Majewski wrote: >On Mon, 9 Apr 2001, kevin parks wrote: > >> Is there another build of Python for OS X? I followed the links from >> the mac python page to the OS precomiled page and found a confusing >> page That's my confusing page...sorry! >with three things that looked nearly identical, but being >> somewhat lucky got the thing i though i needed called >> > > Python-2.0-2.pkg.tgz > > That package did not install for me either, the packaging must have broken between public beta and final. I've uploaded an updated 2.0 package, just so broken packages are not lying around. >(We really need to get rid of those obsolete binaries!) Done! I plan to point people to your iDisk page from my page, if that's ok. -Tony From guido@digicool.com Mon Apr 9 21:20:13 2001 From: guido@digicool.com (Guido van Rossum) Date: Mon, 09 Apr 2001 15:20:13 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Mon, 09 Apr 2001 11:47:25 MST." <3AD203BD.E544ED0F@home.net> References: <200104090126.NAA12369@s454.cosc.canterbury.ac.nz> <200104091341.IAA00888@cj20424-a.reston1.va.home.com> <3AD203BD.E544ED0F@home.net> Message-ID: <200104092020.PAA02237@cj20424-a.reston1.va.home.com> > Guido van Rossum wrote: > > No, but (as has been explained) fixing the parser isn't enough -- all > > tools dealing with source would have to be fixed. Or we would have to > > write our own C-level file object, which has its own drawbacks. > > From what people have posted, it seems clear that having our own C-level > file object is the only reasonable choice. It would take care of all the > issues that have been brought up (both code and other text files, etc). > Even if people have been sloppy and used binary mode for text files > under *nix, that code would still work with *nix text files, which is > the only way it works now anyway. > > Given that something like this has been done in numerous places (JAVA, > MATLAB, ???), It seems likely that there is some code out there that > could be used. Hopefully there is some without licensing issues (Maybe > Scilab or Octave, both are MATLAB clones) I doubt that we could use anything that was done for another language, because everybody who codes this kind of thing makes it do exactly what their environment needs, e.g. in terms of error handling API, functionality, and performance. > What are the drawbacks?? (besides the below example) The drawbacks aren't so much technical (I have a pretty good idea of how to build such a thing), they're political and psychological. There's the need for supporting the old way of doing things for years, there's the need for making it easy to convert existing code to the new way, there's the need to be no slower than the old solution, there's the need to be at least as portable as the old solution (which may mean implementing it *on top of* stdio since on some systems that's all you've got). > I'm not sure who wrote: > > what happens under oddball systems like OpenVMS, which seem to use > > radically different file structures for text and binary data? I've no idea > > what happens if you try to open a text file in binary mode under those. > > Would we have to? At the Python level, you would open a text file, and > get what you expected. The "oddball" port would have to have some > probably very different code for the C-level file object, but that's > presumable the case anyway. what happens when you want to read a > non-native text file on those systems now? So you have to read it as > binary? > > By the way, does any of this tie in at all with trying to add Perl-like > speed to processing text files? It would be one way towards that goal. But notice that we've already gotten most of the way there with the recent readline changes in 2.1. --Guido van Rossum (home page: http://www.python.org/~guido/) From fgranger@mail.dotcom.fr Sun Apr 8 23:03:55 2001 From: fgranger@mail.dotcom.fr (=?iso-8859-1?Q?Fran=E7ois?= Granger) Date: Mon, 9 Apr 2001 00:03:55 +0200 Subject: [Pythonmac-SIG] (begginer) Pickling Message-ID: (My news server does not works tonight...) I send below a simplified version of the code I am writing. When I run it I get the following error message: 'Failed to import class B from module __main__' I tired an alternative wich is commented out (line 44-51 , 61 and 65) but the error message is similar with a reference to class A. I am guessing that this is an issue with namespace that I don't really understand. On a similar track, I would be happy to see a more general algorithm to implement persistence of complexe objects between runs. TIA ======================================================== # python """ Simple test of pickling complex objects """ import pickle class A: """ """ id = 0 def __init__(self): A.id += 1 self.value = 0.0 self.id = A.id def __repr__(self): return str(self.__dict__) + '\n\n' def activate(self): self.value += 1.0 class B: """ """ def __init__(self, ninput = 10, noutput = 10): self.ninput = ninput self.noutput = noutput self.input = {} for i in range(self.ninput): self.input[A.id] = A() self.output = {} for i in range(self.noutput): self.output[A.id] = A() def transmit(self): for i in self.input.keys(): self.input[i].activate() for i in self.output.keys(): self.output[i].activate() """ def save_NN(self, fp): pickle.dump((self.input, self.output), fp) pass def load_NN(self, fp): #set neuron.id to max id ? self.input, self.layer, self.output = pickle.load(fp) pass """ if __name__ == '__main__': inp = 10 out = 10 N = B(inp, out) for i in range(5): N.transmit() fp = open('neuronet.txt', 'w') #N.save_NN(fp) pickle.dump(N, fp) fp.close() fp = open('neuronet.txt', 'r') #N.load_NN(fp) N = pickle.load(fp) fp.close() pass ======================================================== -- [fr, en, es, ia] Information sur la hiérarchie usenet europa.* : http://europa.usenet.eu.org -- "Faites des phrases courtes. Un sujet, un verbe, un complément. Quand vous voudrez ajouter un adjectif, vous viendrez me voir." - Georges Clemenceau, 1841-1929, médecin et homme politique français. Consignes aux journalistes de "L'Aurore". d'après From just@letterror.com Mon Apr 9 21:00:22 2001 From: just@letterror.com (Just van Rossum) Date: Mon, 9 Apr 2001 22:00:22 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <200104092020.PAA02237@cj20424-a.reston1.va.home.com> Message-ID: <20010409220023-r01010600-7dc11706@213.84.27.177> Proposal for 2.2, outline for a PEP? 1) The Python file object needs to be modified so that in text mode it can recognize all major line ending conventions (Unix, Win and Mac). Reading data: - recognize \n, \r and \r\n as line ending, present as \n to Python Writing data: - convert \n to the platform line endings (this is already the case) This modification should be _optional_, because it may break code under unix (insert Guido's explanation here), and because it may not support oddball systems like OpenVMS. It should be _on_ by default under: - Windows - MacPython Classic - MacPython Carbon - Unix Python under MacOS X / Darwin It should probably be off by default on all other systems (I think a compile-time switch is good enough). Maybe if we advertize the potential sloppy-unix-code-breakage loud enough we can make the feature mandatory in a later release, however I don't see a practical way of issuing warnings for the situation. 2) I assume there are quite a few places where Python uses raw C text files: these places should be identified, we should figure out how much work it is to fix these so they behave just like the Python file object as described above. Who would like to team up with me to write a decent PEP and maybe an example implementation? Just From nhodgson@bigpond.net.au Mon Apr 9 21:46:11 2001 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Tue, 10 Apr 2001 06:46:11 +1000 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: <20010409220023-r01010600-7dc11706@213.84.27.177> Message-ID: <007401c0c136$f7d1cb10$8119fea9@neil> Just van Rossum: > It should probably be off by default on all other systems (I think a > compile-time switch is good enough). Maybe if we advertize the potential > sloppy-unix-code-breakage loud enough we can make the feature mandatory in a > later release, however I don't see a practical way of issuing warnings for the > situation. It should be on by default for the Python interpreter reading Python programs as making it off by default leads to the inability to run programs written with Windows or Mac tools on Unix which was the problem reported by 'dsavitsk' on comp.lang.python. If it is going to be off by default then the error message should include "Rerun with -f to fix this error". Neil From just@letterror.com Mon Apr 9 22:07:20 2001 From: just@letterror.com (Just van Rossum) Date: Mon, 9 Apr 2001 23:07:20 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <007401c0c136$f7d1cb10$8119fea9@neil> Message-ID: <20010409230721-r01010600-08aa8401@213.84.27.177> Neil Hodgson wrote: > Just van Rossum: > > > It should probably be off by default on all other systems (I think a > > compile-time switch is good enough). Maybe if we advertize the potential > > sloppy-unix-code-breakage loud enough we can make the feature mandatory in > > a later release, however I don't see a practical way of issuing warnings for > > the situation. > > It should be on by default for the Python interpreter reading Python > programs as making it off by default leads to the inability to run programs > written with Windows or Mac tools on Unix which was the problem reported by > 'dsavitsk' on comp.lang.python. Yes, but as was mentioned before: this will lead to other problems for which we wouldn't have a good excuse: any program printing a traceback with the traceback module will output bogus data if linecache.py will read the source files incorrectly. And that's just one example. I don't think the two features should be switchable separately. Maybe it should be on by default, provided we have a command line switch to to turn the new behavior *off*, just like there used to be a command line switch to revert to string based exceptions. Just From greg@cosc.canterbury.ac.nz Tue Apr 10 00:56:09 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 10 Apr 2001 11:56:09 +1200 (NZST) Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <200104071857.NAA23651@cj20424-a.reston1.va.home.com> Message-ID: <200104092356.LAA12517@s454.cosc.canterbury.ac.nz> Guido: > code written on > Unix with no expectation to ever leave Unix, can currently be sloppy > about using binary mode Maybe there should be a third mode, "extremely text mode", which Python-source-processing utilities (and anything else which wants to be cross-platform-line-ending-friendly) can use. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From greg@cosc.canterbury.ac.nz Tue Apr 10 01:21:36 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 10 Apr 2001 12:21:36 +1200 (NZST) Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <3AD203BD.E544ED0F@home.net> Message-ID: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz> Chris Barker : > Even if people have been sloppy and used binary mode for text files > under *nix, that code would still work with *nix text files, which is > the only way it works now anyway. That's a good point. The only thing that could break is if you opened a non-Unix file in *text* mode, and then expected it to behave as though it had been opened in *binary* mode. I can't imagine any code being screwy enough to do that! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From chrishbarker@home.net Tue Apr 10 01:37:39 2001 From: chrishbarker@home.net (Chris Barker) Date: Mon, 09 Apr 2001 17:37:39 -0700 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: <20010409220023-r01010600-7dc11706@213.84.27.177> Message-ID: <3AD255D3.9872C019@home.net> Just van Rossum wrote: > Proposal for 2.2, outline for a PEP? Thanks, Just, for getting this rolling. > 1) > The Python file object needs to be modified so that in text mode it can > recognize all major line ending conventions (Unix, Win and Mac). > > Reading data: > - recognize \n, \r and \r\n as line ending, present as \n to Python > Writing data: > - convert \n to the platform line endings (this is already the case) > > This modification should be _optional_, because it may break code under unix > (insert Guido's explanation here), and because it may not support oddball > systems like OpenVMS. > > It should be _on_ by default under: > - Windows > - MacPython Classic > - MacPython Carbon > - Unix Python under MacOS X / Darwin > > It should probably be off by default on all other systems (I think a > compile-time switch is good enough). Maybe if we advertize the potential > sloppy-unix-code-breakage loud enough we can make the feature mandatory in a > later release, however I don't see a practical way of issuing warnings for the > situation. I agree that is should be possible to turn the proposed off, but I still think it should be on by default, even on *nix systems (which is mostly what I use, buy the way), as it would only cause a problem for "sloppy" code anyway. Would it be possible to have it be turned on/off at runtime, rather than compile time ? It would be pretty awkward to have a program need a specific version of the interpreter to run. Even a command line flag could be awkward enough, then only the main program could specify the flag, and modules might not be compatible. Another option is for the new version to have another flag or set of flags to the open command, which would indicate that the file being opened is "Unix", "Mac", "DOS", or "Any". this would make it easy to write text files in a non-native format, as well as read them. Even if we didn't go that far, we could use the "t" flag (analogous to "b" for binary), to specify the universal text format, and the default would still be the current, native format. This would keep the "sloppy" *nix code from breaking, and still give full functionality to new code. While we are at it, what would get written is something we need to consider. If we just have the above proposal, reading a file would work great, it could be on a server with a different line ending format, and that would be transparent. Writing, on the other hand is an issue. If a program is running on a windows box, and writing a file on a *nix server, what kind of line ending should it write? Would it even know what the native format is on the server? It seems we would need to be able to specify the line ending format explicitly for writing. Just a few thoughts, maybe we'll get a PEP out of this after all! -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From greg@cosc.canterbury.ac.nz Tue Apr 10 01:29:42 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 10 Apr 2001 12:29:42 +1200 (NZST) Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <3AD203BD.E544ED0F@home.net> Message-ID: <200104100029.MAA12528@s454.cosc.canterbury.ac.nz> Disregard what I just said. The problem isn't about reading text files at all, it's about reading non-text files without explicitly opening them in binary mode. I think the trouble is with the idea that if you don't specify the mode explicitly it defaults to text mode, which on Unix just happens to be the same as binary mode. Could we change that so binary mode is the default on Unix, and if you want any line ending translation, you have to specify text mode explicitly? Is there any standard which says that text mode must be the default? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From chrishbarker@home.net Tue Apr 10 01:47:34 2001 From: chrishbarker@home.net (Chris Barker) Date: Mon, 09 Apr 2001 17:47:34 -0700 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz> Message-ID: <3AD25826.8C95D0AB@home.net> Greg Ewing wrote: > Chris Barker : > > Even if people have been sloppy and used binary mode for text files > > under *nix, that code would still work with *nix text files, which is > > the only way it works now anyway. > > That's a good point. The only thing that could break is if > you opened a non-Unix file in *text* mode, and then expected > it to behave as though it had been opened in *binary* mode. > I can't imagine any code being screwy enough to do that! Actually, I thought about it more, and of course, Guido is right. On *nix, if you open a binary file in text mode, it works just fine, as there is no difference. However, under the proposed scheme, the text mode would translate "\r" into "\n", messing up your binary data. It would also do it only with a couple of particular byte values, so it might not be obvious that anything is wrong right away. I've done that myself, by mistake. I wrote a little tool that used FTP to transfer some binary files. It worked fine under Linux, but then I tried to run it on the Mac, and the files got corrupted. It took me WAY too long to figure out that I had read the file in text mode. Personally, I've always thought it was unfortunate that the default was text mode, rather than binary, or even better, there could be no default: you have to specify either "b" or "t", then there would be no room for confusion. -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From greg@cosc.canterbury.ac.nz Tue Apr 10 02:07:28 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 10 Apr 2001 13:07:28 +1200 (NZST) Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <3AD255D3.9872C019@home.net> Message-ID: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> Chris Barker : > If a program is running on a windows box, and writing a file on a *nix > server, what kind of line ending should it write? Would it even know > what the native format is on the server? It seems we would need to be > able to specify the line ending format explicitly for writing. Yes, I think that's the best that can be done. To do any better would require all file servers to be aware of the text/binary distinction and be willing to translate, and for there to be some way for the Python file object to communicate to the OS which mode is intended. Neither of these things are true in general. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From greg@cosc.canterbury.ac.nz Tue Apr 10 02:18:25 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 10 Apr 2001 13:18:25 +1200 (NZST) Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <3AD25826.8C95D0AB@home.net> Message-ID: <200104100118.NAA12540@s454.cosc.canterbury.ac.nz> Chris Barker : > It took me WAY > too long to figure out that I had read the file in text mode. My favourite way of falling into that trap involves AUFS (the Appleshare Unix File Server). You're browsing the web on a Unix box and come across a juicy-looking Stuffit file. You download it into your AUFS directory, hop over to the Mac and feed it to Stuffit Expander, which promptly throws a wobbly. "Shazbot," you mutter, "it got corrupted in the download somehow." You try a couple more times, with the same result. You're just about to write to the web site maintainer telling them that their file is corrupt, when it dawns on you that: (a) AUFS performs CR/LF translation on files whose Mac type code is 'TEXT'; (b) Unix-created files default to type 'TEXT'. (Sorry, not really Python-related. Pretend you've implemented your Stuffit expander in Python...) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From guido@digicool.com Tue Apr 10 03:32:51 2001 From: guido@digicool.com (Guido van Rossum) Date: Mon, 09 Apr 2001 21:32:51 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Tue, 10 Apr 2001 12:21:36 +1200." <200104100021.MAA12524@s454.cosc.canterbury.ac.nz> References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz> Message-ID: <200104100232.VAA03655@cj20424-a.reston1.va.home.com> > Chris Barker : > > > Even if people have been sloppy and used binary mode for text files > > under *nix, that code would still work with *nix text files, which is > > the only way it works now anyway. > > That's a good point. The only thing that could break is if > you opened a non-Unix file in *text* mode, and then expected > it to behave as though it had been opened in *binary* mode. > I can't imagine any code being screwy enough to do that! Actually, that *is* the scenario I'm worried about. Someone can open a GIF file in text mode today on a Unix platform and it'll just work (until they port the program to another platform, that is. ;-). So Unix weenies haven't had much of an incentive (or warning) about using binary mode properlu. In text translation mode, if there happen to be bytes with values 0x0d in the file, they will be mangled. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@digicool.com Tue Apr 10 03:33:53 2001 From: guido@digicool.com (Guido van Rossum) Date: Mon, 09 Apr 2001 21:33:53 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Tue, 10 Apr 2001 12:29:42 +1200." <200104100029.MAA12528@s454.cosc.canterbury.ac.nz> References: <200104100029.MAA12528@s454.cosc.canterbury.ac.nz> Message-ID: <200104100233.VAA03669@cj20424-a.reston1.va.home.com> > Disregard what I just said. The problem isn't about reading > text files at all, it's about reading non-text files without > explicitly opening them in binary mode. What I said. :-) > I think the trouble is with the idea that if you don't > specify the mode explicitly it defaults to text mode, which > on Unix just happens to be the same as binary mode. > > Could we change that so binary mode is the default on > Unix, and if you want any line ending translation, you > have to specify text mode explicitly? Is there any standard > which says that text mode must be the default? It's pretty clear that the default is text mode. But we could add a new mode character, 't', to force text mode on. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@digicool.com Tue Apr 10 03:41:54 2001 From: guido@digicool.com (Guido van Rossum) Date: Mon, 09 Apr 2001 21:41:54 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Tue, 10 Apr 2001 13:07:28 +1200." <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> Message-ID: <200104100241.VAA03714@cj20424-a.reston1.va.home.com> > > If a program is running on a windows box, and writing a file on a *nix > > server, what kind of line ending should it write? Would it even know > > what the native format is on the server? It seems we would need to be > > able to specify the line ending format explicitly for writing. > > Yes, I think that's the best that can be done. To do any better > would require all file servers to be aware of the text/binary > distinction and be willing to translate, and for there to be > some way for the Python file object to communicate to the OS > which mode is intended. Neither of these things are true in > general. You might need to be able to specify a specific line ending format, but there should also be a default -- and it should be the default appropriate to the OS. So, \n on Unix, \r\n on Windows, \r on Mac running in "Mac mode", and \n on MacOS X running in "Unix mode". --Guido van Rossum (home page: http://www.python.org/~guido/) From tjlahey@sympatico.ca Tue Apr 10 04:09:41 2001 From: tjlahey@sympatico.ca (Tim Lahey) Date: Mon, 9 Apr 2001 23:09:41 -0400 Subject: [Pythonmac-SIG] Python on OS X: Multiple definitions of symbols Message-ID: <20010410031144.IYVF24361.tomts7-srv.bellnexxia.net@localhost> All, I built the latest beta of Python (2.1b2a) using: ./configure --with-dyld --with-suffix=.x make sudo make install Next, I download pyobjc.so from sourceforge. That imports fine. I then download and compile PyXML and when I try and run the tests: [localhost:python/PyXML-0.6.5/test] tjlahey% python test_howto.py SAX tests: dyld: python multiple definitions of symbol _main python definition of _main /usr/local/lib/python2.1/site-packages/_xmlplus/parsers/pyexpat.so definition of _main Does anyone know how to fix these multiple definition of symbol problems? I've had this kind of problem with Numeric on OS X and I can't seem to figure out how to fix this. Thanks, Tim Lahey From vincem@en.com Tue Apr 10 04:00:25 2001 From: vincem@en.com (Vincent Marchetti) Date: Mon, 9 Apr 2001 23:00:25 -0400 Subject: [Pythonmac-SIG] Re: AppleScript -> Python Message-ID: At 5:57 PM +0200 4/9/01, Javier Bezos Lopez wrote: >I'm converting some AppleScripts to Python, but I don't know >how to translate some AppleScript idioms: > - the selected folders, > - every folder, > - ignoring, > - in front of, before, etc. I know how to encode some of the complex object references, if you give examples of these construction in a script I'll give them a try Vince Marchetti vince@en.com From stefan.witzgall@online.de Tue Apr 10 06:03:11 2001 From: stefan.witzgall@online.de (Stefan Witzgall) Date: Tue, 10 Apr 2001 07:03:11 +0200 Subject: [Pythonmac-SIG] Numeric issue (not Mac specififc?) Message-ID: Playing around I found the following: >>> 6666666666666.2+9 6666666666675.2002 >>> 66.2+9 75.200000000000003 >>> 66.2+9.0 75.200000000000003 >>> 0.2+9.0 9.1999999999999993 >>> Is this lack of accuracy documented, perhaps in the description of the types Python use? Is there a possibility to get a predictable accuracy or behavior, or is there a module out anywhere to do mathematical operations in a "better" way? I didn't have any problems with this yet, but this would make it necessary to use intervals, and epsilons and deltas, to test if reals are "equal". Stefan From jwblist@olympus.net Tue Apr 10 07:32:33 2001 From: jwblist@olympus.net (John W Baxter) Date: Mon, 9 Apr 2001 23:32:33 -0700 Subject: [Pythonmac-SIG] Numeric issue (not Mac specififc?) In-Reply-To: References: Message-ID: At 7:03 +0200 4/10/01, Stefan Witzgall wrote: >Playing around I found the following: > >>>> 6666666666666.2+9 >6666666666675.2002 >>>> 66.2+9 >75.200000000000003 >>>> 66.2+9.0 >75.200000000000003 >>>> 0.2+9.0 >9.1999999999999993 >>>> > >Is this lack of accuracy documented, perhaps in the description of the >types Python use? Is there a possibility to get a predictable accuracy or >behavior, or is there a module out anywhere to do mathematical operations >in a "better" way? This is just the way binary floating point works. Numbers which we decimillians "know" are exact generally aren't. [Eduroa doesn't like the spelling of decimillians...I wonder why. ;-)] Seriously, 75.2 is "obviously" exact...it can't be represented exactly in binary floating point. And you are correct: one should not compare computed binary floating point numbers to zero, or to other constants, or to each other...one should instead determine whether one number is close enough to another number. "Comparing" includes the exit test of loops. This only became "obvious" with recent Python versions which don't hide it from us (by not rounding off). Before, one had little surprises like: >>> (0.1 + 0.1 + 0.1) == 0.3 0 without the hints one gets now that something "strange" is going on. To get more "reasonable" results, use print or other tools...try print 6666666666666.2+9 --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jwblist@olympus.net Tue Apr 10 07:47:44 2001 From: jwblist@olympus.net (John W Baxter) Date: Mon, 9 Apr 2001 23:47:44 -0700 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <200104100241.VAA03714@cj20424-a.reston1.va.home.com> References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> <200104100241.VAA03714@cj20424-a.reston1.va.home.com> Message-ID: At 21:41 -0500 4/9/01, Guido van Rossum wrote: >You might need to be able to specify a specific line ending format, >but there should also be a default -- and it should be the default >appropriate to the OS. So, \n on Unix, \r\n on Windows, \r on Mac >running in "Mac mode", and \n on MacOS X running in "Unix mode". Is it the same in Mac OS X when reading a file from a UFS volume as from an HFS(+) volume? Only if the underlying libraries make it so. (Typing in Mac OS X, but I don't have any UFS volumes lying around.) It's a little scary to contemplate that reading two different files, which happen to be on the same disk spindle, will behave differently for the file on the HFS+ volume than for the file on the UFS volume. [There are perhaps similar issues for our Linux friends who mount Windows volumes.] What ever happened to "move text files to another system using FTP in ASCII mode?" Ah, yes...it probably died of Unicode. --John (there may no be any answers for this) Baxter -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From moshez@zadka.site.co.il Tue Apr 10 07:52:11 2001 From: moshez@zadka.site.co.il (Moshe Zadka) Date: Tue, 10 Apr 2001 09:52:11 +0300 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz> References: <200104100021.MAA12524@s454.cosc.canterbury.ac.nz> Message-ID: On Tue, 10 Apr 2001, Greg Ewing wrote: > That's a good point. The only thing that could break is if > you opened a non-Unix file in *text* mode, and then expected > it to behave as though it had been opened in *binary* mode. > I can't imagine any code being screwy enough to do that! Then you've got another thing coming. Most UNIXers aren't aware that the 'b' modifier exists: open(file) opens the file, whether it is text or binary. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org From stefan.witzgall@online.de Tue Apr 10 10:58:34 2001 From: stefan.witzgall@online.de (Stefan Witzgall) Date: Tue, 10 Apr 2001 11:58:34 +0200 Subject: [Pythonmac-SIG] Numeric issue (not Mac specififc?) In-Reply-To: References: Message-ID: John, thank you for this explanation. This behavior is so obvios, that it couldn't have been a secret for the people working longer with Python than I. >And you are correct: one should not compare computed binary floating point >numbers to zero, or to other constants, or to each other...one should >instead determine whether one number is close enough to another number. >"Comparing" includes the exit test of loops. > >This only became "obvious" with recent Python versions which don't hide it >from us (by not rounding off). Before, one had little surprises like: > >>>> (0.1 + 0.1 + 0.1) == 0.3 >0 Strange ;-) >without the hints one gets now that something "strange" is going on. .. no longer. >To get more "reasonable" results, use print or other tools...try >print 6666666666666.2+9 Stefan From guido@digicool.com Tue Apr 10 14:58:39 2001 From: guido@digicool.com (Guido van Rossum) Date: Tue, 10 Apr 2001 08:58:39 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Mon, 09 Apr 2001 23:47:44 MST." References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> <200104100241.VAA03714@cj20424-a.reston1.va.home.com> Message-ID: <200104101358.IAA05924@cj20424-a.reston1.va.home.com> [me] > >You might need to be able to specify a specific line ending format, > >but there should also be a default -- and it should be the default > >appropriate to the OS. So, \n on Unix, \r\n on Windows, \r on Mac > >running in "Mac mode", and \n on MacOS X running in "Unix mode". [JW Baxter] > Is it the same in Mac OS X when reading a file from a UFS volume as from an > HFS(+) volume? I'm not sure that the volume from which you're *reading* could or should have any influence on the default delimiter used for *writing*. The volume you're *writing* to might, if it's easy to determine -- but personally, I'd be happy with a default set at compile time. > Only if the underlying libraries make it so. (Typing in Mac OS X, but I > don't have any UFS volumes lying around.) > > It's a little scary to contemplate that reading two different files, which > happen to be on the same disk spindle, will behave differently for the file > on the HFS+ volume than for the file on the UFS volume. [There are perhaps > similar issues for our Linux friends who mount Windows volumes.] Anyway, disk spindles are the wrong abstraction level to consider here. Who cares about what spindle your files are on? > What ever happened to "move text files to another system using FTP in ASCII > mode?" Ah, yes...it probably died of Unicode. No, obviously it's cross-platform disk sharing. The first time this came up was when it became possible to mount Unix volumes on NT boxes many years ago, and that's when Python's parser (eventually) grew the habit of silently ignoring a \r just before a \n in a source file. It's a sign of how backward the Mac world is that the problem only now pops up for the Mac. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From just@letterror.com Tue Apr 10 14:20:41 2001 From: just@letterror.com (Just van Rossum) Date: Tue, 10 Apr 2001 15:20:41 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <200104101358.IAA05924@cj20424-a.reston1.va.home.com> Message-ID: <20010410152043-r01010600-eda55263@213.84.27.177> Guido van Rossum wrote: > It's a sign of how backward the Mac world is that the problem only now > pops up for the Mac. :-) I know I shouldn't bite, but I find this a very childish remark, Guido! It's also not true... Here's an excerpt from a private thread between me, Jack and Guido. It's dated january 8, 1996, I remember I was just learning Python. (I'll give a translation below.) """ > >> files: > >> is het een probleem om Mac *en* Unix files transparant te kunnen > >> lezen/executen? (een unix.py file veroorzaakt vreemde > >> error...) (Ik neem aan dat je bedoelt files met '\n' in plaats van '\r' als line separator.) > >Hmm, ik weet niet of ik dit een goed idee vindt. Weet je wat: vraag > >eens wat Guido er van vind (met een cc-tje naar mij). Geen goed idee, tenzij de C stdio library dit automatisch doet (kennelijk niet dus). Het is over het algemeel een kleine moeite dit bij het file transport recht te trekken (ftp in text mode etc.). """ Translation: """ [Just] >>> files: >>> is it a problem to read/execute Mac *and* Unix files transparently? >>> (a unix.py file causes a strange error...) [Guido] (I take it you mean files with '\n' instead of '\r' as line separator.) [Jack] >> Hm, I don't know whether I think this is a good idea. You know what, >> ask Guido what he thinks (and cc me). [Guido] Not a good idea, unless the C stdio library does this automatically (apparently it doesn't). In general it's a small effort to correct this during the file transport (ftp in text mode etc.). """ So it's not that the problem wasn't there, it was just not taken very seriously at the time... Just From chrishbarker@home.net Tue Apr 10 19:13:56 2001 From: chrishbarker@home.net (Chris Barker) Date: Tue, 10 Apr 2001 11:13:56 -0700 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: <200104100107.NAA12536@s454.cosc.canterbury.ac.nz> <200104100241.VAA03714@cj20424-a.reston1.va.home.com> <200104101358.IAA05924@cj20424-a.reston1.va.home.com> Message-ID: <3AD34D64.7F66DF52@home.net> Guido van Rossum wrote: > No, obviously it's cross-platform disk sharing. The first time this > came up was when it became possible to mount Unix volumes on NT boxes I'm sure it came up before that, I know it has for me, and I don't happen to do any cross platform disk sharing. It is just a little more soluble if you aren't doing disk sharing. > many years ago, and that's when Python's parser (eventually) grew the > habit of silently ignoring a \r just before a \n in a source file. It can do that? I had no idea. Probably because I work on the Mac and Linux almost exclusively, and hardly ever encounter a Windows box. > It's a sign of how backward the Mac world is that the problem only now > pops up for the Mac. :-) Actually it's a sign of how *nix/Windows focused Python is. It's sad to see that someone thought to fix the problem for *nix/Windows, and didn't even consider the Mac (as Just pointed out the problem has been know for a long time). Frankly, it's also a symptom the the isolationist attitude of a lot of Mac users/developers. and Don't get me started on the spaces vs tabs thing! Just, Are you planning on putting together a PEP from all of this? I'd really like to see this happen! -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From tim.one@home.com Wed Apr 11 05:20:42 2001 From: tim.one@home.com (Tim Peters) Date: Wed, 11 Apr 2001 00:20:42 -0400 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <3AD34D64.7F66DF52@home.net> Message-ID: [Guido] >> ... >> that's when Python's parser (eventually) grew the habit of >> silently ignoring a \r just before a \n in a source file. [Chris Barker] > It can do that? I had no idea. Probably because I work on the Mac and > Linux almost exclusively, and hardly ever encounter a Windows box. >> It's a sign of how backward the Mac world is that the problem only >> now pops up for the Mac. :-) > Actually it's a sign of how *nix/Windows focused Python is. It's sad > to see that someone thought to fix the problem for *nix/Windows, and > didn't even consider the Mac (as Just pointed out the problem has > been know for a long time). This is a reversal of history. The code to ignore \r when seeing \r\n originally (1995) applied to *all* platforms. I don't know why, but Jack submitted a patch to disable this behavior only when "#ifdef macintosh", in revision 2.29 of Parser/tokenizer.c, about 4 years ago. The #ifdef introduced then still exists today; 3 lines introduced by that patch start with XXX here for clarity (appropriately defined ): XXX #ifndef macintosh /* replace "\r\n" with "\n" */ XXX /* For Mac we leave the \r, giving a syntax error */ pt = tok->inp - 2; if (pt >= tok->buf && *pt == '\r') { *pt++ = '\n'; *pt = '\0'; tok->inp = pt; } XXX #endif I have no idea what Mac C libraries return for text-mode reads. They must convert \r to \n, right? In which case I guess any \r remaining *should* be "an error" (but where would it come from, if the C library converts all \r thingies?). Do they leave \n alone? Etc: submit a patch that makes the code above "work", and I'm sure it would be accepted, but a non-Mac person can't guess what's needed. As to "considering the Mac", guilty as charged: I don't know anything about it. What's to consider? How often do you consider the impact of chnages on, say, OpenVMS? Same thing, provided you're as ignorant of it as I am of your system. > Frankly, it's also a symptom the the isolationist attitude of a > lot of Mac users/developers. and Don't get me started on the spaces > vs tabs thing! The std for distributed Python code is 4-space indents, no hard tab characters. So there's nothing left there to get started on . it's-not-that-we-don't-want-to-"fix"-macs-it's-that-we-don't-know- how-macs-work-or-what-"fix"-*means*-to-a-macizoid-ly y'rs - tim From just@letterror.com Wed Apr 11 11:03:27 2001 From: just@letterror.com (Just van Rossum) Date: Wed, 11 Apr 2001 12:03:27 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Message-ID: <20010411120330-r01010600-75da8509@213.84.27.177> Tim Peters wrote: > This is a reversal of history. The code to ignore > \r > when seeing > \r\n > originally (1995) applied to *all* platforms. I don't know why, but Jack > submitted a patch to disable this behavior only when "#ifdef macintosh", in > revision 2.29 of Parser/tokenizer.c, about 4 years ago. The #ifdef > introduced then still exists today; 3 lines introduced by that patch start > with XXX here for clarity (appropriately defined ): Interesting, I didn't know that. Jack's on holiday now, so he won't be able to comment for a while. > I have no idea what Mac C libraries return for text-mode reads. They must > convert \r to \n, right? Yes. > In which case I guess any \r remaining *should* be > "an error" (but where would it come from, if the C library converts all \r > thingies?). Do they leave \n alone? Nope: \r's get translated to \n and for whatever reason \n's get translated to \r... So when opening a unix file on the Mac, it will look like it has \r line endings and when opening a Windows text file on the Mac, it will appear as if it has \n\r line endings... > Etc: submit a patch that makes the > code above "work", and I'm sure it would be accepted, but a non-Mac person > can't guess what's needed. That's probably easy enough -- although would require changing all tokenizer code that looks for \n to also look for \r, including PyOS_ReadLine(), so it goes well beyond the snippet you posted. And then there's the Python file object... Just From stefan.witzgall@online.de Wed Apr 11 11:47:38 2001 From: stefan.witzgall@online.de (Stefan Witzgall) Date: Wed, 11 Apr 2001 12:47:38 +0200 Subject: [Pythonmac-SIG] errors of every kind w/ MacPython 2.0, 2.1xx, MacOS 8.1 Message-ID: Here sits a poor user (the bug himself ;-?) and tries to bring his MacPython into a usable, stable (!) condition. I am running Mac OS 8.1 on my PMac (601 CPU) and have installed all the versions of MacPython lying around, except 1.5c2. To say it: 2.0, 2.1b1, 2.1b2. The latter I configured as "Classic". Now I'm running into errors of every kind when trying the examples. - example0 of the Mac demos gave me an error 1 when starting up (-> MacsBug) - example1 (dnslookup) seems to work. (Both with 2.0 and 2.1b1) - The tkinter example brownian starts up with a so long traceback ... - Other tkinter files start up, show there frame and the buttons, but when clicking a button they crash -> MacsBug, error 11 (so often). - Other tkinter files are running: Hanoi, electrons, draw. Frustrating, "using" MacPython such way makes not much sense. So I'm asking for help: - Is there a way to configure my system w/ MP so this will work fine? - Could anyone recommend a version of MP, even older, that will run smooth? - Are there Python scripts w/ or w/o tkinter that do a more then trivial job and run fine with at least one of the MP versions? Stefan From fgranger@altern.org Wed Apr 11 15:51:51 2001 From: fgranger@altern.org (Francois Granger) Date: Wed, 11 Apr 2001 16:51:51 +0200 Subject: [Pythonmac-SIG] errors of every kind w/ MacPython 2.0, 2.1xx, MacOS 8.1 In-Reply-To: Message-ID: on 11/04/01 12:47, Stefan Witzgall at stefan.witzgall@online.de wrote: > Here sits a poor user (the bug himself ;-?) and tries to bring his > MacPython into a usable, stable (!) condition. At first, I would say that with error 1 and 11, it is a "reinstall the system" situation. Anyway, I don't remember using Python on 8.1 so, I'll give it a try at home when I get 5 minute. For me, MacPython from 1.5.x up to the latest 2.1bx have proven very stable for the last 2 years. But I never used Tkinter, up to now. From owen@astro.washington.edu Wed Apr 11 17:09:48 2001 From: owen@astro.washington.edu (Russell E Owen) Date: Wed, 11 Apr 2001 09:09:48 -0700 Subject: [Pythonmac-SIG] errors of every kind w/ MacPython 2.0, 2.1xx, MacOS 8.1 In-Reply-To: References: Message-ID: >Here sits a poor user (the bug himself ;-?) and tries to bring his >MacPython into a usable, stable (!) condition. > >I am running Mac OS 8.1 on my PMac (601 CPU) and have installed all the >versions of MacPython lying around, except 1.5c2. To say it: 2.0, 2.1b1, >2.1b2. I suspect that 2.0 is not compatible with Mac OS 8.1. Certainly you'd have to install AppearanceLib, which may be installed as part of Carbon (from the ReadMe). Your best bet would be to run 1.5c2 or to upgrade your Mac OS to 8.6 and install Carbon. Note that 1.5c2 does not install Tkinter quite correctly -- a bit of tweaking of the paths is required to get Python to see it. Aside from that, it's very stable and works great. All you lose are the nice additions in 2.0. Note also that Tkinter does not work very well in 2.1b2 (you typically have to "force exit" Tk applications to get them to quit and file events are broken in 2.0 and 2.1b2). -- Russell From Benjamin.Schollnick@usa.xerox.com Wed Apr 11 18:04:48 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Wed, 11 Apr 2001 13:04:48 -0400 Subject: [Pythonmac-SIG] Python Mega Widgets Message-ID: Has anyone used PMW (Python Mega Widgets) under Python v2.0x on the Mac? I'm running into some weird stuff.... The PMWLOADER file doesn't seem to want to run... And I had to modify the __INIT__.py file in the root directory because the internal logic didn't seem to be working nicely on the Mac... - Benjamin From delza@alliances.org Thu Apr 12 00:21:07 2001 From: delza@alliances.org (Dethe Elza) Date: Wed, 11 Apr 2001 16:21:07 -0700 Subject: [Pythonmac-SIG] Binary for mxDateTime? Message-ID: Hi folks, Just returning to the Mac after a long absence, picked up Python in the meantime, and I'm not trying to resolve the two. I've got a script which runs on Windows/Linux OK and I'm trying to run in on my new mac, but it requires mxDateTime. The install for mxBase includes shared libraries built for the Mac, but they don't seem to work. I've tried installing them all through the tree, and adding them to the python path. Finally it occured to me that they were probably built for Python 1.5.x and I'm running Python 2.0 (tried the 2.1 beta but had troubles with Tkinter under carbon, switched to classic and had troubles with Pmw). So, does anyone have binaries of the mxDateTime (etc.) extension types built for Python 2.0 on OS 9? TIA --Dethe Dethe Elza Chief Mad Scientist Burning Tiger Technologies From greg@cosc.canterbury.ac.nz Thu Apr 12 00:44:01 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Thu, 12 Apr 2001 11:44:01 +1200 (NZST) Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do In-Reply-To: <20010411120330-r01010600-75da8509@213.84.27.177> Message-ID: <200104112344.LAA12806@s454.cosc.canterbury.ac.nz> end-of-line conversion? Just van Rossum : > Tim Peters wrote: > > I have no idea what Mac C libraries return for text-mode reads. They must > > convert \r to \n, right? > Yes. Unless you're using the MPW compiler, which swaps the meanings of \r and \n in the source instead! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From tim.one@home.com Thu Apr 12 01:14:19 2001 From: tim.one@home.com (Tim Peters) Date: Wed, 11 Apr 2001 20:14:19 -0400 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <20010411120330-r01010600-75da8509@213.84.27.177> Message-ID: [Just van Rossum] > Nope: \r's get translated to \n and for whatever reason \n's get > translated to \r... So when opening a unix file on the Mac, it > will look like it has \r line endings and when opening a Windows > text file on the Mac, it will appear as if it has \n\r line endings... Then it's probably a Good Thing Jack disabled this code, since it wouldn't have done anything useful on a Mac anyway (for Python to ever see \r\n the source file would have had to contain \n\r, which is nobody's text file convention). >> Etc: submit a patch that makes the code above "work", and I'm >> sure it would be accepted, but a non-Mac person can't guess >> what's needed. > That's probably easy enough -- although would require changing all > tokenizer code that looks for \n to also look for \r, including > PyOS_ReadLine(), so it goes well beyond the snippet you posted. No, there's nothing wrong with the tokenizer code: it's coded in C, and the C text convention is that lines end with \n, period. Reliance on that convention is ubiquitous -- and properly so. What we need instead are platform-specific implementations of fgets() functionality, which deliver lines containing \n where and only where the platform Python is supposed to believe a line ends. Then nothing else in the parser needs to be touched (and, indeed, the current \r\n mini-hack could be thrown away). > And then there's the Python file object... Different issue. If this ever gets that far, note that the crunch to speed up line-at-a-time file input ended up *requiring* use of the native fgets() on Windows, as that was the only way on that platform to avoid having the OS do layers of expensive multithreading locks for each character read. So there's no efficient way in general to get Windows to recognize \r line endings short of implementing our own stdio from the ground up. On other platforms, fileobject.c's get_line() reads one character at a time, and I expect its test for "is this an EOL char?" could be liberalized at reasonable cost. OTOH, how does the new-fangled Mac OS fit into all this? Perhaps, for compatibility, their C libraries already recognize both Unix and Mac Classic line conventions, and deliver plain \n endings for both? Or did they blow that part too ? From guido@digicool.com Thu Apr 12 03:21:36 2001 From: guido@digicool.com (Guido van Rossum) Date: Wed, 11 Apr 2001 21:21:36 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Wed, 11 Apr 2001 20:14:19 -0400." References: Message-ID: <200104120221.VAA14315@cj20424-a.reston1.va.home.com> > Different issue. If this ever gets that far, note that the crunch > to speed up line-at-a-time file input ended up *requiring* use of > the native fgets() on Windows, as that was the only way on that > platform to avoid having the OS do layers of expensive > multithreading locks for each character read. So there's no > efficient way in general to get Windows to recognize \r line endings > short of implementing our own stdio from the ground up. On other > platforms, fileobject.c's get_line() reads one character at a time, > and I expect its test for "is this an EOL char?" could be > liberalized at reasonable cost. I expect that the right solution here is indeed to write our own stdio-like library from the ground up. That can solve any number of problems: telling how many characters are buffered (so you don't have to use unbuffered mode when using select or poll), platform-independent line end recognition, and super-efficient readline() to boot. But it's a lot of work, and won't be compatible with existing extensions that use FILE* (not too many I believe). --Guido van Rossum (home page: http://www.python.org/~guido/) From stefan.witzgall@online.de Thu Apr 12 07:27:59 2001 From: stefan.witzgall@online.de (Stefan Witzgall) Date: Thu, 12 Apr 2001 08:27:59 +0200 Subject: [Pythonmac-SIG] Now installed 1.5.2c1, less problems Message-ID: Was [Pythonmac-SIG] errors of every kind w/ MacPython 2.0, ... OK, now I have installed 4(!) versions of MacPython on my machine (you remember: a Mac OS 8.1 running PMac). The version now installed is 1.5.2c1. I have less problems, tkinter runs after the known hacks. Electrons are fine, Brownian in the Mac example folder causes problems as it does with the newer versions, seems to be a Pythonian problem. ped and the waste examples do not start up, the interpreter falls into "quiet mode", but no error. And a little astonishing, the following code doesn't work with 2.x (please do not ask what version exactly or what fault. So many versions ... ;-) but runs under the 1.5.2c1 interpreter: ---------------snip---------------- # File: hello2.py from Tkinter import * class App: def __init__(self, master): frame = Frame(master) frame.pack() self.button = Button(frame, text="QUIT", fg="red", command=frame.quit) self.button.pack(side=LEFT) self.hi_there = Button(frame, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) def say_hi(self): print "hi there, everyone!" root = Tk() app = App(root) root.mainloop() ---------------snap---------------- So far so good. But: What broke the newer version of MP on my machine? Kept it uptodate (Appearance and so on) as far as it was possible for 8.1 i think. Stefan From tim.one@home.com Thu Apr 12 07:41:20 2001 From: tim.one@home.com (Tim Peters) Date: Thu, 12 Apr 2001 02:41:20 -0400 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <200104120221.VAA14315@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > I expect that the right solution here is indeed to write our own > stdio-like library from the ground up. That can solve any number of > problems: telling how many characters are buffered (so you don't have > to use unbuffered mode when using select or poll), platform- > independent line end recognition, and super-efficient readline() > to boot. We also have the old http://sourceforge.net/tracker/?group_id=5470& atid=105470&func=detail&aid=210821 complaining that use of FILE* in our C API can make it impossible to (in that fellow's case) write an app in Borland C++ on Windows that tries to use those API functions (cuz Borland's FILE* is incompatible with MS's FILE*). I'm not sure the best solution to *that* is to give them a FILE* that's incompatible with everyone's, though > > But it's a lot of work, and won't be compatible with existing > extensions that use FILE* (not too many I believe). I'm more concerned about the "lot of work" part, with which I agree. OTOH, Plauger's book "The Standard C Library" contains source code for every library required by C89. He reported that implementing libm took him twice as long as everything else combined. But those who haven't written a libm will be prone to take a wrong lesson from that . it's-not-that-i/o-is-easy-despite-that-his-libm-code-isn't-production- quality-ly y'rs - tim From just@letterror.com Thu Apr 12 09:03:33 2001 From: just@letterror.com (Just van Rossum) Date: Thu, 12 Apr 2001 10:03:33 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Message-ID: <20010412100334-r01010600-5b54bb95@213.84.27.177> Tim Peters wrote: > No, there's nothing wrong with the tokenizer code: it's coded in C, and the > C text convention is that lines end with \n, period. Reliance on that > convention is ubiquitous -- and properly so. I don't get it: why would a thin layer on top of stdio be bad? Seems much less work than reimplementing stdio. Just From christian@rocketnetwork.com Thu Apr 12 20:59:12 2001 From: christian@rocketnetwork.com (Christian Reyes) Date: Thu, 12 Apr 2001 12:59:12 -0700 Subject: [Pythonmac-SIG] calling a python script from Applescript In-Reply-To: <20010412100334-r01010600-5b54bb95@213.84.27.177> Message-ID: Can someone help me out here? I'm trying to call a python script from AppleScript? Is this possible? TIA, christian From guido@digicool.com Thu Apr 12 23:37:09 2001 From: guido@digicool.com (Guido van Rossum) Date: Thu, 12 Apr 2001 17:37:09 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Thu, 12 Apr 2001 10:03:33 +0200." <20010412100334-r01010600-5b54bb95@213.84.27.177> References: <20010412100334-r01010600-5b54bb95@213.84.27.177> Message-ID: <200104122237.RAA21755@cj20424-a.reston1.va.home.com> > I don't get it: why would a thin layer on top of stdio be bad? Seems > much less work than reimplementing stdio. Because by layering stuff you lose performance. Example: fgets() is often implemented in a way that is faster than you can ever do yourself with portable code. (Because fgets() can peek in the buffer and see if there's a \n somewhere ahead, using memcmp() -- and if this succeeds, it can use memcpy(). You can't do that yourself - only the stdio implementation can. And this is not a hypothetical situation -- Tim used fgets() for a significant speed-up of readline() in 2.1. But if we want to use our own line end convention, we can't use fgets() any more, so we lose big. --Guido van Rossum (home page: http://www.python.org/~guido/) From sdm7g@Virginia.EDU Thu Apr 12 23:08:50 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Thu, 12 Apr 2001 18:08:50 -0400 (EDT) Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <200104122237.RAA21755@cj20424-a.reston1.va.home.com> Message-ID: [ re: various remarks about layering on stdio ] Has anybody looked at sfio ? I used it long ago for other reasons -- for a while the distribution seemed to have disappeared from att ( or maybe I just couldn't find it on netlib ), but I just did a google search and found that there is a new distribution: sfio2000: http://www.research.att.com/sw/tools/sfio/ I haven't looked at the package or the code for a LONG time & I don't know how portable it is, but it has some nice features and advantages -- if you're at the point of considering rewriting stdio it might be worth looking at. -- Steve Majewski From billb@mousa.demon.co.uk Fri Apr 13 00:14:32 2001 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Fri, 13 Apr 2001 00:14:32 +0100 Subject: [Pythonmac-SIG] calling a python script from AppleScript In-Reply-To: References: Message-ID: <498951572349908042474@mousa.demon.co.uk> At 12:59 pm -0700 12/04/01, Christian Reyes wrote: >Can someone help me out here? >I'm trying to call a python script from AppleScript? You tell the finder to open the python file -- it is just the same as clicking in the icon. -- Bill Bedford One of the universal rules of happiness is: always be wary of any helpful item that weighs less than its operating manual. From tim.one@home.com Fri Apr 13 02:00:08 2001 From: tim.one@home.com (Tim Peters) Date: Thu, 12 Apr 2001 21:00:08 -0400 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Message-ID: [Steven D. Majewski] > Has anybody looked at sfio ? > ... > http://www.research.att.com/sw/tools/sfio/ Did just now. Only runs on Unix boxes, so would be a heavyweight way to solve line-end problems across platforms that don't have any . Possible to run it on Windows, but only on top of the commercial UWIN Unix emulation package (http://www.research.att.com/sw/tools/uwin/). They didn't mention Macs at all. The papers should be worth reading for anyone intending to tackle this, though. From tim.one@home.com Fri Apr 13 08:12:05 2001 From: tim.one@home.com (Tim Peters) Date: Fri, 13 Apr 2001 03:12:05 -0400 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <20010412100334-r01010600-5b54bb95@213.84.27.177> Message-ID: [Tim] > No, there's nothing wrong with the tokenizer code: it's coded > in C, and the C text convention is that lines end with \n, period. > Reliance on that convention is ubiquitous -- and properly so. [Just van Rossum] > I don't get it: why would a thin layer on top of stdio be bad? > Seems much less work than reimplementing stdio. What does that question have to do with the snippet you quoted? In context, that snippet was saying that if you did write a small layer on top of stdio, one that just made \n show up when and only when you think Python should believe a line ends, then nothing in the tokenizer would need to change (except to call that layer instead of fgets()), and even the tokenizer's current \r\n mini-hack could be thrown away. If that's all you want, that's all it takes. If you want more than just that, you need more than just that (but I see Guido already explained that, and I explained too why the Windows Python cannot recognize \r endings with reasonable speed for *general* use short of building our own stdio -- but I don't really much care how fast the compiler runs, if all you want is the same limited level of hack afforded by the existing one-shot \r\n tokenizer trick -- and the compiler isn't using the *general*-case fileobject.c get_line() anyway). you-pay-for-what-you-want-and-the-more-you-want-the-more-you'll-pay-ly y'rs - tim From tim.one@home.com Fri Apr 13 08:40:47 2001 From: tim.one@home.com (Tim Peters) Date: Fri, 13 Apr 2001 03:40:47 -0400 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <200104122237.RAA21755@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > ... > But if we want to use our own line end convention, we can't use > fgets() any more, so we lose big. Well, people said "we couldn't" use fgets() for get_line() either, because Python strings can contain embedded nulls but fgets() doesn't tell you how many bytes it read and makes up null bytes of its own. But I have 200 lines of excruciating code in fileobject.c that proved them excruciatingly wrong . The same kind of excruciating crap could almost certainly be used to search for alternative line endings on top of fgets() too. We would have to layer our own buffer on top of the hidden platform buffer to get away with this, because while fgets() will stop at the first \n it sees, there's no way to ask it to stop at any other character (so in general fgets() would "over-read" when looking for a non-native line-end, and we'd have to save the excess in our own buffer). Hard to say how much that would cost. I think it surprised everyone (incl. me!) that even with all the extra buffer-filling and buffer-searching the fgets() hackery does, that method was at worst a wash with the getc_unlocked() method on all platforms tried. In any case, the fgets() hack is only *needed* on Windows, so every other platform could just make get_line()'s character-at-a-time loop search for more end conditions. This can't be impossible . s/\r\n?/\n/g-ly y'rs - tim From just@letterror.com Fri Apr 13 10:43:21 2001 From: just@letterror.com (Just van Rossum) Date: Fri, 13 Apr 2001 11:43:21 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Message-ID: <20010413114324-r01010600-54b4467f@213.84.27.177> I understand now that I simply don't have enough clue about the implementation to even try to be involved with this. Unless it makes sense to have a PEP that doesn't touch the implementation at all (doubtful, IMHO), I'll take back my offer to write one. I still think it's an important issue, but it's simply beyond what I can deal with. To solve the issues on MacOS X, maybe it's enough to hack the Carbon version of stdio so it can handle unix text files. That way we can simply settle for unix line ending if sharing code between BSD Python and Carbon Python is desired. At the same time this would allow using CVS under Darwin for MacPython sources, which is something I look forward to... Just From mal@lemburg.com Fri Apr 13 12:09:09 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 13 Apr 2001 13:09:09 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: <20010413114324-r01010600-54b4467f@213.84.27.177> Message-ID: <3AD6DE54.ED351E8E@lemburg.com> Just van Rossum wrote: > > I understand now that I simply don't have enough clue about the implementation > to even try to be involved with this. Unless it makes sense to have a PEP that > doesn't touch the implementation at all (doubtful, IMHO), I'll take back my > offer to write one. I still think it's an important issue, but it's simply > beyond what I can deal with. Please write the results of this discussion up as a PEP. PEPs don't necessarily have to provide an implementation of what is covered; it sometimes simply suffices to start out with a summary of the discussions that have been going on. Then someone may pick up the threads from there and possibly find a solution which will then get implemented. > To solve the issues on MacOS X, maybe it's enough to hack the Carbon version of > stdio so it can handle unix text files. That way we can simply settle for unix > line ending if sharing code between BSD Python and Carbon Python is desired. At > the same time this would allow using CVS under Darwin for MacPython sources, > which is something I look forward to... AFAIR, this discussion was about handling line endings in Python source code. There have been discussions about turning the tokenizer into a Unicode based machine. We could then use the Unicode tools to do line separations. I don't know why this thread lead to tweaking stdio -- after all we only need a solution for the Python tokenizer and not a general purpose stdio abstraction of text files unless I'm missing something here... -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From just@letterror.com Fri Apr 13 12:43:25 2001 From: just@letterror.com (Just van Rossum) Date: Fri, 13 Apr 2001 13:43:25 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <3AD6DE54.ED351E8E@lemburg.com> Message-ID: <20010413134326-r01010600-bafaee65@213.84.27.177> M.-A. Lemburg wrote: > I don't know why this thread lead to tweaking stdio -- after all > we only need a solution for the Python tokenizer and not a general > purpose stdio abstraction of text files unless I'm missing something > here... Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all, but then what about all tools that read source files line by line? Eg. linecache.py, all IDE's, etc. etc. As Tim wrote a while back: importing-is-only-the-start-of-the-battle So no, we don't "only need a solution for the Python tokenizer"... Just From aahz@rahul.net Fri Apr 13 14:13:22 2001 From: aahz@rahul.net (Aahz Maruch) Date: Fri, 13 Apr 2001 06:13:22 -0700 (PDT) Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <20010413134326-r01010600-bafaee65@213.84.27.177> from "Just van Rossum" at Apr 13, 2001 01:43:25 PM Message-ID: <20010413131323.6358899C97@waltz.rahul.net> Just van Rossum wrote: > M.-A. Lemburg wrote: > >> I don't know why this thread lead to tweaking stdio -- after all >> we only need a solution for the Python tokenizer and not a general >> purpose stdio abstraction of text files unless I'm missing something >> here... > > Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all, > but then what about all tools that read source files line by line? Eg. > linecache.py, all IDE's, etc. etc. I'll repeat my question of yesterday: is there any reason why we couldn't start with QIO? I did some checking after I sent that out, and QIO claims that it can be configured to recognize different kinds of line endings. QIO is claimed to be 2-3 times faster than Python 1.5.2; don't know how that compares to 2.x. [the previous message was sent to python-dev only; this time I'm including pythonmac-sig] -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 http://www.rahul.net/aahz Androgynous poly kinky vanilla queer het I don't really mind a person having the last whine, but I do mind someone else having the last self-righteous whine. From guido@digicool.com Fri Apr 13 15:52:35 2001 From: guido@digicool.com (Guido van Rossum) Date: Fri, 13 Apr 2001 09:52:35 -0500 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Your message of "Fri, 13 Apr 2001 06:13:22 MST." <20010413131323.6358899C97@waltz.rahul.net> References: <20010413131323.6358899C97@waltz.rahul.net> Message-ID: <200104131452.JAA27545@cj20424-a.reston1.va.home.com> > I'll repeat my question of yesterday: is there any reason why we > couldn't start with QIO? I did some checking after I sent that out, and > QIO claims that it can be configured to recognize different kinds of > line endings. QIO is claimed to be 2-3 times faster than Python 1.5.2; > don't know how that compares to 2.x. >From a one-minute review it looks like as good a start as any! --Guido van Rossum (home page: http://www.python.org/~guido/) From chrishbarker@home.net Fri Apr 13 19:20:32 2001 From: chrishbarker@home.net (Chris Barker) Date: Fri, 13 Apr 2001 11:20:32 -0700 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: <20010413114324-r01010600-54b4467f@213.84.27.177> <3AD6DE54.ED351E8E@lemburg.com> Message-ID: <3AD74370.2EF0614C@home.net> "M.-A. Lemburg" wrote: > Please write the results of this discussion up as a PEP. PEPs don't > necessarily have to provide an implementation of what is covered; > it sometimes simply suffices to start out with a summary of the > discussions that have been going on. Then someone may pick up the > threads from there and possibly find a solution which will then > get implemented. Just, I second that. I really think this is a very useful improvement to Python, I'd I'd really like to see it happen. I am probably even more out of my depth than you when it comes to suggesting impimentation, but I'd be glad to help with any parts of a PEP that I can. Guido van Rossum wrote: > > I'll repeat my question of yesterday: is there any reason why we > > couldn't start with QIO? I did some checking after I sent that out, and > > QIO claims that it can be configured to recognize different kinds of > > line endings. QIO is claimed to be 2-3 times faster than Python 1.5.2; > > don't know how that compares to 2.x. > > >From a one-minute review it looks like as good a start as any! Great! I have to say that it really seemed that someone must have produced an open source solution to this problem somewhere, and it turns out there is something Python related already. -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From tim.one@home.com Fri Apr 13 23:39:46 2001 From: tim.one@home.com (Tim Peters) Date: Fri, 13 Apr 2001 18:39:46 -0400 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <20010413134326-r01010600-bafaee65@213.84.27.177> Message-ID: [MAL] > I don't know why this thread lead to tweaking stdio -- after all > we only need a solution for the Python tokenizer ... [Just] > Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is > great and all,> but then what about all tools that read source > files line by line? ... Note that this is why the topic needs a PEP: nothing here is new; the same debates reoccur every time it comes up. [Aahz] > ... > QIO claims that it can be configured to recognize different > kinds of line endings. It can be, yes, but in the same sense as Awk/Perl paragraph mode: you can tell it to consider any string (not just single character) as meaning "end of the line", but it's a *fixed* string per invocation. What people want *here* is more the ability to recognize the regular expression \r\n?|\n as ending a line, and QIO can't do that directly (as currently written). And MAL probably wants Unicode line-end detection: http://www.unicode.org/unicode/reports/tr13/ > QIO is claimed to be 2-3 times faster than Python 1.5.2; don't > know how that compares to 2.x. The bulk of that was due to QIO avoiding per-character thread locks. 2.1 avoids them too, so most of QIO's speed advantage should be gone now. But QIO's internals could certainly be faster than they are (this is obscure because QIO.readline() has so many optional behaviors that the maze of if-tests makes it hard to see the speed-crucial bits; studying Perl's line-reading code is a better model, because Perl's speed-crucial inner loop has no non-essential operations -- Perl makes the *surrounding* code sort out the optional bits, instead of bogging down the loop with them). From mal@lemburg.com Sat Apr 14 17:43:20 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 14 Apr 2001 18:43:20 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: <20010413134326-r01010600-bafaee65@213.84.27.177> Message-ID: <3AD87E28.CCC894AC@lemburg.com> Just van Rossum wrote: > > M.-A. Lemburg wrote: > > > I don't know why this thread lead to tweaking stdio -- after all > > we only need a solution for the Python tokenizer and not a general > > purpose stdio abstraction of text files unless I'm missing something > > here... > > Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is great and all, > but then what about all tools that read source files line by line? Eg. > linecache.py, all IDE's, etc. etc. As Tim wrote a while back: > > importing-is-only-the-start-of-the-battle > > So no, we don't "only need a solution for the Python tokenizer"... See... that's why we need a PEP on these things ;-) Seriously, I thought that you were only talking about being able to work on Python code from different platforms in a network (e.g. code is shared by a Windows box and development takes place on a Mac). Now it seems that you want to go for the full Monty :-) -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Apr 14 18:02:09 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 14 Apr 2001 19:02:09 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? References: Message-ID: <3AD88291.8A82378@lemburg.com> Tim Peters wrote: > > [MAL] > > I don't know why this thread lead to tweaking stdio -- after all > > we only need a solution for the Python tokenizer ... > > [Just] > > Aaaaaaaaaaaargh! ;-) Here we go again: fixing the tokenizer is > > great and all,> but then what about all tools that read source > > files line by line? ... > > Note that this is why the topic needs a PEP: nothing here is new; the same > debates reoccur every time it comes up. Right. > [Aahz] > > ... > > QIO claims that it can be configured to recognize different > > kinds of line endings. > > It can be, yes, but in the same sense as Awk/Perl paragraph mode: you can > tell it to consider any string (not just single character) as meaning "end of > the line", but it's a *fixed* string per invocation. What people want *here* > is more the ability to recognize the regular expression > > \r\n?|\n > > as ending a line, and QIO can't do that directly (as currently written). And > MAL probably wants Unicode line-end detection: > > http://www.unicode.org/unicode/reports/tr13/ Right ;-) > > QIO is claimed to be 2-3 times faster than Python 1.5.2; don't > > know how that compares to 2.x. > > The bulk of that was due to QIO avoiding per-character thread locks. 2.1 > avoids them too, so most of QIO's speed advantage should be gone now. But > QIO's internals could certainly be faster than they are (this is obscure > because QIO.readline() has so many optional behaviors that the maze of > if-tests makes it hard to see the speed-crucial bits; studying Perl's > line-reading code is a better model, because Perl's speed-crucial inner loop > has no non-essential operations -- Perl makes the *surrounding* code sort out > the optional bits, instead of bogging down the loop with them). Just curious: for the applications which Just has in mind, reading source code line-by-line is not really needed. Wouldn't it suffice to read the whole file, split it into lines and then let the tools process the resulting list of lines ? Maybe a naive approach, but one which will most certainly work on all platforms without having to replace stdio... -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From just@letterror.com Sat Apr 14 18:24:44 2001 From: just@letterror.com (Just van Rossum) Date: Sat, 14 Apr 2001 19:24:44 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <3AD87E28.CCC894AC@lemburg.com> Message-ID: <20010414192445-r01010600-f8273ce6@213.84.27.177> M.-A. Lemburg wrote: > > So no, we don't "only need a solution for the Python tokenizer"... > > See... that's why we need a PEP on these things ;-) Agreed. I'll try to write one, once I'm feeling better: having the flu doesn't seem to help focussing on actual content... Just From richard@richardgordon.net Sat Apr 14 18:44:41 2001 From: richard@richardgordon.net (Richard Gordon) Date: Sat, 14 Apr 2001 13:44:41 -0400 Subject: [Pythonmac-SIG] about this x-platform stuff... Message-ID: I have been following the thread about line endings with some interest and wanted to ask about a companion issue that I fight with on a regular basis- path separators for different platforms. Is there a generally accepted approach for adjusting these on the fly in python (i.e., I write a script on Mac and then try to run it on unix where it craps out because of the use of : rather than / as a separator)? It seems like the perl approach was to use some variable and actually write the script with this: infile = 'thisdir'.theSep.'thatdir'.theSep.'otherdir'.theSep.'myfile'; The script would at some point test for OS and set the variable to /, \ or : according to the results and, in theory, you never had to worry about it aside from the fact that the code was even more illegible than usual. Is there a more elegant way to deal with this in python? Thanks. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From just@letterror.com Sat Apr 14 18:54:54 2001 From: just@letterror.com (Just van Rossum) Date: Sat, 14 Apr 2001 19:54:54 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: <3AD88291.8A82378@lemburg.com> Message-ID: <20010414195455-r01010600-bf420a02@213.84.27.177> M.-A. Lemburg wrote: > Just curious: for the applications which Just has in mind, > reading source code line-by-line is not really needed. Wouldn't > it suffice to read the whole file, split it into lines and then > let the tools process the resulting list of lines ? > > Maybe a naive approach, but one which will most certainly work > on all platforms without having to replace stdio... The point is to let existing tools work with all line end conventions *without* changing the tools. Whether this means replacing stdio I still don't know , but it sure means changing the behavior of the Python file object in text mode. Just From cwebster@nevada.edu Sat Apr 14 19:53:28 2001 From: cwebster@nevada.edu (Corran Webster) Date: Sat, 14 Apr 2001 11:53:28 -0700 Subject: [Pythonmac-SIG] about this x-platform stuff... In-Reply-To: References: Message-ID: At 1:44 PM -0400 14/4/01, Richard Gordon wrote: >I have been following the thread about line endings with some >interest and wanted to ask about a companion issue that I fight with >on a regular basis- path separators for different platforms. > >Is there a generally accepted approach for adjusting these on the >fly in python (i.e., I write a script on Mac and then try to run it >on unix where it craps out because of the use of : rather than / as >a separator)? It seems like the perl approach was to use some >variable and actually write the script with this: >infile = 'thisdir'.theSep.'thatdir'.theSep.'otherdir'.theSep.'myfile'; >The script would at some point test for OS and set the variable to >/, \ or : according to the results and, in theory, you never had to >worry about it aside from the fact that the code was even more >illegible than usual. > >Is there a more elegant way to deal with this in python? Thanks. The os and os.path modules are what you want, I suspect. For example infile = os.path.join('thisdir', 'thatdir', 'otherdir', 'myfile') will do the equivalent of what you describe, inserting the correct separator in the appropriate places on different platforms. Similarly os.path.split will correctly split off the filename from the end of a path. os.path.abspath converts a relative path to an absolute path, and os.path.normpath normalises the path, removing unneeded parts. There are a bunch of other useful functions in os.path. The variable os.sep holds the standard separator for the platform if you need to get at it directly, but be careful that obvious things like: ['thisdir', 'thatdir', 'otherdir', 'myfile'].join(os.sep) are not cross-platform. This is a relative path on unix and an absolute path on the mac, for example. You may find some routines in the url and urlparse module useful as well. Regards, Corran From richard@richardgordon.net Sat Apr 14 21:41:38 2001 From: richard@richardgordon.net (Richard Gordon) Date: Sat, 14 Apr 2001 16:41:38 -0400 Subject: [Pythonmac-SIG] about this x-platform stuff... In-Reply-To: References: Message-ID: hi Corran & thanks for the reply. >The os and os.path modules are what you want, I suspect. For example > >infile = os.path.join('thisdir', 'thatdir', 'otherdir', 'myfile') > >will do the equivalent of what you describe, inserting the correct >separator in the appropriate places on different platforms. ok, that's only a little clunky and certainly better than trying to use an inline variable to form the path string. I'll keep this in mind. >The variable os.sep holds the standard separator for the platform if >you need to get at it directly, but be careful that obvious things >like: > >['thisdir', 'thatdir', 'otherdir', 'myfile'].join(os.sep) > >are not cross-platform. This is a relative path on unix and an >absolute path on the mac, for example. sigh. >You may find some routines in the url and urlparse module useful as well. I'll have a look. Thanks again. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From tony.mcdonald@ncl.ac.uk Sun Apr 15 12:08:11 2001 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Sun, 15 Apr 2001 12:08:11 +0100 Subject: [Pythonmac-SIG] Python on OS X: Multiple definitions of symbols In-Reply-To: <20010410031144.IYVF24361.tomts7-srv.bellnexxia.net@localhost> Message-ID: On 10/4/01 4:09 am, "Tim Lahey" wrote: > All, > > I built the latest beta of Python (2.1b2a) using: > ./configure --with-dyld --with-suffix=.x > make > sudo make install > > Next, I download pyobjc.so from sourceforge. That imports fine. I then > download and > compile PyXML and when I try and run the tests: > > [localhost:python/PyXML-0.6.5/test] tjlahey% python test_howto.py > SAX tests: > > dyld: python multiple definitions of symbol _main > python definition of _main > /usr/local/lib/python2.1/site-packages/_xmlplus/parsers/pyexpat.so > definition of _main > > Does anyone know how to fix these multiple definition of symbol > problems? I've had this > kind of problem with Numeric on OS X and I can't seem to figure out how > to fix this. > > Thanks, > > Tim Lahey This is very similar to the problem I had with MySQLdb, here's the gist of my problem, [localhost:~/software/MySQL-python-0.3.5] tonymcd% python Python 2.0 (#3, 10/22/00, 12:04:10) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> import MySQLdb dyld: python multiple definitions of symbol _strtol /System/Library/Frameworks/System.framework/Versions/B/System(strtol.o) definition of _strtol /usr/local/lib/python2.0/site-packages/_mysql.so definition of _strtol Note that my Python is a binary release by Steve Majewski (who's on this list :), ie [localhost:/usr/local] tonymcd% more MacOSX-Darwin-Python2.0-README Python2.0 final built for MacOSX or Darwin1.2 with dyld shared library support including optional modules: bsddb, readline, zlib, pyexpat, and under X11: tkinter and pygtk Files are intended to go in /usr/local/bin and /usr/local/lib/python2.0. assuming you have write permission, cd to /usr/local and untar -- Steve Majewski In the end I managed to get MySQLdb to work by removing the _strtol library from mysqlclient.a. This is what I posted to the python news group. > There was an interesting thread on this at > http://forums.macnn.com/cgi-bin/Forum34/HTML/000284.html > (the answer is from bobDalgeish) ,and following the information I > managed to get it to work in the end. > > Essentially get rid of the strto.o entry (which has strtol in it) in > libmysqlclient.a and ranlib it, ie > > % sudo ar -dv libmysqlclient.a strto.o > % sudo ranlib libmysqlclient.a > > Then recompile up MySQLdb and reinstall it (make sure you remove the old > stuff first). I'm having exactly the same problem with pyexpat on OS X (from the PyXML distribution), and haven't managed to get this to work. I know theres a pyexpat in Steves distribution). I must admit to being a bit out of my depth here...I'm definitely getting confused with the OS X Darwin-Python, Carbonised MacPython and the OS 9 Python implementations. Until recently, it was simple, I did some things like testing XML code on my Python 2.0 OS 9 implementation as the IDE helped a lot and things like MySQL on my Python 1.5.2 Solaris implementation, because there were no libraries available - now things are much more interesting! - but there's a new learning curve :) Tone -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope From evil_ivan@yahoo.com Sun Apr 15 19:00:37 2001 From: evil_ivan@yahoo.com (Phil Christensen) Date: Sun, 15 Apr 2001 11:00:37 -0700 (PDT) Subject: [Pythonmac-SIG] asyncore and IDE Message-ID: <20010415180037.4625.qmail@web11606.mail.yahoo.com> i've been using the Python IDE to develop a asyncore-based sever program. Whenever I call asyncore.loop(), of course, it hangs the program.... of course, Python Interpreter works fine, but doesn't have the great debugging abilities of the IDE.... is there any way to use the IDE for this? I've tried putting the asyncore.loop() call in a separate thread, and it keeps it from hanging, but doesn't seem to be actually working.... -phil __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From just@letterror.com Sun Apr 15 19:11:06 2001 From: just@letterror.com (Just van Rossum) Date: Sun, 15 Apr 2001 20:11:06 +0200 Subject: [Pythonmac-SIG] asyncore and IDE Message-ID: <20010415201109-r01010600-6991cdd3@213.84.27.177> Phil Christensen wrote: > i've been using the Python IDE to develop a asyncore-based sever > program. Whenever I call asyncore.loop(), of course, it hangs the > program.... > > of course, Python Interpreter works fine, but doesn't have the great > debugging abilities of the IDE.... > > is there any way to use the IDE for this? I've tried putting the > asyncore.loop() call in a separate thread, and it keeps it from > hanging, > but doesn't seem to be actually working.... I have done this successfully by registring asyncore.poll as an idle callback to the IDE. This is pretty much undocumented (I might have even invented that mechanism especialloy _for_ asyncore, I forgot...), so I'll dig it up for you. [search, search...] Ok, here's what you do: import W app = W.getapplication() app.addidlefunc(myidlefunc) # in your case: asyncore.poll You can remove an idle func with app.removeidlefunc(myidlefunc) (If an idle callback raises an excption, a traceback is printed to the output window, and the callback is removed from the idle func list. For details, see Wapplication.py.) It worked fairly nicely with asyncore! Just From dma@andrew.cmu.edu Tue Apr 17 17:54:27 2001 From: dma@andrew.cmu.edu (David Andersen) Date: Tue, 17 Apr 2001 12:54:27 -0400 Subject: [Pythonmac-SIG] tkSimpleDialog In-Reply-To: Message-ID: <3964556236.987512067@DAWSON.PC.CC.CMU.EDU> On my Mac (PythonMac 2.0, MacOS 9.0) the "tkSimpleDialog" library / demo in Python 2.0/Lib/lib-tk does not work correctly. The "askinteger" dialog plots the entry box in the same position as the text (row 0 rather than row 1). However the mouse acts as if the entry box were correctly positioned - if I click below the entry box the cursor moves to the corresponding position in the entry box and I can enter or change the value. From chrishbarker@home.net Tue Apr 17 18:52:58 2001 From: chrishbarker@home.net (Chris Barker) Date: Tue, 17 Apr 2001 10:52:58 -0700 Subject: [Pythonmac-SIG] Automating running a sequence of programs References: <20000831084330.D3FFF303181@snelboot.oratrix.nl> Message-ID: <3ADC82FA.E53F2D1B@home.net> Hi all, I need to have a way to automate a sequence of programs running, something along the idea of: create config file run program A run Program B (using a file created by program A) repeat as needed I've tried using findertools.launch, and it mostly works, but I get some long pauses, and I got an appleevent timeout errot (or something like that) on one test run. I think the trick here is that I need the programs to finish running before I run the next one. That does not appear to be happening. I think the programs I'm running lock up the system enough that it sort of works but isn't reliable. So I think my question is: How can a launch antoher program and then wait for it to finish before I do something else? or: How else can I do this? -Thanks, -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From fgranger@altern.org Tue Apr 17 23:02:20 2001 From: fgranger@altern.org (Francois Granger) Date: Wed, 18 Apr 2001 00:02:20 +0200 Subject: [Pythonmac-SIG] Automating running a sequence of programs In-Reply-To: <3ADC82FA.E53F2D1B@home.net> References: <20000831084330.D3FFF303181@snelboot.oratrix.nl> <3ADC82FA.E53F2D1B@home.net> Message-ID: --============_-1224577438==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:52 -0700 17/04/01, in message [Pythonmac-SIG] Automating running a sequence of progr, Chris Barker wrote: >Hi all, > > >I need to have a way to automate a sequence of programs running, >something along the idea of: > >create config file >run program A >run Program B (using a file created by program A) >repeat as needed > >I've tried using findertools.launch, and it mostly works, but I get some >long pauses, and I got an appleevent timeout errot (or something like >that) on one test run. I think the trick here is that I need the >programs to finish running before I run the next one. That does not >appear to be happening. I think the programs I'm running lock up the >system enough that it sort of works but isn't reliable. > >So I think my question is: > >How can a launch antoher program and then wait for it to finish before I >do something else? Have a look to "More findertools" it should be in Mac:Contrib. I enclose in case. It can check for processes. This may be all you need ?? --============_-1224577438==_============ Content-Id: Content-Type: multipart/appledouble; boundary="============_-1224577438==_D============" --============_-1224577438==_D============ Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="%morefindertools.py" Content-Disposition: attachment; filename="%morefindertools.py" ; modification-date="Tue, 10 Oct 2000 09:26:35 +0200" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAADAAAASgAAABIAAAAJAAAAXAAAACAA AAAIAAAAfAAAABAAAAACAAAAjAAAAgNtb3JlZmluZGVydG9vbHMucHlURVhUUGlkZQEA AAAAAQAAAAAAAAAAAAAAAAAAAAAAAABpjzwBdZ1LS20MAAJvloIAAAEAAAABwQAAAMEA AABCAAWSBgdqYW5pY2UyAAWZ7QdqYW5pY2UyDQAABZIGB2phbmljZTMABZn0B2phbmlj ZTMNAAAFkgYHamFuaWNlNAAFmf0HamFuaWNlNA4AAAWSBghqZW5uaWZlci4ABZoICGpl bm5pZmVyAAoAAAWSBgRqaWxsZQAFmhAEamlsbAAMAAAFkgYGSmlzZWxZMgAFmiMGSmlz ZWxZAA0AAAWSBgdKb2xpbmRhAAWaLQdKb2xpbmRhCgAABZIGBGthcmFfAAWaMwRrYXJh AAkAAAWSBgNraWEABZo4A2tpYQwAAAWSBgZrb29rb29kAAWaPAZrAAAAvXtzBwAAAHRh YnNpemUoAgAAAGkIAAAAaQEAAABzDAAAAGZvbnRzZXR0aW5ncygEAAAAcwsAAABQeXRo b24tU2Fuc2kAAAAAaQkAAAAoAwAAAGkAAAAAaQAAAABpAAAAAHMMAAAAd2luZG93Ym91 bmRzKAQAAABpCgEAAGlJAAAAaSAEAABpNQMAAHMLAAAAcnVuX2FzX21haW5pAAAAAHMJ AAAAc2VsZWN0aW9uKAIAAABpywIAAGnLAgAAMAAAAQAAAAHBAAAAwQAAAEIPZq2wBGYA AAAcADIAAFB5V1MAAAAKAIAAAAAAAAAPdgfED3dpbmRvdyBzZXR0aW5ncw== --============_-1224577438==_D============ Content-Type: application/octet-stream; name="morefindertools.py" Content-Disposition: attachment; filename="morefindertools.py" Content-Transfer-Encoding: base64 IiIiVXRpbGl0eSByb3V0aW5lcyBkZXBlbmRpbmcgb24gdGhlIGZpbmRlciwNaW5zcGly ZWQgYnkgZmluZGVydG9vbHMsIGJ1dCBleHRlbmRlZC4NTW9zdCBldmVudHMgaGF2ZSBi ZWVuIGNhcHR1cmVkIGZyb20NTGFzc28gQ2FwdHVyZSBBRSBhbmQgdGhhbiB0cmFuc2xh dGVkIHRvIHB5dGhvbiBjb2RlLg0NSU1QT1JUQU5UDU5vdGUgdGhhdCB0aGUgcHJvY2Vz c2VzKCkgZnVuY3Rpb24gcmV0dXJucyBkaWZmZXJlbnQgdmFsdWVzDWRlcGVuZGluZyBv biB0aGUgT1MgdmVyc2lvbiBpdCBpcyBydW5uaW5nIG9uLiBPbiBNYWNPUyA5DXRoZSBG aW5kZXIgcmV0dXJucyB0aGUgcHJvY2VzcyAqbmFtZXMqIHdoaWNoIGNhbiB0aGVuIGJl DXVzZWQgdG8gZmluZCBvdXQgbW9yZSBhYm91dCB0aGVtLiBPbiBNYWNPUyA4LjYgYW5k IGVhcmxpZXINdGhlIEZpbmRlciByZXR1cm5zIGEgY29kZSB3aGljaCBkb2VzIG5vdCBz ZWVtIHRvIHdvcmsuDVNvIGJvdHRvbSBsaW5lOiB0aGUgcHJvY2Vzc2VzKCkgc3R1ZmYg ZG9lcyBub3Qgd29yayBvbiA8IE1hY09TOQ0NV3JpdHRlbiBieSBlcmlrQGxldHRlcnJv ci5jb20NIiIiDQ1pbXBvcnQgRmluZGVyXzdfMF9TdWl0ZSwgRmluZGVyX1N1aXRlDWlt cG9ydCBBcHBsZUV2ZW50cw1pbXBvcnQgYWV0b29scw1pbXBvcnQgTWFjT1MNaW1wb3J0 IHN5cw1pbXBvcnQgbWFjZnMNaW1wb3J0IGFldHlwZXMNZnJvbSB0eXBlcyBpbXBvcnQg Kg0NX192ZXJzaW9uX18gPSAnMS4wJw1tb3JlZmluZGVydG9vbHNlcnJvciA9ICdtb3Jl ZmluZGVydG9vbHMgRXJyb3InDQ0NU0lHTkFUVVJFPSdNQUNTJw0NY2xhc3MgRmluZGVy KGFldG9vbHMuVGFsa1RvLCBGaW5kZXJfU3VpdGUuRmluZGVyX1N1aXRlLCBGaW5kZXJf N18wX1N1aXRlLkZpbmRlcl83XzBfU3VpdGUpOg0JcGFzcw0JDV9maW5kZXJfdGFsa2Vy ID0gTm9uZQ0NZGVmIF9nZXRmaW5kZXIoKToNCSIiInJldHVybnMgYmFzaWMgKHJlY3lj bGFibGUpIEZpbmRlciBBRSBpbnRlcmZhY2Ugb2JqZWN0IiIiDQlnbG9iYWwgX2ZpbmRl cl90YWxrZXINCWlmIG5vdCBfZmluZGVyX3RhbGtlcjoNCQlfZmluZGVyX3RhbGtlciA9 IEZpbmRlcihTSUdOQVRVUkUpDQlfZmluZGVyX3RhbGtlci5zZW5kX2ZsYWdzID0gKCBf ZmluZGVyX3RhbGtlci5zZW5kX2ZsYWdzIHwgDQkJQXBwbGVFdmVudHMua0FFQ2FuSW50 ZXJhY3QgfCBBcHBsZUV2ZW50cy5rQUVDYW5Td2l0Y2hMYXllcikNCXJldHVybiBfZmlu ZGVyX3RhbGtlcg0NDSMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NIwlUaGUgb3JpZ2luYWwgZmluZGVydG9vbHMNIw0NZGVmIGxh dW5jaChmaWxlKToNCSIiIk9wZW4gYSBmaWxlIHRocnUgdGhlIGZpbmRlci4gU3BlY2lm eSBmaWxlIGJ5IG5hbWUgb3IgZnNzcGVjIiIiDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkN CWZzcyA9IG1hY2ZzLkZTU3BlYyhmaWxlKQ0JdlJlZk51bSwgcGFySUQsIG5hbWUgPSBm c3MuYXNfdHVwbGUoKQ0JZGlyX2ZzcyA9IG1hY2ZzLkZTU3BlYygodlJlZk51bSwgcGFy SUQsICcnKSkNCWZpbGVfYWxpYXMgPSBmc3MuTmV3QWxpYXMoKQ0JZGlyX2FsaWFzID0g ZGlyX2Zzcy5OZXdBbGlhcygpDQlyZXR1cm4gZmluZGVyLm9wZW4oZGlyX2FsaWFzLCBp dGVtcz1bZmlsZV9hbGlhc10pDQkNZGVmIFByaW50KGZpbGUpOg0JIiIiUHJpbnQgYSBm aWxlIHRocnUgdGhlIGZpbmRlci4gU3BlY2lmeSBmaWxlIGJ5IG5hbWUgb3IgZnNzcGVj IiIiDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkNCWZzcyA9IG1hY2ZzLkZTU3BlYyhmaWxl KQ0JdlJlZk51bSwgcGFySUQsIG5hbWUgPSBmc3MuYXNfdHVwbGUoKQ0JZGlyX2ZzcyA9 IG1hY2ZzLkZTU3BlYygodlJlZk51bSwgcGFySUQsICcnKSkNCWZpbGVfYWxpYXMgPSBm c3MuTmV3QWxpYXMoKQ0JZGlyX2FsaWFzID0gZGlyX2Zzcy5OZXdBbGlhcygpDQlyZXR1 cm4gZmluZGVyLl9wcmludChkaXJfYWxpYXMsIGl0ZW1zPVtmaWxlX2FsaWFzXSkNCQ1k ZWYgY29weShzcmMsIGRzdGRpcik6DQkiIiJDb3B5IGEgZmlsZSB0byBhIGZvbGRlciIi Ig0JZmluZGVyID0gX2dldGZpbmRlcigpDQlzcmNfZnNzID0gbWFjZnMuRlNTcGVjKHNy YykNCWRzdF9mc3MgPSBtYWNmcy5GU1NwZWMoZHN0ZGlyKQ0Jc3JjX2FsaWFzID0gc3Jj X2Zzcy5OZXdBbGlhcygpDQlkc3RfYWxpYXMgPSBkc3RfZnNzLk5ld0FsaWFzKCkNCXJl dHVybiBmaW5kZXIuY29weV90byhkc3RfYWxpYXMsIF9mcm9tPVtzcmNfYWxpYXNdKQ0N ZGVmIG1vdmUoc3JjLCBkc3RkaXIpOg0JIiIiTW92ZSBhIGZpbGUgdG8gYSBmb2xkZXIi IiINCWZpbmRlciA9IF9nZXRmaW5kZXIoKQ0Jc3JjX2ZzcyA9IG1hY2ZzLkZTU3BlYyhz cmMpDQlkc3RfZnNzID0gbWFjZnMuRlNTcGVjKGRzdGRpcikNCXNyY19hbGlhcyA9IHNy Y19mc3MuTmV3QWxpYXMoKQ0JZHN0X2FsaWFzID0gZHN0X2Zzcy5OZXdBbGlhcygpDQly ZXR1cm4gZmluZGVyLm1vdmVfdG8oZHN0X2FsaWFzLCBfZnJvbT1bc3JjX2FsaWFzXSkN DWRlZiBzbGVlcCgpOg0JIiIiUHV0IHRoZSBtYWMgdG8gc2xlZXAiIiINCWZpbmRlciA9 IF9nZXRmaW5kZXIoKQ0JZmluZGVyLnNsZWVwKCkNCQ1kZWYgc2h1dGRvd24oKToNCSIi IlNodXQgdGhlIG1hYyBkb3duIiIiDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkNCWZpbmRl ci5zaHV0X2Rvd24oKQ0JDWRlZiByZXN0YXJ0KCk6DQkiIiJSZXN0YXJ0IHRoZSBtYWMi IiINCWZpbmRlciA9IF9nZXRmaW5kZXIoKQ0JZmluZGVyLnJlc3RhcnQoKQ0NDSMtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NIwlB ZGRpdGlvbmFsIGZpbmRlcnRvb2xzDSMNDWRlZiByZXZlYWwoZmlsZSk6DQkiIiJSZXZl YWwgYSBmaWxlIGluIHRoZSBmaW5kZXIuIFNwZWNpZnkgZmlsZSBieSBuYW1lIG9yIGZz c3BlYy4iIiINCWZpbmRlciA9IF9nZXRmaW5kZXIoKQ0JZnNzID0gbWFjZnMuRlNTcGVj KGZpbGUpDQlmaWxlX2FsaWFzID0gZnNzLk5ld0FsaWFzKCkNCXJldHVybiBmaW5kZXIu cmV2ZWFsKGZpbGVfYWxpYXMpDQkNZGVmIHNlbGVjdChmaWxlKToNCSIiInNlbGVjdCBh IGZpbGUgaW4gdGhlIGZpbmRlci4gU3BlY2lmeSBmaWxlIGJ5IG5hbWUgb3IgZnNzcGVj LiIiIg0JZmluZGVyID0gX2dldGZpbmRlcigpDQlmc3MgPSBtYWNmcy5GU1NwZWMoZmls ZSkNCWZpbGVfYWxpYXMgPSBmc3MuTmV3QWxpYXMoKQ0JcmV0dXJuIGZpbmRlci5zZWxl Y3QoZmlsZV9hbGlhcykNCQ1kZWYgdXBkYXRlKGZpbGUpOg0JIiIiVXBkYXRlIHRoZSBk aXNwbGF5IG9mIHRoZSBzcGVjaWZpZWQgb2JqZWN0KHMpIHRvIG1hdGNoIA0JdGhlaXIg b24tZGlzayByZXByZXNlbnRhdGlvbi4gU3BlY2lmeSBmaWxlIGJ5IG5hbWUgb3IgZnNz cGVjLiIiIg0JZmluZGVyID0gX2dldGZpbmRlcigpDQlmc3MgPSBtYWNmcy5GU1NwZWMo ZmlsZSkNCWZpbGVfYWxpYXMgPSBmc3MuTmV3QWxpYXMoKQ0JcmV0dXJuIGZpbmRlci51 cGRhdGUoZmlsZV9hbGlhcykNDQ0jLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDSMJTW9yZSBmaW5kZXJ0b29scw0jDQ1kZWYgY29t bWVudChvYmplY3QsIGNvbW1lbnQ9Tm9uZSk6DQkiIiJjb21tZW50OiBnZXQgb3Igc2V0 IHRoZSBGaW5kZXItY29tbWVudCBvZiB0aGUgaXRlbSwgZGlzcGxheWVkIGluIHRoZSDS R2V0IEluZm/TIHdpbmRvdy4iIiINCW9iamVjdCA9IG1hY2ZzLkZTU3BlYyhvYmplY3Qp DQlmc3MgPSBtYWNmcy5GU1NwZWMob2JqZWN0KQ0Jb2JqZWN0X2FsaWFzID0gZnNzLk5l d0FsaWFzKCkNCWlmIGNvbW1lbnQgPT0gTm9uZToNCQlyZXR1cm4gX2dldGNvbW1lbnQo b2JqZWN0X2FsaWFzKQ0JZWxzZToNCQlyZXR1cm4gX3NldGNvbW1lbnQob2JqZWN0X2Fs aWFzLCBjb21tZW50KQ0JDWRlZiBfc2V0Y29tbWVudChvYmplY3RfYWxpYXMsIGNvbW1l bnQpOg0JZmluZGVyID0gX2dldGZpbmRlcigpDQlhcmdzID0ge30NCWF0dHJzID0ge30N CWFlb2JqXzAwID0gYWV0eXBlcy5PYmplY3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5 cGUoJ2NvYmonKSwgZm9ybT0iYWxpcyIsIHNlbGQ9b2JqZWN0X2FsaWFzLCBmcj1Ob25l KQ0JYWVvYmpfMDEgPSBhZXR5cGVzLk9iamVjdFNwZWNpZmllcih3YW50PWFldHlwZXMu VHlwZSgncHJvcCcpLCBmb3JtPSJwcm9wIiwgc2VsZD1hZXR5cGVzLlR5cGUoJ2NvbXQn KSwgZnI9YWVvYmpfMDApDQlhcmdzWyctLS0tJ10gPSBhZW9ial8wMQ0JYXJnc1siZGF0 YSJdID0gY29tbWVudA0JX3JlcGx5LCBhcmdzLCBhdHRycyA9IGZpbmRlci5zZW5kKCJj b3JlIiwgInNldGQiLCBhcmdzLCBhdHRycykNCWlmIGFyZ3MuaGFzX2tleSgnZXJybicp Og0JCXJhaXNlIG1vcmVmaW5kZXJ0b29sc2Vycm9yLCBhZXRvb2xzLmRlY29kZWVycm9y KGFyZ3MpDQlpZiBhcmdzLmhhc19rZXkoJy0tLS0nKToNCQlyZXR1cm4gYXJnc1snLS0t LSddDQ1kZWYgX2dldGNvbW1lbnQob2JqZWN0X2FsaWFzKToNCWZpbmRlciA9IF9nZXRm aW5kZXIoKQ0JYXJncyA9IHt9DQlhdHRycyA9IHt9DQlhZW9ial8wMCA9IGFldHlwZXMu T2JqZWN0U3BlY2lmaWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdjb2JqJyksIGZvcm09ImFs aXMiLCBzZWxkPW9iamVjdF9hbGlhcywgZnI9Tm9uZSkNCWFlb2JqXzAxID0gYWV0eXBl cy5PYmplY3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5cGUoJ3Byb3AnKSwgZm9ybT0i cHJvcCIsIHNlbGQ9YWV0eXBlcy5UeXBlKCdjb210JyksIGZyPWFlb2JqXzAwKQ0JYXJn c1snLS0tLSddID0gYWVvYmpfMDENCV9yZXBseSwgYXJncywgYXR0cnMgPSBmaW5kZXIu c2VuZCgiY29yZSIsICJnZXRkIiwgYXJncywgYXR0cnMpDQlpZiBhcmdzLmhhc19rZXko J2Vycm4nKToNCQlyYWlzZSBtb3JlZmluZGVydG9vbHNlcnJvciwgYWV0b29scy5kZWNv ZGVlcnJvcihhcmdzKQ0JaWYgYXJncy5oYXNfa2V5KCctLS0tJyk6DQkJcmV0dXJuIGFy Z3NbJy0tLS0nXQ0NDSMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NIwlHZXQgaW5mb3JtYXRpb24gYWJvdXQgY3VycmVudCBwcm9j ZXNzZXMgaW4gdGhlIEZpbmRlci4NDWRlZiBwcm9jZXNzZXMoKToNCSIiInByb2Nlc3Nl cyByZXR1cm5zIGEgbGlzdCBvZiBhbGwgYWN0aXZlIHByb2Nlc3NlcyBydW5uaW5nIG9u IHRoaXMgY29tcHV0ZXIgYW5kIHRoZWlyIGNyZWF0b3JzLiIiIg0JZmluZGVyID0gX2dl dGZpbmRlcigpDQlhcmdzID0ge30NCWF0dHJzID0ge30NCXByb2Nlc3NuYW1lcyA9IFtd DQlwcm9jZXNzbnVtYmVycyA9IFtdDQljcmVhdG9ycyA9IFtdDQlwYXJ0aXRpb25zID0g W10NCXVzZWQgPSBbXQ0JIyMgZ2V0IHRoZSBwcm9jZXNzbmFtZXMgb3IgZWxzZSB0aGUg cHJvY2Vzc251bWJlcnMNCWFyZ3NbJy0tLS0nXSA9IGFldHlwZXMuT2JqZWN0U3BlY2lm aWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdwcmNzJyksIGZvcm09ImluZHgiLCBzZWxkPWFl dHlwZXMuVW5rbm93bignYWJzbycsICJhbGwgIiksIGZyPU5vbmUpDQlfcmVwbHksIGFy Z3MsIGF0dHJzID0gZmluZGVyLnNlbmQoJ2NvcmUnLCAnZ2V0ZCcsIGFyZ3MsIGF0dHJz KQ0JaWYgYXJncy5oYXNfa2V5KCdlcnJuJyk6DQkJcmFpc2UgbW9yZWZpbmRlcnRvb2xz ZXJyb3IsIGFldG9vbHMuZGVjb2RlZXJyb3IoYXJncykNCXAgPSBbXQ0JaWYgYXJncy5o YXNfa2V5KCctLS0tJyk6DQkJcCA9ICBhcmdzWyctLS0tJ10NCQlmb3IgcHJvYyBpbiBw Og0JCQlpZiBoYXNhdHRyKHByb2MsICdzZWxkJyk6DQkJCQkjIGl0IGhhcyBhIHJlYWwg bmFtZQ0JCQkJcHJvY2Vzc25hbWVzLmFwcGVuZChwcm9jLnNlbGQpDQkJCWVsaWYgaGFz YXR0cihwcm9jLCAndHlwZScpOg0JCQkJaWYgcHJvYy50eXBlID09ICJwc24gIjoNCQkJ CQkjIGl0IGhhcyBhIHByb2Nlc3MgbnVtYmVyDQkJCQkJcHJvY2Vzc251bWJlcnMuYXBw ZW5kKHByb2MuZGF0YSkNCSMjIGdldCB0aGUgY3JlYXRvcnMNCWFyZ3MgPSB7fQ0JYXR0 cnMgPSB7fQ0JYWVvYmpfMCA9IGFldHlwZXMuT2JqZWN0U3BlY2lmaWVyKHdhbnQ9YWV0 eXBlcy5UeXBlKCdwcmNzJyksIGZvcm09ImluZHgiLCBzZWxkPWFldHlwZXMuVW5rbm93 bignYWJzbycsICJhbGwgIiksIGZyPU5vbmUpDQlhcmdzWyctLS0tJ10gPSAgYWV0eXBl cy5PYmplY3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5cGUoJ3Byb3AnKSwgZm9ybT0i cHJvcCIsIHNlbGQ9YWV0eXBlcy5UeXBlKCdmY3J0JyksIGZyPWFlb2JqXzApDQlfcmVw bHksIGFyZ3MsIGF0dHJzID0gZmluZGVyLnNlbmQoJ2NvcmUnLCAnZ2V0ZCcsIGFyZ3Ms IGF0dHJzKQ0JaWYgYXJncy5oYXNfa2V5KCdlcnJuJyk6DQkJcmFpc2UgbW9yZWZpbmRl cnRvb2xzZXJyb3IsIGFldG9vbHMuZGVjb2RlZXJyb3IoX2FyZykNCWlmIGFyZ3MuaGFz X2tleSgnLS0tLScpOg0JCXAgPSAgYXJnc1snLS0tLSddDQkJZm9yIHByb2MgaW4gcDoN CQkJY3JlYXRvcnMuYXBwZW5kKHByb2MudHlwZSkNCSMjIGNvbmNhdGVuYXRlIGluIG9u ZSBkaWN0DQlyZXN1bHQgPSBbXQ0JaWYgbGVuKHByb2Nlc3NuYW1lcykgPiBsZW4ocHJv Y2Vzc251bWJlcnMpOg0JCWRhdGEgPSBwcm9jZXNzbmFtZXMNCWVsc2U6DQkJZGF0YSA9 IHByb2Nlc3NudW1iZXJzDQlmb3IgaSBpbiByYW5nZShsZW4oY3JlYXRvcnMpKToNCQly ZXN1bHQuYXBwZW5kKChkYXRhW2ldLCBjcmVhdG9yc1tpXSkpDQlyZXR1cm4gcmVzdWx0 DQ1jbGFzcyBfcHJvY2VzczoNCXBhc3MNDWRlZiBpc2FjdGl2ZXByb2Nlc3MocHJvY2Vz c25hbWUpOg0JIiIiQ2hlY2sgb2YgcHJvY2Vzc25hbWUgaXMgYWN0aXZlLiBNYWNPUzki IiINCWFsbCA9IHByb2Nlc3NlcygpDQlvayA9IDANCWZvciBuLCBjIGluIGFsbDoNCQlp ZiBuID09IHByb2Nlc3NuYW1lOg0JCQlyZXR1cm4gMQ0JcmV0dXJuIDANCQ1kZWYgcHJv Y2Vzc2luZm8ocHJvY2Vzc25hbWUpOg0JIiIiUmV0dXJuIGFuIG9iamVjdCB3aXRoIGFs bCBwcm9jZXNzIHByb3BlcnRpZXMgYXMgYXR0cmlidXRlcyBmb3IgcHJvY2Vzc25hbWUu IE1hY09TOSIiIg0JcCA9IF9wcm9jZXNzKCkNCQ0JaWYgcHJvY2Vzc25hbWUgPT0gIkZp bmRlciI6DQkJcC5wYXJ0aXRpb24gPSBOb25lDQkJcC51c2VkID0gTm9uZQ0JZWxzZToN CQlwLnBhcnRpdGlvbiA9IF9wcm9jZXNzcHJvcGVydHkocHJvY2Vzc25hbWUsICdhcHB0 JykNCQlwLnVzZWQgPSBfcHJvY2Vzc3Byb3BlcnR5KHByb2Nlc3NuYW1lLCAncHVzZCcp DQlwLnZpc2libGUgPSBfcHJvY2Vzc3Byb3BlcnR5KHByb2Nlc3NuYW1lLCAncHZpcycp CQkjSXMgdGhlIHByb2Nlc3MnIGxheWVyIHZpc2libGU/DQlwLmZyb250bW9zdCA9IF9w cm9jZXNzcHJvcGVydHkocHJvY2Vzc25hbWUsICdwaXNmJykJI0lzIHRoZSBwcm9jZXNz IHRoZSBmcm9udG1vc3QgcHJvY2Vzcz8NCXAuZmlsZSA9IF9wcm9jZXNzcHJvcGVydHko cHJvY2Vzc25hbWUsICdmaWxlJykJCQkjdGhlIGZpbGUgZnJvbSB3aGljaCB0aGUgcHJv Y2VzcyB3YXMgbGF1bmNoZWQNCXAuZmlsZXR5cGUgID0gX3Byb2Nlc3Nwcm9wZXJ0eShw cm9jZXNzbmFtZSwgJ2FzdHknKQkJI3RoZSBPU1R5cGUgb2YgdGhlIGZpbGUgdHlwZSBv ZiB0aGUgcHJvY2Vzcw0JcC5jcmVhdG9ydHlwZSA9IF9wcm9jZXNzcHJvcGVydHkocHJv Y2Vzc25hbWUsICdmY3J0JykJI3RoZSBPU1R5cGUgb2YgdGhlIGNyZWF0b3Igb2YgdGhl IHByb2Nlc3MgKHRoZSBzaWduYXR1cmUpDQlwLmFjY2VwdGhpZ2hsZXZlbCA9IF9wcm9j ZXNzcHJvcGVydHkocHJvY2Vzc25hbWUsICdyZXZ0JykJI0lzIHRoZSBwcm9jZXNzIGhp Z2gtbGV2ZWwgZXZlbnQgYXdhcmUgKGFjY2VwdHMgb3BlbiBhcHBsaWNhdGlvbiwgb3Bl biBkb2N1bWVudCwgcHJpbnQgZG9jdW1lbnQsIGFuZCBxdWl0KT8NCXAuaGFzc2NyaXB0 aW5nID0gX3Byb2Nlc3Nwcm9wZXJ0eShwcm9jZXNzbmFtZSwgJ2hzY3InKQkJI0RvZXMg dGhlIHByb2Nlc3MgaGF2ZSBhIHNjcmlwdGluZyB0ZXJtaW5vbG9neSwgaS5lLiwgY2Fu IGl0IGJlIHNjcmlwdGVkPw0JcmV0dXJuIHANCQ1kZWYgX3Byb2Nlc3Nwcm9wZXJ0eShw cm9jZXNzbmFtZSwgcHJvcGVydHkpOg0JIiIicmV0dXJuIHRoZSBwYXJ0aXRpb24gc2l6 ZSBhbmQgbWVtb3J5IHVzZWQgZm9yIHByb2Nlc3NuYW1lIiIiDQlmaW5kZXIgPSBfZ2V0 ZmluZGVyKCkNCWFyZ3MgPSB7fQ0JYXR0cnMgPSB7fQ0JYWVvYmpfMDAgPSBhZXR5cGVz Lk9iamVjdFNwZWNpZmllcih3YW50PWFldHlwZXMuVHlwZSgncHJjcycpLCBmb3JtPSJu YW1lIiwgc2VsZD1wcm9jZXNzbmFtZSwgZnI9Tm9uZSkNCWFlb2JqXzAxID0gYWV0eXBl cy5PYmplY3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5cGUoJ3Byb3AnKSwgZm9ybT0i cHJvcCIsIHNlbGQ9YWV0eXBlcy5UeXBlKHByb3BlcnR5KSwgZnI9YWVvYmpfMDApDQlh cmdzWyctLS0tJ10gPSBhZW9ial8wMQ0JX3JlcGx5LCBhcmdzLCBhdHRycyA9IGZpbmRl ci5zZW5kKCJjb3JlIiwgImdldGQiLCBhcmdzLCBhdHRycykNCWlmIGFyZ3MuaGFzX2tl eSgnZXJybicpOg0JCXJhaXNlIG1vcmVmaW5kZXJ0b29sc2Vycm9yLCBhZXRvb2xzLmRl Y29kZWVycm9yKGFyZ3MpDQlpZiBhcmdzLmhhc19rZXkoJy0tLS0nKToNCQlyZXR1cm4g YXJnc1snLS0tLSddDQ0NIy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0jCU1lc3MgYXJvdW5kIHdpdGggRmluZGVyIHdpbmRvd3Mu DQkNZGVmIG9wZW53aW5kb3cob2JqZWN0KToNCSIiIk9wZW4gYSBGaW5kZXIgd2luZG93 IGZvciBvYmplY3QsIFNwZWNpZnkgb2JqZWN0IGJ5IG5hbWUgb3IgZnNzcGVjLiIiIg0J ZmluZGVyID0gX2dldGZpbmRlcigpDQlvYmplY3QgPSBtYWNmcy5GU1NwZWMob2JqZWN0 KQ0JZnNzID0gbWFjZnMuRlNTcGVjKG9iamVjdCkNCW9iamVjdF9hbGlhcyA9IGZzcy5O ZXdBbGlhcygpDQlhcmdzID0ge30NCWF0dHJzID0ge30NCV9jb2RlID0gJ2FldnQnDQlf c3ViY29kZSA9ICdvZG9jJw0JYWVvYmpfMCA9IGFldHlwZXMuT2JqZWN0U3BlY2lmaWVy KHdhbnQ9YWV0eXBlcy5UeXBlKCdjZm9sJyksIGZvcm09ImFsaXMiLCBzZWxkPW9iamVj dF9hbGlhcywgZnI9Tm9uZSkNCWFyZ3NbJy0tLS0nXSA9IGFlb2JqXzANCV9yZXBseSwg YXJncywgYXR0cnMgPSBmaW5kZXIuc2VuZChfY29kZSwgX3N1YmNvZGUsIGFyZ3MsIGF0 dHJzKQ0JaWYgYXJncy5oYXNfa2V5KCdlcnJuJyk6DQkJcmFpc2UgbW9yZWZpbmRlcnRv b2xzZXJyb3IsIGFldG9vbHMuZGVjb2RlZXJyb3IoYXJncykNCQ1kZWYgY2xvc2V3aW5k b3cob2JqZWN0KToNCSIiIkNsb3NlIGEgRmluZGVyIHdpbmRvdyBmb3IgZm9sZGVyLCBT cGVjaWZ5IGJ5IHBhdGguIiIiDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkNCWZzcyA9IG1h Y2ZzLkZTU3BlYyhvYmplY3QpDQlvYmplY3RfYWxpYXMgPSBmc3MuTmV3QWxpYXMoKQ0J YXJncyA9IHt9DQlhdHRycyA9IHt9DQlfY29kZSA9ICdjb3JlJw0JX3N1YmNvZGUgPSAn Y2xvcycNCWFlb2JqXzAgPSBhZXR5cGVzLk9iamVjdFNwZWNpZmllcih3YW50PWFldHlw ZXMuVHlwZSgnY2ZvbCcpLCBmb3JtPSJhbGlzIiwgc2VsZD1vYmplY3RfYWxpYXMsIGZy PU5vbmUpDQlhcmdzWyctLS0tJ10gPSBhZW9ial8wDQlfcmVwbHksIGFyZ3MsIGF0dHJz ID0gZmluZGVyLnNlbmQoX2NvZGUsIF9zdWJjb2RlLCBhcmdzLCBhdHRycykNCWlmIGFy Z3MuaGFzX2tleSgnZXJybicpOg0JCXJhaXNlIG1vcmVmaW5kZXJ0b29sc2Vycm9yLCBh ZXRvb2xzLmRlY29kZWVycm9yKGFyZ3MpDQ1kZWYgbG9jYXRpb24ob2JqZWN0LCBwb3M9 Tm9uZSk6DQkiIiJTZXQgdGhlIHBvc2l0aW9uIG9mIGEgRmluZGVyIHdpbmRvdyBmb3Ig Zm9sZGVyIHRvIHBvcz0odywgaCkuIFNwZWNpZnkgZmlsZSBieSBuYW1lIG9yIGZzc3Bl Yy4NCUlmIHBvcz1Ob25lLCBsb2NhdGlvbiB3aWxsIHJldHVybiB0aGUgY3VycmVudCBw b3NpdGlvbiBvZiB0aGUgb2JqZWN0LiIiIg0JZnNzID0gbWFjZnMuRlNTcGVjKG9iamVj dCkNCW9iamVjdF9hbGlhcyA9IGZzcy5OZXdBbGlhcygpDQlpZiBub3QgcG9zOg0JCXJl dHVybiBfZ2V0bG9jYXRpb24ob2JqZWN0X2FsaWFzKQ0JcmV0dXJuIF9zZXRsb2NhdGlv bihvYmplY3RfYWxpYXMsIHBvcykNCQ1kZWYgX3NldGxvY2F0aW9uKG9iamVjdF9hbGlh cywgKHgsIHkpKToNCSIiIl9zZXRsb2NhdGlvbjogU2V0IHRoZSBsb2NhdGlvbiBvZiB0 aGUgaWNvbiBmb3IgdGhlIG9iamVjdC4iIiINCWZpbmRlciA9IF9nZXRmaW5kZXIoKQ0J YXJncyA9IHt9DQlhdHRycyA9IHt9DQlhZW9ial8wMCA9IGFldHlwZXMuT2JqZWN0U3Bl Y2lmaWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdjZm9sJyksIGZvcm09ImFsaXMiLCBzZWxk PW9iamVjdF9hbGlhcywgZnI9Tm9uZSkNCWFlb2JqXzAxID0gYWV0eXBlcy5PYmplY3RT cGVjaWZpZXIod2FudD1hZXR5cGVzLlR5cGUoJ3Byb3AnKSwgZm9ybT0icHJvcCIsIHNl bGQ9YWV0eXBlcy5UeXBlKCdwb3NuJyksIGZyPWFlb2JqXzAwKQ0JYXJnc1snLS0tLSdd ID0gYWVvYmpfMDENCWFyZ3NbImRhdGEiXSA9IFt4LCB5XQ0JX3JlcGx5LCBhcmdzLCBh dHRycyA9IGZpbmRlci5zZW5kKCJjb3JlIiwgInNldGQiLCBhcmdzLCBhdHRycykNCWlm IGFyZ3MuaGFzX2tleSgnZXJybicpOg0JCXJhaXNlIG1vcmVmaW5kZXJ0b29sc2Vycm9y LCBhZXRvb2xzLmRlY29kZWVycm9yKGFyZ3MpDQlyZXR1cm4gKHgseSkNCQ1kZWYgX2dl dGxvY2F0aW9uKG9iamVjdF9hbGlhcyk6DQkiIiJfZ2V0bG9jYXRpb246IGdldCB0aGUg bG9jYXRpb24gb2YgdGhlIGljb24gZm9yIHRoZSBvYmplY3QuIiIiDQlmaW5kZXIgPSBf Z2V0ZmluZGVyKCkNCWFyZ3MgPSB7fQ0JYXR0cnMgPSB7fQ0JYWVvYmpfMDAgPSBhZXR5 cGVzLk9iamVjdFNwZWNpZmllcih3YW50PWFldHlwZXMuVHlwZSgnY2ZvbCcpLCBmb3Jt PSJhbGlzIiwgc2VsZD1vYmplY3RfYWxpYXMsIGZyPU5vbmUpDQlhZW9ial8wMSA9IGFl dHlwZXMuT2JqZWN0U3BlY2lmaWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdwcm9wJyksIGZv cm09InByb3AiLCBzZWxkPWFldHlwZXMuVHlwZSgncG9zbicpLCBmcj1hZW9ial8wMCkN CWFyZ3NbJy0tLS0nXSA9IGFlb2JqXzAxDQlfcmVwbHksIGFyZ3MsIGF0dHJzID0gZmlu ZGVyLnNlbmQoImNvcmUiLCAiZ2V0ZCIsIGFyZ3MsIGF0dHJzKQ0JaWYgYXJncy5oYXNf a2V5KCdlcnJuJyk6DQkJcmFpc2UgbW9yZWZpbmRlcnRvb2xzZXJyb3IsIGFldG9vbHMu ZGVjb2RlZXJyb3IoYXJncykNCWlmIGFyZ3MuaGFzX2tleSgnLS0tLScpOg0JCXBvcyA9 IGFyZ3NbJy0tLS0nXQ0JCXJldHVybiBwb3MuaCwgcG9zLnYNDWRlZiBsYWJlbChvYmpl Y3QsIGluZGV4PU5vbmUpOg0JIiIibGFiZWw6IHNldCBvciBnZXQgdGhlIGxhYmVsIG9m IHRoZSBpdGVtLiBTcGVjaWZ5IGZpbGUgYnkgbmFtZSBvciBmc3NwZWMuIiIiDQlmc3Mg PSBtYWNmcy5GU1NwZWMob2JqZWN0KQ0Jb2JqZWN0X2FsaWFzID0gZnNzLk5ld0FsaWFz KCkNCWlmIGluZGV4ID09IE5vbmU6DQkJcmV0dXJuIF9nZXRsYWJlbChvYmplY3RfYWxp YXMpDQlpZiBpbmRleCA8IDAgb3IgaW5kZXggPiA3Og0JCWluZGV4ID0gMA0JcmV0dXJu IF9zZXRsYWJlbChvYmplY3RfYWxpYXMsIGluZGV4KQ0JDWRlZiBfZ2V0bGFiZWwob2Jq ZWN0X2FsaWFzKToNCSIiImxhYmVsOiBHZXQgdGhlIGxhYmVsIGZvciB0aGUgb2JqZWN0 LiIiIg0JZmluZGVyID0gX2dldGZpbmRlcigpDQlhcmdzID0ge30NCWF0dHJzID0ge30N CWFlb2JqXzAwID0gYWV0eXBlcy5PYmplY3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5 cGUoJ2NvYmonKSwgZm9ybT0iYWxpcyIsIHNlbGQ9b2JqZWN0X2FsaWFzLCBmcj1Ob25l KQ0JYWVvYmpfMDEgPSBhZXR5cGVzLk9iamVjdFNwZWNpZmllcih3YW50PWFldHlwZXMu VHlwZSgncHJvcCcpLCBmb3JtPSJwcm9wIiwgc2VsZD1hZXR5cGVzLlR5cGUoJ2xhYmkn KSwgZnI9YWVvYmpfMDApDQlhcmdzWyctLS0tJ10gPSBhZW9ial8wMQ0JX3JlcGx5LCBh cmdzLCBhdHRycyA9IGZpbmRlci5zZW5kKCJjb3JlIiwgImdldGQiLCBhcmdzLCBhdHRy cykNCWlmIGFyZ3MuaGFzX2tleSgnZXJybicpOg0JCXJhaXNlIG1vcmVmaW5kZXJ0b29s c2Vycm9yLCBhZXRvb2xzLmRlY29kZWVycm9yKGFyZ3MpDQlpZiBhcmdzLmhhc19rZXko Jy0tLS0nKToNCQlyZXR1cm4gYXJnc1snLS0tLSddDQ1kZWYgX3NldGxhYmVsKG9iamVj dF9hbGlhcywgaW5kZXgpOg0JIiIibGFiZWw6IFNldCB0aGUgbGFiZWwgZm9yIHRoZSBv YmplY3QuIiIiDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkNCWFyZ3MgPSB7fQ0JYXR0cnMg PSB7fQ0JX2NvZGUgPSAnY29yZScNCV9zdWJjb2RlID0gJ3NldGQnDQlhZW9ial8wID0g YWV0eXBlcy5PYmplY3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5cGUoJ3Byb3AnKSwN CQkJZm9ybT0iYWxpcyIsIHNlbGQ9b2JqZWN0X2FsaWFzLCBmcj1Ob25lKQ0JYWVvYmpf MSA9IGFldHlwZXMuT2JqZWN0U3BlY2lmaWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdwcm9w JyksDQkJCWZvcm09InByb3AiLCBzZWxkPWFldHlwZXMuVHlwZSgnbGFiaScpLCBmcj1h ZW9ial8wKQ0JYXJnc1snLS0tLSddID0gYWVvYmpfMQ0JYXJnc1siZGF0YSJdID0gaW5k ZXgNCV9yZXBseSwgYXJncywgYXR0cnMgPSBmaW5kZXIuc2VuZChfY29kZSwgX3N1YmNv ZGUsIGFyZ3MsIGF0dHJzKQ0JaWYgYXJncy5oYXNfa2V5KCdlcnJuJyk6DQkJcmFpc2Ug bW9yZWZpbmRlcnRvb2xzZXJyb3IsIGFldG9vbHMuZGVjb2RlZXJyb3IoYXJncykNCXJl dHVybiBpbmRleA0NZGVmIHdpbmRvd3ZpZXcoZm9sZGVyLCB2aWV3PU5vbmUpOg0JIiIi d2luZG93dmlldzogU2V0IHRoZSB2aWV3IG9mIHRoZSB3aW5kb3cgZm9yIHRoZSBmb2xk ZXIuIFNwZWNpZnkgZmlsZSBieSBuYW1lIG9yIGZzc3BlYy4NCTAgPSBieSBpY29uIChk ZWZhdWx0KQ0JMSA9IGJ5IG5hbWUNCTIgPSBieSBidXR0b24NCSIiIg0JZnNzID0gbWFj ZnMuRlNTcGVjKGZvbGRlcikNCWZvbGRlcl9hbGlhcyA9IGZzcy5OZXdBbGlhcygpDQlp ZiB2aWV3ID09IE5vbmU6DQkJcmV0dXJuIF9nZXR3aW5kb3d2aWV3KGZvbGRlcl9hbGlh cykNCXJldHVybiBfc2V0d2luZG93dmlldyhmb2xkZXJfYWxpYXMsIHZpZXcpDQkNZGVm IF9zZXR3aW5kb3d2aWV3KGZvbGRlcl9hbGlhcywgdmlldz0wKToNCSIiInNldCB0aGUg d2luZG93dmlldyIiIg0JYXR0cnMgPSB7fQ0JYXJncyA9IHt9DQlpZiB2aWV3ID09IDE6 DQkJX3YgPSBhZXR5cGVzLlR5cGUoJ3BuYW0nKQ0JZWxpZiB2aWV3ID09IDI6DQkJX3Yg PSBhZXR5cGVzLlR5cGUoJ2xnYnUnKQ0JZWxzZToNCQlfdiA9IGFldHlwZXMuVHlwZSgn aWltZycpDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkNCWFlb2JqXzAgPSBhZXR5cGVzLk9i amVjdFNwZWNpZmllcih3YW50ID0gYWV0eXBlcy5UeXBlKCdjZm9sJyksIA0JCQlmb3Jt ID0gJ2FsaXMnLCBzZWxkID0gZm9sZGVyX2FsaWFzLCBmcj1Ob25lKQ0JYWVvYmpfMSA9 IGFldHlwZXMuT2JqZWN0U3BlY2lmaWVyKHdhbnQgPSBhZXR5cGVzLlR5cGUoJ3Byb3An KSwgDQkJCWZvcm0gPSAncHJvcCcsIHNlbGQgPSBhZXR5cGVzLlR5cGUoJ2N3bmQnKSwg ZnI9YWVvYmpfMCkNCWFlb2JqXzIgPSBhZXR5cGVzLk9iamVjdFNwZWNpZmllcih3YW50 ID0gYWV0eXBlcy5UeXBlKCdwcm9wJyksIA0JCQlmb3JtID0gJ3Byb3AnLCBzZWxkID0g YWV0eXBlcy5UeXBlKCdwdmV3JyksIGZyPWFlb2JqXzEpDQlhZW9ial8zID0gYWV0eXBl cy5PYmplY3RTcGVjaWZpZXIod2FudCA9IGFldHlwZXMuVHlwZSgncHJvcCcpLCANCQkJ Zm9ybSA9ICdwcm9wJywgc2VsZCA9IF92LCBmcj1Ob25lKQ0JX2NvZGUgPSAnY29yZScN CV9zdWJjb2RlID0gJ3NldGQnDQlhcmdzWyctLS0tJ10gPSBhZW9ial8yDQlhcmdzWydk YXRhJ10gPSBhZW9ial8zDQlfcmVwbHksIGFyZ3MsIGF0dHJzID0gZmluZGVyLnNlbmQo X2NvZGUsIF9zdWJjb2RlLCBhcmdzLCBhdHRycykNCWlmIGFyZ3MuaGFzX2tleSgnZXJy bicpOg0JCXJhaXNlIG1vcmVmaW5kZXJ0b29sc2Vycm9yLCBhZXRvb2xzLmRlY29kZWVy cm9yKGFyZ3MpDQlpZiBhcmdzLmhhc19rZXkoJy0tLS0nKToNCQlyZXR1cm4gYXJnc1sn LS0tLSddDQ1kZWYgX2dldHdpbmRvd3ZpZXcoZm9sZGVyX2FsaWFzKToNCSIiImdldCB0 aGUgd2luZG93dmlldyIiIg0JYXR0cnMgPSB7fQ0JYXJncyA9IHt9DQlmaW5kZXIgPSBf Z2V0ZmluZGVyKCkNCWFyZ3MgPSB7fQ0JYXR0cnMgPSB7fQ0JYWVvYmpfMDAgPSBhZXR5 cGVzLk9iamVjdFNwZWNpZmllcih3YW50PWFldHlwZXMuVHlwZSgnY2ZvbCcpLCBmb3Jt PSJhbGlzIiwgc2VsZD1mb2xkZXJfYWxpYXMsIGZyPU5vbmUpDQlhZW9ial8wMSA9IGFl dHlwZXMuT2JqZWN0U3BlY2lmaWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdwcm9wJyksIGZv cm09InByb3AiLCBzZWxkPWFldHlwZXMuVHlwZSgnY3duZCcpLCBmcj1hZW9ial8wMCkN CWFlb2JqXzAyID0gYWV0eXBlcy5PYmplY3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5 cGUoJ3Byb3AnKSwgZm9ybT0icHJvcCIsIHNlbGQ9YWV0eXBlcy5UeXBlKCdwdmV3Jyks IGZyPWFlb2JqXzAxKQ0JYXJnc1snLS0tLSddID0gYWVvYmpfMDINCV9yZXBseSwgYXJn cywgYXR0cnMgPSBmaW5kZXIuc2VuZCgiY29yZSIsICJnZXRkIiwgYXJncywgYXR0cnMp DQlpZiBhcmdzLmhhc19rZXkoJ2Vycm4nKToNCQlyYWlzZSBtb3JlZmluZGVydG9vbHNl cnJvciwgYWV0b29scy5kZWNvZGVlcnJvcihhcmdzKQ0Jdmlld3MgPSB7J2lpbWcnOjAs ICdwbmFtJzoxLCAnbGdidSc6Mn0NCWlmIGFyZ3MuaGFzX2tleSgnLS0tLScpOg0JCXJl dHVybiB2aWV3c1thcmdzWyctLS0tJ10uZW51bV0NDWRlZiB3aW5kb3dzaXplKGZvbGRl ciwgc2l6ZT1Ob25lKToNCSIiIlNldCB0aGUgc2l6ZSBvZiBhIEZpbmRlciB3aW5kb3cg Zm9yIGZvbGRlciB0byBzaXplPSh3LCBoKSwgU3BlY2lmeSBieSBwYXRoLg0JSWYgc2l6 ZT1Ob25lLCB3aW5kb3dzaXplIHdpbGwgcmV0dXJuIHRoZSBjdXJyZW50IHNpemUgb2Yg dGhlIHdpbmRvdy4NCVNwZWNpZnkgZmlsZSBieSBuYW1lIG9yIGZzc3BlYy4NCSIiIg0J ZnNzID0gbWFjZnMuRlNTcGVjKGZvbGRlcikNCWZvbGRlcl9hbGlhcyA9IGZzcy5OZXdB bGlhcygpDQlvcGVud2luZG93KGZzcykNCWlmIG5vdCBzaXplOg0JCXJldHVybiBfZ2V0 d2luZG93c2l6ZShmb2xkZXJfYWxpYXMpDQlyZXR1cm4gX3NldHdpbmRvd3NpemUoZm9s ZGVyX2FsaWFzLCBzaXplKQ0JDWRlZiBfc2V0d2luZG93c2l6ZShmb2xkZXJfYWxpYXMs ICh3LCBoKSk6DQkiIiJTZXQgdGhlIHNpemUgb2YgYSBGaW5kZXIgd2luZG93IGZvciBm b2xkZXIgdG8gKHcsIGgpIiIiDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkNCWFyZ3MgPSB7 fQ0JYXR0cnMgPSB7fQ0JX2NvZGUgPSAnY29yZScNCV9zdWJjb2RlID0gJ3NldGQnDQlh ZXZhcjAwID0gW3csIGhdDQlhZW9ial8wID0gYWV0eXBlcy5PYmplY3RTcGVjaWZpZXIo d2FudD1hZXR5cGVzLlR5cGUoJ2Nmb2wnKSwNCQkJZm9ybT0iYWxpcyIsIHNlbGQ9Zm9s ZGVyX2FsaWFzLCBmcj1Ob25lKQ0JYWVvYmpfMSA9IGFldHlwZXMuT2JqZWN0U3BlY2lm aWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdwcm9wJyksIA0JCQlmb3JtPSJwcm9wIiwgc2Vs ZD1hZXR5cGVzLlR5cGUoJ2N3bmQnKSwgZnI9YWVvYmpfMCkNCWFlb2JqXzIgPSBhZXR5 cGVzLk9iamVjdFNwZWNpZmllcih3YW50PWFldHlwZXMuVHlwZSgncHJvcCcpLCANCQkJ Zm9ybT0icHJvcCIsIHNlbGQ9YWV0eXBlcy5UeXBlKCdwdHN6JyksIGZyPWFlb2JqXzEp DQlhcmdzWyctLS0tJ10gPSBhZW9ial8yDQlhcmdzWyJkYXRhIl0gPSBhZXZhcjAwDQlf cmVwbHksIGFyZ3MsIGF0dHJzID0gZmluZGVyLnNlbmQoX2NvZGUsIF9zdWJjb2RlLCBh cmdzLCBhdHRycykNCWlmIGFyZ3MuaGFzX2tleSgnZXJybicpOg0JCXJhaXNlIG1vcmVm aW5kZXJ0b29sc2Vycm9yLCBhZXRvb2xzLmRlY29kZWVycm9yKGFyZ3MpDQlyZXR1cm4g KHcsIGgpDQkJDWRlZiBfZ2V0d2luZG93c2l6ZShmb2xkZXJfYWxpYXMpOg0JIiIiU2V0 IHRoZSBzaXplIG9mIGEgRmluZGVyIHdpbmRvdyBmb3IgZm9sZGVyIHRvICh3LCBoKSIi Ig0JZmluZGVyID0gX2dldGZpbmRlcigpDQlhcmdzID0ge30NCWF0dHJzID0ge30NCWFl b2JqXzAgPSBhZXR5cGVzLk9iamVjdFNwZWNpZmllcih3YW50PWFldHlwZXMuVHlwZSgn Y2ZvbCcpLCANCQkJZm9ybT0iYWxpcyIsIHNlbGQ9Zm9sZGVyX2FsaWFzLCBmcj1Ob25l KQ0JYWVvYmpfMSA9IGFldHlwZXMuT2JqZWN0U3BlY2lmaWVyKHdhbnQ9YWV0eXBlcy5U eXBlKCdwcm9wJyksIA0JCQlmb3JtPSJwcm9wIiwgc2VsZD1hZXR5cGVzLlR5cGUoJ2N3 bmQnKSwgZnI9YWVvYmpfMCkNCWFlb2JqXzIgPSBhZXR5cGVzLk9iamVjdFNwZWNpZmll cih3YW50PWFldHlwZXMuVHlwZSgncHJvcCcpLCANCQkJZm9ybT0icHJvcCIsIHNlbGQ9 YWV0eXBlcy5UeXBlKCdwb3NuJyksIGZyPWFlb2JqXzEpDQlhcmdzWyctLS0tJ10gPSBh ZW9ial8yDQlfcmVwbHksIGFyZ3MsIGF0dHJzID0gZmluZGVyLnNlbmQoJ2NvcmUnLCAn Z2V0ZCcsIGFyZ3MsIGF0dHJzKQ0JaWYgYXJncy5oYXNfa2V5KCdlcnJuJyk6DQkJcmFp c2UgbW9yZWZpbmRlcnRvb2xzZXJyb3IsIGFldG9vbHMuZGVjb2RlZXJyb3IoYXJncykN CWlmIGFyZ3MuaGFzX2tleSgnLS0tLScpOg0JCXJldHVybiBhcmdzWyctLS0tJ10NDWRl ZiB3aW5kb3dwb3NpdGlvbihmb2xkZXIsIHBvcz1Ob25lKToNCSIiIlNldCB0aGUgcG9z aXRpb24gb2YgYSBGaW5kZXIgd2luZG93IGZvciBmb2xkZXIgdG8gcG9zPSh3LCBoKS4i IiINCWZzcyA9IG1hY2ZzLkZTU3BlYyhmb2xkZXIpDQlmb2xkZXJfYWxpYXMgPSBmc3Mu TmV3QWxpYXMoKQ0Jb3BlbndpbmRvdyhmc3MpDQlpZiBub3QgcG9zOg0JCXJldHVybiBf Z2V0d2luZG93cG9zaXRpb24oZm9sZGVyX2FsaWFzKQ0JaWYgdHlwZShwb3MpID09IElu c3RhbmNlVHlwZToNCQkjIHBvcyBtaWdodCBiZSBhIFFEUG9pbnQgb2JqZWN0IGFzIHJl dHVybmVkIGJ5IF9nZXR3aW5kb3dwb3NpdGlvbg0JCXBvcyA9IChwb3MuaCwgcG9zLnYp DQlyZXR1cm4gX3NldHdpbmRvd3Bvc2l0aW9uKGZvbGRlcl9hbGlhcywgcG9zKQ0JCQkN ZGVmIF9zZXR3aW5kb3dwb3NpdGlvbihmb2xkZXJfYWxpYXMsICh4LCB5KSk6DQkiIiJT ZXQgdGhlIHNpemUgb2YgYSBGaW5kZXIgd2luZG93IGZvciBmb2xkZXIgdG8gKHcsIGgp LiIiIg0JZmluZGVyID0gX2dldGZpbmRlcigpDQlhcmdzID0ge30NCWF0dHJzID0ge30N CWFlb2JqXzAgPSBhZXR5cGVzLk9iamVjdFNwZWNpZmllcih3YW50PWFldHlwZXMuVHlw ZSgnY2ZvbCcpLCANCQkJZm9ybT0iYWxpcyIsIHNlbGQ9Zm9sZGVyX2FsaWFzLCBmcj1O b25lKQ0JYWVvYmpfMSA9IGFldHlwZXMuT2JqZWN0U3BlY2lmaWVyKHdhbnQ9YWV0eXBl cy5UeXBlKCdwcm9wJyksIA0JCQlmb3JtPSJwcm9wIiwgc2VsZD1hZXR5cGVzLlR5cGUo J2N3bmQnKSwgZnI9YWVvYmpfMCkNCWFlb2JqXzIgPSBhZXR5cGVzLk9iamVjdFNwZWNp Zmllcih3YW50PWFldHlwZXMuVHlwZSgncHJvcCcpLCANCQkJZm9ybT0icHJvcCIsIHNl bGQ9YWV0eXBlcy5UeXBlKCdwb3NuJyksIGZyPWFlb2JqXzEpDQlhcmdzWyctLS0tJ10g PSBhZW9ial8yDQlhcmdzWyJkYXRhIl0gPSBbeCwgeV0NCV9yZXBseSwgYXJncywgYXR0 cnMgPSBmaW5kZXIuc2VuZCgnY29yZScsICdzZXRkJywgYXJncywgYXR0cnMpDQlpZiBh cmdzLmhhc19rZXkoJ2Vycm4nKToNCQlyYWlzZSBtb3JlZmluZGVydG9vbHNlcnJvciwg YWV0b29scy5kZWNvZGVlcnJvcihhcmdzKQ0JaWYgYXJncy5oYXNfa2V5KCctLS0tJyk6 DQkJcmV0dXJuIGFyZ3NbJy0tLS0nXQ0NZGVmIF9nZXR3aW5kb3dwb3NpdGlvbihmb2xk ZXJfYWxpYXMpOg0JIiIiR2V0IHRoZSBzaXplIG9mIGEgRmluZGVyIHdpbmRvdyBmb3Ig Zm9sZGVyLCBTcGVjaWZ5IGJ5IHBhdGguIiIiDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkN CWFyZ3MgPSB7fQ0JYXR0cnMgPSB7fQ0JYWVvYmpfMCA9IGFldHlwZXMuT2JqZWN0U3Bl Y2lmaWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdjZm9sJyksIA0JCQlmb3JtPSJhbGlzIiwg c2VsZD1mb2xkZXJfYWxpYXMsIGZyPU5vbmUpDQlhZW9ial8xID0gYWV0eXBlcy5PYmpl Y3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5cGUoJ3Byb3AnKSwgDQkJCWZvcm09InBy b3AiLCBzZWxkPWFldHlwZXMuVHlwZSgnY3duZCcpLCBmcj1hZW9ial8wKQ0JYWVvYmpf MiA9IGFldHlwZXMuT2JqZWN0U3BlY2lmaWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdwcm9w JyksIA0JCQlmb3JtPSJwcm9wIiwgc2VsZD1hZXR5cGVzLlR5cGUoJ3B0c3onKSwgZnI9 YWVvYmpfMSkNCWFyZ3NbJy0tLS0nXSA9IGFlb2JqXzINCV9yZXBseSwgYXJncywgYXR0 cnMgPSBmaW5kZXIuc2VuZCgnY29yZScsICdnZXRkJywgYXJncywgYXR0cnMpDQlpZiBh cmdzLmhhc19rZXkoJ2Vycm4nKToNCQlyYWlzZSBtb3JlZmluZGVydG9vbHNlcnJvciwg YWV0b29scy5kZWNvZGVlcnJvcihhcmdzKQ0JaWYgYXJncy5oYXNfa2V5KCctLS0tJyk6 DQkJcmV0dXJuIGFyZ3NbJy0tLS0nXQ0NZGVmIGljb24ob2JqZWN0LCBpY29uZGF0YT1O b25lKToNCSIiImljb24gc2V0cyB0aGUgaWNvbiBvZiBvYmplY3QsIGlmIG5vIGljb25k YXRhIGlzIGdpdmVuLA0JaWNvbiB3aWxsIHJldHVybiBhbiBBRSBvYmplY3Qgd2l0aCBi aW5hcnkgZGF0YSBmb3IgdGhlIGN1cnJlbnQgaWNvbi4NCUlmIGxlZnQgdW50b3VjaGVk LCB0aGlzIGRhdGEgY2FuIGJlIHVzZWQgdG8gcGFzdGUgdGhlIGljb24gb24gYW5vdGhl ciBmaWxlLg0JRGV2ZWxvcG1lbnQgb3Bwb3J0dW5pdHk6IGdldCBhbmQgc2V0IHRoZSBk YXRhIGFzIFBJQ1QuIiIiDQlmc3MgPSBtYWNmcy5GU1NwZWMob2JqZWN0KQ0Jb2JqZWN0 X2FsaWFzID0gZnNzLk5ld0FsaWFzKCkNCWlmIGljb25kYXRhID09IE5vbmU6DQkJcmV0 dXJuIF9nZXRpY29uKG9iamVjdF9hbGlhcykNCXJldHVybiBfc2V0aWNvbihvYmplY3Rf YWxpYXMsIGljb25kYXRhKQ0JDWRlZiBfZ2V0aWNvbihvYmplY3RfYWxpYXMpOg0JIiIi Z2V0IHRoZSBpY29uZGF0YSBmb3Igb2JqZWN0LiBCaW5hcnkgZGF0YSBvZiBzb21lIHNv cnQuIiIiDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkNCWFyZ3MgPSB7fQ0JYXR0cnMgPSB7 fQ0JYWVvYmpfMDAgPSBhZXR5cGVzLk9iamVjdFNwZWNpZmllcih3YW50PWFldHlwZXMu VHlwZSgnY29iaicpLCANCQkJZm9ybT0iYWxpcyIsIHNlbGQ9b2JqZWN0X2FsaWFzLCBm cj1Ob25lKQ0JYWVvYmpfMDEgPSBhZXR5cGVzLk9iamVjdFNwZWNpZmllcih3YW50PWFl dHlwZXMuVHlwZSgncHJvcCcpLCANCQkJZm9ybT0icHJvcCIsIHNlbGQ9YWV0eXBlcy5U eXBlKCdpaW1nJyksIGZyPWFlb2JqXzAwKQ0JYXJnc1snLS0tLSddID0gYWVvYmpfMDEN CV9yZXBseSwgYXJncywgYXR0cnMgPSBmaW5kZXIuc2VuZCgiY29yZSIsICJnZXRkIiwg YXJncywgYXR0cnMpDQlpZiBhcmdzLmhhc19rZXkoJ2Vycm4nKToNCQlyYWlzZSBtb3Jl ZmluZGVydG9vbHNlcnJvciwgYWV0b29scy5kZWNvZGVlcnJvcihhcmdzKQ0JaWYgYXJn cy5oYXNfa2V5KCctLS0tJyk6DQkJcmV0dXJuIGFyZ3NbJy0tLS0nXQ0NZGVmIF9zZXRp Y29uKG9iamVjdF9hbGlhcywgaWNvbmRhdGEpOg0JIiIic2V0IHRoZSBpY29uZGF0YSBm b3Igb2JqZWN0LCBmb3JtYXR0ZWQgYXMgcHJvZHVjZWQgYnkgX2dldGljb24oKSIiIg0J ZmluZGVyID0gX2dldGZpbmRlcigpDQlhcmdzID0ge30NCWF0dHJzID0ge30NCWFlb2Jq XzAwID0gYWV0eXBlcy5PYmplY3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5cGUoJ2Nv YmonKSwgDQkJCWZvcm09ImFsaXMiLCBzZWxkPW9iamVjdF9hbGlhcywgZnI9Tm9uZSkN CWFlb2JqXzAxID0gYWV0eXBlcy5PYmplY3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5 cGUoJ3Byb3AnKSwgDQkJCWZvcm09InByb3AiLCBzZWxkPWFldHlwZXMuVHlwZSgnaWlt ZycpLCBmcj1hZW9ial8wMCkNCWFyZ3NbJy0tLS0nXSA9IGFlb2JqXzAxDQlhcmdzWyJk YXRhIl0gPSBpY29uZGF0YQ0JX3JlcGx5LCBhcmdzLCBhdHRycyA9IGZpbmRlci5zZW5k KCJjb3JlIiwgInNldGQiLCBhcmdzLCBhdHRycykNCWlmIGFyZ3MuaGFzX2tleSgnZXJy bicpOg0JCXJhaXNlIG1vcmVmaW5kZXJ0b29sc2Vycm9yLCBhZXRvb2xzLmRlY29kZWVy cm9yKGFyZ3MpDQlpZiBhcmdzLmhhc19rZXkoJy0tLS0nKToNCQlyZXR1cm4gYXJnc1sn LS0tLSddLmRhdGENDQ0jLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDSMJVm9sdW1lcyBhbmQgc2VydmVycy4NCQ1kZWYgbW91bnR2 b2x1bWUodm9sdW1lLCBzZXJ2ZXI9Tm9uZSwgdXNlcm5hbWU9Tm9uZSwgcGFzc3dvcmQ9 Tm9uZSk6DQkiIiJtb3VudCBhIHZvbHVtZSwgbG9jYWwgb3Igb24gYSBzZXJ2ZXIgb24g QXBwbGVUYWxrLg0JTm90ZTogbW91bnRpbmcgYSBBU0lQIHNlcnZlciByZXF1aXJlcyBh IGRpZmZlcmVudCBvcGVyYXRpb24uDQlzZXJ2ZXIgaXMgdGhlIG5hbWUgb2YgdGhlIHNl cnZlciB3aGVyZSB0aGUgdm9sdW1lIGJlbG9uZ3MNCXVzZXJuYW1lLCBwYXNzd29yZCBi ZWxvbmcgdG8gYSByZWdpc3RlcmVkIHVzZXIgb2YgdGhlIHZvbHVtZS4iIiINCWZpbmRl ciA9IF9nZXRmaW5kZXIoKQ0JYXJncyA9IHt9DQlhdHRycyA9IHt9DQlpZiBwYXNzd29y ZDoNCQlhcmdzWyJQQVNTIl0gPSBwYXNzd29yZA0JaWYgdXNlcm5hbWU6DQkJYXJnc1si VVNFUiJdID0gdXNlcm5hbWUNCWlmIHNlcnZlcjoNCQlhcmdzWyJTUlZSIl0gPSBzZXJ2 ZXINCWFyZ3NbJy0tLS0nXSA9IHZvbHVtZQ0JX3JlcGx5LCBhcmdzLCBhdHRycyA9IGZp bmRlci5zZW5kKCJhZXZ0IiwgIm12b2wiLCBhcmdzLCBhdHRycykNCWlmIGFyZ3MuaGFz X2tleSgnZXJybicpOg0JCXJhaXNlIG1vcmVmaW5kZXJ0b29sc2Vycm9yLCBhZXRvb2xz LmRlY29kZWVycm9yKGFyZ3MpDQlpZiBhcmdzLmhhc19rZXkoJy0tLS0nKToNCQlyZXR1 cm4gYXJnc1snLS0tLSddDQ1kZWYgdW5tb3VudHZvbHVtZSh2b2x1bWUpOg0JIiIidW5t b3VudCBhIHZvbHVtZSB0aGF0J3Mgb24gdGhlIGRlc2t0b3AiIiINCXB1dGF3YXkodm9s dW1lKQ0JDWRlZiBwdXRhd2F5KG9iamVjdCk6DQkiIiJwdXRoIHRoZSBvYmplY3QgYXdh eSwgd2hlcmVldmVyIGl0IGNhbWUgZnJvbS4iIiINCWZpbmRlciA9IF9nZXRmaW5kZXIo KQ0JYXJncyA9IHt9DQlhdHRycyA9IHt9DQlhcmdzWyctLS0tJ10gPSBhZXR5cGVzLk9i amVjdFNwZWNpZmllcih3YW50PWFldHlwZXMuVHlwZSgnY2RpcycpLCBmb3JtPSJuYW1l Iiwgc2VsZD1vYmplY3QsIGZyPU5vbmUpDQlfcmVwbHksIGFyZ3MsIGF0dHJzID0gdGFs a2VyLnNlbmQoImZuZHIiLCAicHR3eSIsIGFyZ3MsIGF0dHJzKQ0JaWYgYXJncy5oYXNf a2V5KCdlcnJuJyk6DQkJcmFpc2UgbW9yZWZpbmRlcnRvb2xzZXJyb3IsIGFldG9vbHMu ZGVjb2RlZXJyb3IoYXJncykNCWlmIGFyZ3MuaGFzX2tleSgnLS0tLScpOg0JCXJldHVy biBhcmdzWyctLS0tJ10NDQ0jLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDSMJTWlzY2VsbGFuZW91cyBmdW5jdGlvbnMNIw0NZGVm IHZvbHVtZWxldmVsKGxldmVsKToNCSIiInNldCB0aGUgYXVkaW8gb3V0cHV0IGxldmVs LCBwYXJhbWV0ZXIgYmV0d2VlbiAwIChzaWxlbnQpIGFuZCA3IChmdWxsIGJsYXN0KSIi Ig0JZmluZGVyID0gX2dldGZpbmRlcigpDQlhcmdzID0ge30NCWF0dHJzID0ge30NCWlm IGxldmVsIDwgMDoNCQlsZXZlbCA9IDANCWVsaWYgbGV2ZWwgPiA3Og0JCWxldmVsID0g Nw0JYXJnc1snLS0tLSddID0gbGV2ZWwNCV9yZXBseSwgYXJncywgYXR0cnMgPSBmaW5k ZXIuc2VuZCgiYWV2dCIsICJzdHZsIiwgYXJncywgYXR0cnMpDQlpZiBhcmdzLmhhc19r ZXkoJ2Vycm4nKToNCQlyYWlzZSBtb3JlZmluZGVydG9vbHNlcnJvciwgYWV0b29scy5k ZWNvZGVlcnJvcihhcmdzKQ0JaWYgYXJncy5oYXNfa2V5KCctLS0tJyk6DQkJcmV0dXJu IGFyZ3NbJy0tLS0nXQ0NZGVmIE9TdmVyc2lvbigpOg0JIiIicmV0dXJuIHRoZSB2ZXJz aW9uIG9mIHRoZSBzeXN0ZW0gc29mdHdhcmUiIiINCWZpbmRlciA9IF9nZXRmaW5kZXIo KQ0JYXJncyA9IHt9DQlhdHRycyA9IHt9DQlhZW9ial8wMCA9IGFldHlwZXMuT2JqZWN0 U3BlY2lmaWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdwcm9wJyksIGZvcm09InByb3AiLCBz ZWxkPWFldHlwZXMuVHlwZSgndmVyMicpLCBmcj1Ob25lKQ0JYXJnc1snLS0tLSddID0g YWVvYmpfMDANCV9yZXBseSwgYXJncywgYXR0cnMgPSBmaW5kZXIuc2VuZCgiY29yZSIs ICJnZXRkIiwgYXJncywgYXR0cnMpDQlpZiBhcmdzLmhhc19rZXkoJ2Vycm4nKToNCQly YWlzZSBtb3JlZmluZGVydG9vbHNlcnJvciwgYWV0b29scy5kZWNvZGVlcnJvcihhcmdz KQ0JaWYgYXJncy5oYXNfa2V5KCctLS0tJyk6DQkJcmV0dXJuIGFyZ3NbJy0tLS0nXQ0N ZGVmIGZpbGVzaGFyaW5nKCk6DQkiIiJyZXR1cm4gdGhlIGN1cnJlbnQgc3RhdHVzIG9m IGZpbGVzaGFyaW5nIGFuZCB3aGV0aGVyIGl0IGlzIHN0YXJ0aW5nIHVwIG9yIG5vdDoN CQktMQlmaWxlIHNoYXJpbmcgaXMgb2ZmIGFuZCBub3Qgc3RhcnRpbmcgdXANCQkwCWZp bGUgc2hhcmluZyBpcyBvZmYgYW5kIHN0YXJ0aW5nIHVwDQkJMQlmaWxlIHNoYXJpbmcg aXMgb24iIiINCXN0YXR1cyA9IC0xDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkNCSMgc2Vl IGlmIGl0IGlzIG9uDQlhcmdzID0ge30NCWF0dHJzID0ge30NCWFyZ3NbJy0tLS0nXSA9 IGFldHlwZXMuT2JqZWN0U3BlY2lmaWVyKHdhbnQ9YWV0eXBlcy5UeXBlKCdwcm9wJyks IGZvcm09InByb3AiLCBzZWxkPWFldHlwZXMuVHlwZSgnZnNocicpLCBmcj1Ob25lKQ0J X3JlcGx5LCBhcmdzLCBhdHRycyA9IGZpbmRlci5zZW5kKCJjb3JlIiwgImdldGQiLCBh cmdzLCBhdHRycykNCWlmIGFyZ3MuaGFzX2tleSgnZXJybicpOg0JCXJhaXNlIG1vcmVm aW5kZXJ0b29sc2Vycm9yLCBhZXRvb2xzLmRlY29kZWVycm9yKGFyZ3MpDQlpZiBhcmdz Lmhhc19rZXkoJy0tLS0nKToNCQlpZiBhcmdzWyctLS0tJ10gPT0gMDoNCQkJc3RhdHVz ID0gLTENCQllbHNlOg0JCQlzdGF0dXMgPSAxDQkjIGlzIGl0IHN0YXJ0aW5nIHVwIHBl cmNoYW5jZT8NCWFyZ3MgPSB7fQ0JYXR0cnMgPSB7fQ0JYXJnc1snLS0tLSddID0gYWV0 eXBlcy5PYmplY3RTcGVjaWZpZXIod2FudD1hZXR5cGVzLlR5cGUoJ3Byb3AnKSwgZm9y bT0icHJvcCIsIHNlbGQ9YWV0eXBlcy5UeXBlKCdmc3VwJyksIGZyPU5vbmUpDQlfcmVw bHksIGFyZ3MsIGF0dHJzID0gZmluZGVyLnNlbmQoImNvcmUiLCAiZ2V0ZCIsIGFyZ3Ms IGF0dHJzKQ0JaWYgYXJncy5oYXNfa2V5KCdlcnJuJyk6DQkJcmFpc2UgbW9yZWZpbmRl cnRvb2xzZXJyb3IsIGFldG9vbHMuZGVjb2RlZXJyb3IoYXJncykNCWlmIGFyZ3MuaGFz X2tleSgnLS0tLScpOg0JCWlmIGFyZ3NbJy0tLS0nXSA9PSAxOg0JCQlzdGF0dXMgPSAw DQlyZXR1cm4gc3RhdHVzDQkNZGVmIG1vdmV0b3RyYXNoKHBhdGgpOg0JIiIibW92ZSB0 aGUgb2JqZWN0IHRvIHRoZSB0cmFzaCIiIg0JZnNzID0gbWFjZnMuRlNTcGVjKHBhdGgp DQl0cmFzaGZvbGRlciA9IG1hY2ZzLkZTU3BlYyhtYWNmcy5GaW5kRm9sZGVyKGZzcy5h c190dXBsZSgpWzBdLCAndHJzaCcsIDApICsgKCIiLCkpLmFzX3BhdGhuYW1lKCkNCWZp bmRlcnRvb2xzLm1vdmUocGF0aCwgdHJhc2hmb2xkZXIpDQ1kZWYgZW1wdHl0cmFzaCgp Og0JIiIiZW1wdHkgdGhlIHRyYXNoIiIiDQlmaW5kZXIgPSBfZ2V0ZmluZGVyKCkNCWFy Z3MgPSB7fQ0JYXR0cnMgPSB7fQ0JYXJnc1snLS0tLSddID0gYWV0eXBlcy5PYmplY3RT cGVjaWZpZXIod2FudD1hZXR5cGVzLlR5cGUoJ3Byb3AnKSwgZm9ybT0icHJvcCIsIHNl bGQ9YWV0eXBlcy5UeXBlKCd0cnNoJyksIGZyPU5vbmUpDQlfcmVwbHksIGFyZ3MsIGF0 dHJzID0gZmluZGVyLnNlbmQoImZuZHIiLCAiZW1wdCIsIGFyZ3MsIGF0dHJzKQ0JaWYg YXJncy5oYXNfa2V5KCdlcnJuJyk6DQkJcmFpc2UgYWV0b29scy5FcnJvciwgYWV0b29s cy5kZWNvZGVlcnJvcihhcmdzKQ0= --============_-1224577438==_D============-- --============_-1224577438==_============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit -- "Faites des phrases courtes. Un sujet, un verbe, un complément. Quand vous voudrez ajouter un adjectif, vous viendrez me voir." - Georges Clemenceau, 1841-1929, médecin et homme politique français. Consignes aux journalistes de "L'Aurore". d'après --============_-1224577438==_============-- From chrishbarker@home.net Wed Apr 18 01:34:49 2001 From: chrishbarker@home.net (Chris Barker) Date: Tue, 17 Apr 2001 17:34:49 -0700 Subject: [Pythonmac-SIG] Automating running a sequence of programs References: <20000831084330.D3FFF303181@snelboot.oratrix.nl> <3ADC82FA.E53F2D1B@home.net> Message-ID: <3ADCE129.302CD548@home.net> Francois Granger wrote: > Have a look to "More findertools" it should be in Mac:Contrib. I > enclose in case. It can check for processes. This may be all you need > ?? Thanks, I'll give that a try next week when I get back from vacation. -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From JBezos@unionradio.es Wed Apr 18 17:37:09 2001 From: JBezos@unionradio.es (Javier Bezos Lopez) Date: Wed, 18 Apr 2001 18:37:09 +0200 Subject: [Pythonmac-SIG] RV: AppleScript -> Python Message-ID: <31399D7148E6D4119EC700D0B7A78DB74B00EA@SRVEXCH2UR28> Thank you very much for the answers. A private mail pointed me to ASCaptureParser. It produces a somewhat cryptic code, but I think it will be enough to start. Javier From Benjamin.Schollnick@usa.xerox.com Fri Apr 20 14:17:20 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 20 Apr 2001 09:17:20 -0400 Subject: [Pythonmac-SIG] Hiding the PythonInterpreter.Out window? Message-ID: I'm messing around with the TCL based code, and I want to hide the PythonInterpreter.Out window (STDOUT?).... Is there some way to do this? The Python Run time options don't seem to offer this? And I'd also like to enforce this when the application is built using "Build Application" applet.... - Benjamin From richard@richardgordon.net Sat Apr 21 00:49:56 2001 From: richard@richardgordon.net (Richard Gordon) Date: Fri, 20 Apr 2001 19:49:56 -0400 Subject: [Pythonmac-SIG] Hiding the PythonInterpreter.Out window? In-Reply-To: References: Message-ID: >I'm messing around with the TCL based code, and I want to hide the >PythonInterpreter.Out window (STDOUT?).... > >Is there some way to do this? The Python Run time options don't seem >to offer this? And I'd also like to enforce this when the application >is built using "Build Application" applet.... Launch EditPythonPrefs, hit the Default Startup Options button, then check the box next to Delay Console Window Until Needed (or something like that). I don't know whether this will govern the behavior of an application you build or not, but it would seem likely. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From jack@oratrix.nl Mon Apr 23 10:16:44 2001 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 23 Apr 2001 11:16:44 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion? In-Reply-To: Message by "Tim Peters" , Thu, 12 Apr 2001 21:00:08 -0400 , Message-ID: <20010423091644.AB453312BA0@snelboot.oratrix.nl> > [Steven D. Majewski] > > Has anybody looked at sfio ? > > ... > > http://www.research.att.com/sw/tools/sfio/ > > Did just now. Only runs on Unix boxes, so would be a heavyweight way to > solve line-end problems across platforms that don't have any . But purely by chance I know that Matthias Neeracher, who has written the GUSI unix-emulation package that MacPython uses to do socket IO and select and such, is an SFIO fan, and there's all sorts of hooks in GUSI to allow use of SFIO. So I think that there's a good chance that sfio is okay for MacPython. I've just dug out the 1991 usenix article, I'll read through it shortly. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From philippesmets@mac.com Mon Apr 23 20:33:33 2001 From: philippesmets@mac.com (Philippe Smets) Date: Mon, 23 Apr 2001 21:33:33 +0200 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #685 - 10 msgs In-Reply-To: Message-ID: I never saw an answer to this question: > Van: "Schollnick, Benjamin" > Datum: Wed, 11 Apr 2001 13:04:48 -0400 > Aan: pythonmac-sig@python.org > Onderwerp: [Pythonmac-SIG] Python Mega Widgets > > Has anyone used PMW (Python Mega Widgets) under Python v2.0x on the Mac? > > I'm running into some weird stuff.... The PMWLOADER file doesn't seem to > want > to run... And I had to modify the __INIT__.py file in the root directory > because the internal logic didn't seem to be working nicely on the Mac... > > - Benjamin > I started learning Python a few months ago and meanwhile bought "Python and Tkinter Programming" by John Grayson. He uses PMW heavilly in his examples ? So can I use PMW with MacPython ? And what changes do I have to make to the PMW code ? Philippe From zilp@village.uunet.be Mon Apr 23 20:36:31 2001 From: zilp@village.uunet.be (Philippe Smets) Date: Mon, 23 Apr 2001 21:36:31 +0200 Subject: [Pythonmac-SIG] Python Mega Widgets In-Reply-To: Message-ID: Hi, I just send a mail to the list but forgot to edit the subject line. Sorry folks, a little to fast. Philippe From jack@oratrix.nl Tue Apr 24 10:42:06 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 24 Apr 2001 11:42:06 +0200 Subject: [Pythonmac-SIG] Python Mega Widgets In-Reply-To: Message by Philippe Smets , Mon, 23 Apr 2001 21:36:31 +0200 , Message-ID: <20010424094206.52155312BA0@snelboot.oratrix.nl> I tried PMW with MacPython some time ago (may well be 1.5.2) and it worked fine after a little massaging of, if I remember correctly, the loader. I don't remember exactly what the problems were, though, so I guess you're on your own. But at least you now know that it should be possible to get it working:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From Benjamin.Schollnick@usa.xerox.com Tue Apr 24 13:30:19 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Tue, 24 Apr 2001 08:30:19 -0400 Subject: [Pythonmac-SIG] PMW (Python MegaWidgets) on Macintosh Message-ID: I haven't heard anything yet either... In theory PMW should work fine, but as I mentioned the logic in the loader seems to be strange... - Benjamin -----Original Message----- From: Philippe Smets [mailto:philippesmets@mac.com] Sent: Monday, April 23, 2001 3:34 PM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #685 - 10 msgs I never saw an answer to this question: > Van: "Schollnick, Benjamin" > Datum: Wed, 11 Apr 2001 13:04:48 -0400 > Aan: pythonmac-sig@python.org > Onderwerp: [Pythonmac-SIG] Python Mega Widgets > > Has anyone used PMW (Python Mega Widgets) under Python v2.0x on the Mac? > > I'm running into some weird stuff.... The PMWLOADER file doesn't seem to > want > to run... And I had to modify the __INIT__.py file in the root directory > because the internal logic didn't seem to be working nicely on the Mac... > > - Benjamin > I started learning Python a few months ago and meanwhile bought "Python and Tkinter Programming" by John Grayson. He uses PMW heavilly in his examples ? So can I use PMW with MacPython ? And what changes do I have to make to the PMW code ? Philippe _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From ariza@flexatone.com Tue Apr 24 18:50:55 2001 From: ariza@flexatone.com (christopher ariza) Date: Tue, 24 Apr 2001 12:50:55 -0500 Subject: [Pythonmac-SIG] Python Mega Widgets In-Reply-To: Message-ID: i did a bit of work with some of the simple PMW examples from Grayson's book under MacPython 1.5.2. most of the time things worked while drag-and-dropping with the interpreter, though eventually i ran into a serious problem with the package loader while trying to use 'BuildApplication'. i never found a solution and had to replace PMW widgets with standard Tkinter widgets, which then worked fine with 'BuildApplication'. sorry i cant be of more help! ____________________ christopher ariza http://flexatone.com From ariza@flexatone.com Tue Apr 24 19:05:51 2001 From: ariza@flexatone.com (christopher ariza) Date: Tue, 24 Apr 2001 13:05:51 -0500 Subject: [Pythonmac-SIG] Python Mega Widgets Message-ID: just dug up an old post and remembered what had happened: it wasnt BuildApplication at all (or 1.5.2...), it was this: im trying to build an application using Pmw with the Mac Python 2.0 BuildApplication script. BuildApplication succeeds, with no errors. however, when executing the program, i get the following error message: File "python 2.0:Pmw:__init__.py", line 28, in ? _listdir = os.listdir(_dir) mac.error: (2, 'No such file or directory') this seems to be a problem with the Pmw Dynamic Loader. the pmw web page says this should be fixed by creating a frozen Pmw.py module that includes all Pmw code. the standard download includes the necessary script: Pmw:Pmw_0_8_4:bin:bundlepmw.py however, this file seems to only run on unix. ____________________ christopher ariza http://flexatone.com From owen@astro.washington.edu Tue Apr 24 18:25:25 2001 From: owen@astro.washington.edu (Russell E Owen) Date: Tue, 24 Apr 2001 10:25:25 -0700 Subject: [Pythonmac-SIG] Tkinter problems Message-ID: I've been using Tkinter on a Mac (MacPython 2.0 non-carbon, Mac OS 9.1, PowerMac G4) and have run into a few problems that I'm wondering if others have seen. 1) Can't catch explicit arrow or control keys. I've tried binding "" and "" events to an Entry widget with no luck -- the callback is never called. I then bound the same Entry widget to the "" event and examined the keysyms and I do see "Up" when I hit the up arrow, so Tkinter does actually generate this event. (Control-P produced a keysym of "p" and I'm not sure how to tell if the control key was seen). 2) Dialogs that should be modal are not. I tried generating my own modal dialog from the Introduction to Tkinter code and I could select any window while it was up. I then tried Pmw's Dialog with the same result. 3) Random crashes when using the Pmw's Dialog. 4) Crashes when using menus. -- Russell From richard@richardgordon.net Wed Apr 25 18:46:15 2001 From: richard@richardgordon.net (Richard Gordon) Date: Wed, 25 Apr 2001 13:46:15 -0400 Subject: [Pythonmac-SIG] Problem with IDE Patches Message-ID: hi I had applied the printing and AdvancedEditor patches to the IDE in Python 2.0 and that worked fine, but I can't seem to get syntax coloring to work after applying them to the IDE in 2.1. I've reapplied/rebuilt several times and Syntax Coloring is checked when I open a script in the IDE, but nothing is colorized. Any thoughts? Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From delza@alliances.org Wed Apr 25 16:58:23 2001 From: delza@alliances.org (Dethe Elza) Date: Wed, 25 Apr 2001 08:58:23 -0700 Subject: [Pythonmac-SIG] Tkinter problems In-Reply-To: Message-ID: (Russell: sorry for you getting this twice, I keep forgetting that Mailman doesn't set the list to be the reply address, so I end up replying to the sender instead of the list. Again and again.) I haven't seen the same problems you have, but I've had other issues with Tkinter: 1) Text that comes up selected when I run on Windows or Linux is not selected when I run on the Mac (OS 9/Python 2.0). 2) Resizing either doesn't work, or has strange effect (like menus disappearing). Again, this works OK on Linux and Windows. --Dethe > From: Russell E Owen > Date: Tue, 24 Apr 2001 10:25:25 -0700 > To: Mac Python mailing list > Subject: [Pythonmac-SIG] Tkinter problems > > I've been using Tkinter on a Mac (MacPython 2.0 non-carbon, Mac OS > 9.1, PowerMac G4) and have run into a few problems that I'm wondering > if others have seen. > > 1) Can't catch explicit arrow or control keys. I've tried binding > "" and "" events to an Entry widget > with no luck -- the callback is never called. I then bound the same > Entry widget to the "" event and examined the keysyms and I > do see "Up" when I hit the up arrow, so Tkinter does actually > generate this event. (Control-P produced a keysym of "p" and I'm not > sure how to tell if the control key was seen). > > 2) Dialogs that should be modal are not. I tried generating my own > modal dialog from the Introduction to Tkinter code and I could select > any window while it was up. I then tried Pmw's Dialog with the same > result. > > 3) Random crashes when using the Pmw's Dialog. > > 4) Crashes when using menus. > > -- Russell > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From jack@oratrix.nl Wed Apr 25 11:27:34 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 25 Apr 2001 12:27:34 +0200 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate Message-ID: <20010425102734.AE74C312BA0@snelboot.oratrix.nl> Folks, MacPython 2.1 is ready, as far as I can tell. Please download the installer from http://www.cwi.nl/ftp/jack/python/mac/newer and report back success/failure. If all goes well I'll put it in the standard place and announce it tomorrow. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From richard@richardgordon.net Wed Apr 25 19:01:38 2001 From: richard@richardgordon.net (Richard Gordon) Date: Wed, 25 Apr 2001 14:01:38 -0400 Subject: [Pythonmac-SIG] Pmw, Tix and BLT Message-ID: I managed to get Pmw working ok in 2.1 (altho tests/all.py is broken, it seems to be that way in windoze as well while just using demos/all.py is fine). I also finally got BLT running on windoze after a lot of thrashing around and wondered if anybody has a binary of it available for Mac? Also, does anyone have Mac binaries available for Tix as I noticed that the 2.1 distribution includes tixwidgets.py but it won't run without Tix obviously and I kind of hate to attempt to compile the source with MPW altho I guess that maybe I could do it with lots of luck. Thanks. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From cwebster@nevada.edu Wed Apr 25 22:42:42 2001 From: cwebster@nevada.edu (Corran Webster) Date: Wed, 25 Apr 2001 14:42:42 -0700 Subject: [Pythonmac-SIG] Mac OS X compilers and Python 2.1 Message-ID: Does anyone here know if it is possible to get the developer tools (such as gcc or Project Builder - which is basically an IDE for gcc, as far as I can see) supplied by Apple for OS X to compile power PC shared libraries like the ones currently used by MacPython? As the author of the Python MPW HOWTO, I've been asked if it's possible; and the ability to do so would be very nice, but I don't know if it's even remotely possible. I spent an evening earlier this week playing with both gcc and Project Builder, but with no luck; indeed I'm so far over my head with Project Builder I have no idea if what I was doing was even vaguely reasonable. Any suggestions would be most welcome, success stories even more so. If it's possible, I'll try to find time to write up a HOWTO which describes the process. Regards, Corran From jack@oratrix.nl Wed Apr 25 22:58:47 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 25 Apr 2001 23:58:47 +0200 Subject: [Pythonmac-SIG] Mac OS X compilers and Python 2.1 In-Reply-To: Message by Corran Webster , Wed, 25 Apr 2001 14:42:42 -0700 , Message-ID: <20010425215852.81D6AE845F@oratrix.oratrix.nl> Recently, Corran Webster said: > Does anyone here know if it is possible to get the developer tools > (such as gcc or Project Builder - which is basically an IDE for gcc, > as far as I can see) supplied by Apple for OS X to compile power PC > shared libraries like the ones currently used by MacPython? Steve is the guru in this area, but I'm pretty convinced that this won't work. Gcc and friends use the Mach-O executable format, while MacPython uses CFM. And while bridging between the two is possible it would probably be fearsomely difficult for Python extensions, as they have oodles of callback back into the core Python code. MacPython is stuck with CFM for the time being because it's the only format supported on both OS9 and OSX. But there's been some work done on "porting" the MacPython-specific modules to unix-Python (or, in other words, the gcc/Mach-O tools), so it may well be feasible to have two Pythons for the Mac with similar functionality, where one is binary compatible with OS9 and the other is more unix-based. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From owen@astro.washington.edu Wed Apr 25 23:31:00 2001 From: owen@astro.washington.edu (Russell E Owen) Date: Wed, 25 Apr 2001 15:31:00 -0700 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate In-Reply-To: <20010425102734.AE74C312BA0@snelboot.oratrix.nl> References: <20010425102734.AE74C312BA0@snelboot.oratrix.nl> Message-ID: >MacPython 2.1 is ready, as far as I can tell. Please download the installer >from http://www.cwi.nl/ftp/jack/python/mac/newer and report back >success/failure. If all goes well I'll put it in the standard place and >announce it tomorrow. I just tested it on a PowerMac G4 running MacOS 9.1. Classic version (since I use Tk). The basics that I tried work fine -- built in tests and my own non-Tk code. However, Tk is unfortunately broken. The main symptom is that most Tk scripts freeze after launch. I cannot move windows around, switch out of the script or do anything else. To get out of this I can type cmd-period (at which point the output window shows a keyboard interrupt and the script is done) or I force PythonInterpreter). One such example script is . The colors program from Grayson's "Python and Tkinter Programming" also shows this problem. Some other scripts do not (including Grayson's bouncing ball script that demonstrates animation via "after") and I've not been able to find a common theme. Just to be clear, I am using PythonInterpreter (not the IDE) and the Classic version (not Carbon). Everything tested runs under 2.0 on my Mac and on a unix box. Also, here's a nonrepeatable problem: EditPythonPrefs crashed the first time I ran it. I tried to record the data, but in the process of trying to copy it I lost it all. After displaying a crash dump of some kind in a standard Python output window it was in a very strange state where the application had no entries in the menu bar -- just a blank bar across the top of the screen. Yet I could switch to other applications and they seemed OK. Force exit got me out of that one. Subsequent runs worked fine. If anybody else sees this, I hope you'll have more luck recording the info than I did. Regards, -- Russell From fgranger@altern.org Wed Apr 25 23:32:35 2001 From: fgranger@altern.org (Francois Granger) Date: Thu, 26 Apr 2001 00:32:35 +0200 Subject: [Pythonmac-SIG] Problem with IDE Patches In-Reply-To: References: Message-ID: At 13:46 -0400 25/04/01, in message [Pythonmac-SIG] Problem with IDE Patches, Richard Gordon wrote: >hi > >I had applied the printing and AdvancedEditor patches to the IDE in >Python 2.0 and that worked fine, but I can't seem to get syntax >coloring to work after applying them to the IDE in 2.1. I've >reapplied/rebuilt several times and Syntax Coloring is checked when >I open a script in the IDE, but nothing is colorized. Any thoughts? As far as I remember, I get the colors on the Mac at work (Cube, 9.0.4) not at home (G4 B&W, 9.0.4) both running MacPython 2.1b2. -- "Faites des phrases courtes. Un sujet, un verbe, un complément. Quand vous voudrez ajouter un adjectif, vous viendrez me voir." - Georges Clemenceau, 1841-1929, médecin et homme politique français. Consignes aux journalistes de "L'Aurore". d'après From richard@richardgordon.net Thu Apr 26 04:48:53 2001 From: richard@richardgordon.net (Richard Gordon) Date: Wed, 25 Apr 2001 23:48:53 -0400 Subject: [Pythonmac-SIG] MemoryError Problem Message-ID: --============_-1223865552==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I finally got around to downloading the source code for "Python & Tkinter Programming" and observed that a) there are a lot of files and b) the line endings are \r\n. I have usually just done a batch Find/Replace in BBEdit to deal with things like this, but decided that it was time to sit down and write a python script to change the line endings to \r, so off we go. The code is below and it works pretty good thru about half of the files, then dies with a memory error (using Python 2.1b2). I've tried jacking the interpreter's memory up to 48000 but it still tipped over at about the same point. I couldn't tell you exactly how many files are involved, but it's a lot and most are small. There is a chapter-based directory structure, but it isn't terribly deep and I don't think that this is some kind of recursion limit thing. So does anyone see something here that may be causing the problem? I'm a little suspicious about .xreadlines() but it's really fast and I'd like to use it if possible. Any help will be appreciated. As an aside, I had originally planned to modify the files in place by opening each in read mode, doing xreadlines, then opening it again in write mode and writing the processed lines back into the file. I didn't get any errors when I tried this, but nothing actually was written into the file either, so I wound up renaming the originals and writing a new file out under the old name. This is not an optimal solution and I'd be interested in any suggestions that you may have about editing files in place. Thanks. #code starts here import sys, os from time import time start = time() fcount = 0 def strip(f): global fcount infh = open(f, 'rb').xreadlines() os.rename(f, f +'~') outfh = open(f, 'wb') for line in infh: outfh.write(line.replace('\n','')) outfh.close() fcount =+ 1 return def run(d): names = os.listdir(d) for name in names: f = d + ':' + name if os.path.isfile(f): if os.path.splitext(f)[1]=='.py': strip(f) else: run(f) run('Conkie:python_scripts:PTP') stop = time() elapsed = stop-start print "Changed %d files in %d seconds" % (fcount, elapsed) #eof Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net --============_-1223865552==_ma============ Content-Type: text/enriched; charset="us-ascii" I finally got around to downloading the source code for "Python & Tkinter Programming" and observed that a) there are a lot of files and b) the line endings are \r\n. I have usually just done a batch Find/Replace in BBEdit to deal with things like this, but decided that it was time to sit down and write a python script to change the line endings to \r, so off we go. The code is below and it works pretty good thru about half of the files, then dies with a memory error (using Python 2.1b2). I've tried jacking the interpreter's memory up to 48000 but it still tipped over at about the same point. I couldn't tell you exactly how many files are involved, but it's a lot and most are small. There is a chapter-based directory structure, but it isn't terribly deep and I don't think that this is some kind of recursion limit thing. So does anyone see something here that may be causing the problem? I'm a little suspicious about .xreadlines() but it's really fast and I'd like to use it if possible. Any help will be appreciated. As an aside, I had originally planned to modify the files in place by opening each in read mode, doing xreadlines, then opening it again in write mode and writing the processed lines back into the file. I didn't get any errors when I tried this, but nothing actually was written into the file either, so I wound up renaming the originals and writing a new file out under the old name. This is not an optimal solution and I'd be interested in any suggestions that you may have about editing files in place. Thanks. #code starts here Monacoimport sys, os from time import time start = time() fcount = 0 def strip(f): global fcount infh = open(f, 'rb').xreadlines() os.rename(f, f +'~') outfh = open(f, 'wb') for line in infh: outfh.write(line.replace('\n','')) outfh.close() fcount =+ 1 return def run(d): names = os.listdir(d) for name in names: f = d + ':' + name if os.path.isfile(f): if os.path.splitext(f)[1]=='.py': strip(f) else: run(f) run('Conkie:python_scripts:PTP') stop = time() elapsed = stop-start print "Changed %d files in %d seconds" % (fcount, elapsed) #eof Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net --============_-1223865552==_ma============-- From fgranger@altern.org Thu Apr 26 10:44:55 2001 From: fgranger@altern.org (Francois Granger) Date: Thu, 26 Apr 2001 11:44:55 +0200 Subject: [Pythonmac-SIG] Problem with IDE Patches In-Reply-To: Message-ID: on 26/04/01 0:32, Francois Granger at fgranger@altern.org wrote: > At 13:46 -0400 25/04/01, in message [Pythonmac-SIG] Problem with IDE > Patches, Richard Gordon wrote: >> hi >> >> I had applied the printing and AdvancedEditor patches to the IDE in >> Python 2.0 and that worked fine, but I can't seem to get syntax >> coloring to work after applying them to the IDE in 2.1. I've >> reapplied/rebuilt several times and Syntax Coloring is checked when >> I open a script in the IDE, but nothing is colorized. Any thoughts? > > As far as I remember, I get the colors on the Mac at work (Cube, > 9.0.4) not at home (G4 B&W, 9.0.4) both running MacPython 2.1b2. Sorry, I checked in the office. It currently does not work. But it has been working at installation since I wrote on April 19 to Mr Strout: "I just re-installed your patch "Advanced Editor Patch" with MacPython 2.1b2 and it woks." From fgranger@altern.org Thu Apr 26 11:29:45 2001 From: fgranger@altern.org (Francois Granger) Date: Thu, 26 Apr 2001 12:29:45 +0200 Subject: [Pythonmac-SIG] MemoryError Problem In-Reply-To: Message-ID: on 26/04/01 5:48, Richard Gordon at richard@richardgordon.net wrote: > [...] and I'd be interested in any suggestions that you may have > about editing files in place. Thanks. Have a look to the module /lib/module-fileinput.html in the HTML documentation def strip(f): global fcount infh = open(f, 'rb').read() os.rename(f, f +'~') outfh = open(f, 'wb') outfh.write(infh.replace('\n','')) outfh.close() fcount =+ 1 From richard@richardgordon.net Fri Apr 27 03:46:40 2001 From: richard@richardgordon.net (Richard Gordon) Date: Thu, 26 Apr 2001 22:46:40 -0400 Subject: [Pythonmac-SIG] MemoryError Problem In-Reply-To: References: Message-ID: --============_-1223782882==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:29 PM +0200 4/26/01, Francois Granger wrote: hi Francois & thanks for the response. >Have a look to the module /lib/module-fileinput.html in the HTML >documentation I've used fileinput before and could never get the command line switch to modify files in place to work- it looked like it was just creating temp files even if this did work which is what prompted me to just start from scratch. > >def strip(f): > global fcount > infh = open(f, 'rb').read() Gadzooks, using read() works fine while both xreadlines() and readlines() fail at about the same point! I'm not quite sure why that's the case but I appreciate the suggestion. Of course it turned out that some of the files had unix endings instead of windoze endings so I had to change things a bit: def strip(f): global fcount infh = open(f, 'rb').read() os.rename(f, f +'~') outfh = open(f, 'wb') if infh.find('\r\n') != -1: outfh.write(infh.replace('\n','')) elif infh.find('\n') != -1: outfh.write(infh.replace('\n','\r')) else: pass outfh.close() fcount = fcount + 1 return This works well and converted 294 files in 77 seconds on my aging 8100->G3. As an aside, the main reason that I have this recurring need to change endings is that Stuffit 5.5's line conversion facility is broken and has to be disabled or you wind up with all kinds of strange messes. Now all I have to do is decide how to get rid of the original 294 files that have become *.py~ relics. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net --============_-1223782882==_ma============ Content-Type: text/enriched; charset="us-ascii" At 12:29 PM +0200 4/26/01, Francois Granger wrote: hi Francois & thanks for the response. Have a look to the module /lib/module-fileinput.html in the HTML documentation I've used fileinput before and could never get the command line switch to modify files in place to work- it looked like it was just creating temp files even if this did work which is what prompted me to just start from scratch. def strip(f): global fcount infh = open(f, 'rb').read() Gadzooks, using read() works fine while both xreadlines() and readlines() fail at about the same point! I'm not quite sure why that's the case but I appreciate the suggestion. Of course it turned out that some of the files had unix endings instead of windoze endings so I had to change things a bit: Monacodef strip(f): global fcount infh = open(f, 'rb').read() os.rename(f, f +'~') outfh = open(f, 'wb') if infh.find('\r\n') != -1: outfh.write(infh.replace('\n','')) elif infh.find('\n') != -1: outfh.write(infh.replace('\n','\r')) else: pass outfh.close() fcount = fcount + 1 return This works well and converted 294 files in 77 seconds on my aging 8100->G3. As an aside, the main reason that I have this recurring need to change endings is that Stuffit 5.5's line conversion facility is broken and has to be disabled or you wind up with all kinds of strange messes. Now all I have to do is decide how to get rid of the original 294 files that have become *.py~ relics. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net --============_-1223782882==_ma============-- From richar@iis.ee.ethz.ch Fri Apr 27 07:52:18 2001 From: richar@iis.ee.ethz.ch (Christoph Richardet - Mac Sys. Admin IIS ETHZ) Date: Fri, 27 Apr 2001 08:52:18 +0200 Subject: [Pythonmac-SIG] Filelocking Message-ID: Is there a possibility to lock a file on a macintosh for writing (mostly used for cgi-scripts)? From jack@oratrix.nl Fri Apr 27 09:16:42 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 27 Apr 2001 10:16:42 +0200 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate In-Reply-To: Message by Russell E Owen , Wed, 25 Apr 2001 15:31:00 -0700 , Message-ID: <20010427081644.6BFEA312BAB@snelboot.oratrix.nl> > >MacPython 2.1 is ready, as far as I can tell. Please download the installer > >from http://www.cwi.nl/ftp/jack/python/mac/newer and report back > >success/failure. If all goes well I'll put it in the standard place and > >announce it tomorrow. > > I just tested it on a PowerMac G4 running MacOS 9.1. Classic version > (since I use Tk). The basics that I tried work fine -- built in tests > and my own non-Tk code. However, Tk is unfortunately broken. I'm working on this, but it turns out to be painful. There's a couple of new bits in _tkinter that fix the old bug that after Tkinter has done anything at all your Python window doens't work anymore, but they apparently break tkinter itself. I hope to have a new version tonight. Aside from Russel, did anyone else try the new installer? Did it work (except for the Tkinter problem)? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From TattooMabonzoK. Fri Apr 27 21:13:09 2001 From: TattooMabonzoK. (TattooMabonzoK.) Date: Fri, 27 Apr 2001 22:13:09 +0200 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate In-Reply-To: <20010427081644.6BFEA312BAB@snelboot.oratrix.nl> Message-ID: On Friday, April 27, 2001, at 10:16 AM, Jack Jansen wrote: > > Aside from Russel, did anyone else try the new installer? Did it work > (except > for the Tkinter problem)? I did. On Mac OS X 10.0.1 (the full installer). Worked great. I can see that a large number of cosmetic bugs have been corrected :-). There are still a quite a few of them left though (mostly button outline) ;-/ The IDE is still quite ugly (sorry). But now that BBEdit supports python *and* run natively on X that 's less of a problem except for debugging. I must report that running import test.autotest, 2 tests failed (test_asynchat and test_socket) which never happened with the beta. Maybe this is due to the fact that my LAN @ home is running on private IP addresses (the 192.168.xxx.xxx kind) and there're not configured for reverse lookup? --- cut 2 tests failed: test_asynchat test_socket 29 tests skipped: test_al test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gc test_gl test_grp test_imgfile test_largefile test_linuxaudiodev test_locale test_mmap test_nis test_openpty test_poll test_popen2 test_pty test_pwd test_signal test_sunaudiodev test_sundry test_timing test_winreg test_winsound --- cut --- cut test_asynchat The actual stdout doesn't match the expected stdout. This much did match (between asterisk lines): ********************************************************************** test_asynchat Connected ********************************************************************** Then ... We expected (repr): "Received: 'hello world'\n" But instead we got: "error: uncaptured python exception, closing channel (socket.error:(22, 'Invalid argument') [cocoa:users:shared:hacking:python 2.1:lib:asynchat.py|handle_read|82] [cocoa:users:shared:hacking:python 2.1:lib:asyncore.py|recv|349])" The actual stdout doesn't match the expected stdout. This much did match (between asterisk lines): ********************************************************************** test_asynchat Connected ********************************************************************** Then ... We expected (repr): '' But instead we got: ' ' test test_asynchat failed -- Writing: ' ', expected: '' --- cut Btw the case of the file path above are not correct in case (no pun intended :-) it matters. --- cut test_socket test test_socket crashed -- socket.error: host not found --- cut Thanks for the great work and support Jack and everybody else! = tmk = > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig > ++++ > www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction. > htm > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From jack@oratrix.nl Fri Apr 27 22:19:36 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 27 Apr 2001 23:19:36 +0200 Subject: [Pythonmac-SIG] Re: Python installer results. In-Reply-To: Message by Kelvin Chu , Fri, 27 Apr 2001 08:14:19 -0400 , <20010427081419.A67796@elk.uvm.edu> Message-ID: <20010427211941.8BCF0E938F@oratrix.oratrix.nl> Kelvin, I'm sending my reply to the whole list, because your problem has me baffled. Let's see whether anyone else can shed some insight. Recently, Kelvin Chu said: > Hello, Jack; > > Many, many thanks for the hard work you've put in with the MacPython stuff. > I've been using it now for a while on Unix boxes and am delighted to see it > on the Mac. > > I grabbed a copy of the installer from > http://www.cwi.nl/ftp/jack/python/mac/newer/MacPython21full.hqx and ran > into some problems. I'm running on a 450MHz iMac running OSX (10.01, build > 4K78 - updated software from Apple). > > As predicted by the installer, the ConfigurePythonCarbon step fails and I > have to run it by hand. I get the following error. > > Traceback (most recent call last): > File "Moes:SWdev:Jack:Python:Mac:scripts:ConfigurePython.py", line > 199, in ? > File "Moes:SWdev:Jack:Python:Mac:scripts:ConfigurePython.py", line > 162, in main > File "Moes:SWdev:Jack:Python:Mac:scripts:ConfigurePython.py", line > 75, in mkcorealias > file "hatch:users:kelvin:applications:python > 2.1:mac:lib:macostools.py", line 75, in copy > ofp = open(dstfss.as_pathname(), 'wb') > IOError: [Errno 13] Permission denied: > 'Hatch:System:Library:CFMSupport:PythonCore 2.1' What appears to be happening here is that it tries to install PythonCore in the wrong folder. It should put it into /Library/CFMSupport but it tries to put it in /System/Library/CFMSupport. This directory is unwriteable for mere administrators, because it contains Apple's stuff. You might be able to write it as root, but this is not a good idea. For me everything worked fine (also 10.0.0 as admin user). The only thing that I can imagine is that FindFolder has changed between 10.0.0 and 1.0.1 and now it does not create the /Library/CFMSupport folder... Nope, just tried it, it does create it nicely. Hmm, maybe FindFolder fails for some unknown reason on your system. Could you try the following: >>> import macfs >>> import MACFS >>> vrefnum, dirid = macfs.FindFolder(MACFS.kLocalDomain, MACFS.kSharedLibrariesFolderType, 1) >>> fss = macfs.FSSpec((vrefnum, dirid, 'dummy')) >>> print fss.as_pathname() -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Apr 27 22:45:24 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 27 Apr 2001 23:45:24 +0200 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate In-Reply-To: Message by "Tattoo Mabonzo K." , Fri, 27 Apr 2001 22:13:09 +0200 , Message-ID: <20010427214529.B2F31E938F@oratrix.oratrix.nl> Recently, "Tattoo Mabonzo K." said: > I must report that running import test.autotest, 2 tests failed > (test_asynchat and test_socket) which never happened with the beta. Maybe > this is due to the fact that my LAN @ home is running on private IP > addresses (the 192.168.xxx.xxx kind) and there're not configured for > reverse lookup? For test_socket you can indeed expect a failure if reverse lookup isn't configured. For test_asynchat I am not sure. Is anyone else seeing this test fail? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Apr 27 22:49:07 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 27 Apr 2001 23:49:07 +0200 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate In-Reply-To: Message by Russell E Owen , Wed, 25 Apr 2001 15:31:00 -0700 , Message-ID: <20010427214912.6FD8EE938F@oratrix.oratrix.nl> There are new final candidate installers in ftp://www.cwi.nl/ftp/jack/python/mac/newer . The only difference is that there is a new _tkinter.ppc.slb module that should have the bugs fixed that Russell reported. Again, I will wait one more day again to let people give this a try and then I'll move it to the standard place and advertise it. Russell: you are morally obliged to try this after causing me all this work:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From owen@astro.washington.edu Fri Apr 27 23:20:20 2001 From: owen@astro.washington.edu (Russell E Owen) Date: Fri, 27 Apr 2001 15:20:20 -0700 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate In-Reply-To: <20010427214912.6FD8EE938F@oratrix.oratrix.nl> References: <20010427214912.6FD8EE938F@oratrix.oratrix.nl> Message-ID: At 11:49 PM +0200 2001-04-27, Jack Jansen wrote: >There are new final candidate installers in >ftp://www.cwi.nl/ftp/jack/python/mac/newer . This URL didn't work for me. I suspect the correct one is: http://www.cwi.nl/ftp/jack/python/mac/newer I installed (it politely asked if it should remove my old prefs -- much appreciated as I'd not deinstalled the previous 2.1fc). The Tk stuff I tried (that failed last time) all ran fine this time. Thank you very much for fixing it! -- Russell P.S. Just for the heck of it I tried some code that uses file events (which are broken in 2.0 and so I didn't expect them to work in 2.1). In 2.0 the callback function associated with a Tk file event is silently never called. The same code 2.1 gives a runtime error when I try to set up the file event: Tkinter.tkinter.READABLE, self.__readSocket) TypeError: object is not callable: None This is probably a bit of an improvement -- no more silent failure. From owen@astro.washington.edu Fri Apr 27 23:21:18 2001 From: owen@astro.washington.edu (Russell E Owen) Date: Fri, 27 Apr 2001 15:21:18 -0700 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate Message-ID: At 11:49 PM +0200 2001-04-27, Jack Jansen wrote: >There are new final candidate installers in >ftp://www.cwi.nl/ftp/jack/python/mac/newer This URL didn't work for me. I suspect the correct one is: http://www.cwi.nl/ftp/jack/python/mac/newer I installed (it politely asked if it should remove my old prefs -- much appreciated as I'd not deinstalled the previous 2.1fc). The Tk stuff I tried (that failed last time) all ran fine this time. Thank you very much for fixing it! -- Russell P.S. Just for the heck of it I tried some code that uses file events (which are broken in 2.0 and so I didn't expect them to work in 2.1). In 2.0 the callback function associated with a Tk file event is silently never called. The same code 2.1 gives a runtime error when I try to set up the file event: Tkinter.tkinter.READABLE, self.__readSocket) TypeError: object is not callable: None This is probably a bit of an improvement -- no more silent failure. From jack@oratrix.nl Fri Apr 27 23:33:09 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 28 Apr 2001 00:33:09 +0200 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate In-Reply-To: Message by Russell E Owen , Fri, 27 Apr 2001 15:20:20 -0700 , Message-ID: <20010427223314.20A95E938F@oratrix.oratrix.nl> Recently, Russell E Owen said: > At 11:49 PM +0200 2001-04-27, Jack Jansen wrote: > >There are new final candidate installers in > >ftp://www.cwi.nl/ftp/jack/python/mac/newer . > > This URL didn't work for me. I suspect the correct one is: > http://www.cwi.nl/ftp/jack/python/mac/newer You're absolutely right. Silly me... > P.S. Just for the heck of it I tried some code that uses file events > (which are broken in 2.0 and so I didn't expect them to work in 2.1). > In 2.0 the callback function associated with a Tk file event is > silently never called. The same code 2.1 gives a runtime error when I > try to set up the file event: > > Tkinter.tkinter.READABLE, self.__readSocket) > TypeError: object is not callable: None > > This is probably a bit of an improvement -- no more silent failure. Yes, this is a side-effect of the fix I made. I would have expected a NameError, though, on app.createfilehandler(). Oh well, as you say, this is better than it was. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jwblist@olympus.net Sat Apr 28 06:17:54 2001 From: jwblist@olympus.net (John W Baxter) Date: Fri, 27 Apr 2001 22:17:54 -0700 Subject: [Pythonmac-SIG] Re: Python installer results. In-Reply-To: <20010427211941.8BCF0E938F@oratrix.oratrix.nl> References: <20010427211941.8BCF0E938F@oratrix.oratrix.nl> Message-ID: At 23:19 +0200 4/27/01, Jack Jansen wrote: >> I grabbed a copy of the installer from >> http://www.cwi.nl/ftp/jack/python/mac/newer/MacPython21full.hqx and ran >> into some problems. I'm running on a 450MHz iMac running OSX (10.01, build >> 4K78 - updated software from Apple). The "real" 10.0.1 is build 4L13. (I didn't install any of the "prematurely available" ones.) I'll keep Kelvin's message around until after I install. -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From TattooMabonzoK. Sat Apr 28 16:52:06 2001 From: TattooMabonzoK. (TattooMabonzoK.) Date: Sat, 28 Apr 2001 17:52:06 +0200 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate In-Reply-To: <20010427214912.6FD8EE938F@oratrix.oratrix.nl> Message-ID: On Friday, April 27, 2001, at 11:49 PM, Jack Jansen wrote: > There are new final candidate installers in > ftp://www.cwi.nl/ftp/jack/python/mac/newer . > > The only difference is that there is a new _tkinter.ppc.slb module > that should have the bugs fixed that Russell reported. Again, I will > wait one more day again to let people give this a try and then I'll > move it to the standard place and advertise it. Russell: you are > morally obliged to try this after causing me all this work:-) Just double-checked and re-installed the latest candidate. Everything went smooth (with the same minor caveats I mentioned in my previous e-mail). I've just noticed that when Python is the frontmost app, the cursor blinks when it's on located above the PythonInterpreter.out window. It doesn't seem like this is normal behavior although it doesn't seem to do any harm. Again a million thanks to Jack et all for pulling out this carbon native release. I can now live in X and essentially never go back to 9. This is soooooo cool :-)! Bye now, = tmk = > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig > ++++ > www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction. > htm > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From owen@astro.washington.edu Sat Apr 28 18:00:00 2001 From: owen@astro.washington.edu (Russell E Owen) Date: Sat, 28 Apr 2001 10:00:00 -0700 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate In-Reply-To: References: Message-ID: At 5:52 PM +0200 4/28/01, Tattoo Mabonzo K. wrote: >I've just noticed that when Python is the frontmost app, the cursor >blinks when it's on located above the PythonInterpreter.out window. >It doesn't seem like this is normal behavior although it doesn't >seem to do any harm. This is normal-for-Python behavior, at least I've always seen it on my machine while running Tk apps. My guess is it's something about the Tk event loop. -- Russell From TattooMabonzoK. Sat Apr 28 18:09:08 2001 From: TattooMabonzoK. (TattooMabonzoK.) Date: Sat, 28 Apr 2001 19:09:08 +0200 Subject: [Pythonmac-SIG] MacPython 2.1 release candidate In-Reply-To: Message-ID: On Saturday, April 28, 2001, at 07:00 PM, Russell E Owen wrote: > At 5:52 PM +0200 4/28/01, Tattoo Mabonzo K. wrote: >> I've just noticed that when Python is the frontmost app, the cursor >> blinks when it's on located above the PythonInterpreter.out window. It >> doesn't seem like this is normal behavior although it doesn't seem to do >> any harm. > > This is normal-for-Python behavior, at least I've always seen it on my > machine while running Tk apps. My guess is it's something about the Tk > event loop. But this is the plain interpreter. No Tk and on OS X (10.0.1). I haven't seen that behavior in any other (carbon) app. = tmk = > > -- Russell > From kolya@beeb.net Mon Apr 30 08:49:48 2001 From: kolya@beeb.net (Kolya) Date: Mon, 30 Apr 2001 08:49:48 +0100 Subject: [Pythonmac-SIG] Have to run ConfigurePythonCarbon after each reboot Message-ID: I am new to the delights of Python so please excuse my ignorance. I downloaded MacPython 2.1 on April 27, and it looks great! The only problem is that whenever I try running my one and only applet after starting or restarting the Mac, I get the error message: The application ... could not be opened because PythonCoreCarbon could not be found. Then I run ConfigurePythonCarbon and everything works just fine. Until the next reboot. I am running Mac OS 9.0.4. Am I doing something wrong? Kolya Wolf From fgranger@altern.org Fri Apr 27 10:12:28 2001 From: fgranger@altern.org (Francois Granger) Date: Fri, 27 Apr 2001 11:12:28 +0200 Subject: [Pythonmac-SIG] MemoryError Problem In-Reply-To: References: Message-ID: At 22:46 -0400 26/04/01, in message Re: [Pythonmac-SIG] MemoryError Problem, Richard Gordon wrote: >Of course it turned out that some of the files had unix endings >instead of windoze endings so I had to change things a bit: > >def strip(f): > global fcount > infh = open(f, 'rb').read() > os.rename(f, f +'~') > outfh = open(f, 'wb') > if infh.find('\r\n') != -1: > outfh.write(infh.replace('\n','')) > elif infh.find('\n') != -1: > outfh.write(infh.replace('\n','\r')) > else: pass > outfh.close() > fcount = fcount + 1 > return I did this some time ago for the same problem. # -- line ending f = open(file, 'rb') temp = f.read() f.seek(0) crNum = string.count(temp, '\r') lfNum = string.count(temp, '\n') if lfNum == crNum: # dos f.close() os.rename(file, join(doneFolder, split(file)[1][:27]) + '.dos') temp = string.replace(temp, '\n\r', '\n') f = open(file, 'w') f.write(temp) f.close() f = open(file) elif crNum: f.close() os.rename(file, join(doneFolder, split(file)[1][:27]) + '.uix') temp = string.replace(temp, '\r', '\n') f = open(file, 'w') f.write(temp) f.close() f = open(file) -- "Faites des phrases courtes. Un sujet, un verbe, un complément. Quand vous voudrez ajouter un adjectif, vous viendrez me voir." - Georges Clemenceau, 1841-1929, médecin et homme politique français. Consignes aux journalistes de "L'Aurore". d'après