From Jack.Jansen@oratrix.com Thu Aug 1 15:58:46 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 1 Aug 2002 16:58:46 +0200 Subject: [Pythonmac-SIG] PythonLauncher - first stab available In-Reply-To: Message-ID: <2DEB765E-A55F-11D6-B123-003065517236@oratrix.com> On woensdag, juli 31, 2002, at 03:33 , Ian McLaury wrote: > if (([[anApplication currentEvent] modifierFlags] & > NSAlternateKeyMask) == 0) { > // might also check for whether app is launching if > that's important > > // handle file open here > // ... > } I was very excited about this, but I can't get it to work. The modifierFlags never seems to have any value. Here's the event when I print it with NSLog: type=Kitdefined loc=(0,600) time=36645.5 flags=0 win=0 winNum=0 ctxt=0xee53 subtype=1 data1=368 data2=0 -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From aureli@ipk.fhg.de Thu Aug 1 16:41:11 2002 From: aureli@ipk.fhg.de (Aureli Soria Frisch) Date: Thu, 1 Aug 2002 17:41:11 +0200 Subject: [Pythonmac-SIG] Python for Mac OS X (again) In-Reply-To: References: Message-ID: Hi all, I want to change to Mac OS X... I have been gone through the mailing-list in order to find some advices on the best way to do that but I could not get a clear picture of the actual state (sorry...) and still have some questions. I want to use Unix Python on the Mac, since I think it will be easier for me to exchange code/modules with other people in the dept currently programming in Python for Linux. Am I right or have overseen something?. What do I lose by not installing the MacPython for Mac OS X? Fink seems the most comfortable way to install unix-python on Mac OS X. Did you make some bad experiences with that? Could you compare a bit with other binary distributions of unix-python for Mac OS X? How about installing the following packages with fink: NumPy SciPy PIL Gnuplot Tkinter ? I have been using Tkinter for GUI development and thinking on changing to wxPython. The GUIs are not for complex user applications, but for experiment-tools internally used. Basically what I am seeking is to run the GUIs cross-plattform (I was a bit disappointed some Tkinter.widgets were not working right in Linux/Windows). Some opinions are very welcome... Thanks for the time... Best Regards, Aureli PD: Is there any central info point for unix-python on OS X as Jack's page for MacPython? -- ################################# Aureli Soria Frisch Fraunhofer IPK Dept. Pattern Recognition post: Pascalstr. 8-9, 10587 Berlin, Germany e-mail: aureli@ipk.fhg.de fon: +49 30 39006-143 fax: +49 30 3917517 web: http://vision.fhg.de/~aureli/web-aureli_en.html ################################# From ianjones@purgatory.healthmedia.umich.edu Thu Aug 1 19:12:46 2002 From: ianjones@purgatory.healthmedia.umich.edu (Ian McLaury) Date: Thu, 1 Aug 2002 14:12:46 -0400 Subject: [Pythonmac-SIG] PythonLauncher - detect option key In-Reply-To: <2DEB765E-A55F-11D6-B123-003065517236@oratrix.com> References: <2DEB765E-A55F-11D6-B123-003065517236@oratrix.com> Message-ID: At 4:58 PM +0200 8/1/02, Jack Jansen wrote: >I was very excited about this, but I can't get it to work. The >modifierFlags never seems to have any value. Here's the event when I >print it with NSLog: > type=Kitdefined loc=(0,600) time=36645.5 flags=0 win=0 winNum=0 ctxt=0xee53 > subtype=1 data1=368 data2=0 I have had a little success experimenting with this code: - (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename { NSLog(@"currentEvent: %@", [theApplication currentEvent]); if ([[theApplication currentEvent] modifierFlags] & NSAlternateKeyMask) { NSLog(@"option key is down"); } return YES; } I seem to get different kinds of events, I'm not sure why. If I get a 'type=Kitdefined' event, the modifier flags are always 0. With a 'MouseMoved' event or a 'SysDefined' event, the modifier flags are always set appropriately. Those are the three event types I've seen in these experiments. If I hold option down *before* I drag the file onto PythonLauncher (and keep it down throughout the drag and drop) I seem to have a little better luck getting it to generate appropriate modifier flags. If I drag the file onto PythonLauncher, *then* (while still holding down the mouse button) press option and drop the file, the modifier flags seem more likely to be unset. But it's inconsistent. Now I'm searching for NSEvent wisdom on the cocoa-dev list. I'll report back with any enlightenment. Ian From Martina@Oefelein.de Thu Aug 1 20:01:45 2002 From: Martina@Oefelein.de (Martina Oefelein) Date: Thu, 1 Aug 2002 21:01:45 +0200 Subject: [Pythonmac-SIG] PyXML 0.8 build for MacPython? In-Reply-To: References: Message-ID: Has anybody a build of PyXML for MacPython 2.2? At 12:37 Uhr +0200 01.08.2002, Martin v. L=F6wis wrote: >Version 0.8 of the Python/XML distribution is now available. It >should be considered a beta release, and can be downloaded from >the following URLs: > >http://prdownloads.sourceforge.net/pyxml/PyXML-0.8.tar.gz >http://prdownloads.sourceforge.net/pyxml/PyXML-0.8.win32-py2.1.exe >http://prdownloads.sourceforge.net/pyxml/PyXML-0.8.win32-py2.2.exe >http://prdownloads.sourceforge.net/pyxml/PyXML-0.8-2.2.i386.rpm -- ciao Martina From bob@redivi.com Thu Aug 1 21:22:45 2002 From: bob@redivi.com (Bob Ippolito) Date: Thu, 1 Aug 2002 16:22:45 -0400 Subject: [Pythonmac-SIG] PythonLauncher - detect option key In-Reply-To: Message-ID: <70828ECE-A58C-11D6-A0B2-0003938210D6@redivi.com> try this: if (GetCurrentKeyModifiers() & optionKey) { // do your thing } -bob On Thursday, August 1, 2002, at 02:12 PM, Ian McLaury wrote: > At 4:58 PM +0200 8/1/02, Jack Jansen wrote: >> I was very excited about this, but I can't get it to work. The >> modifierFlags never seems to have any value. Here's the event when I >> print it with NSLog: >> type=Kitdefined loc=(0,600) time=36645.5 flags=0 win=0 winNum=0 >> ctxt=0xee53 >> subtype=1 data1=368 data2=0 > > I have had a little success experimenting with this code: > > - (BOOL)application:(NSApplication *)theApplication openFile:(NSString > *)filename { > NSLog(@"currentEvent: %@", [theApplication currentEvent]); > if ([[theApplication currentEvent] modifierFlags] & > NSAlternateKeyMask) { > NSLog(@"option key is down"); > } > return YES; > } > > I seem to get different kinds of events, I'm not sure why. If I get a > 'type=Kitdefined' event, the modifier flags are always 0. With a > 'MouseMoved' event or a 'SysDefined' event, the modifier flags are > always set appropriately. Those are the three event types I've seen in > these experiments. > > If I hold option down *before* I drag the file onto PythonLauncher (and > keep it down throughout the drag and drop) I seem to have a little > better luck getting it to generate appropriate modifier flags. If I > drag the file onto PythonLauncher, *then* (while still holding down the > mouse button) press option and drop the file, the modifier flags seem > more likely to be unset. But it's inconsistent. > > Now I'm searching for NSEvent wisdom on the cocoa-dev list. I'll report > back with any enlightenment. > > Ian > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.com Thu Aug 1 22:19:15 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 1 Aug 2002 23:19:15 +0200 Subject: [Pythonmac-SIG] PythonLauncher - detect option key In-Reply-To: <70828ECE-A58C-11D6-A0B2-0003938210D6@redivi.com> Message-ID: <555F18A2-A594-11D6-9A79-003065517236@oratrix.com> On donderdag, augustus 1, 2002, at 10:22 , Bob Ippolito wrote: > try this: > > if (GetCurrentKeyModifiers() & optionKey) { > // do your thing > } That's exactly what I did, as I was already dragging Carbon in anyway. Great minds think alike:-) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Thu Aug 1 22:47:29 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 1 Aug 2002 23:47:29 +0200 Subject: [Pythonmac-SIG] Python for Mac OS X (again) In-Reply-To: Message-ID: <4719FD1D-A598-11D6-9A79-003065517236@oratrix.com> On donderdag, augustus 1, 2002, at 05:41 , Aureli Soria Frisch wrote: > Fink seems the most comfortable way to install unix-python on > Mac OS X. Did you make some bad experiences with that? > Could you compare a bit with other binary distributions of > unix-python for Mac OS X? > How about installing the following packages with fink: > > NumPy > SciPy > PIL > Gnuplot > Tkinter ? > > I have been using Tkinter for GUI development and thinking on > changing to wxPython. The GUIs are not for complex user > applications, but for experiment-tools internally used. Both for Tkinter and for wxPython you need a framework build of Python. This rules out the current fink distribution, which is a static Python. There's a good framework Python distribution at the wxPython site. > PD: Is there any central info point for unix-python on OS X as > Jack's page for MacPython? At some point in the future my MacPython page will be updated, but I just don't have the time for it right now. Also, things will become a lot simpler when Python 2.3 is going to appear, as then there's really no reason anymore to use the old MacPython if you're on OSX, as the new MacPython (currently referred to as MachoPython) will be a unix-Python based framework build with all the goodies people expect from MacPython. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Robin.Siebler@corp.palm.com Thu Aug 1 23:14:07 2002 From: Robin.Siebler@corp.palm.com (Robin Siebler) Date: Thu, 1 Aug 2002 15:14:07 -0700 Subject: [Pythonmac-SIG] Using Python instead of AppleScript Message-ID: <400CE9390E334A4393CEECDD6863120A04D0B3E4@ussccm003.corp.palm.com> Can anyone give me an example of how to do this? For instance, I have this AppleScript: tell application "CodeWarrior IDE 4.2.5" activate open file "MacOS X 10.1.3:SimpleMac.mcp" dissassemble file "simple.c" end tell How would I do this using python instead? Robin L. Siebler Software Test Engineer Palm --------------------------------------- [Homer can't stop the monorail] Marge Simpson: I've brought somebody to help you. Homer Simpson: Is it Batman? Marge Simpson: It's a scientist. Homer Simpson: Batman's a scientist. Marge Simpson: It's NOT Batman. From billb@mousa.demon.co.uk Fri Aug 2 01:47:38 2002 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Fri, 2 Aug 2002 01:47:38 +0100 Subject: [Pythonmac-SIG] Using Python instead of AppleScript In-Reply-To: <400CE9390E334A4393CEECDD6863120A04D0B3E4@ussccm003.corp.palm.com> References: <400CE9390E334A4393CEECDD6863120A04D0B3E4@ussccm003.corp.palm.com> Message-ID: At 3:14 pm -0700 01/08/02, Robin Siebler wrote: >Can anyone give me an example of how to do this? For instance, I have this >AppleScript: > >tell application "CodeWarrior IDE 4.2.5" > activate > open file "MacOS X 10.1.3:SimpleMac.mcp" > dissassemble file "simple.c" >end tell > >How would I do this using python instead? Untested import CodeWarrior cw =3D CodeWarrior.CodeWarrior(start=3D1) cw.activate() cw.open(CodeWarrior.file(file1)) cw.dissemble_file(CodeWarrior.file(file2)) -- Bill Bedford It was a dodgy transformer again and again. It was a dodgy transformer that cost =A33/10 From mlm@acm.org Fri Aug 2 03:59:48 2002 From: mlm@acm.org (Mitchell L Model) Date: Thu, 1 Aug 2002 22:59:48 -0400 Subject: [Pythonmac-SIG] IDLE on OS X Message-ID: I just reviewed the last four months of Python mailing list mail on Python to see what the status of IDLE is on the Mac, and I'm pretty confused. There seem to be so many variations of Python for OS X that it's hard to tell what works with what. Can someone please summarize the state of IDLE on OS X or post recommendations for using it? I can answer one question: "How do I start IDLE on OS X?". I've never used IDLE before, so this was a non-trivial exercise for me, that included reading various web pages, pointed to in the usual places, about Tk on OS X and using Tkinter in Python on OS X. I still didn't find anything that said how to start IDLE, but with a little experimentation and a lot of guessing, I found at least the following worked (I'm using XDarwin and python 2.2.1 installed via fink): start XDarwin In XDarwin, in an xterm or Emacs shell, do:: % python >>> import Tkinter >>> import idlelib.idle and if everything's OK you get prompted for the IDLE shell window, from which you can open other windows. Whether you can do anything useful after that is another question, which I haven't yet answered. I've downloaded and installed various Tk/Tcl packages for OS X, both from within fink and separately, so unfortunately I can no longer characterize what you can expect to find in an unmoidifed OS X installation, what you get with fink python, what you get with other pythons, what you get by installing Tk/Tcl separately, and so forth. I haven't even figured out yet whether the Tk used when I import Tkinter is the Tk.framework in my /Library/Frameworks folder or one that's somewhere else. (It would be easy enough to move the framework and try again, but I'm afraid to find out that things still work, because then I have to go figure out why :-) It would be nice if someone could clarify for experienced OS X and python programmers who have never done anything with Tk or IDLE how this all ties together. Or point to someplace that does. -- --- Mitchell From Jack.Jansen@cwi.nl Fri Aug 2 08:54:01 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 2 Aug 2002 09:54:01 +0200 Subject: [Pythonmac-SIG] IDLE on OS X In-Reply-To: Message-ID: <0240CCB7-A5ED-11D6-9D96-0030655234CE@cwi.nl> Mitchel, the confusion you see is the result of OSX still being pretty new, and things not having settled down yet. At the moment there are (from a user point of view) three variations of Python for OSX (old MacPython, framework-Python (aka MachoPython, and the candidate for MacPython 2.3 for OSX) and unix-Python) and two variations of Tk (X11-Tk and AquaTk). Out of the six possible combinations 2 or 3 work. The one you picked (unix-Python + X11-Tk + XDarwin server) works, but the consensus is that this is a stopgap: running X11 on OSX is not goint to be something for the masses. The combination that is expected to become the standard is framework-Python with AquaTk, but these should still be considered experimental at this point in time. On Friday, August 2, 2002, at 04:59 , Mitchell L Model wrote: > I just reviewed the last four months of Python mailing list mail on > Python to see what the status of IDLE is on the Mac, and I'm pretty > confused. There seem to be so many variations of Python for OS X that > it's hard to tell what works with what. Can someone please summarize > the state of IDLE on OS X or post recommendations for using it? > > I can answer one question: "How do I start IDLE on OS X?". I've never > used IDLE before, so this was a non-trivial exercise for me, that > included reading various web pages, pointed to in the usual places, > about Tk on OS X and using Tkinter in Python on OS X. I still didn't > find anything that said how to start IDLE, but with a little > experimentation and a lot of guessing, I found at least the following > worked (I'm using XDarwin and python 2.2.1 installed via fink): > > start XDarwin > > In XDarwin, in an xterm or Emacs shell, do:: > > % python > >>> import Tkinter > >>> import idlelib.idle > > and if everything's OK you get prompted for the IDLE shell window, from > which you can open other windows. Whether you can do anything useful > after that is another question, which I haven't yet answered. > > I've downloaded and installed various Tk/Tcl packages for OS X, both > from within fink and separately, so unfortunately I can no longer > characterize what you can expect to find in an unmoidifed OS X > installation, what you get with fink python, what you get with other > pythons, what you get by installing Tk/Tcl separately, and so forth. I > haven't even figured out yet whether the Tk used when I import Tkinter > is the Tk.framework in my /Library/Frameworks folder or one that's > somewhere else. (It would be easy enough to move the framework and try > again, but I'm afraid to find out that things still work, because then > I have to go figure out why :-) It would be nice if someone could > clarify for experienced OS X and python programmers who have never done > anything with Tk or IDLE how this all ties together. Or point to > someplace that does. > -- > --- Mitchell > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From aureli@ipk.fhg.de Fri Aug 2 10:02:43 2002 From: aureli@ipk.fhg.de (Aureli Soria Frisch) Date: Fri, 2 Aug 2002 11:02:43 +0200 Subject: [Pythonmac-SIG] Python for Mac OS X (again) In-Reply-To: <4719FD1D-A598-11D6-9A79-003065517236@oratrix.com> References: <4719FD1D-A598-11D6-9A79-003065517236@oratrix.com> Message-ID: > >Both for Tkinter and for wxPython you need a framework build of >Python. This rules out the current fink distribution, which is a >static Python. There's a good framework Python distribution at the >wxPython site. What is the difference between a framework build of Python and a static Python? >At some point in the future my MacPython page will be updated, but I >just don't have the time for it right now. Also, things will become >a lot simpler when Python 2.3 is going to appear, as then there's >really no reason anymore to use the old MacPython if you're on OSX, >as the new MacPython (currently referred to as MachoPython) will be >a unix-Python based framework build with all the goodies people >expect from MacPython. Sounds great!! When it is planned Python 2.3 for OS X to appear? Thanks. Best regards -- ################################# Aureli Soria Frisch Fraunhofer IPK Dept. Pattern Recognition post: Pascalstr. 8-9, 10587 Berlin, Germany e-mail: aureli@ipk.fhg.de fon: +49 30 39006-143 fax: +49 30 3917517 web: http://vision.fhg.de/~aureli/web-aureli_en.html ################################# From Jack.Jansen@cwi.nl Fri Aug 2 10:25:38 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 2 Aug 2002 11:25:38 +0200 Subject: [Pythonmac-SIG] Python for Mac OS X (again) In-Reply-To: Message-ID: On Friday, August 2, 2002, at 11:02 , Aureli Soria Frisch wrote: >> >> Both for Tkinter and for wxPython you need a framework build of >> Python. This rules out the current fink distribution, which is a >> static Python. There's a good framework Python distribution at the >> wxPython site. > > What is the difference between a framework build of Python and a static > Python? A framework build is a particular way of building that plays nicely with OSX. All of the Python functionality (the core shared library, the Lib directories, etc) are stored in /Library/Frameworks/Python.framework. The commandline "python" interpreter is a tiny skeleton program that links against this. But, more importantly, there's also an alternative interpreter, Python.app, which is a fullblown MacOSX Application (as opposed to a unix commandline tool). To be able to connect to the window server with full functionality you must be running as such a fullblown .app, it seems. >> At some point in the future my MacPython page will be updated, but I >> just don't have the time for it right now. Also, things will become a >> lot simpler when Python 2.3 is going to appear, as then there's really >> no reason anymore to use the old MacPython if you're on OSX, as the >> new MacPython (currently referred to as MachoPython) will be a >> unix-Python based framework build with all the goodies people expect >> from MacPython. > > Sounds great!! When it is planned Python 2.3 for OS X to appear? Early alfa releases should become available real soon now. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tony.mcdonald@ncl.ac.uk Fri Aug 2 13:43:01 2002 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Fri, 02 Aug 2002 13:43:01 +0100 Subject: [Pythonmac-SIG] Python for Mac OS X (again) In-Reply-To: Message-ID: On 2/8/02 10:25 am, "Jack Jansen" wrote: > > On Friday, August 2, 2002, at 11:02 , Aureli Soria Frisch wrote: > >>> >>> Both for Tkinter and for wxPython you need a framework build of >>> Python. This rules out the current fink distribution, which is a >>> static Python. There's a good framework Python distribution at the >>> wxPython site. >> >> What is the difference between a framework build of Python and a static >> Python? > > A framework build is a particular way of building that plays nicely with > OSX. All of the Python functionality (the core shared library, the Lib > directories, etc) are stored in /Library/Frameworks/Python.framework. > The commandline "python" interpreter is a tiny skeleton program that > links against this. But, more importantly, there's also an alternative > interpreter, Python.app, which is a fullblown MacOSX Application (as > opposed to a unix commandline tool). To be able to connect to the window > server with full functionality you must be running as such a fullblown > .app, it seems. > Thanks for the explanation Jack, as someone who's using unix python exclusively (but got there from OS9 MacPython), that's helped to clear things up a little. I'd like to use the framework python in conjunction with the module browser and IDE to code and debug scripts that use unix modules such as MySQLdb and the _xmlplus libraries. Is this something that is going to be doable perhaps? As a test for myself, I downloaded the wx python framework and installed that, I tried to build the IDE in the old way as '% python2.2 BuildIDE.py', but got an error that PythonInterpreter was not found on sys.path. I'll have a dig around and see if I can get that to work when I get a spare hour or two. Anyhow, thanks for the explanation, things are slowly gelling in my head about all these versions of python... Cheers 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.Jansen@cwi.nl Fri Aug 2 14:17:35 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 2 Aug 2002 15:17:35 +0200 Subject: [Pythonmac-SIG] Python for Mac OS X (again) In-Reply-To: Message-ID: <35BE6C64-A61A-11D6-9D96-0030655234CE@cwi.nl> On Friday, August 2, 2002, at 02:43 , Tony McDonald wrote: > As a test for myself, I downloaded the wx python framework and installed > that, I tried to build the IDE in the old way as '% python2.2 > BuildIDE.py', > but got an error that PythonInterpreter was not found on sys.path. I'll > have > a dig around and see if I can get that to work when I get a spare hour > or > two. I haven't used BuildIDE.py, but I wouldn't be surprised if it is OS9-only. From the current CVS I use the following to build the IDE (but this is a fast-moving target, so what was needed at the time the wxpython framework distribution was created I don't remember anymore, and may well be different): pythonw Mac/scripts/BuildApplet.py --output /Applications/PythonIDE.app --noargv Mac/Tools/IDE/PythonIDE.py I think you really need pythonw even though BuildApplet doesn't have a GUI when run from the commandline, because pythonw knows where the applet template is. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Aug 2 16:43:05 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 2 Aug 2002 17:43:05 +0200 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review Message-ID: <89402CF1-A62E-11D6-9D96-0030655234CE@cwi.nl> Folks, if you check out the current head of the CVS repository you'll get all the applet and launcher and other stuff that I plan to include in 2.3. Let me know what you think. Here's the quick instructions: 1. configure --enable-framework 2. make 3. make frameworkinstall 4. make osxapps The last step will do all the goodies. It'll create a folder /Applications/Python that contains PythonLauncher, PythonIDE and BuildApplet. Also, there will be a hidden application /Library/Frameworks/Python.framework/Versions/Current/Resources/Python.app that is used both for executing .pyw scripts by PythonLauncher and as the applet template by BuildApplet and PythonIDE. Applets can be created with sys.argv emulation, i.e. if you drop files on them your script will see the pathnames of the files in sys.argv. This is the default. Alternatively scripts can do their own AppleEvent handling, PythonIDE does this, but you have to invoke BuildApplet form the commandline currently to get that behaviour. A couple of bells and whistles are still needed. Here's what I can come up with, please suggest more: - icons for the .pyw file type and for BuildApplet, - a way to associate .py and .pyw files with either PythonIDE or PythonLauncher from within PythonIDE - moving stuff out of python.rsrc into a library rsrc file so applets become a lot smaller and faster to create. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From managan@llnl.gov Fri Aug 2 17:59:42 2002 From: managan@llnl.gov (Rob Managan) Date: Fri, 2 Aug 2002 09:59:42 -0700 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: <89402CF1-A62E-11D6-9D96-0030655234CE@cwi.nl> References: <89402CF1-A62E-11D6-9D96-0030655234CE@cwi.nl> Message-ID: At 5:43 PM +0200 8/2/2002, Jack Jansen wrote: >Folks, >if you check out the current head of the CVS repository you'll get >all the applet and >launcher and other stuff that I plan to include in 2.3. Let me know >what you think. > >Here's the quick instructions: >1. configure --enable-framework >2. make >3. make frameworkinstall >4. make osxapps > >The last step will do all the goodies. It'll create a folder >/Applications/Python >that contains PythonLauncher, PythonIDE and BuildApplet. Also, there >will be a hidden >application >/Library/Frameworks/Python.framework/Versions/Current/Resources/Python.app >that is >used both for executing .pyw scripts by PythonLauncher and as the >applet template by BuildApplet >and PythonIDE. I went and did a 'cvs update' to get the latest files and followed the instructions above. I can take a script and drop it on PythonLauncher and have it run. When I try to open PythonIDE or drop a script on it the splash screen comes up and then it quits. Any ideas? Do I have a conflict with another copy of Python? How do I diagnose this type of thing??? -- *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan LLNL ph: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From ryanwilcox@mac.com Fri Aug 2 20:42:33 2002 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Fri, 2 Aug 2002 15:42:33 -0400 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: Message-ID: On Friday, August 2, 2002, at 9:59 AM, Rob Managan wrote: >When I try to open PythonIDE or drop a script on it the splash screen >comes up and then it quits. I get that too. BuildApplet and PythonLauncher work fine. PythonIDE quits right after it's splash screen. So, Rob, it's not just you ;), -Ryan Wilcox ---------------- PGP: 0x2F4E9C31 ---------------- From oussoren@cistron.nl Fri Aug 2 20:47:11 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Fri, 2 Aug 2002 21:47:11 +0200 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: Message-ID: Let me join the 'me too' parade... > I've noticed that it quits due to a python exception: > Traceback (most recent call last): > File > "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDE. > py", line 38, in ? > import PythonIDEMain > File > "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDEMain. > py", line 7, in ? > import W > File > "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/W.py", > line 7, in ? > from Wtext import * > File > "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wtext.py" > , line 6, in ? > import waste > ImportError: No module named waste BTW. I only got this for after I did 'chmod g+w' on the Python.framework (my Python.framework is owned by root:admin), this may be the indication of another problem: Apperently normal users need write access to the python installation. IMHO this is something that should be avoided. Ronald From Robin.Siebler@corp.palm.com Fri Aug 2 21:03:47 2002 From: Robin.Siebler@corp.palm.com (Robin Siebler) Date: Fri, 2 Aug 2002 13:03:47 -0700 Subject: [Pythonmac-SIG] MacPython and Python incompatibility? Message-ID: <400CE9390E334A4393CEECDD6863120A04D0B3F0@ussccm003.corp.palm.com> In MacPython 'import findertools' works and it doesn't from the = command-line version of Python. I am assuming that the 2 are = incompatible? This sucks (for me) because I like TAB completion, and = the only way I have found to get TAB completion on the Mac is by using = IPython. And it appears that I cannot use IPython from within = MacPython's interactive window. Any suggestions? Robin L. Siebler Software Test Engineer Palm --------------------------------------- Bart Simpson: [answering the phone] Joe's Taxidermy. You snuff 'em, we = stuff 'em. From Jack.Jansen@oratrix.com Fri Aug 2 21:11:09 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 2 Aug 2002 22:11:09 +0200 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: Message-ID: On vrijdag, augustus 2, 2002, at 09:47 , Ronald Oussoren wrote: > Let me join the 'me too' parade... >> import waste >> ImportError: No module named waste Ah, that's the culprit! The IDE needs the waste module. The waste module will be built by the toplevel make, but only if it can find the waste library. You have to get the waste distribution (from www.merzwaren.com), and make sure it's reachable as one of "../waste", "../../waste", etc. It's probably best to put a symlink "waste" beside the Python distribution that points to the right location. I'll add a better error message to the IDE, and some building notes to the README. > BTW. I only got this for after I did 'chmod g+w' on the > Python.framework (my Python.framework is owned by root:admin), > this may be the indication of another problem: Apperently > normal users need write access to the python installation. IMHO > this is something that should be avoided. Hmm, my Python.framework is owned by jack.admin. Two questions arise: - How come yours is owned by root? did you do a "sudo make install"? I think I suggested that at some point in the past, but I've since then come to the conclusion that this isn't a good idea. So if there's anywhere where this is still suggested I'd like to know where. - Even if the framework is owned by root I don't understand why this should be a problem... Where did things fail? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From oussoren@cistron.nl Fri Aug 2 21:21:48 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Fri, 2 Aug 2002 22:21:48 +0200 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: Message-ID: <7917DD6A-A655-11D6-8E16-0003931CFE24@cistron.nl> On Friday, August 2, 2002, at 10:11 , Jack Jansen wrote: > > On vrijdag, augustus 2, 2002, at 09:47 , Ronald Oussoren wrote: > >> Let me join the 'me too' parade... >>> import waste >>> ImportError: No module named waste > > Ah, that's the culprit! The IDE needs the waste module. The waste > module will be built by the toplevel make, but only if it can find the > waste library. You have to get the waste distribution (from > www.merzwaren.com), and make sure it's reachable as one of "../waste", > "../../waste", etc. It's probably best to put a symlink "waste" beside > the Python distribution that points to the right location. I'll try that. Thanks. > > I'll add a better error message to the IDE, and some building notes to > the README. > >> BTW. I only got this for after I did 'chmod g+w' on the >> Python.framework (my Python.framework is owned by root:admin), this >> may be the indication of another problem: Apperently normal users need >> write access to the python installation. IMHO this is something that >> should be avoided. > > Hmm, my Python.framework is owned by jack.admin. Two questions arise: > - How come yours is owned by root? did you do a "sudo make install"? I > think I suggested that at some point in the past, but I've since then > come to the conclusion that this isn't a good idea. So if there's > anywhere where this is still suggested I'd like to know where. > - Even if the framework is owned by root I don't understand why this > should be a problem... Where did things fail? The problem was that the framework was not writeable by me. In general I try to avoid having files that are writeable by me outside of my home-directory. It is a bit inconvenient, but helps me from accidently trashing my system. But, even if *I* have write-access to system directories, I don't want other users to also have write-access to those directories (not that I normally share my machine with other users, but this is an issue for centrally managed systems) It fails like this: IOError: [Errno 13] Permission denied: '/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Widgets.rsrc. df.rsrc' Traceback (most recent call last): File "./Mac/Tools/IDE/PythonIDE.py", line 35, in ? File "./Mac/Tools/IDE/PythonIDE.py", line 23, in init File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/macresource.py" , line 64, in need refno = open_pathname(pathname) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/macresource.py" , line 92, in open_pathname pathname = _decode(pathname) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/macresource.py" , line 104, in _decode applesingle.decode(pathname, newpathname, resonly=1) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/applesingle.py" , line 74, in decode fp = open(output, 'wb') IOError: [Errno 13] Permission denied: '/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Widgets.rsrc. df.rsrc' Traceback (most recent call last): File "./Mac/Tools/IDE/PythonIDE.py", line 35, in ? File "./Mac/Tools/IDE/PythonIDE.py", line 23, in init File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/macresource.py" , line 64, in need refno = open_pathname(pathname) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/macresource.py" , line 92, in open_pathname pathname = _decode(pathname) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/macresource.py" , line 104, in _decode applesingle.decode(pathname, newpathname, resonly=1) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/applesingle.py" , line 74, in decode fp = open(output, 'wb') Ronald From Jack.Jansen@oratrix.com Fri Aug 2 22:57:54 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 2 Aug 2002 23:57:54 +0200 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: <7917DD6A-A655-11D6-8E16-0003931CFE24@cistron.nl> Message-ID: On vrijdag, augustus 2, 2002, at 10:21 , Ronald Oussoren wrote: >> - Even if the framework is owned by root I don't understand >> why this should be a problem... Where did things fail? > > The problem was that the framework was not writeable by me. In > general I try to avoid having files that are writeable by me > outside of my home-directory. It is a bit inconvenient, but > helps me from accidently trashing my system. But, even if *I* > have write-access to system directories, I don't want other > users to also have write-access to those directories (not that > I normally share my machine with other users, but this is an > issue for centrally managed systems) > > It fails like this: > IOError: [Errno 13] Permission denied: > '/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Widgets. > rsrc. > df.rsrc' Ah! That's an interesting problem... Here's what's going on, maybe someone here has good ideas on how to solve it. The ".rsrc" files in the CVS tree aren't actually resource files: they're resource files encoded as AppleSingle. This is the way MacCVS manages to store two-fork files on a CVS server that is blissfully unaware of this Apple-ism. The macresourced module is aware that a .rsrc file can be either a bona-fide resource file or an AppleSingle file. In the latter case it decodes the file and caches the result as a ".rsrc.df.rsrc" file, with the resources in the data fork. But: if you can't write the directory where the .rsrc resides this fails. Storing the files as datafork-based .rsrc files in CVS will make life miserable for me when building on OS9. Checking the files out with MacCVS will make the standard unix tarball distribution non-functional on OSX. Hmm, I could probably pre-convert the files while installing, similar to the precompilation step for .pyc and .pyo files.... Could you file a sourceforge bug report for this, please, so I won't forget? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From kevino@tulane.edu Sat Aug 3 05:56:36 2002 From: kevino@tulane.edu (Kevin Ollivier) Date: Sat, 3 Aug 2002 00:56:36 -0400 Subject: [Pythonmac-SIG] Testing Latest Mac(ho)Python Message-ID: <63ADA952-A69D-11D6-A237-00039384E8D4@tulane.edu> Hi all, The release of the new Mac(ho)Python is good timing - I was planning on testing out my wxPython on OS X this weekend. =) Compiling and setup all went fine. PythonLauncher is really cool, gives plenty of config options and I like the fact that you can associate Python scripts with either Python.app or PythonLauncher.app. =) Haven't tried BuildApplet yet, but I probably will give it a spin later this weekend. (Just curious, will the "BuildApplication" type functionality be added to MachoPython?) I did however run into one problem, with PythonIDE.app. For some reason, a mkdirs function in macostools.py seems to be getting caught in an infinite loop every time I try running it. Here's the traceback: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDE. py", line 38, in ? import PythonIDEMain File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDEMain. py", line 282, in ? PythonIDE() File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDEMain. py", line 30, in __init__ Wapplication.Application.__init__(self, 'Pide') File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication. py", line 27, in __init__ FrameWork.Application.__init__(self) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/FrameWork.py", line 113, in __init__ self.makemenubar() File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication. py", line 266, in makemenubar self.makeusermenus() File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/PythonIDEMain. py", line 127, in makeusermenus prefs = self.getprefs() File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/Wapplication. py", line 401, in getprefs return MacPrefs.GetPrefs(self.preffilepath) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/MacPrefs. py", line 104, in GetPrefs macostools.mkdirs(head) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/macostools.py", line 60, in mkdirs mkdirs(head) ... ... File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/macostools.py", line 60, in mkdirs mkdirs(head) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/macostools.py", line 55, in mkdirs if dst == '' or os.path.exists(dst): RuntimeError: maximum recursion depth exceeded Any ideas? It seems like Python is really shaping up on OS X - so far my wxPython app is running almost exactly like the Windows version! I hadn't played with wxPython or MachoPython for a couple months, and in that short time they've come a long way! =) Kevin From tony.mcdonald@ncl.ac.uk Sat Aug 3 15:15:01 2002 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Sat, 03 Aug 2002 15:15:01 +0100 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: <89402CF1-A62E-11D6-9D96-0030655234CE@cwi.nl> Message-ID: On 2/8/02 4:43 pm, "Jack Jansen" wrote: > Folks, > if you check out the current head of the CVS repository you'll get all > the applet and > launcher and other stuff that I plan to include in 2.3. Let me know what > you think. > > Here's the quick instructions: > 1. configure --enable-framework Ok so far... > 2. make I get this error; /usr/local/bin/install -c -m 644 ./Mac/OSXResources/framework/English.lproj/InfoPlist.strings \ Python.framework/Versions/2.3/Resources/English.lproj/InfoPlist.strings ln -fsh 2.3 Python.framework/Versions/Current ln: invalid option -- h Try `ln --help' for more information. make: *** [Python.framework/Versions/2.3/Python] Error 1 Anyone know what I'm doing wrong? Specs are: 10.1.5, dev tools from december. % cc -v Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs Apple Computer, Inc. version gcc-934.3, based on gcc version 2.95.2 19991024 (release) Cheers 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 zbir@urbanape.com Sat Aug 3 16:08:00 2002 From: zbir@urbanape.com (Zachery Bir) Date: Sat, 3 Aug 2002 11:08:00 -0400 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: Message-ID: On Saturday, August 3, 2002, at 10:15 , Tony McDonald wrote: > Ok so far... > >> 2. make > > I get this error; > > /usr/local/bin/install -c -m 644 > ./Mac/OSXResources/framework/English.lproj/InfoPlist.strings \ > > Python.framework/Versions/2.3/Resources/English.lproj/InfoPlist.strings > ln -fsh 2.3 Python.framework/Versions/Current > ln: invalid option -- h > Try `ln --help' for more information. > make: *** [Python.framework/Versions/2.3/Python] Error 1 > > Anyone know what I'm doing wrong? Most likely you're using fink's ln, which has no -h switch. Try editing your Makefile to specify LN=/bin/ln or from your shell, try $ LN=/bin/ln make Zac From steph-info@wanadoo.fr Sat Aug 3 18:29:58 2002 From: steph-info@wanadoo.fr (Stephane Serra) Date: Sat, 3 Aug 2002 19:29:58 +0200 Subject: [Pythonmac-SIG] Bus error failure while building readline Message-ID: Hello, Trying to compile MachoPython 2.3 updated today via cvs, I got the following error: """/sw/src/Python CVS/python/dist/src/Modules/readline.c:533: warning:=20= return makes pointer from integer without a cast gcc -Wl,-F. -bundle -framework Python build/temp.darwin-5.5-Power=20 Macintosh-2.3/readline.o -L/usr/lib/termcap=20 -L/Library/Frameworks/Python.framework/Versions/2.3/lib -L/usr/local/lib=20= -lreadline -lncurses -o build/lib.darwin-5.5-Power=20 Macintosh-2.3/readline.so /usr/bin/ld: warning unused multiple definitions of symbol _tgoto /usr/local/lib/libncurses.dylib(lib_tgoto.o) definition of _tgoto /usr/lib/libSystem.dylib(tgoto.o) unused definition of _tgoto /usr/bin/ld: warning unused multiple definitions of symbol _tputs /usr/local/lib/libncurses.dylib(lib_tputs.o) definition of _tputs /usr/lib/libSystem.dylib(tputs.o) unused definition of _tputs /usr/bin/ld: warning unused multiple definitions of symbol _BC /usr/local/lib/libncurses.dylib(lib_termcap.o) definition of _BC /usr/lib/libSystem.dylib(curses.o) unused definition of _BC /usr/bin/ld: warning unused multiple definitions of symbol _PC /usr/local/lib/libncurses.dylib(lib_tputs.o) definition of _PC /usr/lib/libSystem.dylib(curses.o) unused definition of _PC /usr/bin/ld: warning unused multiple definitions of symbol _UP /usr/local/lib/libncurses.dylib(lib_termcap.o) definition of _UP /usr/lib/libSystem.dylib(curses.o) unused definition of _UP /usr/bin/ld: warning unused multiple definitions of symbol _tgetent /usr/local/lib/libncurses.dylib(lib_termcap.o) definition of _tgetent /usr/lib/libSystem.dylib(termcap.o) unused definition of _tgetent /usr/bin/ld: warning unused multiple definitions of symbol _tgetflag /usr/local/lib/libncurses.dylib(lib_termcap.o) definition of _tgetflag /usr/lib/libSystem.dylib(termcap.o) unused definition of _tgetflag /usr/bin/ld: warning unused multiple definitions of symbol _tgetnum /usr/local/lib/libncurses.dylib(lib_termcap.o) definition of _tgetnum /usr/lib/libSystem.dylib(termcap.o) unused definition of _tgetnum /usr/bin/ld: warning unused multiple definitions of symbol _tgetstr /usr/local/lib/libncurses.dylib(lib_termcap.o) definition of _tgetstr /usr/lib/libSystem.dylib(termcap.o) unused definition of _tgetstr /usr/bin/ld: warning unused multiple definitions of symbol _ospeed /usr/local/lib/libncurses.dylib(lib_tputs.o) definition of _ospeed /usr/lib/libSystem.dylib(tputs.o) unused definition of _ospeed /usr/bin/ld: warning unused multiple definitions of symbol _stdscr /usr/local/lib/libncurses.dylib(lib_data.o) definition of _stdscr /usr/lib/libSystem.dylib(curses.o) unused definition of _stdscr /usr/bin/ld: warning unused multiple definitions of symbol _curscr /usr/local/lib/libncurses.dylib(lib_data.o) definition of _curscr /usr/lib/libSystem.dylib(curses.o) unused definition of _curscr /usr/bin/ld: warning unused multiple definitions of symbol _LINES /usr/local/lib/libncurses.dylib(lib_setup.o) definition of _LINES /usr/lib/libSystem.dylib(curses.o) unused definition of _LINES /usr/bin/ld: warning unused multiple definitions of symbol _COLS /usr/local/lib/libncurses.dylib(lib_setup.o) definition of _COLS /usr/lib/libSystem.dylib(curses.o) unused definition of _COLS /usr/bin/ld: warning unused multiple definitions of symbol _ttytype /usr/local/lib/libncurses.dylib(lib_setup.o) definition of _ttytype /usr/lib/libSystem.dylib(setterm.o) unused definition of _ttytype make: *** [sharedmods] Bus error""" I previously got an error about /usr/lib/termcap directory=20 unavailability then after a quick search I found it in /usr/share/misc/termcap and made a symlink in /usr/lib.... I wonder if this is correct... I'm running OSX 10.1.5 and never had this kind of problem compiling python. Could anyone suggest a workaround ? Thanks very much. St=E9phane Serra. =09 =09 From tony.mcdonald@ncl.ac.uk Sat Aug 3 19:09:34 2002 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Sat, 03 Aug 2002 19:09:34 +0100 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: Message-ID: On 3/8/02 4:08 pm, "Zachery Bir" wrote: > On Saturday, August 3, 2002, at 10:15 , Tony McDonald wrote: > >> Ok so far... >> >>> 2. make >> >> I get this error; >> >> /usr/local/bin/install -c -m 644 >> ./Mac/OSXResources/framework/English.lproj/InfoPlist.strings \ >> >> Python.framework/Versions/2.3/Resources/English.lproj/InfoPlist.strings >> ln -fsh 2.3 Python.framework/Versions/Current >> ln: invalid option -- h >> Try `ln --help' for more information. >> make: *** [Python.framework/Versions/2.3/Python] Error 1 >> >> Anyone know what I'm doing wrong? > > Most likely you're using fink's ln, which has no -h switch. Try > editing your Makefile to specify LN=/bin/ln or from your shell, try > > $ LN=/bin/ln make > > Zac > Cheers for that Zac, That certainly helped, I do have fink installed - I edited the Makefile to assign LN to /bin/ln and things got a bit further along. I installed the April dev tools and tried again. Now I'm getting this though; gcc -Wl,-F. -bundle -framework Python build/temp.darwin-5.5-Power Macintosh-2.3/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.darwin-5.5-Power Macintosh-2.3/readline.so /usr/bin/ld: warning -L: directory name (/usr/lib/termcap) does not exist make: *** [sharedmods] Bus error A 'locate termcap' says the following; 168[17:51]tonymcd@localhost python/dist/src % locate termcap /Applications/Emacs.app/Contents/Resources/share/emacs/20.7/etc/termcap.src /sw/include/termcap.h /sw/share/man/man3/curs_termcap.3x /sw/src/ncurses-5.2-6/ncurses-5.2/objects/read_termcap.o /sw/src/ncurses-5.2-6/ncurses-5.2/obj_s/read_termcap.o /System/Library/Perl/termcap.pl /Users/tonymcd/.termcap /usr/local/include/termcap.h /usr/local/share/man/man3/curs_termcap.3x /usr/share/emacs/20.7/etc/termcap.src /usr/share/man/man3/termcap.3 /usr/share/man/man5/termcap.5 /usr/share/misc/termcap /usr/share/misc/termcap.db /usr/X11R6/lib/X11/etc/xterm.termcap So I don't seem to have /usr/lib/termcap anywhere on my system...(rebuilt locate.db and did a root level 'find') I'll see if I can build the thing from source... 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.Jansen@oratrix.com Sat Aug 3 21:06:30 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 3 Aug 2002 22:06:30 +0200 Subject: [Pythonmac-SIG] Bus error failure while building readline In-Reply-To: Message-ID: <80726430-A71C-11D6-851A-003065517236@oratrix.com> Stephane and Tony, Both of you seem to have installed fink stuff. I haven't, so that's why your seeing problems I don't see, could you help me debugging this? I don't want to install fink, exactly because of the problems you're seeing: if I were preparing the distribution on a system with lots of fink-installed stuff there's too much chance of breaking things for people who don't use fink. (Especially since one of the fink-people told me they're moving away from the policy of putting everything into /sw I'm afraid to taint my system, I'd like to keep it as vanilla as possible). I'd like the distribution to run unmodified both for people using vanilla OSX and people using fink-enhanced OSX, but for this I need feedback (such as the 'ln' issue). And if it turns out to be too much work at the very least there'll need to be a note in the readme file telling people about things like the LN=/bin/ln trick. On to the problem at hand, which seems to be with readline for both of you, although the actual symptoms are different. In both cases setup.py seems to be thrown into confusion. In Tony's case I think that the problem is that you have /usr/local/include/termcap.h, which makes setup.py guess you have termcap installed into /usr/local, and hence the termcap library in /usr/local/lib/termcap.a (or .so). If there is a legitimate reason for having termcap.h and not termcap.a (i.e. if this isn't caused by some partial install or other local problem): could you suggest a mod to setup.py to detect this situation? Stephane's problem is a different one: here we have a conflict of curses versions. Apple ships a very old (and unusable to Python) curses version, and while the newer library correctly obscures the older one (in libSystem.dylib) something apparently still goes wrong. My guess is that the bus error happens when setup.py tries to actually import the readline module it has just created (a sanity check it does for all modules it builds). Could you try importing the module under gdb to get a stacktrace and see where it fails? Has anyone gotten the readline module to build under recent versions of OSX Python? How? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sat Aug 3 21:16:37 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 3 Aug 2002 22:16:37 +0200 Subject: [Pythonmac-SIG] Fink and ln -fsh Message-ID: Question: does the fink "ln" have the -n option to forestall following symlinks in the destination? For OSX ln -n is a synonym for -h, so I could use "ln -fsn" in the Makefile... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sat Aug 3 21:39:09 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 3 Aug 2002 22:39:09 +0200 Subject: [Pythonmac-SIG] Testing Latest Mac(ho)Python In-Reply-To: <63ADA952-A69D-11D6-A237-00039384E8D4@tulane.edu> Message-ID: <102087EE-A721-11D6-851A-003065517236@oratrix.com> On zaterdag, augustus 3, 2002, at 06:56 , Kevin Ollivier wrote: > I did however run into one problem, with PythonIDE.app. For > some reason, a mkdirs function in macostools.py seems to be > getting caught in an infinite loop every time I try running it. > Here's the traceback: This is a silly bug in macostools.py: it still caters for :-separated pathnames only. I'll fix it shortly. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bob@redivi.com Sat Aug 3 21:53:03 2002 From: bob@redivi.com (Bob Ippolito) Date: Sat, 3 Aug 2002 16:53:03 -0400 Subject: [Pythonmac-SIG] Bus error failure while building readline In-Reply-To: <80726430-A71C-11D6-851A-003065517236@oratrix.com> References: <80726430-A71C-11D6-851A-003065517236@oratrix.com> Message-ID: <20020803165303.A19012@redivi.com> On Sat, Aug 03, 2002 at 10:06:30PM +0200, Jack Jansen wrote: > Stephane and Tony, > Both of you seem to have installed fink stuff. I haven't, so > that's why your seeing problems I don't see, could you help me > debugging this? I don't want to install fink, exactly because of > the problems you're seeing: if I were preparing the distribution > on a system with lots of fink-installed stuff there's too much > chance of breaking things for people who don't use fink. > (Especially since one of the fink-people told me they're moving > away from the policy of putting everything into /sw I'm afraid > to taint my system, I'd like to keep it as vanilla as possible). -cut- All they have to do is take the "source /sw/bin/init.csh" or whatever the heck it is out of their ~/.cshrc and start up a new terminal.. I'm with you, there's no good reason to support fink people when they're compiling non-fink-based software. All they have to do is turn it off to get a normal OS X environment; it's certainly not worth your time to try and "debug" these issues. -bob From tony.mcdonald@ncl.ac.uk Sat Aug 3 23:19:39 2002 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Sat, 03 Aug 2002 23:19:39 +0100 Subject: [Pythonmac-SIG] Bus error failure while building readline In-Reply-To: <80726430-A71C-11D6-851A-003065517236@oratrix.com> Message-ID: On 3/8/02 9:06 pm, "Jack Jansen" wrote: > Stephane and Tony, > Both of you seem to have installed fink stuff. I haven't, so > that's why your seeing problems I don't see, could you help me > debugging this? I'll do what I can Jack, but I'm no expert in setup.py or distutils. > I don't want to install fink, exactly because of > the problems you're seeing: if I were preparing the distribution > on a system with lots of fink-installed stuff there's too much > chance of breaking things for people who don't use fink. > (Especially since one of the fink-people told me they're moving > away from the policy of putting everything into /sw I'm afraid > to taint my system, I'd like to keep it as vanilla as possible). > I can completely understand that. I've certainly accepted that by using fink, 'all bets are off' and that I'm on my own, and that it's much more important to have an OSX python that works on stock systems! :) I've looked at the fink FAQ and it seems that almost all the files it wants are installed in /sw. The reason I started using fink is that I had problems using the Apple compiler to get things like gnuplot compiled, and in the process I've populated /usr/local/ with quite a few things (gnu tar and unix python being a few of them). > I'd like the distribution to run unmodified both for people > using vanilla OSX and people using fink-enhanced OSX, but for > this I need feedback (such as the 'ln' issue). And if it turns > out to be too much work at the very least there'll need to be a > note in the readme file telling people about things like the > LN=/bin/ln trick. > That's the ideal, certainly. I'm not sure that the problem I have is due to fink though - it's probably something to do with my 'fiddling around' with /usr/local/ isn't it? I have the luxury of another, clean, OSX system - but unfortunately it doesn't have the developer tools on it (and unfortunately there's not enough space to install the dev tools). There's a /usr/local/ directory, but there's nothing in it. > On to the problem at hand, which seems to be with readline for > both of you, although the actual symptoms are different. In both > cases setup.py seems to be thrown into confusion. > > In Tony's case I think that the problem is that you have > /usr/local/include/termcap.h, which makes setup.py guess you > have termcap installed into /usr/local, and hence the termcap > library in /usr/local/lib/termcap.a (or .so). If there is a > legitimate reason for having termcap.h and not termcap.a (i.e. > if this isn't caused by some partial install or other local > problem): could you suggest a mod to setup.py to detect this > situation? > I changed /usr/local/include/termcap.h to termcap.h-, did make clean; ./configure --enable-framework and then make. Got the same error though. Bob sent this in: -cut- All they have to do is take the "source /sw/bin/init.csh" or whatever the heck it is out of their ~/.cshrc and start up a new terminal.. I'm with you, there's no good reason to support fink people when they're compiling non-fink-based software. All they have to do is turn it off to get a normal OS X environment; it's certainly not worth your time to try and "debug" these issues. -bob I've already done that Bob, there's no fink stuff in path or environment variables or anything else. This seems to be a problem with compiling up stuff into /usr/local/ previously. I definitely agree it's not worth Jacks' time to try and debug fink issues. I decided to be more pragmatic than correct about this, and changed the LN variable in Makefile to /bin/ln. I also commented out some lines in setup.py .... 384 - 386 readline_libs.append('termcap') # exts.append( Extension('readline', ['readline.c'], # library_dirs=['/usr/lib/termcap'], # libraries=readline_libs) ) (I know this is a bloody awful 'solution') The 'make', 'make frameworkinstall' and 'make osxapps' now work. I now get the 'splash screen' problem with the IDE. That's ok, I can deal with that tomorrow morning as I'm a bit knackered now. Thanks for all the help in getting this far, 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 dp@ulaluma.com Sun Aug 4 00:57:52 2002 From: dp@ulaluma.com (Donovan Preston) Date: Sat, 03 Aug 2002 16:57:52 -0700 Subject: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture Message-ID: Hello, I'm glad there is a significant amount of activity and interest in the latest Mach-O python features. Since there seem to be a significant number of people attempting to use Mach-O python for the first time, and a few have encountered difficulties, I thought I'd write up a step-by-step howto incorporating a fink workaround and including instructions for getting WASTE. I posted it to my blog: http://www.ulaluma.com/pyx Please, let me know if you have problems following the instructions here and I will revise them. Donovan From jacobkm@cats.ucsc.edu Sun Aug 4 04:45:28 2002 From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss) Date: Sat, 3 Aug 2002 20:45:28 -0700 Subject: [Pythonmac-SIG] Fink and ln -fsh In-Reply-To: References: Message-ID: >Question: does the fink "ln" have the -n option to forestall >following symlinks in the destination? For OSX ln -n is a synonym >for -h, so I could use "ln -fsn" in the Makefile... Yes: [localhost:~] jacob% /sw/bin/ln --help [...snip...] -n, --no-dereference treat destination that is a symlink to a directory as if it were a normal file [...snip...] Jacob From tony.mcdonald@ncl.ac.uk Sun Aug 4 10:48:10 2002 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Sun, 04 Aug 2002 10:48:10 +0100 Subject: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: Message-ID: On 4/8/02 12:57 am, "Donovan Preston" wrote: > Hello, >=20 > I'm glad there is a significant amount of activity and interest in the > latest Mach-O python features. Since there seem to be a significant numbe= r > of people attempting to use Mach-O python for the first time, and a few h= ave > encountered difficulties, I thought I'd write up a step-by-step howto > incorporating a fink workaround and including instructions for getting > WASTE. I posted it to my blog: >=20 > http://www.ulaluma.com/pyx >=20 > Please, let me know if you have problems following the instructions here = and > I will revise them. >=20 > Donovan >=20 Well, I'm back after a good nights sleep. Your HowTo page is very helpful Donovan - thanks a lot. Certainly, setting the PATH explicitly takes out the fink connection (and the 'necessity' to change the LN to be /bin/ln). It doesn=B9t get around the bus errors due to readline, so I had to keep the commented lines in (384-386). The plus side is that the IDE now works with the information provided on adding the waste engine. Very nice it is too! Course, now I need to try and figure out how to get the AdvancedEditor patc= h to work! :) [[ Side note: the ln that is in /usr/local/bin (ie my gnu one) seems to wor= k the same as the fink version as reported by Jacob. ]] One last thing - most of my python work is on solaris. I got there via MacPython and really wanted to use the PythonIDE to edit scripts that were going to be deployed on solaris. I tried to get MySQLdb running under the MacPython (classic) installation so I could try my scripts out. No joy ther= e (this was using CodeWarrior a few years back). That's the main reason that I got into the unix version of python on OSX, I could use MySQLdb and others (through vim) and edit things locally, before deploying on solaris - but I lost the PythonIDE ability. Sorry for rambling, but if I wanted to get the PythonIDE to edit scripts fo= r unix modules - what's the best way of doing it? I have just two other questions abut the FrameworkPython too (please shout out if I've missed something obvious, and it's already documented); 1) Is there a 'terminal' version of it? /Library/Frameworks/Python.framework/Versions/2.3/bin/python gives a bus error; Python 2.3a0 (#19, Aug 4 2002, 09:36:17) [GCC 2.95.2 19991024 (release)] on darwin Type "help", "copyright", "credits" or "license" for more information. Bus error And finally! 2) how do you ensure that when you install a new module, it goes in the right place? Ie, presumably, /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ Honest - *big* thanks for the help so far! Cheers, Tone. --=20 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 tony.mcdonald@ncl.ac.uk Sun Aug 4 11:48:33 2002 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Sun, 04 Aug 2002 11:48:33 +0100 Subject: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: Message-ID: On 4/8/02 10:48 am, "Tony McDonald" wrote: > I have just two other questions abut the FrameworkPython too (please shout > out if I've missed something obvious, and it's already documented); > > 1) Is there a 'terminal' version of it? > /Library/Frameworks/Python.framework/Versions/2.3/bin/python gives a bus > error; > Python 2.3a0 (#19, Aug 4 2002, 09:36:17) > [GCC 2.95.2 19991024 (release)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > Bus error Don't know about this bit - I still get a bus error. I could be missing the point a bit here as I (obviously) get a terminal window within the IDE. However... > > And finally! > 2) how do you ensure that when you install a new module, it goes in the > right place? Ie, presumably, > /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ > % /Library/Frameworks/Python.framework/Versions/Current/bin/python setup.py build % /Library/Frameworks/Python.framework/Versions/Current/bin/python setup.py install (why no bus error?) Puts the modules (at least MySQLdb from http://sourceforge.net/projects/mysql-python) into the right place, ie the Framework python with no API mismatches or the like. I've just run a quick MySQL python script in the IDE and it works :) *Very* nice! - now, about that AdvancedEditor patch ... 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 dan@grassi.org Sun Aug 4 17:53:11 2002 From: dan@grassi.org (Dan Grassi) Date: Sun, 4 Aug 2002 12:53:11 -0400 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: <89402CF1-A62E-11D6-9D96-0030655234CE@cwi.nl> Message-ID: Jack, Thanks for all the hard work, things are really looking terrific! Also thanks to all those who have contributed the various pieces , MacPython in and all it's capabilities is really coming together! On Friday, August 2, 2002, at 11:43 AM, Jack Jansen wrote: I noticed a few problems: 1) /Library/Frameworks/Python.framework/Versions/2.3/Mac/scripts is not created 2) There need to be sym-links in /usr/local/bin to python and pythonw at a minimum. There may be issues with this because of prior installs such as the WxPython version of python which creates these symlinks so they may be present but point to the wrong place such as: /usr/local/bin/pythonw -> /Library/Frameworks/Python.framework/Versions/2.2/bin/python (notice the 2.2 instead of current). > make frameworkinstall I found the following errors but I understand that this is pre-alpha (cvs head): Compiling /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ wxPython/lib/grids.py ... File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ wxPython/lib/grids.py", line 129 w = (sz.width - (ncols - 1) * self.hgap) / ncols; ^ SyntaxError: inconsistent use of tabs and spaces in indentation Compiling /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ wxPython/lib/imagebrowser.py ... File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ wxPython/lib/imagebrowser.py", line 293 self.files = filelist ^ SyntaxError: inconsistent use of tabs and spaces in indentation Compiling /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ wxPython/lib/mixins/listctrl.py ... File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ wxPython/lib/mixins/listctrl.py", line 150 """ Standard initialiser. ^ SyntaxError: inconsistent use of tabs and spaces in indentation Compiling /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ wxPython/lib/pyshell.py ... File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ wxPython/lib/pyshell.py", line 251 braceOpposite = -1 ^ SyntaxError: inconsistent use of tabs and spaces in indentation Compiling /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ wxPython/lib/wxpTag.py ... File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ wxPython/lib/wxpTag.py", line 244 while i Message-ID: On 8/4/02 2:48 AM, "Tony McDonald" wrote: > 1) Is there a 'terminal' version of it? > /Library/Frameworks/Python.framework/Versions/2.3/bin/python gives a bus > error; > Python 2.3a0 (#19, Aug 4 2002, 09:36:17) > [GCC 2.95.2 19991024 (release)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > Bus error That is indeed the 'terminal' version. You shouldn't be getting a bus error... All I can think is that it's because of the version of readline you have installed. Seems about right; readline works only for interactive input, therefore setup.py build works; and the ide doesn't use readline so that works properly... So, try uninstalling readline and recompiling. Or, figure out how to get a readline installed that doesn't crash the interactive interpreter, because I would like to be able to use it as well :) Finally, about the advanced editor patch, it's simply a matter of changing all of the toolbox module imports from "import Blah" to "from Carbon import Blah"... Otherwise, I didn't have to change a thing to get the advanced editor to work. I will try to apply it to my fresh copy of the IDE I installed yesterday and post another step-by-step for people interested in having this functionality. By the way, Jack or Just, how come this functionality was never incorporated into the base IDE? It has some funny behavior, but syntax coloring alone is totally worth it... Donovan http://www.ulaluma.com/pyx From tony.mcdonald@ncl.ac.uk Sun Aug 4 20:22:51 2002 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Sun, 04 Aug 2002 20:22:51 +0100 Subject: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: Message-ID: On 4/8/02 7:56 pm, "Donovan Preston" wrote: >> 1) Is there a 'terminal' version of it? >> /Library/Frameworks/Python.framework/Versions/2.3/bin/python gives a bus >> error; >> Python 2.3a0 (#19, Aug 4 2002, 09:36:17) >> [GCC 2.95.2 19991024 (release)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> Bus error > > That is indeed the 'terminal' version. You shouldn't be getting a bus > error... All I can think is that it's because of the version of readline you > have installed. Seems about right; readline works only for interactive > input, therefore setup.py build works; and the ide doesn't use readline so > that works properly... > That sounds about right... > So, try uninstalling readline and recompiling. Or, figure out how to get a > readline installed that doesn't crash the interactive interpreter, because I > would like to be able to use it as well :) > I wish I could, but I'm at my limit of being able to do this in framework land. I think if I could get something like that working (interactive interpreter, framework python, IDE running 'unix' modules like MySQLdb), then I'd be very happy. However, two out of three isn't bad! :) > Finally, about the advanced editor patch, it's simply a matter of changing > all of the toolbox module imports from "import Blah" to "from Carbon import > Blah"... Otherwise, I didn't have to change a thing to get the advanced > editor to work. I will try to apply it to my fresh copy of the IDE I > installed yesterday and post another step-by-step for people interested in > having this functionality. > That's very interesting. I posted something earlier this afternoon that's on hold due to the attachment I posted. The attachment is a edited version of PyEdit.py that includes the changes that Joe Strouts patch would apply to get syntax colouring enabled. The 'clean' PyEdit.py doesn't seem to have anything syntax colouring code in it - perhaps you're using a PyEdit that you've already edited Donovan? There certainly seem to be differences between PyEdit from CVS and an old copy of have from MacPython 2.1. > By the way, Jack or Just, how come this functionality was never incorporated > into the base IDE? It has some funny behavior, but syntax coloring alone is > totally worth it... > Totally agree there Donovan, but then, it's not me that's putting these (increasingly good) python distributions together :) 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 dan@grassi.org Sun Aug 4 20:52:02 2002 From: dan@grassi.org (Dan Grassi) Date: Sun, 4 Aug 2002 15:52:02 -0400 Subject: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: <219C0FD6-A7E0-11D6-80CC-00039346A28A@grassi.org> Message-ID: On Sunday, August 4, 2002, at 02:56 PM, Donovan Preston wrote: > Finally, about the advanced editor patch, it's simply a matter of > changing > all of the toolbox module imports from "import Blah" to "from Carbon > import > Blah"... Otherwise, I didn't have to change a thing to get the advanced > editor to work. I will try to apply it to my fresh copy of the IDE I > installed yesterday and post another step-by-step for people interested > in > having this functionality. But there is another issue, AdvancedEditorPatch.py does not work but it is a simple fix. The first insert: PyEdit.InsertAfter(" self.run_as_main = 0", """ if self.settings.has_key("syntax_coloring"): self.syntax_coloring = self.settings["syntax_coloring"] else: self.syntax_coloring = 1 """) does not work because of changes in PyEdit.py in the 2.3 cvs tree. Instead it needs to be: PyEdit.InsertAfter(r""" self.run_as_main = self.settings.get("run_as_main", 0)""", r""" self.syntax_coloring = self.settings.get("syntax_coloring", 0) """) Without this self.syntax_coloring is not created and the pop-up menu crashes the IDE when it is referenced. For completeness the changes in PyAdvancedEditor.py are: old: import Qd import Fm import Evt import Events change to: #from Carbon import Qd from Carbon import Fm from Carbon import Evt from Carbon import Events Dan From noon@snow.nrcc.cornell.edu Sun Aug 4 20:55:41 2002 From: noon@snow.nrcc.cornell.edu (William Noon) Date: Sun, 04 Aug 2002 15:55:41 -0400 Subject: [Pythonmac-SIG] Bus error failure while building readline In-Reply-To: Your message of "Sat, 03 Aug 2002 22:06:30 +0200." <80726430-A71C-11D6-851A-003065517236@oratrix.com> Message-ID: <200208041955.PAA20315@snow.nrcc.cornell.edu> Jack -- I have been following along on the latest cvs builds and have run into the same series of roadbumps. The permissions in Python.framework/.../Mac/Tools/IDE changed to g+w. The dependency on Waste for the 'make osxapps' Need to 'cd Mac/OSX; make installunixprograms' to get the commandline python in /usr/local/bin After installing Waste, I got the IDE to build but it failed at startup. An update from cvs fixed that and the IDE is now working. (you know about that). I have two systems, both at 10.1.5 and the December tools. The first has been hacked on for a couple years and has lots of libraries/packages installed in /usr/local (but never a full fink install). The second is recent and isn't as adulterated. The first machine builds with readline but the second doesn't. On machine 1 I have readline and ncurses taken from the gnu-darwin project (same as fink versions?). But I only installed the libraries and include files (no /usr/local/share/termcap...) or /usr/lib/termcap. There is the /usr/share/misc/terminfo... defs from OSX. I will try installing only the readline libraries on machine 2 and see if that builds the readline.so module without error. --Bill Noon From tony.mcdonald@ncl.ac.uk Sun Aug 4 17:39:12 2002 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Sun, 04 Aug 2002 17:39:12 +0100 Subject: [Pythonmac-SIG] Mach{ho}Python IDE with syntax colouring In-Reply-To: Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3111327557_3186067 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > > *Very* nice! - now, about that AdvancedEditor patch ... > Ok, been fiddling all afternoon. I hope my ignorance doesn't show too much. I've edited the PyEdit.py and PyAdvancedEditor.py files and now get syntax colouring (sp! :) in the IDE. Bear in mind that this is a very hacky solution - I've just edited things until they 'work', I hope this helps other people. To get to this happy state of affairs I'd suggest you follow the instructions that Donovan has posted on his blog at http://www.ulaluma.com/pyx. That should sort out problems with people who've used fink. If you've messed about with /usr/local, then it's assumed you're an adult and you need to take some responsibility for your actions. I had to edit some lines (384-386) in setup.py readline_libs.append('termcap') # exts.append( Extension('readline', ['readline.c'], # library_dirs=['/usr/lib/termcap'], # libraries=readline_libs) ) If you then copy the PyEdit.py file (attached) and PyAdvancedEdit.py from into dist/src/Mac/Tools/IDE you'll hopefully be set. The PyAdvancedEdit.py is all Joe Strouts' work, all I did was edit it so: from Carbon import Qd from Carbon import Fm from Carbon import Evt from Carbon import Events I then followed Jacks instructions % ./configure --enable-framework % make % make frameworkinstall % make osxapps You *should* get a Python IDE application in /Applications/Python. A bonus (at least from my PoV) is that if you install modules using the following; % /Library/Frameworks/Python.framework/Versions/Current/bin/python setup.py Then they'll get installed into the Framework and not /usr/local/lib/python2.x. This then makes those modules available to the IDE (at least MySQLdb anyhow) As I said earlier, I'm no expert in this, so if someone knows a cleaner way of doing this, please let us all know. It goes without saying that my thanks go to Jack and Donovan in particular. Hope this helps, 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 --B_3111327557_3186067 Content-type: multipart/appledouble; boundary="B_3111327552_3212811" --B_3111327552_3212811 Content-type: application/applefile; name="PyEdit.py" Content-transfer-encoding: base64 Content-disposition: attachment AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAACAAAAADAAAAXgAAAAkAAAAC AAAAZwAAAdJURVhUUGVwcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFB5RWRpdC5weQAAAQAA AAGgAAAAoAAAADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcUHl0aG9uAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAAAAFAAAAAAAAAa6wAAAAAAABrrAAAAALly2c4A ABelAAAABAAAADsAAAIzAAAC0gAABEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIHdAAABAAAAAaAAAACgAAAAMgAP8JAA pgAAABwAMgAAUHBycwAAAAoAgf//AAAAAAPDoJQ= --B_3111327552_3212811 Content-type: text/plain; name="PyEdit.py"; x-mac-creator="50657072"; x-mac-type="54455854" Content-disposition: attachment Content-transfer-encoding: base64 IiIiQSAobGVzcyAmIGxlc3MpIHNpbXBsZSBQeXRob24gZWRpdG9yIiIiCgppbXBvcnQgVwpp bXBvcnQgV3RyYWNlYmFjawpmcm9tIFdrZXlzIGltcG9ydCAqCmZyb20gUHlBZHZhbmNlZEVk aXRvciBpbXBvcnQgUHlBZHZhbmNlZEVkaXRvcgoKaW1wb3J0IG1hY2ZzCmltcG9ydCBNQUNG UwppbXBvcnQgTWFjT1MKZnJvbSBDYXJib24gaW1wb3J0IFdpbgpmcm9tIENhcmJvbiBpbXBv cnQgUmVzCmZyb20gQ2FyYm9uIGltcG9ydCBFdnQKZnJvbSBDYXJib24gaW1wb3J0IFFkCmlt cG9ydCBvcwppbXBvcnQgaW1wCmltcG9ydCBzeXMKaW1wb3J0IHN0cmluZwppbXBvcnQgbWFy c2hhbAppbXBvcnQgcmUKCmlmIGhhc2F0dHIoV2luLCAiRnJvbnROb25GbG9hdGluZ1dpbmRv dyIpOgoJTXlGcm9udFdpbmRvdyA9IFdpbi5Gcm9udE5vbkZsb2F0aW5nV2luZG93CmVsc2U6 CglNeUZyb250V2luZG93ID0gV2luLkZyb250V2luZG93CgoKdHJ5OgoJaW1wb3J0IFd0aHJl YWRpbmcKZXhjZXB0IEltcG9ydEVycm9yOgoJaGF2ZVRocmVhZGluZyA9IDAKZWxzZToKCWhh dmVUaHJlYWRpbmcgPSBXdGhyZWFkaW5nLmhhdmVUaHJlYWRpbmcKCl9zY3JpcHR1bnRpdGxl ZGNvdW50ZXIgPSAxCl93b3JkY2hhcnMgPSBzdHJpbmcuYXNjaWlfbGV0dGVycyArIHN0cmlu Zy5kaWdpdHMgKyAiXyIKCgpydW5CdXR0b25MYWJlbHMgPSBbIlJ1biBhbGwiLCAiU3RvcCEi XQpydW5TZWxCdXR0b25MYWJlbHMgPSBbIlJ1biBzZWxlY3Rpb24iLCAiUGF1c2UhIiwgIlJl c3VtZSJdCgoKY2xhc3MgRWRpdG9yKFcuV2luZG93KToKCQoJZGVmIF9faW5pdF9fKHNlbGYs IHBhdGggPSAiIiwgdGl0bGUgPSAiIik6CgkJZGVmYXVsdGZvbnRzZXR0aW5ncywgZGVmYXVs dHRhYnNldHRpbmdzLCBkZWZhdWx0d2luZG93c2l6ZSA9IGdldGVkaXRvcnByZWZzKCkKCQln bG9iYWwgX3NjcmlwdHVudGl0bGVkY291bnRlcgoJCWlmIG5vdCBwYXRoOgoJCQlpZiB0aXRs ZToKCQkJCXNlbGYudGl0bGUgPSB0aXRsZQoJCQllbHNlOgoJCQkJc2VsZi50aXRsZSA9ICJV bnRpdGxlZCBTY3JpcHQgIiArIGBfc2NyaXB0dW50aXRsZWRjb3VudGVyYAoJCQkJX3Njcmlw dHVudGl0bGVkY291bnRlciA9IF9zY3JpcHR1bnRpdGxlZGNvdW50ZXIgKyAxCgkJCXRleHQg PSAiIgoJCQlzZWxmLl9jcmVhdG9yID0gVy5fc2lnbmF0dXJlCgkJCXNlbGYuX2VvbG4gPSBv cy5saW5lc2VwCgkJZWxpZiBvcy5wYXRoLmV4aXN0cyhwYXRoKToKCQkJcGF0aCA9IHJlc29s dmVhbGlhc2VzKHBhdGgpCgkJCWRpciwgbmFtZSA9IG9zLnBhdGguc3BsaXQocGF0aCkKCQkJ c2VsZi50aXRsZSA9IG5hbWUKCQkJZiA9IG9wZW4ocGF0aCwgInJiIikKCQkJdGV4dCA9IGYu cmVhZCgpCgkJCWYuY2xvc2UoKQoJCQlmc3MgPSBtYWNmcy5GU1NwZWMocGF0aCkKCQkJc2Vs Zi5fY3JlYXRvciwgZmlsZXR5cGUgPSBmc3MuR2V0Q3JlYXRvclR5cGUoKQoJCWVsc2U6CgkJ CXJhaXNlIElPRXJyb3IsICJmaWxlICclcycgZG9lcyBub3QgZXhpc3QiICUgcGF0aAoJCXNl bGYucGF0aCA9IHBhdGgKCQkKCQlpZiAnXG4nIGluIHRleHQ6CgkJCWltcG9ydCBFYXN5RGlh bG9ncwoJCQlpZiBzdHJpbmcuZmluZCh0ZXh0LCAnXHJcbicpID49IDA6CgkJCQlzZWxmLl9l b2xuID0gJ1xyXG4nCgkJCWVsc2U6CgkJCQlzZWxmLl9lb2xuID0gJ1xuJwoJCQl0ZXh0ID0g c3RyaW5nLnJlcGxhY2UodGV4dCwgc2VsZi5fZW9sbiwgJ1xyJykKCQkJY2hhbmdlID0gMAoJ CWVsc2U6CgkJCWNoYW5nZSA9IDAKCQkJc2VsZi5fZW9sbiA9ICdccicKCQkKCQlzZWxmLnNl dHRpbmdzID0ge30KCQlpZiBzZWxmLnBhdGg6CgkJCXNlbGYucmVhZHdpbmRvd3NldHRpbmdz KCkKCQlpZiBzZWxmLnNldHRpbmdzLmhhc19rZXkoIndpbmRvd2JvdW5kcyIpOgoJCQlib3Vu ZHMgPSBzZWxmLnNldHRpbmdzWyJ3aW5kb3dib3VuZHMiXQoJCWVsc2U6CgkJCWJvdW5kcyA9 IGRlZmF1bHR3aW5kb3dzaXplCgkJaWYgc2VsZi5zZXR0aW5ncy5oYXNfa2V5KCJmb250c2V0 dGluZ3MiKToKCQkJc2VsZi5mb250c2V0dGluZ3MgPSBzZWxmLnNldHRpbmdzWyJmb250c2V0 dGluZ3MiXQoJCWVsc2U6CgkJCXNlbGYuZm9udHNldHRpbmdzID0gZGVmYXVsdGZvbnRzZXR0 aW5ncwoJCWlmIHNlbGYuc2V0dGluZ3MuaGFzX2tleSgidGFic2l6ZSIpOgoJCQl0cnk6CgkJ CQlzZWxmLnRhYnNldHRpbmdzID0gKHRhYnNpemUsIHRhYm1vZGUpID0gc2VsZi5zZXR0aW5n c1sidGFic2l6ZSJdCgkJCWV4Y2VwdDoKCQkJCXNlbGYudGFic2V0dGluZ3MgPSBkZWZhdWx0 dGFic2V0dGluZ3MKCQllbHNlOgoJCQlzZWxmLnRhYnNldHRpbmdzID0gZGVmYXVsdHRhYnNl dHRpbmdzCgkJCgkJVy5XaW5kb3cuX19pbml0X18oc2VsZiwgYm91bmRzLCBzZWxmLnRpdGxl LCBtaW5zaXplID0gKDMzMCwgMTIwKSwgdGFiYmFibGUgPSAwKQoJCXNlbGYuc2V0dXB3aWRn ZXRzKHRleHQpCgkJaWYgY2hhbmdlID4gMDoKCQkJc2VsZi5lZGl0Z3JvdXAuZWRpdG9yLnRl eHRjaGFuZ2VkKCkKCQkKCQlpZiBzZWxmLnNldHRpbmdzLmhhc19rZXkoInNlbGVjdGlvbiIp OgoJCQlzZWxzdGFydCwgc2VsZW5kID0gc2VsZi5zZXR0aW5nc1sic2VsZWN0aW9uIl0KCQkJ c2VsZi5zZXRzZWxlY3Rpb24oc2Vsc3RhcnQsIHNlbGVuZCkKCQlzZWxmLm9wZW4oKQoJCXNl bGYuc2V0aW5mb3RleHQoKQoJCXNlbGYuZ2xvYmFscyA9IHt9CgkJc2VsZi5fYnVmID0gIiIg ICMgZm9yIHdyaXRlIG1ldGhvZAoJCXNlbGYuZGVidWdnaW5nID0gMAoJCXNlbGYucHJvZmls aW5nID0gMAoJCXNlbGYucnVuX2FzX21haW4gPSBzZWxmLnNldHRpbmdzLmdldCgicnVuX2Fz X21haW4iLCAwKQoJCXNlbGYucnVuX3dpdGhfaW50ZXJwcmV0ZXIgPSBzZWxmLnNldHRpbmdz LmdldCgicnVuX3dpdGhfaW50ZXJwcmV0ZXIiLCAwKQoJCXNlbGYucnVuX3dpdGhfY2xfaW50 ZXJwcmV0ZXIgPSBzZWxmLnNldHRpbmdzLmdldCgicnVuX3dpdGhfY2xfaW50ZXJwcmV0ZXIi LCAwKQoJCXNlbGYuX3RocmVhZHN0YXRlID0gKDAsIDApCgkJc2VsZi5fdGhyZWFkID0gTm9u ZQoJCglkZWYgcmVhZHdpbmRvd3NldHRpbmdzKHNlbGYpOgoJCXRyeToKCQkJcmVzcmVmID0g UmVzLkZTcE9wZW5SZXNGaWxlKHNlbGYucGF0aCwgMSkKCQlleGNlcHQgUmVzLkVycm9yOgoJ CQlyZXR1cm4KCQl0cnk6CgkJCVJlcy5Vc2VSZXNGaWxlKHJlc3JlZikKCQkJZGF0YSA9IFJl cy5HZXQxUmVzb3VyY2UoJ1B5V1MnLCAxMjgpCgkJCXNlbGYuc2V0dGluZ3MgPSBtYXJzaGFs LmxvYWRzKGRhdGEuZGF0YSkKCQlleGNlcHQ6CgkJCXBhc3MKCQlSZXMuQ2xvc2VSZXNGaWxl KHJlc3JlZikKCQkKCWRlZiB3cml0ZXdpbmRvd3NldHRpbmdzKHNlbGYpOgoJCXRyeToKCQkJ cmVzcmVmID0gUmVzLkZTcE9wZW5SZXNGaWxlKHNlbGYucGF0aCwgMykKCQlleGNlcHQgUmVz LkVycm9yOgoJCQlSZXMuRlNwQ3JlYXRlUmVzRmlsZShzZWxmLnBhdGgsIHNlbGYuX2NyZWF0 b3IsICdURVhUJywgTUFDRlMuc21BbGxTY3JpcHRzKQoJCQlyZXNyZWYgPSBSZXMuRlNwT3Bl blJlc0ZpbGUoc2VsZi5wYXRoLCAzKQoJCXRyeToKCQkJZGF0YSA9IFJlcy5SZXNvdXJjZSht YXJzaGFsLmR1bXBzKHNlbGYuc2V0dGluZ3MpKQoJCQlSZXMuVXNlUmVzRmlsZShyZXNyZWYp CgkJCXRyeToKCQkJCXRlbXAgPSBSZXMuR2V0MVJlc291cmNlKCdQeVdTJywgMTI4KQoJCQkJ dGVtcC5SZW1vdmVSZXNvdXJjZSgpCgkJCWV4Y2VwdCBSZXMuRXJyb3I6CgkJCQlwYXNzCgkJ CWRhdGEuQWRkUmVzb3VyY2UoJ1B5V1MnLCAxMjgsICJ3aW5kb3cgc2V0dGluZ3MiKQoJCWZp bmFsbHk6CgkJCVJlcy5VcGRhdGVSZXNGaWxlKHJlc3JlZikKCQkJUmVzLkNsb3NlUmVzRmls ZShyZXNyZWYpCgkKCWRlZiBnZXRzZXR0aW5ncyhzZWxmKToKCQlzZWxmLnNldHRpbmdzID0g e30KCQlzZWxmLnNldHRpbmdzWyJ3aW5kb3dib3VuZHMiXSA9IHNlbGYuZ2V0Ym91bmRzKCkK CQlzZWxmLnNldHRpbmdzWyJzZWxlY3Rpb24iXSA9IHNlbGYuZ2V0c2VsZWN0aW9uKCkKCQlz ZWxmLnNldHRpbmdzWyJmb250c2V0dGluZ3MiXSA9IHNlbGYuZWRpdGdyb3VwLmVkaXRvci5n ZXRmb250c2V0dGluZ3MoKQoJCXNlbGYuc2V0dGluZ3NbInRhYnNpemUiXSA9IHNlbGYuZWRp dGdyb3VwLmVkaXRvci5nZXR0YWJzZXR0aW5ncygpCgkJc2VsZi5zZXR0aW5nc1sicnVuX2Fz X21haW4iXSA9IHNlbGYucnVuX2FzX21haW4KCQlzZWxmLnNldHRpbmdzWyJydW5fd2l0aF9p bnRlcnByZXRlciJdID0gc2VsZi5ydW5fd2l0aF9pbnRlcnByZXRlcgoJCXNlbGYuc2V0dGlu Z3NbInJ1bl93aXRoX2NsX2ludGVycHJldGVyIl0gPSBzZWxmLnJ1bl93aXRoX2NsX2ludGVy cHJldGVyCgkKCWRlZiBnZXQoc2VsZik6CgkJcmV0dXJuIHNlbGYuZWRpdGdyb3VwLmVkaXRv ci5nZXQoKQoJCglkZWYgZ2V0c2VsZWN0aW9uKHNlbGYpOgoJCXJldHVybiBzZWxmLmVkaXRn cm91cC5lZGl0b3IudGVkLldFR2V0U2VsZWN0aW9uKCkKCQoJZGVmIHNldHNlbGVjdGlvbihz ZWxmLCBzZWxzdGFydCwgc2VsZW5kKToKCQlzZWxmLmVkaXRncm91cC5lZGl0b3Iuc2V0c2Vs ZWN0aW9uKHNlbHN0YXJ0LCBzZWxlbmQpCgkKCWRlZiBnZXRmaWxlbmFtZShzZWxmKToKCQlp ZiBzZWxmLnBhdGg6CgkJCXJldHVybiBzZWxmLnBhdGgKCQlyZXR1cm4gJzwlcz4nICUgc2Vs Zi50aXRsZQoJCglkZWYgc2V0dXB3aWRnZXRzKHNlbGYsIHRleHQpOgoJCXRvcGJhcmhlaWdo dCA9IDI0CgkJcG9wZmllbGR3aWR0aCA9IDgwCgkJc2VsZi5sYXN0bGluZW5vID0gTm9uZQoJ CQoJCSMgbWFrZSBhbiBlZGl0b3IKCQlzZWxmLmVkaXRncm91cCA9IFcuR3JvdXAoKDAsIHRv cGJhcmhlaWdodCArIDEsIDAsIDApKQoJCVB5QWR2YW5jZWRFZGl0b3IoKDAsIDAsIC0xNSwt MTUpLCB0ZXh0LCAKCQkJCWZvbnRzZXR0aW5ncyA9IHNlbGYuZm9udHNldHRpbmdzLCAKCQkJ CXRhYnNldHRpbmdzID0gc2VsZi50YWJzZXR0aW5ncywKCQkJCWZpbGUgPSBzZWxmLmdldGZp bGVuYW1lKCkpCgkJZWRpdG9yLmdldGVudmlyb25tZW50ID0gc2VsZi5nZXRlbnZpcm9ubWVu dAoJCQkJCgkJIyBtYWtlIHRoZSB3aWRnZXRzCgkJc2VsZi5wb3BmaWVsZCA9IENsYXNzRmlu ZGVyKChwb3BmaWVsZHdpZHRoIC0gMTcsIC0xNSwgMTYsIDE2KSwgW10sIHNlbGYucG9wc2Vs ZWN0bGluZSkKCQlzZWxmLmxpbmVmaWVsZCA9IFcuRWRpdFRleHQoKC0xLCAtMTUsIHBvcGZp ZWxkd2lkdGggLSAxNSwgMTYpLCBpbnNldCA9ICg2LCAxKSkKCQlzZWxmLmVkaXRncm91cC5f YmFyeCA9IFcuU2Nyb2xsYmFyKChwb3BmaWVsZHdpZHRoIC0gMiwgLTE1LCAtMTQsIDE2KSwg ZWRpdG9yLmhzY3JvbGwsIG1heCA9IDMyNzY3KQoJCXNlbGYuZWRpdGdyb3VwLl9iYXJ5ID0g Vy5TY3JvbGxiYXIoKC0xNSwgMTQsIDE2LCAtMTQpLCBlZGl0b3IudnNjcm9sbCwgbWF4ID0g MzI3NjcpCgkJc2VsZi5lZGl0Z3JvdXAuZWRpdG9yID0gZWRpdG9yCSMgYWRkIGVkaXRvciAq YWZ0ZXIqIHNjcm9sbGJhcnMKCQkKCQlzZWxmLmVkaXRncm91cC5vcHRpb25zbWVudSA9IFcu UG9wdXBNZW51KCgtMTUsIC0xLCAxNiwgMTYpLCBbXSkKCQlzZWxmLmVkaXRncm91cC5vcHRp b25zbWVudS5iaW5kKCc8Y2xpY2s+Jywgc2VsZi5tYWtlb3B0aW9uc21lbnUpCgkJCgkJc2Vs Zi5iZXZlbGJveCA9IFcuQmV2ZWxCb3goKDAsIDAsIDAsIHRvcGJhcmhlaWdodCkpCgkJc2Vs Zi5obGluZSA9IFcuSG9yaXpvbnRhbExpbmUoKDAsIHRvcGJhcmhlaWdodCwgMCwgMCkpCgkJ c2VsZi5pbmZvdGV4dCA9IFcuVGV4dEJveCgoMTc1LCA2LCAtNCwgMTQpLCBiYWNrZ3JvdW5k Y29sb3IgPSAoMHhlMDAwLCAweGUwMDAsIDB4ZTAwMCkpCgkJc2VsZi5ydW5idXR0b24gPSBX LkJldmVsQnV0dG9uKCg2LCA0LCA4MCwgMTYpLCBydW5CdXR0b25MYWJlbHNbMF0sIHNlbGYu cnVuKQoJCXNlbGYucnVuc2VsYnV0dG9uID0gVy5CZXZlbEJ1dHRvbigoOTAsIDQsIDgwLCAx NiksIHJ1blNlbEJ1dHRvbkxhYmVsc1swXSwgc2VsZi5ydW5zZWxlY3Rpb24pCgkJCgkJIyBi aW5kIHNvbWUga2V5cwoJCWVkaXRvci5iaW5kKCJjbWRyIiwgc2VsZi5ydW5idXR0b24ucHVz aCkKCQllZGl0b3IuYmluZCgiZW50ZXIiLCBzZWxmLnJ1bnNlbGJ1dHRvbi5wdXNoKQoJCWVk aXRvci5iaW5kKCJjbWRqIiwgc2VsZi5kb21lbnVfZ290b2xpbmUpCgkJZWRpdG9yLmJpbmQo ImNtZGQiLCBzZWxmLmRvbWVudV90b2dnbGVkZWJ1Z2dlcikKCQllZGl0b3IuYmluZCgiPGlk bGU+Iiwgc2VsZi51cGRhdGVzZWxlY3Rpb24pCgkJCgkJZWRpdG9yLmJpbmQoImNtZGUiLCBz ZWFyY2hlbmdpbmUuc2V0ZmluZHN0cmluZykKCQllZGl0b3IuYmluZCgiY21kZiIsIHNlYXJj aGVuZ2luZS5zaG93KQoJCWVkaXRvci5iaW5kKCJjbWRnIiwgc2VhcmNoZW5naW5lLmZpbmRu ZXh0KQoJCWVkaXRvci5iaW5kKCJjbWRzaGlmdHIiLCBzZWFyY2hlbmdpbmUucmVwbGFjZSkK CQllZGl0b3IuYmluZCgiY21kdCIsIHNlYXJjaGVuZ2luZS5yZXBsYWNlZmluZCkKCQkKCQlz ZWxmLmxpbmVmaWVsZC5iaW5kKCJyZXR1cm4iLCBzZWxmLmRvbGluZWZpZWxkKQoJCXNlbGYu bGluZWZpZWxkLmJpbmQoImVudGVyIiwgc2VsZi5kb2xpbmVmaWVsZCkKCQlzZWxmLmxpbmVm aWVsZC5iaW5kKCJ0YWIiLCBzZWxmLmRvbGluZWZpZWxkKQoJCQoJCSMgaW50ZXJjZXB0IGNs aWNrcwoJCWVkaXRvci5iaW5kKCI8Y2xpY2s+Iiwgc2VsZi5jbGlja2VkaXRvcikKCQlzZWxm LmxpbmVmaWVsZC5iaW5kKCI8Y2xpY2s+Iiwgc2VsZi5jbGlja2xpbmVmaWVsZCkKCQoJZGVm IG1ha2VvcHRpb25zbWVudShzZWxmKToKCQltZW51aXRlbXMgPSBbKCdGb250IHNldHRpbmdz XHhjOScsIHNlbGYuZG9tZW51X2ZvbnRzZXR0aW5ncyksIAoJCQkJKCJTYXZlIG9wdGlvbnNc eGM5Iiwgc2VsZi5kb21lbnVfb3B0aW9ucyksCgkJCQknLScsCgkJCQkoJ1wwJyArIGNocihz ZWxmLnJ1bl9hc19tYWluKSArICdSdW4gYXMgX19tYWluX18nLCBzZWxmLmRvbWVudV90b2dn bGVfcnVuX2FzX21haW4pLCAKCQkJCSMoJ1wwJyArIGNocihzZWxmLnJ1bl93aXRoX2ludGVy cHJldGVyKSArICdSdW4gd2l0aCBJbnRlcnByZXRlcicsIHNlbGYuZG9tZW51X2R0b2dnbGVf cnVuX3dpdGhfaW50ZXJwcmV0ZXIpLCAKCQkJCSgnXDAnICsgY2hyKHNlbGYucnVuX3dpdGhf Y2xfaW50ZXJwcmV0ZXIpICsgJ1J1biB3aXRoIGNvbW1hbmRsaW5lIFB5dGhvbicsIHNlbGYu ZG9tZW51X3RvZ2dsZV9ydW5fd2l0aF9jbF9pbnRlcnByZXRlciksIAoJCQkJJy0nLAoJCQkJ KCdNb2R1bGFyaXplJywgc2VsZi5kb21lbnVfbW9kdWxhcml6ZSksCgkJCQkoJ1wwJyArIGNo cihzZWxmLnN5bnRheF9jb2xvcmluZykgKyAnU3ludGF4IENvbG9yaW5nJywgc2VsZi5kb21l bnVfdG9nZ2xlX3N5bnRheF9jb2xvcmluZyksIAoJCQkJKCdCcm93c2UgbmFtZXNwYWNlXHhj OScsIHNlbGYuZG9tZW51X2Jyb3dzZW5hbWVzcGFjZSksIAoJCQkJJy0nXQoJCWlmIHNlbGYu cHJvZmlsaW5nOgoJCQltZW51aXRlbXMgPSBtZW51aXRlbXMgKyBbKCdEaXNhYmxlIHByb2Zp bGVyJywgc2VsZi5kb21lbnVfdG9nZ2xlcHJvZmlsZXIpXQoJCWVsc2U6CgkJCW1lbnVpdGVt cyA9IG1lbnVpdGVtcyArIFsoJ0VuYWJsZSBwcm9maWxlcicsIHNlbGYuZG9tZW51X3RvZ2ds ZXByb2ZpbGVyKV0KCQlpZiBzZWxmLmVkaXRncm91cC5lZGl0b3IuX2RlYnVnZ2VyOgoJCQlt ZW51aXRlbXMgPSBtZW51aXRlbXMgKyBbKCdEaXNhYmxlIGRlYnVnZ2VyJywgc2VsZi5kb21l bnVfdG9nZ2xlZGVidWdnZXIpLAoJCQkJKCdDbGVhciBicmVha3BvaW50cycsIHNlbGYuZG9t ZW51X2NsZWFyYnJlYWtwb2ludHMpLAoJCQkJKCdFZGl0IGJyZWFrcG9pbnRzXHhjOScsIHNl bGYuZG9tZW51X2VkaXRicmVha3BvaW50cyldCgkJZWxzZToKCQkJbWVudWl0ZW1zID0gbWVu dWl0ZW1zICsgWygnRW5hYmxlIGRlYnVnZ2VyJywgc2VsZi5kb21lbnVfdG9nZ2xlZGVidWdn ZXIpXQoJCXNlbGYuZWRpdGdyb3VwLm9wdGlvbnNtZW51LnNldChtZW51aXRlbXMpCgkKCWRl ZiBkb21lbnVfdG9nZ2xlX3N5bnRheF9jb2xvcmluZyhzZWxmKToKCQlzZWxmLnN5bnRheF9j b2xvcmluZyA9IG5vdCBzZWxmLnN5bnRheF9jb2xvcmluZwoJCXNlbGYuZWRpdGdyb3VwLmVk aXRvci5zZXRjb2xvcmluZyhzZWxmLnN5bnRheF9jb2xvcmluZykKCglkZWYgZG9tZW51X3Rv Z2dsZV9ydW5fYXNfbWFpbihzZWxmKToKCQlzZWxmLnJ1bl9hc19tYWluID0gbm90IHNlbGYu cnVuX2FzX21haW4KCQlzZWxmLnJ1bl93aXRoX2ludGVycHJldGVyID0gMAoJCXNlbGYucnVu X3dpdGhfY2xfaW50ZXJwcmV0ZXIgPSAwCgkJc2VsZi5lZGl0Z3JvdXAuZWRpdG9yLnNlbGVj dGlvbmNoYW5nZWQoKQoJCglkZWYgWFhkb21lbnVfdG9nZ2xlX3J1bl93aXRoX2ludGVycHJl dGVyKHNlbGYpOgoJCXNlbGYucnVuX3dpdGhfaW50ZXJwcmV0ZXIgPSBub3Qgc2VsZi5ydW5f d2l0aF9pbnRlcnByZXRlcgoJCXNlbGYucnVuX2FzX21haW4gPSAwCgkJaWYgc2VsZi5zZXR0 aW5ncy5oYXNfa2V5KCJzeW50YXhfY29sb3JpbmciKToKCQkJc2VsZi5zeW50YXhfY29sb3Jp bmcgPSBzZWxmLnNldHRpbmdzWyJzeW50YXhfY29sb3JpbmciXQoJCWVsc2U6CgkJCXNlbGYu c3ludGF4X2NvbG9yaW5nID0gMQoKCQlzZWxmLnJ1bl93aXRoX2NsX2ludGVycHJldGVyID0g MAoJCXNlbGYuZWRpdGdyb3VwLmVkaXRvci5zZWxlY3Rpb25jaGFuZ2VkKCkKCQoJZGVmIGRv bWVudV90b2dnbGVfcnVuX3dpdGhfY2xfaW50ZXJwcmV0ZXIoc2VsZik6CgkJc2VsZi5ydW5f d2l0aF9jbF9pbnRlcnByZXRlciA9IG5vdCBzZWxmLnJ1bl93aXRoX2NsX2ludGVycHJldGVy CgkJc2VsZi5ydW5fYXNfbWFpbiA9IDAKCQlpZiBzZWxmLnNldHRpbmdzLmhhc19rZXkoInN5 bnRheF9jb2xvcmluZyIpOgoJCQlzZWxmLnN5bnRheF9jb2xvcmluZyA9IHNlbGYuc2V0dGlu Z3NbInN5bnRheF9jb2xvcmluZyJdCgkJZWxzZToKCQkJc2VsZi5zeW50YXhfY29sb3Jpbmcg PSAxCgoJCXNlbGYucnVuX3dpdGhfaW50ZXJwcmV0ZXIgPSAwCgkJc2VsZi5lZGl0Z3JvdXAu ZWRpdG9yLnNlbGVjdGlvbmNoYW5nZWQoKQoJCglkZWYgc2hvd2JyZWFrcG9pbnRzKHNlbGYs IG9ub2ZmKToKCQlzZWxmLmVkaXRncm91cC5lZGl0b3Iuc2hvd2JyZWFrcG9pbnRzKG9ub2Zm KQoJCXNlbGYuZGVidWdnaW5nID0gb25vZmYKCQoJZGVmIGRvbWVudV9jbGVhcmJyZWFrcG9p bnRzKHNlbGYsICphcmdzKToKCQlzZWxmLmVkaXRncm91cC5lZGl0b3IuY2xlYXJicmVha3Bv aW50cygpCgkKCWRlZiBkb21lbnVfZWRpdGJyZWFrcG9pbnRzKHNlbGYsICphcmdzKToKCQlz ZWxmLmVkaXRncm91cC5lZGl0b3IuZWRpdGJyZWFrcG9pbnRzKCkKCQoJZGVmIGRvbWVudV90 b2dnbGVkZWJ1Z2dlcihzZWxmLCAqYXJncyk6CgkJaWYgbm90IHNlbGYuZGVidWdnaW5nOgoJ CQlXLlNldEN1cnNvcignd2F0Y2gnKQoJCXNlbGYuZGVidWdnaW5nID0gbm90IHNlbGYuZGVi dWdnaW5nCgkJc2VsZi5lZGl0Z3JvdXAuZWRpdG9yLnRvZ2dsZWJyZWFrcG9pbnRzKCkKCQkK CWRlZiBkb21lbnVfdG9nZ2xlcHJvZmlsZXIoc2VsZiwgKmFyZ3MpOgoJCXNlbGYucHJvZmls aW5nID0gbm90IHNlbGYucHJvZmlsaW5nCgkKCWRlZiBkb21lbnVfYnJvd3NlbmFtZXNwYWNl KHNlbGYsICphcmdzKToKCQlpbXBvcnQgUHlCcm93c2VyLCBXCgkJVy5TZXRDdXJzb3IoJ3dh dGNoJykKCQlnbG9iYWxzLCBmaWxlLCBtb2RuYW1lID0gc2VsZi5nZXRlbnZpcm9ubWVudCgp CgkJaWYgbm90IG1vZG5hbWU6CgkJCW1vZG5hbWUgPSBzZWxmLnRpdGxlCgkJUHlCcm93c2Vy LkJyb3dzZXIoZ2xvYmFscywgIk9iamVjdCBicm93c2VyOiAiICsgbW9kbmFtZSkKCQoJZGVm IGRvbWVudV9tb2R1bGFyaXplKHNlbGYsICphcmdzKToKCQltb2RuYW1lID0gX2ZpbGVuYW1l X2FzX21vZG5hbWUoc2VsZi50aXRsZSkKCQlpZiBub3QgbW9kbmFtZToKCQkJcmFpc2UgVy5B bGVydEVycm9yLCAiQ2FuJ3QgbW9kdWxhcml6ZSBcIiVzXCIiICUgc2VsZi50aXRsZQoJCXJ1 bl9hc19tYWluID0gc2VsZi5ydW5fYXNfbWFpbgoJCXNlbGYucnVuX2FzX21haW4gPSAwCgkJ aWYgc2VsZi5zZXR0aW5ncy5oYXNfa2V5KCJzeW50YXhfY29sb3JpbmciKToKCQkJc2VsZi5z eW50YXhfY29sb3JpbmcgPSBzZWxmLnNldHRpbmdzWyJzeW50YXhfY29sb3JpbmciXQoJCWVs c2U6CgkJCXNlbGYuc3ludGF4X2NvbG9yaW5nID0gMQoKCQlzZWxmLnJ1bigpCgkJc2VsZi5y dW5fYXNfbWFpbiA9IHJ1bl9hc19tYWluCgkJaWYgc2VsZi5wYXRoOgoJCQlmaWxlID0gc2Vs Zi5wYXRoCgkJZWxzZToKCQkJZmlsZSA9IHNlbGYudGl0bGUKCQkKCQlpZiBzZWxmLmdsb2Jh bHMgYW5kIG5vdCBzeXMubW9kdWxlcy5oYXNfa2V5KG1vZG5hbWUpOgoJCQltb2R1bGUgPSBp bXAubmV3X21vZHVsZShtb2RuYW1lKQoJCQlmb3IgYXR0ciBpbiBzZWxmLmdsb2JhbHMua2V5 cygpOgoJCQkJc2V0YXR0cihtb2R1bGUsYXR0cixzZWxmLmdsb2JhbHNbYXR0cl0pCgkJCXN5 cy5tb2R1bGVzW21vZG5hbWVdID0gbW9kdWxlCgkJCXNlbGYuZ2xvYmFscyA9IHt9CgkKCWRl ZiBkb21lbnVfZm9udHNldHRpbmdzKHNlbGYsICphcmdzKToKCQlpbXBvcnQgRm9udFNldHRp bmdzCgkJZm9udHNldHRpbmdzID0gc2VsZi5lZGl0Z3JvdXAuZWRpdG9yLmdldGZvbnRzZXR0 aW5ncygpCgkJdGFic2V0dGluZ3MgPSBzZWxmLmVkaXRncm91cC5lZGl0b3IuZ2V0dGFic2V0 dGluZ3MoKQoJCXNldHRpbmdzID0gRm9udFNldHRpbmdzLkZvbnREaWFsb2coZm9udHNldHRp bmdzLCB0YWJzZXR0aW5ncykKCQlpZiBzZXR0aW5nczoKCQkJZm9udHNldHRpbmdzLCB0YWJz ZXR0aW5ncyA9IHNldHRpbmdzCgkJCXNlbGYuZWRpdGdyb3VwLmVkaXRvci5zZXRmb250c2V0 dGluZ3MoZm9udHNldHRpbmdzKQoJCQlzZWxmLmVkaXRncm91cC5lZGl0b3Iuc2V0dGFic2V0 dGluZ3ModGFic2V0dGluZ3MpCgkKCWRlZiBkb21lbnVfb3B0aW9ucyhzZWxmLCAqYXJncyk6 CgkJcnYgPSBTYXZlT3B0aW9ucyhzZWxmLl9jcmVhdG9yLCBzZWxmLl9lb2xuKQoJCWlmIHJ2 OgoJCQlzZWxmLmVkaXRncm91cC5lZGl0b3Iuc2VsZWN0aW9uY2hhbmdlZCgpICMgb3VjaC4u LgoJCQlzZWxmLl9jcmVhdG9yLCBzZWxmLl9lb2xuID0gcnYKCQoJZGVmIGNsaWNrbGluZWZp ZWxkKHNlbGYpOgoJCWlmIHNlbGYuX2N1cnJlbnR3aWRnZXQgPD4gc2VsZi5saW5lZmllbGQ6 CgkJCXNlbGYubGluZWZpZWxkLnNlbGVjdCgxKQoJCQlzZWxmLmxpbmVmaWVsZC5zZWxlY3Rh bGwoKQoJCQlyZXR1cm4gMQoJCglkZWYgY2xpY2tlZGl0b3Ioc2VsZik6CgkJaWYgc2VsZi5f Y3VycmVudHdpZGdldCA8PiBzZWxmLmVkaXRncm91cC5lZGl0b3I6CgkJCXNlbGYuZG9saW5l ZmllbGQoKQoJCQlyZXR1cm4gMQoJCglkZWYgdXBkYXRlc2VsZWN0aW9uKHNlbGYsIGZvcmNl ID0gMCk6CgkJc2VsID0gbWluKHNlbGYuZWRpdGdyb3VwLmVkaXRvci5nZXRzZWxlY3Rpb24o KSkKCQlsaW5lbm8gPSBzZWxmLmVkaXRncm91cC5lZGl0b3Iub2Zmc2V0dG9saW5lKHNlbCkK CQlpZiBsaW5lbm8gPD4gc2VsZi5sYXN0bGluZW5vIG9yIGZvcmNlOgoJCQlzZWxmLmxhc3Rs aW5lbm8gPSBsaW5lbm8KCQkJc2VsZi5saW5lZmllbGQuc2V0KHN0cihsaW5lbm8gKyAxKSkK CQkJc2VsZi5saW5lZmllbGQuc2VsdmlldygpCgkKCWRlZiBkb2xpbmVmaWVsZChzZWxmKToK CQl0cnk6CgkJCWxpbmVubyA9IHN0cmluZy5hdG9pKHNlbGYubGluZWZpZWxkLmdldCgpKSAt IDEKCQkJaWYgbGluZW5vIDw+IHNlbGYubGFzdGxpbmVubzoKCQkJCXNlbGYuZWRpdGdyb3Vw LmVkaXRvci5zZWxlY3RsaW5lKGxpbmVubykKCQkJCXNlbGYudXBkYXRlc2VsZWN0aW9uKDEp CgkJZXhjZXB0OgoJCQlzZWxmLnVwZGF0ZXNlbGVjdGlvbigxKQoJCXNlbGYuZWRpdGdyb3Vw LmVkaXRvci5zZWxlY3QoMSkKCQoJZGVmIHNldGluZm90ZXh0KHNlbGYpOgoJCWlmIG5vdCBo YXNhdHRyKHNlbGYsICdpbmZvdGV4dCcpOgoJCQlyZXR1cm4KCQlpZiBzZWxmLnBhdGg6CgkJ CXNlbGYuaW5mb3RleHQuc2V0KHNlbGYucGF0aCkKCQllbHNlOgoJCQlzZWxmLmluZm90ZXh0 LnNldCgiIikKCQoJZGVmIGNsb3NlKHNlbGYpOgoJCWlmIHNlbGYuZWRpdGdyb3VwLmVkaXRv ci5jaGFuZ2VkOgoJCQlpbXBvcnQgRWFzeURpYWxvZ3MKCQkJUWQuSW5pdEN1cnNvcigpCgkJ CXNhdmUgPSBFYXN5RGlhbG9ncy5Bc2tZZXNOb0NhbmNlbCgnU2F2ZSB3aW5kb3cgIiVzIiBi ZWZvcmUgY2xvc2luZz8nICUgc2VsZi50aXRsZSwKCQkJCQlkZWZhdWx0PTEsIG5vPSJEb25c eGQ1dCBzYXZlIikKCQkJaWYgc2F2ZSA+IDA6CgkJCQlpZiBzZWxmLmRvbWVudV9zYXZlKCk6 CgkJCQkJcmV0dXJuIDEKCQkJZWxpZiBzYXZlIDwgMDoKCQkJCXJldHVybiAxCgkJc2VsZi5n bG9iYWxzID0gTm9uZQoJCVcuV2luZG93LmNsb3NlKHNlbGYpCgkKCWRlZiBkb21lbnVfY2xv c2Uoc2VsZiwgKmFyZ3MpOgoJCXJldHVybiBzZWxmLmNsb3NlKCkKCQoJZGVmIGRvbWVudV9z YXZlKHNlbGYsICphcmdzKToKCQlpZiBub3Qgc2VsZi5wYXRoOgoJCQkjIFdpbGwgY2FsbCB1 cyByZWN1cnNpdmVseQoJCQlyZXR1cm4gc2VsZi5kb21lbnVfc2F2ZV9hcygpCgkJZGF0YSA9 IHNlbGYuZWRpdGdyb3VwLmVkaXRvci5nZXQoKQoJCWlmIHNlbGYuX2VvbG4gIT0gJ1xyJzoK CQkJZGF0YSA9IHN0cmluZy5yZXBsYWNlKGRhdGEsICdccicsIHNlbGYuX2VvbG4pCgkJZnAg PSBvcGVuKHNlbGYucGF0aCwgJ3diJykgICMgb3BlbiBmaWxlIGluIGJpbmFyeSBtb2RlLCBk YXRhIGhhcyAnXHInIGxpbmUtZW5kaW5ncwoJCWZwLndyaXRlKGRhdGEpCgkJZnAuY2xvc2Uo KQoJCWZzcyA9IG1hY2ZzLkZTU3BlYyhzZWxmLnBhdGgpCgkJZnNzLlNldENyZWF0b3JUeXBl KHNlbGYuX2NyZWF0b3IsICdURVhUJykKCQlzZWxmLmdldHNldHRpbmdzKCkKCQlzZWxmLndy aXRld2luZG93c2V0dGluZ3MoKQoJCXNlbGYuZWRpdGdyb3VwLmVkaXRvci5jaGFuZ2VkID0g MAoJCXNlbGYuZWRpdGdyb3VwLmVkaXRvci5zZWxjaGFuZ2VkID0gMAoJCWltcG9ydCBsaW5l Y2FjaGUKCQlpZiBsaW5lY2FjaGUuY2FjaGUuaGFzX2tleShzZWxmLnBhdGgpOgoJCQlkZWwg bGluZWNhY2hlLmNhY2hlW3NlbGYucGF0aF0KCQlpbXBvcnQgbWFjb3N0b29scwoJCW1hY29z dG9vbHMudG91Y2hlZChzZWxmLnBhdGgpCgkKCWRlZiBjYW5fc2F2ZShzZWxmLCBtZW51aXRl bSk6CgkJcmV0dXJuIHNlbGYuZWRpdGdyb3VwLmVkaXRvci5jaGFuZ2VkIG9yIHNlbGYuZWRp dGdyb3VwLmVkaXRvci5zZWxjaGFuZ2VkCgkKCWRlZiBkb21lbnVfc2F2ZV9hcyhzZWxmLCAq YXJncyk6CgkJZnNzLCBvayA9IG1hY2ZzLlN0YW5kYXJkUHV0RmlsZSgnU2F2ZSBhczonLCBz ZWxmLnRpdGxlKQoJCWlmIG5vdCBvazogCgkJCXJldHVybiAxCgkJc2VsZi5zaG93YnJlYWtw b2ludHMoMCkKCQlzZWxmLnBhdGggPSBmc3MuYXNfcGF0aG5hbWUoKQoJCXNlbGYuc2V0aW5m b3RleHQoKQoJCXNlbGYudGl0bGUgPSBvcy5wYXRoLnNwbGl0KHNlbGYucGF0aClbLTFdCgkJ c2VsZi53aWQuU2V0V1RpdGxlKHNlbGYudGl0bGUpCgkJc2VsZi5kb21lbnVfc2F2ZSgpCgkJ c2VsZi5lZGl0Z3JvdXAuZWRpdG9yLnNldGZpbGUoc2VsZi5nZXRmaWxlbmFtZSgpKQoJCWFw cCA9IFcuZ2V0YXBwbGljYXRpb24oKQoJCWFwcC5tYWtlb3BlbndpbmRvd3NtZW51KCkKCQlp ZiBoYXNhdHRyKGFwcCwgJ21ha2VzY3JpcHRzbWVudScpOgoJCQlhcHAgPSBXLmdldGFwcGxp Y2F0aW9uKCkKCQkJZnNzLCBmc3NfY2hhbmdlZCA9IGFwcC5zY3JpcHRzZm9sZGVyLlJlc29s dmUoKQoJCQlwYXRoID0gZnNzLmFzX3BhdGhuYW1lKCkKCQkJaWYgcGF0aCA9PSBzZWxmLnBh dGhbOmxlbihwYXRoKV06CgkJCQlXLmdldGFwcGxpY2F0aW9uKCkubWFrZXNjcmlwdHNtZW51 KCkKCQoJZGVmIGRvbWVudV9zYXZlX2FzX2FwcGxldChzZWxmLCAqYXJncyk6CgkJaW1wb3J0 IGJ1aWxkdG9vbHMKCQkKCQlidWlsZHRvb2xzLkRFQlVHID0gMAkjIG91Y2guCgkJCgkJaWYg c2VsZi50aXRsZVstMzpdID09ICIucHkiOgoJCQlkZXN0bmFtZSA9IHNlbGYudGl0bGVbOi0z XQoJCWVsc2U6CgkJCWRlc3RuYW1lID0gc2VsZi50aXRsZSArICIuYXBwbGV0IgoJCWZzcywg b2sgPSBtYWNmcy5TdGFuZGFyZFB1dEZpbGUoJ1NhdmUgYXMgQXBwbGV0OicsIGRlc3RuYW1l KQoJCWlmIG5vdCBvazogCgkJCXJldHVybiAxCgkJVy5TZXRDdXJzb3IoIndhdGNoIikKCQlk ZXN0bmFtZSA9IGZzcy5hc19wYXRobmFtZSgpCgkJaWYgc2VsZi5wYXRoOgoJCQlmaWxlbmFt ZSA9IHNlbGYucGF0aAoJCQlpZiBmaWxlbmFtZVstMzpdID09ICIucHkiOgoJCQkJcnNyY25h bWUgPSBmaWxlbmFtZVs6LTNdICsgJy5yc3JjJwoJCQllbHNlOgoJCQkJcnNyY25hbWUgPSBm aWxlbmFtZSArICcucnNyYycKCQllbHNlOgoJCQlmaWxlbmFtZSA9IHNlbGYudGl0bGUKCQkJ cnNyY25hbWUgPSAiIgoJCQoJCXB5dGV4dCA9IHNlbGYuZWRpdGdyb3VwLmVkaXRvci5nZXQo KQoJCXB5dGV4dCA9IHN0cmluZy5zcGxpdChweXRleHQsICdccicpCgkJcHl0ZXh0ID0gc3Ry aW5nLmpvaW4ocHl0ZXh0LCAnXG4nKSArICdcbicKCQl0cnk6CgkJCWNvZGUgPSBjb21waWxl KHB5dGV4dCwgZmlsZW5hbWUsICJleGVjIikKCQlleGNlcHQgKFN5bnRheEVycm9yLCBFT0ZF cnJvcik6CgkJCXJhaXNlIGJ1aWxkdG9vbHMuQnVpbGRFcnJvciwgIlN5bnRheCBlcnJvciBp biBzY3JpcHQgJXMiICUgYGZpbGVuYW1lYAoJCQoJCSMgVHJ5IHJlbW92aW5nIHRoZSBvdXRw dXQgZmlsZQoJCXRyeToKCQkJb3MucmVtb3ZlKGRlc3RuYW1lKQoJCWV4Y2VwdCBvcy5lcnJv cjoKCQkJcGFzcwoJCXRlbXBsYXRlID0gYnVpbGR0b29scy5maW5kdGVtcGxhdGUoKQoJCWJ1 aWxkdG9vbHMucHJvY2Vzc19jb21tb24odGVtcGxhdGUsIE5vbmUsIGNvZGUsIHJzcmNuYW1l LCBkZXN0bmFtZSwgMCwgMSkKCQoJZGVmIGRvbWVudV9nb3RvbGluZShzZWxmLCAqYXJncyk6 CgkJc2VsZi5saW5lZmllbGQuc2VsZWN0YWxsKCkKCQlzZWxmLmxpbmVmaWVsZC5zZWxlY3Qo MSkKCQlzZWxmLmxpbmVmaWVsZC5zZWxlY3RhbGwoKQoJCglkZWYgZG9tZW51X3NlbGVjdGxp bmUoc2VsZiwgKmFyZ3MpOgoJCXNlbGYuZWRpdGdyb3VwLmVkaXRvci5leHBhbmRzZWxlY3Rp b24oKQoJCglkZWYgZG9tZW51X2ZpbmQoc2VsZiwgKmFyZ3MpOgoJCXNlYXJjaGVuZ2luZS5z aG93KCkKCQoJZGVmIGRvbWVudV9lbnRlcnNlYXJjaHN0cmluZyhzZWxmLCAqYXJncyk6CgkJ c2VhcmNoZW5naW5lLnNldGZpbmRzdHJpbmcoKQoJCglkZWYgZG9tZW51X3JlcGxhY2Uoc2Vs ZiwgKmFyZ3MpOgoJCXNlYXJjaGVuZ2luZS5yZXBsYWNlKCkKCQoJZGVmIGRvbWVudV9maW5k bmV4dChzZWxmLCAqYXJncyk6CgkJc2VhcmNoZW5naW5lLmZpbmRuZXh0KCkKCQoJZGVmIGRv bWVudV9yZXBsYWNlZmluZChzZWxmLCAqYXJncyk6CgkJc2VhcmNoZW5naW5lLnJlcGxhY2Vm aW5kKCkKCQoJZGVmIGRvbWVudV9ydW4oc2VsZiwgKmFyZ3MpOgoJCXNlbGYucnVuYnV0dG9u LnB1c2goKQoJCglkZWYgZG9tZW51X3J1bnNlbGVjdGlvbihzZWxmLCAqYXJncyk6CgkJc2Vs Zi5ydW5zZWxidXR0b24ucHVzaCgpCgkKCWRlZiBydW4oc2VsZik6CgkJaWYgc2VsZi5fdGhy ZWFkc3RhdGUgPT0gKDAsIDApOgoJCQlzZWxmLl9ydW4oKQoJCWVsc2U6CgkJCWxvY2sgPSBX dGhyZWFkaW5nLkxvY2soKQoJCQlsb2NrLmFjcXVpcmUoKQoJCQlzZWxmLl90aHJlYWQucG9z dEV4Y2VwdGlvbihLZXlib2FyZEludGVycnVwdCkKCQkJaWYgc2VsZi5fdGhyZWFkLmlzQmxv Y2tlZCgpOgoJCQkJc2VsZi5fdGhyZWFkLnN0YXJ0KCkKCQkJbG9jay5yZWxlYXNlKCkKCQoJ ZGVmIF9ydW4oc2VsZik6CgkJaWYgc2VsZi5ydW5fd2l0aF9pbnRlcnByZXRlcjoKCQkJaWYg c2VsZi5lZGl0Z3JvdXAuZWRpdG9yLmNoYW5nZWQ6CgkJCQlpbXBvcnQgRWFzeURpYWxvZ3MK CQkJCVFkLkluaXRDdXJzb3IoKQoJCQkJc2F2ZSA9IEVhc3lEaWFsb2dzLkFza1llc05vQ2Fu Y2VsKCdTYXZlICIlcyIgYmVmb3JlIHJ1bm5pbmc/JyAlIHNlbGYudGl0bGUsIDEpCgkJCQlp ZiBzYXZlID4gMDoKCQkJCQlpZiBzZWxmLmRvbWVudV9zYXZlKCk6CgkJCQkJCXJldHVybgoJ CQkJZWxpZiBzYXZlIDwgMDoKCQkJCQlyZXR1cm4KCQkJaWYgbm90IHNlbGYucGF0aDoKCQkJ CXJhaXNlIFcuQWxlcnRFcnJvciwgIkNhbid0IHJ1biB1bnNhdmVkIGZpbGUiCgkJCXNlbGYu X3J1bl93aXRoX2ludGVycHJldGVyKCkKCQllbGlmIHNlbGYucnVuX3dpdGhfY2xfaW50ZXJw cmV0ZXI6CgkJCWlmIHNlbGYuZWRpdGdyb3VwLmVkaXRvci5jaGFuZ2VkOgoJCQkJaW1wb3J0 IEVhc3lEaWFsb2dzCgkJCQlRZC5Jbml0Q3Vyc29yKCkKCQkJCXNhdmUgPSBFYXN5RGlhbG9n cy5Bc2tZZXNOb0NhbmNlbCgnU2F2ZSAiJXMiIGJlZm9yZSBydW5uaW5nPycgJSBzZWxmLnRp dGxlLCAxKQoJCQkJaWYgc2F2ZSA+IDA6CgkJCQkJaWYgc2VsZi5kb21lbnVfc2F2ZSgpOgoJ CQkJCQlyZXR1cm4KCQkJCWVsaWYgc2F2ZSA8IDA6CgkJCQkJcmV0dXJuCgkJCWlmIG5vdCBz ZWxmLnBhdGg6CgkJCQlyYWlzZSBXLkFsZXJ0RXJyb3IsICJDYW4ndCBydW4gdW5zYXZlZCBm aWxlIgoJCQlzZWxmLl9ydW5fd2l0aF9jbF9pbnRlcnByZXRlcigpCgkJZWxzZToKCQkJcHl0 ZXh0ID0gc2VsZi5lZGl0Z3JvdXAuZWRpdG9yLmdldCgpCgkJCWdsb2JhbHMsIGZpbGUsIG1v ZG5hbWUgPSBzZWxmLmdldGVudmlyb25tZW50KCkKCQkJc2VsZi5leGVjc3RyaW5nKHB5dGV4 dCwgZ2xvYmFscywgZ2xvYmFscywgZmlsZSwgbW9kbmFtZSkKCQoJZGVmIF9ydW5fd2l0aF9p bnRlcnByZXRlcihzZWxmKToKCQlpbnRlcnBfcGF0aCA9IG9zLnBhdGguam9pbihzeXMuZXhl Y19wcmVmaXgsICJQeXRob25JbnRlcnByZXRlciIpCgkJaWYgbm90IG9zLnBhdGguZXhpc3Rz KGludGVycF9wYXRoKToKCQkJcmFpc2UgVy5BbGVydEVycm9yLCAiQ2FuJ3QgZmluZCBpbnRl cnByZXRlciIKCQlpbXBvcnQgZmluZGVydG9vbHMKCQlYWFgKCglkZWYgX3J1bl93aXRoX2Ns X2ludGVycHJldGVyKHNlbGYpOgoJCWltcG9ydCBUZXJtaW5hbAoJCWludGVycF9wYXRoID0g b3MucGF0aC5qb2luKHN5cy5leGVjX3ByZWZpeCwgImJpbiIsICJweXRob24iKQoJCWZpbGVf cGF0aCA9IHNlbGYucGF0aAoJCWlmIG5vdCBvcy5wYXRoLmV4aXN0cyhpbnRlcnBfcGF0aCk6 CgkJCSMgVGhpcyAiY2FuIGhhcHBlbiIgaWYgd2UgYXJlIHJ1bm5pbmcgSURFIHVuZGVyIE1h Y1B5dGhvbi4gVHJ5CgkJCSMgdGhlIHN0YW5kYXJkIGxvY2F0aW9uLgoJCQlpbnRlcnBfcGF0 aCA9ICIvTGlicmFyeS9GcmFtZXdvcmtzL1B5dGhvbi5mcmFtZXdvcmsvVmVyc2lvbnMvMi4z L2Jpbi9weXRob24iCgkJCXRyeToKCQkJCWZzciA9IG1hY2ZzLkZTUmVmKGludGVycF9wYXRo KQoJCQlleGNlcHQgbWFjZnMuRXJyb3I6CgkJCQlyYWlzZSBXLkFsZXJ0RXJyb3IsICJDYW4n dCBmaW5kIGNvbW1hbmQtbGluZSBQeXRob24iCgkJCWZpbGVfcGF0aCA9IG1hY2ZzLkZTUmVm KG1hY2ZzLkZTU3BlYyhzZWxmLnBhdGgpKS5hc19wYXRobmFtZSgpCgkJY21kID0gJyIlcyIg IiVzIiA7IGV4aXQnICUgKGludGVycF9wYXRoLCBmaWxlX3BhdGgpCgkJdCA9IFRlcm1pbmFs LlRlcm1pbmFsKCkKCQl0LmRvX3NjcmlwdCh3aXRoX2NvbW1hbmQ9Y21kKQoJCglkZWYgcnVu c2VsZWN0aW9uKHNlbGYpOgoJCWlmIHNlbGYuX3RocmVhZHN0YXRlID09ICgwLCAwKToKCQkJ c2VsZi5fcnVuc2VsZWN0aW9uKCkKCQllbGlmIHNlbGYuX3RocmVhZHN0YXRlID09ICgxLCAx KToKCQkJc2VsZi5fdGhyZWFkLmJsb2NrKCkKCQkJc2VsZi5zZXR0aHJlYWRzdGF0ZSgoMSwg MikpCgkJZWxpZiBzZWxmLl90aHJlYWRzdGF0ZSA9PSAoMSwgMik6CgkJCXNlbGYuX3RocmVh ZC5zdGFydCgpCgkJCXNlbGYuc2V0dGhyZWFkc3RhdGUoKDEsIDEpKQoJCglkZWYgX3J1bnNl bGVjdGlvbihzZWxmKToKCQlpZiBzZWxmLnJ1bl93aXRoX2ludGVycHJldGVyIG9yIHNlbGYu cnVuX3dpdGhfY2xfaW50ZXJwcmV0ZXI6CgkJCXJhaXNlIFcuQWxlcnRFcnJvciwgIkNhbid0 IHJ1biBzZWxlY3Rpb24gd2l0aCBJbnRlcnByZXRlciIKCQlnbG9iYWxzLCBmaWxlLCBtb2Ru YW1lID0gc2VsZi5nZXRlbnZpcm9ubWVudCgpCgkJbG9jYWxzID0gZ2xvYmFscwoJCSMgc2Vs ZWN0IHdob2xlIGxpbmVzCgkJc2VsZi5lZGl0Z3JvdXAuZWRpdG9yLmV4cGFuZHNlbGVjdGlv bigpCgkJCgkJIyBnZXQgbGluZW5vIG9mIGZpcnN0IHNlbGVjdGVkIGxpbmUKCQlzZWxzdGFy dCwgc2VsZW5kID0gc2VsZi5lZGl0Z3JvdXAuZWRpdG9yLmdldHNlbGVjdGlvbigpCgkJc2Vs c3RhcnQsIHNlbGVuZCA9IG1pbihzZWxzdGFydCwgc2VsZW5kKSwgbWF4KHNlbHN0YXJ0LCBz ZWxlbmQpCgkJc2VsZmlyc3RsaW5lID0gc2VsZi5lZGl0Z3JvdXAuZWRpdG9yLm9mZnNldHRv bGluZShzZWxzdGFydCkKCQlhbGx0ZXh0ID0gc2VsZi5lZGl0Z3JvdXAuZWRpdG9yLmdldCgp CgkJcHl0ZXh0ID0gYWxsdGV4dFtzZWxzdGFydDpzZWxlbmRdCgkJbGluZXMgPSBzdHJpbmcu c3BsaXQocHl0ZXh0LCAnXHInKQoJCWluZGVudCA9IGdldG1pbmluZGVudChsaW5lcykKCQlp ZiBpbmRlbnQgPT0gMToKCQkJY2xhc3NuYW1lID0gJycKCQkJYWxsbGluZXMgPSBzdHJpbmcu c3BsaXQoYWxsdGV4dCwgJ1xyJykKCQkJZm9yIGkgaW4gcmFuZ2Uoc2VsZmlyc3RsaW5lIC0g MSwgLTEsIC0xKToKCQkJCWxpbmUgPSBhbGxsaW5lc1tpXQoJCQkJaWYgbGluZVs6Nl0gPT0g J2NsYXNzICc6CgkJCQkJY2xhc3NuYW1lID0gc3RyaW5nLnNwbGl0KHN0cmluZy5zdHJpcChs aW5lWzY6XSkpWzBdCgkJCQkJY2xhc3NlbmQgPSBpZGVudGlmaWVSRV9tYXRjaChjbGFzc25h bWUpCgkJCQkJaWYgY2xhc3NlbmQgPCAxOgoJCQkJCQlyYWlzZSBXLkFsZXJ0RXJyb3IsICJD YW4ndCBmaW5kIGEgY2xhc3MuIgoJCQkJCWNsYXNzbmFtZSA9IGNsYXNzbmFtZVs6Y2xhc3Nl bmRdCgkJCQkJYnJlYWsKCQkJCWVsaWYgbGluZSBhbmQgbGluZVswXSBub3QgaW4gJ1x0Iyc6 CgkJCQkJcmFpc2UgVy5BbGVydEVycm9yLCAiQ2FuJ3QgZmluZCBhIGNsYXNzLiIKCQkJZWxz ZToKCQkJCXJhaXNlIFcuQWxlcnRFcnJvciwgIkNhbid0IGZpbmQgYSBjbGFzcy4iCgkJCWlm IGdsb2JhbHMuaGFzX2tleShjbGFzc25hbWUpOgoJCQkJa2xhc3MgPSBnbG9iYWxzW2NsYXNz bmFtZV0KCQkJZWxzZToKCQkJCXJhaXNlIFcuQWxlcnRFcnJvciwgIkNhbid0IGZpbmQgY2xh c3MgXCIlc1wiLiIgJSBjbGFzc25hbWUKCQkJIyBhZGQgY2xhc3MgZGVmCgkJCXB5dGV4dCA9 ICgiY2xhc3MgJXM6XG4iICUgY2xhc3NuYW1lKSArIHB5dGV4dAoJCQlzZWxmaXJzdGxpbmUg PSBzZWxmaXJzdGxpbmUgLSAxCgkJZWxpZiBpbmRlbnQgPiAwOgoJCQlyYWlzZSBXLkFsZXJ0 RXJyb3IsICJDYW4ndCBydW4gaW5kZW50ZWQgY29kZS4iCgkJCgkJIyBhZGQgIm5ld2xpbmVz IiB0byBmb29sIGNvbXBpbGUvZXhlYzogCgkJIyBub3cgYSB0cmFjZWJhY2sgd2lsbCBnaXZl IHRoZSByaWdodCBsaW5lIG51bWJlcgoJCXB5dGV4dCA9IHNlbGZpcnN0bGluZSAqICdccicg KyBweXRleHQKCQlzZWxmLmV4ZWNzdHJpbmcocHl0ZXh0LCBnbG9iYWxzLCBsb2NhbHMsIGZp bGUsIG1vZG5hbWUpCgkJaWYgaW5kZW50ID09IDEgYW5kIGdsb2JhbHNbY2xhc3NuYW1lXSBp cyBub3Qga2xhc3M6CgkJCSMgdXBkYXRlIHRoZSBjbGFzcyBpbiBwbGFjZQoJCQlrbGFzcy5f X2RpY3RfXy51cGRhdGUoZ2xvYmFsc1tjbGFzc25hbWVdLl9fZGljdF9fKQoJCQlnbG9iYWxz W2NsYXNzbmFtZV0gPSBrbGFzcwoJCglkZWYgc2V0dGhyZWFkc3RhdGUoc2VsZiwgc3RhdGUp OgoJCW9sZHN0YXRlID0gc2VsZi5fdGhyZWFkc3RhdGUKCQlpZiBvbGRzdGF0ZVswXSA8PiBz dGF0ZVswXToKCQkJc2VsZi5ydW5idXR0b24uc2V0dGl0bGUocnVuQnV0dG9uTGFiZWxzW3N0 YXRlWzBdXSkKCQlpZiBvbGRzdGF0ZVsxXSA8PiBzdGF0ZVsxXToKCQkJc2VsZi5ydW5zZWxi dXR0b24uc2V0dGl0bGUocnVuU2VsQnV0dG9uTGFiZWxzW3N0YXRlWzFdXSkKCQlzZWxmLl90 aHJlYWRzdGF0ZSA9IHN0YXRlCgkKCWRlZiBfZXhlY190aHJlYWR3cmFwcGVyKHNlbGYsICph cmdzLCAqKmt3YXJncyk6CgkJYXBwbHkoZXhlY3N0cmluZywgYXJncywga3dhcmdzKQoJCXNl bGYuc2V0dGhyZWFkc3RhdGUoKDAsIDApKQoJCXNlbGYuX3RocmVhZCA9IE5vbmUKCQoJZGVm IGV4ZWNzdHJpbmcoc2VsZiwgcHl0ZXh0LCBnbG9iYWxzLCBsb2NhbHMsIGZpbGUsIG1vZG5h bWUpOgoJCXRyYWNlYmFja3dpbmRvdy5oaWRlKCkKCQkjIHVwZGF0ZSB3aW5kb3dzCgkJVy5n ZXRhcHBsaWNhdGlvbigpLnJlZnJlc2h3aW5kb3dzKCkKCQlpZiBzZWxmLnJ1bl9hc19tYWlu OgoJCQltb2RuYW1lID0gIl9fbWFpbl9fIgoJCWlmIHNlbGYucGF0aDoKCQkJZGlyID0gb3Mu cGF0aC5kaXJuYW1lKHNlbGYucGF0aCkKCQkJc2F2ZWRpciA9IG9zLmdldGN3ZCgpCgkJCW9z LmNoZGlyKGRpcikKCQkJc3lzLnBhdGguaW5zZXJ0KDAsIGRpcikKCQllbHNlOgoJCQljd2Rp bmRleCA9IE5vbmUKCQl0cnk6CgkJCWlmIGhhdmVUaHJlYWRpbmc6CgkJCQlzZWxmLl90aHJl YWQgPSBXdGhyZWFkaW5nLlRocmVhZChvcy5wYXRoLmJhc2VuYW1lKGZpbGUpLCAKCQkJCQkJ CXNlbGYuX2V4ZWNfdGhyZWFkd3JhcHBlciwgcHl0ZXh0LCBnbG9iYWxzLCBsb2NhbHMsIGZp bGUsIHNlbGYuZGVidWdnaW5nLCAKCQkJCQkJCW1vZG5hbWUsIHNlbGYucHJvZmlsaW5nKQoJ CQkJc2VsZi5zZXR0aHJlYWRzdGF0ZSgoMSwgMSkpCgkJCQlzZWxmLl90aHJlYWQuc3RhcnQo KQoJCQllbHNlOgoJCQkJZXhlY3N0cmluZyhweXRleHQsIGdsb2JhbHMsIGxvY2FscywgZmls ZSwgc2VsZi5kZWJ1Z2dpbmcsIAoJCQkJCQkJbW9kbmFtZSwgc2VsZi5wcm9maWxpbmcpCgkJ ZmluYWxseToKCQkJaWYgc2VsZi5wYXRoOgoJCQkJb3MuY2hkaXIoc2F2ZWRpcikKCQkJCWRl bCBzeXMucGF0aFswXQoJCglkZWYgZ2V0ZW52aXJvbm1lbnQoc2VsZik6CgkJaWYgc2VsZi5w YXRoOgoJCQlmaWxlID0gc2VsZi5wYXRoCgkJCWRpciA9IG9zLnBhdGguZGlybmFtZShmaWxl KQoJCQkjIGNoZWNrIGlmIHdlJ3JlIHBhcnQgb2YgYSBwYWNrYWdlCgkJCW1vZG5hbWUgPSAi IgoJCQl3aGlsZSBvcy5wYXRoLmV4aXN0cyhvcy5wYXRoLmpvaW4oZGlyLCAiX19pbml0X18u cHkiKSk6CgkJCQlkaXIsIGRpcm5hbWUgPSBvcy5wYXRoLnNwbGl0KGRpcikKCQkJCW1vZG5h bWUgPSBkaXJuYW1lICsgJy4nICsgbW9kbmFtZQoJCQlzdWJuYW1lID0gX2ZpbGVuYW1lX2Fz X21vZG5hbWUoc2VsZi50aXRsZSkKCQkJaWYgc3VibmFtZSBpcyBOb25lOgoJCQkJcmV0dXJu IHNlbGYuZ2xvYmFscywgZmlsZSwgTm9uZQoJCQlpZiBtb2RuYW1lOgoJCQkJaWYgc3VibmFt ZSA9PSAiX19pbml0X18iOgoJCQkJCSMgc3RyaXAgdHJhaWxpbmcgcGVyaW9kCgkJCQkJbW9k bmFtZSA9IG1vZG5hbWVbOi0xXQoJCQkJZWxzZToKCQkJCQltb2RuYW1lID0gbW9kbmFtZSAr IHN1Ym5hbWUKCQkJZWxzZToKCQkJCW1vZG5hbWUgPSBzdWJuYW1lCgkJCWlmIHN5cy5tb2R1 bGVzLmhhc19rZXkobW9kbmFtZSk6CgkJCQlnbG9iYWxzID0gc3lzLm1vZHVsZXNbbW9kbmFt ZV0uX19kaWN0X18KCQkJCXNlbGYuZ2xvYmFscyA9IHt9CgkJCWVsc2U6CgkJCQlnbG9iYWxz ID0gc2VsZi5nbG9iYWxzCgkJCQltb2RuYW1lID0gc3VibmFtZQoJCWVsc2U6CgkJCWZpbGUg PSAnPCVzPicgJSBzZWxmLnRpdGxlCgkJCWdsb2JhbHMgPSBzZWxmLmdsb2JhbHMKCQkJbW9k bmFtZSA9IGZpbGUKCQlyZXR1cm4gZ2xvYmFscywgZmlsZSwgbW9kbmFtZQoJCglkZWYgd3Jp dGUoc2VsZiwgc3R1ZmYpOgoJCSIiImZvciB1c2UgYXMgc3Rkb3V0IiIiCgkJc2VsZi5fYnVm ID0gc2VsZi5fYnVmICsgc3R1ZmYKCQlpZiAnXG4nIGluIHNlbGYuX2J1ZjoKCQkJc2VsZi5m bHVzaCgpCgkKCWRlZiBmbHVzaChzZWxmKToKCQlzdHVmZiA9IHN0cmluZy5zcGxpdChzZWxm Ll9idWYsICdcbicpCgkJc3R1ZmYgPSBzdHJpbmcuam9pbihzdHVmZiwgJ1xyJykKCQllbmQg PSBzZWxmLmVkaXRncm91cC5lZGl0b3IudGVkLldFR2V0VGV4dExlbmd0aCgpCgkJc2VsZi5l ZGl0Z3JvdXAuZWRpdG9yLnRlZC5XRVNldFNlbGVjdGlvbihlbmQsIGVuZCkKCQlzZWxmLmVk aXRncm91cC5lZGl0b3IudGVkLldFSW5zZXJ0KHN0dWZmLCBOb25lLCBOb25lKQoJCXNlbGYu ZWRpdGdyb3VwLmVkaXRvci51cGRhdGVzY3JvbGxiYXJzKCkKCQlzZWxmLl9idWYgPSAiIgoJ CSMgPyBvcHRpb25hbDoKCQkjc2VsZi53aWQuU2VsZWN0V2luZG93KCkKCQoJZGVmIGdldGNs YXNzbGlzdChzZWxmKToKCQlmcm9tIHN0cmluZyBpbXBvcnQgZmluZCwgc3RyaXAKCQltZXRo b2RSRSA9IHJlLmNvbXBpbGUociJcclsgXHRdK2RlZiAiKQoJCWZpbmRNZXRob2QgPSBtZXRo b2RSRS5zZWFyY2gKCQllZGl0b3IgPSBzZWxmLmVkaXRncm91cC5lZGl0b3IKCQl0ZXh0ID0g ZWRpdG9yLmdldCgpCgkJbGlzdCA9IFtdCgkJYXBwZW5kID0gbGlzdC5hcHBlbmQKCQlmdW5j dGFnID0gImZ1bmMiCgkJY2xhc3N0YWcgPSAiY2xhc3MiCgkJbWV0aG9kdGFnID0gIm1ldGhv ZCIKCQlwb3MgPSAtMQoJCWlmIHRleHRbOjRdID09ICdkZWYgJzoKCQkJYXBwZW5kKChwb3Mg KyA0LCBmdW5jdGFnKSkKCQkJcG9zID0gNAoJCXdoaWxlIDE6CgkJCXBvcyA9IGZpbmQodGV4 dCwgJ1xyZGVmICcsIHBvcyArIDEpCgkJCWlmIHBvcyA8IDA6CgkJCQlicmVhawoJCQlhcHBl bmQoKHBvcyArIDUsIGZ1bmN0YWcpKQoJCXBvcyA9IC0xCgkJaWYgdGV4dFs6Nl0gPT0gJ2Ns YXNzICc6CgkJCWFwcGVuZCgocG9zICsgNiwgY2xhc3N0YWcpKQoJCQlwb3MgPSA2CgkJd2hp bGUgMToKCQkJcG9zID0gZmluZCh0ZXh0LCAnXHJjbGFzcyAnLCBwb3MgKyAxKQoJCQlpZiBw b3MgPCAwOgoJCQkJYnJlYWsKCQkJYXBwZW5kKChwb3MgKyA3LCBjbGFzc3RhZykpCgkJcG9z ID0gMAoJCXdoaWxlIDE6CgkJCW0gPSBmaW5kTWV0aG9kKHRleHQsIHBvcyArIDEpCgkJCWlm IG0gaXMgTm9uZToKCQkJCWJyZWFrCgkJCXBvcyA9IG0ucmVnc1swXVswXQoJCQkjcG9zID0g ZmluZCh0ZXh0LCAnXHJcdGRlZiAnLCBwb3MgKyAxKQoJCQlhcHBlbmQoKG0ucmVnc1swXVsx XSwgbWV0aG9kdGFnKSkKCQlsaXN0LnNvcnQoKQoJCWNsYXNzbGlzdCA9IFtdCgkJbWV0aG9k bGlzdGFwcGVuZCA9IE5vbmUKCQlvZmZzZXRUb0xpbmUgPSBlZGl0b3IudGVkLldFT2Zmc2V0 VG9MaW5lCgkJZ2V0TGluZVJhbmdlID0gZWRpdG9yLnRlZC5XRUdldExpbmVSYW5nZQoJCWFw cGVuZCA9IGNsYXNzbGlzdC5hcHBlbmQKCQlmb3IgcG9zLCB0YWcgaW4gbGlzdDoKCQkJbGlu ZW5vID0gb2Zmc2V0VG9MaW5lKHBvcykKCQkJbGluZVN0YXJ0LCBsaW5lRW5kID0gZ2V0TGlu ZVJhbmdlKGxpbmVubykKCQkJbGluZSA9IHN0cmlwKHRleHRbcG9zOmxpbmVFbmRdKQoJCQls aW5lID0gbGluZVs6aWRlbnRpZmllUkVfbWF0Y2gobGluZSldCgkJCWlmIHRhZyBpcyBmdW5j dGFnOgoJCQkJYXBwZW5kKCgiZGVmICIgKyBsaW5lLCBsaW5lbm8gKyAxKSkKCQkJCW1ldGhv ZGxpc3RhcHBlbmQgPSBOb25lCgkJCWVsaWYgdGFnIGlzIGNsYXNzdGFnOgoJCQkJYXBwZW5k KFsiY2xhc3MgIiArIGxpbmVdKQoJCQkJbWV0aG9kbGlzdGFwcGVuZCA9IGNsYXNzbGlzdFst MV0uYXBwZW5kCgkJCWVsaWYgbWV0aG9kbGlzdGFwcGVuZCBhbmQgdGFnIGlzIG1ldGhvZHRh ZzoKCQkJCW1ldGhvZGxpc3RhcHBlbmQoKCJkZWYgIiArIGxpbmUsIGxpbmVubyArIDEpKQoJ CXJldHVybiBjbGFzc2xpc3QKCQoJZGVmIHBvcHNlbGVjdGxpbmUoc2VsZiwgbGluZW5vKToK CQlzZWxmLmVkaXRncm91cC5lZGl0b3Iuc2VsZWN0bGluZShsaW5lbm8gLSAxKQoJCglkZWYg c2VsZWN0bGluZShzZWxmLCBsaW5lbm8sIGNoYXJvZmZzZXQgPSAwKToKCQlzZWxmLmVkaXRn cm91cC5lZGl0b3Iuc2VsZWN0bGluZShsaW5lbm8gLSAxLCBjaGFyb2Zmc2V0KQoKY2xhc3Mg X3NhdmVvcHRpb25zOgoJCglkZWYgX19pbml0X18oc2VsZiwgY3JlYXRvciwgZW9sbik6CgkJ c2VsZi5ydiA9IE5vbmUKCQlzZWxmLmVvbG4gPSBlb2xuCgkJc2VsZi53ID0gdyA9IFcuTW9k YWxEaWFsb2coKDI2MCwgMTYwKSwgJ1NhdmUgb3B0aW9ucycpCgkJcmFkaW9idXR0b25zID0g W10KCQl3LmxhYmVsID0gVy5UZXh0Qm94KCg4LCA4LCA4MCwgMTgpLCAiRmlsZSBjcmVhdG9y OiIpCgkJdy5pZGVfcmFkaW8gPSBXLlJhZGlvQnV0dG9uKCg4LCAyMiwgMTYwLCAxOCksICJU aGlzIGFwcGxpY2F0aW9uIiwgcmFkaW9idXR0b25zLCBzZWxmLmlkZV9oaXQpCgkJdy5pbnRl cnBfcmFkaW8gPSBXLlJhZGlvQnV0dG9uKCg4LCA0MiwgMTYwLCAxOCksICJNYWNQeXRob24g SW50ZXJwcmV0ZXIiLCByYWRpb2J1dHRvbnMsIHNlbGYuaW50ZXJwX2hpdCkKCQl3LmludGVy cHhfcmFkaW8gPSBXLlJhZGlvQnV0dG9uKCg4LCA2MiwgMTYwLCAxOCksICJPU1ggUHl0aG9u VyBJbnRlcnByZXRlciIsIHJhZGlvYnV0dG9ucywgc2VsZi5pbnRlcnB4X2hpdCkKCQl3Lm90 aGVyX3JhZGlvID0gVy5SYWRpb0J1dHRvbigoOCwgODIsIDUwLCAxOCksICJPdGhlcjoiLCBy YWRpb2J1dHRvbnMpCgkJdy5vdGhlcl9jcmVhdG9yID0gVy5FZGl0VGV4dCgoNjIsIDgyLCA0 MCwgMjApLCBjcmVhdG9yLCBzZWxmLm90aGVyc2VsZWN0KQoJCXcubm9uZV9yYWRpbyA9IFcu UmFkaW9CdXR0b24oKDgsIDEwMiwgMTYwLCAxOCksICJOb25lIiwgcmFkaW9idXR0b25zLCBz ZWxmLm5vbmVfaGl0KQoJCXcuY2FuY2VsYnV0dG9uID0gVy5CdXR0b24oKC0xODAsIC0zMCwg ODAsIDE2KSwgIkNhbmNlbCIsIHNlbGYuY2FuY2VsYnV0dG9uaGl0KQoJCXcub2tidXR0b24g PSBXLkJ1dHRvbigoLTkwLCAtMzAsIDgwLCAxNiksICJEb25lIiwgc2VsZi5va2J1dHRvbmhp dCkKCQl3LnNldGRlZmF1bHRidXR0b24ody5va2J1dHRvbikKCQlpZiBjcmVhdG9yID09ICdQ eXRoJzoKCQkJdy5pbnRlcnBfcmFkaW8uc2V0KDEpCgkJZWxpZiBjcmVhdG9yID09IFcuX3Np Z25hdHVyZToKCQkJdy5pZGVfcmFkaW8uc2V0KDEpCgkJZWxpZiBjcmVhdG9yID09ICdQeXRY JzoKCQkJdy5pbnRlcnB4X3JhZGlvLnNldCgxKQoJCWVsaWYgY3JlYXRvciA9PSAnXDBcMFww XDAnOgoJCQl3Lm5vbmVfcmFkaW8uc2V0KDEpCgkJZWxzZToKCQkJdy5vdGhlcl9yYWRpby5z ZXQoMSkKCQkJCgkJdy5lb2xubGFiZWwgPSBXLlRleHRCb3goKDE2OCwgOCwgODAsIDE4KSwg Ik5ld2xpbmUgc3R5bGU6IikKCQlyYWRpb2J1dHRvbnMgPSBbXQoJCXcudW5peF9yYWRpbyA9 IFcuUmFkaW9CdXR0b24oKDE2OCwgMjIsIDgwLCAxOCksICJVbml4IiwgcmFkaW9idXR0b25z LCBzZWxmLnVuaXhfaGl0KQoJCXcubWFjX3JhZGlvID0gVy5SYWRpb0J1dHRvbigoMTY4LCA0 MiwgODAsIDE4KSwgIk1hY2ludG9zaCIsIHJhZGlvYnV0dG9ucywgc2VsZi5tYWNfaGl0KQoJ CXcud2luX3JhZGlvID0gVy5SYWRpb0J1dHRvbigoMTY4LCA2MiwgODAsIDE4KSwgIldpbmRv d3MiLCByYWRpb2J1dHRvbnMsIHNlbGYud2luX2hpdCkKCQlpZiBzZWxmLmVvbG4gPT0gJ1xu JzoKCQkJdy51bml4X3JhZGlvLnNldCgxKQoJCWVsaWYgc2VsZi5lb2xuID09ICdcclxuJzoK CQkJdy53aW5fcmFkaW8uc2V0KDEpCgkJZWxzZToKCQkJdy5tYWNfcmFkaW8uc2V0KDEpCgkJ CgkJdy5iaW5kKCJjbWQuIiwgdy5jYW5jZWxidXR0b24ucHVzaCkKCQl3Lm9wZW4oKQoJCglk ZWYgaWRlX2hpdChzZWxmKToKCQlzZWxmLncub3RoZXJfY3JlYXRvci5zZXQoVy5fc2lnbmF0 dXJlKQoJCglkZWYgaW50ZXJwX2hpdChzZWxmKToKCQlzZWxmLncub3RoZXJfY3JlYXRvci5z ZXQoIlB5dGgiKQoJCglkZWYgaW50ZXJweF9oaXQoc2VsZik6CgkJc2VsZi53Lm90aGVyX2Ny ZWF0b3Iuc2V0KCJQeXRYIikKCQoJZGVmIG5vbmVfaGl0KHNlbGYpOgoJCXNlbGYudy5vdGhl cl9jcmVhdG9yLnNldCgiXDBcMFwwXDAiKQoJCglkZWYgb3RoZXJzZWxlY3Qoc2VsZiwgKmFy Z3MpOgoJCXNlbF9mcm9tLCBzZWxfdG8gPSBzZWxmLncub3RoZXJfY3JlYXRvci5nZXRzZWxl Y3Rpb24oKQoJCWNyZWF0b3IgPSBzZWxmLncub3RoZXJfY3JlYXRvci5nZXQoKVs6NF0KCQlj cmVhdG9yID0gY3JlYXRvciArICIgIiAqICg0IC0gbGVuKGNyZWF0b3IpKQoJCXNlbGYudy5v dGhlcl9jcmVhdG9yLnNldChjcmVhdG9yKQoJCXNlbGYudy5vdGhlcl9jcmVhdG9yLnNldHNl bGVjdGlvbihzZWxfZnJvbSwgc2VsX3RvKQoJCXNlbGYudy5vdGhlcl9yYWRpby5zZXQoMSkK CQoJZGVmIG1hY19oaXQoc2VsZik6CgkJc2VsZi5lb2xuID0gJ1xyJwoJCQoJZGVmIHVuaXhf aGl0KHNlbGYpOgoJCXNlbGYuZW9sbiA9ICdcbicKCQkKCWRlZiB3aW5faGl0KHNlbGYpOgoJ CXNlbGYuZW9sbiA9ICdcclxuJwoJCQoJZGVmIGNhbmNlbGJ1dHRvbmhpdChzZWxmKToKCQlz ZWxmLncuY2xvc2UoKQoJCglkZWYgb2tidXR0b25oaXQoc2VsZik6CgkJc2VsZi5ydiA9IChz ZWxmLncub3RoZXJfY3JlYXRvci5nZXQoKVs6NF0sIHNlbGYuZW9sbikKCQlzZWxmLncuY2xv c2UoKQoKCmRlZiBTYXZlT3B0aW9ucyhjcmVhdG9yLCBlb2xuKToKCXMgPSBfc2F2ZW9wdGlv bnMoY3JlYXRvciwgZW9sbikKCXJldHVybiBzLnJ2CgoKZGVmIF9lc2NhcGUod2hlcmUsIHdo YXQpIDogCglyZXR1cm4gc3RyaW5nLmpvaW4oc3RyaW5nLnNwbGl0KHdoZXJlLCB3aGF0KSwg J1xcJyArIHdoYXQpCgpkZWYgX21ha2V3aG9sZXdvcmRwYXR0ZXJuKHdvcmQpOgoJIyBmaXJz dCwgZXNjYXBlIHNwZWNpYWwgcmVnZXggY2hhcnMKCWZvciBlc2MgaW4gIlxcW10oKXwuKl4r JD8iOgoJCXdvcmQgPSBfZXNjYXBlKHdvcmQsIGVzYykKCW5vdHdvcmRjaGFyc3BhdCA9ICdb XicgKyBfd29yZGNoYXJzICsgJ10nCglwYXR0ZXJuID0gJygnICsgd29yZCArICcpJwoJaWYg d29yZFswXSBpbiBfd29yZGNoYXJzOgoJCXBhdHRlcm4gPSBub3R3b3JkY2hhcnNwYXQgKyBw YXR0ZXJuCglpZiB3b3JkWy0xXSBpbiBfd29yZGNoYXJzOgoJCXBhdHRlcm4gPSBwYXR0ZXJu ICsgbm90d29yZGNoYXJzcGF0CglyZXR1cm4gcmUuY29tcGlsZShwYXR0ZXJuKQoKCmNsYXNz IFNlYXJjaEVuZ2luZToKCQoJZGVmIF9faW5pdF9fKHNlbGYpOgoJCXNlbGYudmlzaWJsZSA9 IDAKCQlzZWxmLncgPSBOb25lCgkJc2VsZi5wYXJtcyA9IHsgICJmaW5kIjogIiIsCgkJCQkJ InJlcGxhY2UiOiAiIiwKCQkJCQkid3JhcCI6IDEsCgkJCQkJImNhc2VzZW5zIjogMSwKCQkJ CQkid2hvbGV3b3JkIjogMQoJCQkJfQoJCWltcG9ydCBNYWNQcmVmcwoJCXByZWZzID0gTWFj UHJlZnMuR2V0UHJlZnMoVy5nZXRhcHBsaWNhdGlvbigpLnByZWZmaWxlcGF0aCkKCQlpZiBw cmVmcy5zZWFyY2hlbmdpbmU6CgkJCXNlbGYucGFybXNbImNhc2VzZW5zIl0gPSBwcmVmcy5z ZWFyY2hlbmdpbmUuY2FzZXNlbnMKCQkJc2VsZi5wYXJtc1sid3JhcCJdID0gcHJlZnMuc2Vh cmNoZW5naW5lLndyYXAKCQkJc2VsZi5wYXJtc1sid2hvbGV3b3JkIl0gPSBwcmVmcy5zZWFy Y2hlbmdpbmUud2hvbGV3b3JkCgkKCWRlZiBzaG93KHNlbGYpOgoJCXNlbGYudmlzaWJsZSA9 IDEKCQlpZiBzZWxmLnc6CgkJCXNlbGYudy53aWQuU2hvd1dpbmRvdygpCgkJCXNlbGYudy53 aWQuU2VsZWN0V2luZG93KCkKCQkJc2VsZi53LmZpbmQuZWRpdC5zZWxlY3QoMSkKCQkJc2Vs Zi53LmZpbmQuZWRpdC5zZWxlY3RhbGwoKQoJCQlyZXR1cm4KCQlzZWxmLncgPSBXLkRpYWxv ZygoNDIwLCAxNTApLCAiRmluZCIpCgkJCgkJc2VsZi53LmZpbmQgPSBUaXRsZWRFZGl0VGV4 dCgoMTAsIDQsIDMwMCwgMzYpLCAiU2VhcmNoIGZvcjoiKQoJCXNlbGYudy5yZXBsYWNlID0g VGl0bGVkRWRpdFRleHQoKDEwLCAxMDAsIDMwMCwgMzYpLCAiUmVwbGFjZSB3aXRoOiIpCgkJ CgkJc2VsZi53LmJveGVzID0gVy5Hcm91cCgoMTAsIDUwLCAzMDAsIDQwKSkKCQlzZWxmLncu Ym94ZXMuY2FzZXNlbnMgPSBXLkNoZWNrQm94KCgwLCAwLCAxMDAsIDE2KSwgIkNhc2Ugc2Vu c2l0aXZlIikKCQlzZWxmLncuYm94ZXMud2hvbGV3b3JkID0gVy5DaGVja0JveCgoMCwgMjAs IDEwMCwgMTYpLCAiV2hvbGUgd29yZCIpCgkJc2VsZi53LmJveGVzLndyYXAgPSBXLkNoZWNr Qm94KCgxMTAsIDAsIDEwMCwgMTYpLCAiV3JhcCBhcm91bmQiKQoJCQoJCXNlbGYuYnV0dG9u cyA9IFsJKCJGaW5kIiwJCSJjbWRmIiwJIHNlbGYuZmluZCksIAoJCQkJCSgiUmVwbGFjZSIs CSAgICAgImNtZHIiLAkgc2VsZi5yZXBsYWNlKSwgCgkJCQkJKCJSZXBsYWNlIGFsbCIsCSBO b25lLCAgIHNlbGYucmVwbGFjZWFsbCksIAoJCQkJCSgiRG9uJ3QgZmluZCIsICAiY21kZCIs CSBzZWxmLmRvbnQpLCAKCQkJCQkoIkNhbmNlbCIsCSAgICAgICJjbWQuIiwJIHNlbGYuY2Fu Y2VsKQoJCQkJXQoJCWZvciBpIGluIHJhbmdlKGxlbihzZWxmLmJ1dHRvbnMpKToKCQkJYm91 bmRzID0gLTkwLCAyMiArIGkgKiAyNCwgODAsIDE2CgkJCXRpdGxlLCBzaG9ydGN1dCwgY2Fs bGJhY2sgPSBzZWxmLmJ1dHRvbnNbaV0KCQkJc2VsZi53W3RpdGxlXSA9IFcuQnV0dG9uKGJv dW5kcywgdGl0bGUsIGNhbGxiYWNrKQoJCQlpZiBzaG9ydGN1dDoKCQkJCXNlbGYudy5iaW5k KHNob3J0Y3V0LCBzZWxmLndbdGl0bGVdLnB1c2gpCgkJc2VsZi53LnNldGRlZmF1bHRidXR0 b24oc2VsZi53WyJEb24ndCBmaW5kIl0pCgkJc2VsZi53LmZpbmQuZWRpdC5iaW5kKCI8a2V5 PiIsIHNlbGYua2V5KQoJCXNlbGYudy5iaW5kKCI8YWN0aXZhdGU+Iiwgc2VsZi5hY3RpdmF0 ZSkKCQlzZWxmLncuYmluZCgiPGNsb3NlPiIsIHNlbGYuY2xvc2UpCgkJc2VsZi53Lm9wZW4o KQoJCXNlbGYuc2V0cGFybXMoKQoJCXNlbGYudy5maW5kLmVkaXQuc2VsZWN0KDEpCgkJc2Vs Zi53LmZpbmQuZWRpdC5zZWxlY3RhbGwoKQoJCXNlbGYuY2hlY2tidXR0b25zKCkKCQoJZGVm IGNsb3NlKHNlbGYpOgoJCXNlbGYuaGlkZSgpCgkJcmV0dXJuIC0xCgkKCWRlZiBrZXkoc2Vs ZiwgY2hhciwgbW9kaWZpZXJzKToKCQlzZWxmLncuZmluZC5lZGl0LmtleShjaGFyLCBtb2Rp ZmllcnMpCgkJc2VsZi5jaGVja2J1dHRvbnMoKQoJCXJldHVybiAxCgkKCWRlZiBhY3RpdmF0 ZShzZWxmLCBvbm9mZik6CgkJaWYgb25vZmY6CgkJCXNlbGYuY2hlY2tidXR0b25zKCkKCQoJ ZGVmIGNoZWNrYnV0dG9ucyhzZWxmKToKCQllZGl0b3IgPSBmaW5kZWRpdG9yKHNlbGYpCgkJ aWYgZWRpdG9yOgoJCQlpZiBzZWxmLncuZmluZC5nZXQoKToKCQkJCWZvciB0aXRsZSwgY21k LCBjYWxsIGluIHNlbGYuYnV0dG9uc1s6LTJdOgoJCQkJCXNlbGYud1t0aXRsZV0uZW5hYmxl KDEpCgkJCQlzZWxmLncuc2V0ZGVmYXVsdGJ1dHRvbihzZWxmLndbIkZpbmQiXSkKCQkJZWxz ZToKCQkJCWZvciB0aXRsZSwgY21kLCBjYWxsIGluIHNlbGYuYnV0dG9uc1s6LTJdOgoJCQkJ CXNlbGYud1t0aXRsZV0uZW5hYmxlKDApCgkJCQlzZWxmLncuc2V0ZGVmYXVsdGJ1dHRvbihz ZWxmLndbIkRvbid0IGZpbmQiXSkKCQllbHNlOgoJCQlmb3IgdGl0bGUsIGNtZCwgY2FsbCBp biBzZWxmLmJ1dHRvbnNbOi0yXToKCQkJCXNlbGYud1t0aXRsZV0uZW5hYmxlKDApCgkJCXNl bGYudy5zZXRkZWZhdWx0YnV0dG9uKHNlbGYud1siRG9uJ3QgZmluZCJdKQoJCglkZWYgZmlu ZChzZWxmKToKCQlzZWxmLmdldHBhcm1zZnJvbXdpbmRvdygpCgkJaWYgc2VsZi5maW5kbmV4 dCgpOgoJCQlzZWxmLmhpZGUoKQoJCglkZWYgcmVwbGFjZShzZWxmKToKCQllZGl0b3IgPSBm aW5kZWRpdG9yKHNlbGYpCgkJaWYgbm90IGVkaXRvcjoKCQkJcmV0dXJuCgkJaWYgc2VsZi52 aXNpYmxlOgoJCQlzZWxmLmdldHBhcm1zZnJvbXdpbmRvdygpCgkJdGV4dCA9IGVkaXRvci5n ZXRzZWxlY3RlZHRleHQoKQoJCWZpbmQgPSBzZWxmLnBhcm1zWyJmaW5kIl0KCQlpZiBub3Qg c2VsZi5wYXJtc1siY2FzZXNlbnMiXToKCQkJZmluZCA9IHN0cmluZy5sb3dlcihmaW5kKQoJ CQl0ZXh0ID0gc3RyaW5nLmxvd2VyKHRleHQpCgkJaWYgdGV4dCA9PSBmaW5kOgoJCQlzZWxm LmhpZGUoKQoJCQllZGl0b3IuaW5zZXJ0KHNlbGYucGFybXNbInJlcGxhY2UiXSkKCQoJZGVm IHJlcGxhY2VhbGwoc2VsZik6CgkJZWRpdG9yID0gZmluZGVkaXRvcihzZWxmKQoJCWlmIG5v dCBlZGl0b3I6CgkJCXJldHVybgoJCWlmIHNlbGYudmlzaWJsZToKCQkJc2VsZi5nZXRwYXJt c2Zyb213aW5kb3coKQoJCVcuU2V0Q3Vyc29yKCJ3YXRjaCIpCgkJZmluZCA9IHNlbGYucGFy bXNbImZpbmQiXQoJCWlmIG5vdCBmaW5kOgoJCQlyZXR1cm4KCQlmaW5kbGVuID0gbGVuKGZp bmQpCgkJcmVwbGFjZSA9IHNlbGYucGFybXNbInJlcGxhY2UiXQoJCXJlcGxhY2VsZW4gPSBs ZW4ocmVwbGFjZSkKCQlUZXh0ID0gZWRpdG9yLmdldCgpCgkJaWYgbm90IHNlbGYucGFybXNb ImNhc2VzZW5zIl06CgkJCWZpbmQgPSBzdHJpbmcubG93ZXIoZmluZCkKCQkJdGV4dCA9IHN0 cmluZy5sb3dlcihUZXh0KQoJCWVsc2U6CgkJCXRleHQgPSBUZXh0CgkJbmV3dGV4dCA9ICIi CgkJcG9zID0gMAoJCWNvdW50ZXIgPSAwCgkJd2hpbGUgMToKCQkJaWYgc2VsZi5wYXJtc1si d2hvbGV3b3JkIl06CgkJCQl3aG9sZXdvcmRSRSA9IF9tYWtld2hvbGV3b3JkcGF0dGVybihm aW5kKQoJCQkJbWF0Y2ggPSB3aG9sZXdvcmRSRS5zZWFyY2godGV4dCwgcG9zKQoJCQkJaWYg bWF0Y2g6CgkJCQkJcG9zID0gbWF0Y2guc3RhcnQoMSkKCQkJCWVsc2U6CgkJCQkJcG9zID0g LTEKCQkJZWxzZToKCQkJCXBvcyA9IHN0cmluZy5maW5kKHRleHQsIGZpbmQsIHBvcykKCQkJ aWYgcG9zIDwgMDoKCQkJCWJyZWFrCgkJCWNvdW50ZXIgPSBjb3VudGVyICsgMQoJCQl0ZXh0 ID0gdGV4dFs6cG9zXSArIHJlcGxhY2UgKyB0ZXh0W3BvcyArIGZpbmRsZW46XQoJCQlUZXh0 ID0gVGV4dFs6cG9zXSArIHJlcGxhY2UgKyBUZXh0W3BvcyArIGZpbmRsZW46XQoJCQlwb3Mg PSBwb3MgKyByZXBsYWNlbGVuCgkJVy5TZXRDdXJzb3IoImFycm93IikKCQlpZiBjb3VudGVy OgoJCQlzZWxmLmhpZGUoKQoJCQlpbXBvcnQgRWFzeURpYWxvZ3MKCQkJZnJvbSBDYXJib24g aW1wb3J0IFJlcwoJCQllZGl0b3IudGV4dGNoYW5nZWQoKQoJCQllZGl0b3Iuc2VsZWN0aW9u Y2hhbmdlZCgpCgkJCWVkaXRvci50ZWQuV0VVc2VUZXh0KFJlcy5SZXNvdXJjZShUZXh0KSkK CQkJZWRpdG9yLnRlZC5XRUNhbFRleHQoKQoJCQllZGl0b3IuU2V0UG9ydCgpCgkJCWVkaXRv ci5HZXRXaW5kb3coKS5JbnZhbFdpbmRvd1JlY3QoZWRpdG9yLl9ib3VuZHMpCgkJCSNlZGl0 b3IudGVkLldFVXBkYXRlKHNlbGYudy53aWQuR2V0V2luZG93UG9ydCgpLnZpc1JnbikKCQkJ RWFzeURpYWxvZ3MuTWVzc2FnZSgiUmVwbGFjZWQgJWQgb2NjdXJyZW5jZXMiICUgY291bnRl cikKCQoJZGVmIGRvbnQoc2VsZik6CgkJc2VsZi5nZXRwYXJtc2Zyb213aW5kb3coKQoJCXNl bGYuaGlkZSgpCgkKCWRlZiByZXBsYWNlZmluZChzZWxmKToKCQlzZWxmLnJlcGxhY2UoKQoJ CXNlbGYuZmluZG5leHQoKQoJCglkZWYgc2V0ZmluZHN0cmluZyhzZWxmKToKCQllZGl0b3Ig PSBmaW5kZWRpdG9yKHNlbGYpCgkJaWYgbm90IGVkaXRvcjoKCQkJcmV0dXJuCgkJZmluZCA9 IGVkaXRvci5nZXRzZWxlY3RlZHRleHQoKQoJCWlmIG5vdCBmaW5kOgoJCQlyZXR1cm4KCQlz ZWxmLnBhcm1zWyJmaW5kIl0gPSBmaW5kCgkJaWYgc2VsZi53OgoJCQlzZWxmLncuZmluZC5l ZGl0LnNldChzZWxmLnBhcm1zWyJmaW5kIl0pCgkJCXNlbGYudy5maW5kLmVkaXQuc2VsZWN0 YWxsKCkKCQoJZGVmIGZpbmRuZXh0KHNlbGYpOgoJCWVkaXRvciA9IGZpbmRlZGl0b3Ioc2Vs ZikKCQlpZiBub3QgZWRpdG9yOgoJCQlyZXR1cm4KCQlmaW5kID0gc2VsZi5wYXJtc1siZmlu ZCJdCgkJaWYgbm90IGZpbmQ6CgkJCXJldHVybgoJCXRleHQgPSBlZGl0b3IuZ2V0KCkKCQlp ZiBub3Qgc2VsZi5wYXJtc1siY2FzZXNlbnMiXToKCQkJZmluZCA9IHN0cmluZy5sb3dlcihm aW5kKQoJCQl0ZXh0ID0gc3RyaW5nLmxvd2VyKHRleHQpCgkJc2Vsc3RhcnQsIHNlbGVuZCA9 IGVkaXRvci5nZXRzZWxlY3Rpb24oKQoJCXNlbHN0YXJ0LCBzZWxlbmQgPSBtaW4oc2Vsc3Rh cnQsIHNlbGVuZCksIG1heChzZWxzdGFydCwgc2VsZW5kKQoJCWlmIHNlbGYucGFybXNbIndo b2xld29yZCJdOgoJCQl3aG9sZXdvcmRSRSA9IF9tYWtld2hvbGV3b3JkcGF0dGVybihmaW5k KQoJCQltYXRjaCA9IHdob2xld29yZFJFLnNlYXJjaCh0ZXh0LCBzZWxlbmQpCgkJCWlmIG1h dGNoOgoJCQkJcG9zID0gbWF0Y2guc3RhcnQoMSkKCQkJZWxzZToKCQkJCXBvcyA9IC0xCgkJ ZWxzZToKCQkJcG9zID0gc3RyaW5nLmZpbmQodGV4dCwgZmluZCwgc2VsZW5kKQoJCWlmIHBv cyA+PSAwOgoJCQllZGl0b3Iuc2V0c2VsZWN0aW9uKHBvcywgcG9zICsgbGVuKGZpbmQpKQoJ CQlyZXR1cm4gMQoJCWVsaWYgc2VsZi5wYXJtc1sid3JhcCJdOgoJCQlpZiBzZWxmLnBhcm1z WyJ3aG9sZXdvcmQiXToKCQkJCW1hdGNoID0gd2hvbGV3b3JkUkUuc2VhcmNoKHRleHQsIDAp CgkJCQlpZiBtYXRjaDoKCQkJCQlwb3MgPSBtYXRjaC5zdGFydCgxKQoJCQkJZWxzZToKCQkJ CQlwb3MgPSAtMQoJCQllbHNlOgoJCQkJcG9zID0gc3RyaW5nLmZpbmQodGV4dCwgZmluZCkK CQkJaWYgc2Vsc3RhcnQgPiBwb3MgPj0gMDoKCQkJCWVkaXRvci5zZXRzZWxlY3Rpb24ocG9z LCBwb3MgKyBsZW4oZmluZCkpCgkJCQlyZXR1cm4gMQoJCglkZWYgc2V0cGFybXMoc2VsZik6 CgkJZm9yIGtleSwgdmFsdWUgaW4gc2VsZi5wYXJtcy5pdGVtcygpOgoJCQl0cnk6CgkJCQlz ZWxmLndba2V5XS5zZXQodmFsdWUpCgkJCWV4Y2VwdCBLZXlFcnJvcjoKCQkJCXNlbGYudy5i b3hlc1trZXldLnNldCh2YWx1ZSkKCQoJZGVmIGdldHBhcm1zZnJvbXdpbmRvdyhzZWxmKToK CQlpZiBub3Qgc2VsZi53OgoJCQlyZXR1cm4KCQlmb3Iga2V5LCB2YWx1ZSBpbiBzZWxmLnBh cm1zLml0ZW1zKCk6CgkJCXRyeToKCQkJCXZhbHVlID0gc2VsZi53W2tleV0uZ2V0KCkKCQkJ ZXhjZXB0IEtleUVycm9yOgoJCQkJdmFsdWUgPSBzZWxmLncuYm94ZXNba2V5XS5nZXQoKQoJ CQlzZWxmLnBhcm1zW2tleV0gPSB2YWx1ZQoJCglkZWYgY2FuY2VsKHNlbGYpOgoJCXNlbGYu aGlkZSgpCgkJc2VsZi5zZXRwYXJtcygpCgkKCWRlZiBoaWRlKHNlbGYpOgoJCWlmIHNlbGYu dzoKCQkJc2VsZi53LndpZC5IaWRlV2luZG93KCkKCQkJc2VsZi52aXNpYmxlID0gMAoJCglk ZWYgd3JpdGVwcmVmcyhzZWxmKToKCQlpbXBvcnQgTWFjUHJlZnMKCQlzZWxmLmdldHBhcm1z ZnJvbXdpbmRvdygpCgkJcHJlZnMgPSBNYWNQcmVmcy5HZXRQcmVmcyhXLmdldGFwcGxpY2F0 aW9uKCkucHJlZmZpbGVwYXRoKQoJCXByZWZzLnNlYXJjaGVuZ2luZS5jYXNlc2VucyA9IHNl bGYucGFybXNbImNhc2VzZW5zIl0KCQlwcmVmcy5zZWFyY2hlbmdpbmUud3JhcCA9IHNlbGYu cGFybXNbIndyYXAiXQoJCXByZWZzLnNlYXJjaGVuZ2luZS53aG9sZXdvcmQgPSBzZWxmLnBh cm1zWyJ3aG9sZXdvcmQiXQoJCXByZWZzLnNhdmUoKQoJCgpjbGFzcyBUaXRsZWRFZGl0VGV4 dChXLkdyb3VwKToKCQoJZGVmIF9faW5pdF9fKHNlbGYsIHBvc3NpemUsIHRpdGxlLCB0ZXh0 ID0gIiIpOgoJCVcuR3JvdXAuX19pbml0X18oc2VsZiwgcG9zc2l6ZSkKCQlzZWxmLnRpdGxl ID0gVy5UZXh0Qm94KCgwLCAwLCAwLCAxNiksIHRpdGxlKQoJCXNlbGYuZWRpdCA9IFcuRWRp dFRleHQoKDAsIDE2LCAwLCAwKSwgdGV4dCkKCQoJZGVmIHNldChzZWxmLCB2YWx1ZSk6CgkJ c2VsZi5lZGl0LnNldCh2YWx1ZSkKCQoJZGVmIGdldChzZWxmKToKCQlyZXR1cm4gc2VsZi5l ZGl0LmdldCgpCgoKY2xhc3MgQ2xhc3NGaW5kZXIoVy5Qb3B1cFdpZGdldCk6CgkKCWRlZiBj bGljayhzZWxmLCBwb2ludCwgbW9kaWZpZXJzKToKCQlXLlNldEN1cnNvcigid2F0Y2giKQoJ CXNlbGYuc2V0KHNlbGYuX3BhcmVudHdpbmRvdy5nZXRjbGFzc2xpc3QoKSkKCQlXLlBvcHVw V2lkZ2V0LmNsaWNrKHNlbGYsIHBvaW50LCBtb2RpZmllcnMpCgoKZGVmIGdldG1pbmluZGVu dChsaW5lcyk6CglpbmRlbnQgPSAtMQoJZm9yIGxpbmUgaW4gbGluZXM6CgkJc3RyaXBwZWQg PSBzdHJpbmcuc3RyaXAobGluZSkKCQlpZiBub3Qgc3RyaXBwZWQgb3Igc3RyaXBwZWRbMF0g PT0gJyMnOgoJCQljb250aW51ZQoJCWlmIGluZGVudCA8IDAgb3IgbGluZVs6aW5kZW50XSA8 PiBpbmRlbnQgKiAnXHQnOgoJCQlpbmRlbnQgPSAwCgkJCWZvciBjIGluIGxpbmU6CgkJCQlp ZiBjIDw+ICdcdCc6CgkJCQkJYnJlYWsKCQkJCWluZGVudCA9IGluZGVudCArIDEKCXJldHVy biBpbmRlbnQKCgpkZWYgZ2V0b3B0aW9ua2V5KCk6CglyZXR1cm4gbm90IG5vdCBvcmQoRXZ0 LkdldEtleXMoKVs3XSkgJiAweDA0CgoKZGVmIGV4ZWNzdHJpbmcocHl0ZXh0LCBnbG9iYWxz LCBsb2NhbHMsIGZpbGVuYW1lPSI8c3RyaW5nPiIsIGRlYnVnZ2luZz0wLCAKCQkJbW9kbmFt ZT0iX19tYWluX18iLCBwcm9maWxpbmc9MCk6CglpZiBkZWJ1Z2dpbmc6CgkJaW1wb3J0IFB5 RGVidWdnZXIsIGJkYgoJCUJkYlF1aXQgPSBiZGIuQmRiUXVpdAoJZWxzZToKCQlCZGJRdWl0 ID0gJ0JkYlF1aXREdW1teUV4Y2VwdGlvbicKCXB5dGV4dCA9IHN0cmluZy5zcGxpdChweXRl eHQsICdccicpCglweXRleHQgPSBzdHJpbmcuam9pbihweXRleHQsICdcbicpICsgJ1xuJwoJ Vy5TZXRDdXJzb3IoIndhdGNoIikKCWdsb2JhbHNbJ19fbmFtZV9fJ10gPSBtb2RuYW1lCgln bG9iYWxzWydfX2ZpbGVfXyddID0gZmlsZW5hbWUKCXN5cy5hcmd2ID0gW2ZpbGVuYW1lXQoJ dHJ5OgoJCWNvZGUgPSBjb21waWxlKHB5dGV4dCwgZmlsZW5hbWUsICJleGVjIikKCWV4Y2Vw dDoKCQkjIFhYWFggQkFBQUFEREQuLi4uIFdlIGxldCB0cmFjZWJhY2t3aW5kb3cgZGVjaWRl IHRvIHRyZWF0IFN5bnRheEVycm9yIAoJCSMgc3BlY2lhbC4gVGhhdCdzIHdyb25nIGJlY2F1 c2UgVEhJUyBjYXNlIGlzIHNwZWNpYWwgKGNvdWxkIGJlIGxpdGVyYWwgCgkJIyBvdmVyZmxv dyEpIGFuZCBTeW50YXhFcnJvciBjb3VsZCBtZWFuIHdlIG5lZWQgYSB0cmFjZWJhY2sgKHN5 bnRheCBlcnJvciAKCQkjIGluIGltcG9ydGVkIG1vZHVsZSEhIQoJCXRyYWNlYmFja3dpbmRv dy50cmFjZWJhY2soMSwgZmlsZW5hbWUpCgkJcmV0dXJuCgl0cnk6CgkJaWYgZGVidWdnaW5n OgoJCQlpZiBoYXZlVGhyZWFkaW5nOgoJCQkJbG9jayA9IFd0aHJlYWRpbmcuTG9jaygpCgkJ CQlsb2NrLmFjcXVpcmUoKQoJCQkJUHlEZWJ1Z2dlci5zdGFydGZyb21oZXJlKCkKCQkJCWxv Y2sucmVsZWFzZSgpCgkJCWVsc2U6CgkJCQlQeURlYnVnZ2VyLnN0YXJ0ZnJvbWhlcmUoKQoJ CWVsaWYgbm90IGhhdmVUaHJlYWRpbmc6CgkJCWlmIGhhc2F0dHIoTWFjT1MsICdFbmFibGVB cHBzd2l0Y2gnKToKCQkJCU1hY09TLkVuYWJsZUFwcHN3aXRjaCgwKQoJCXRyeToKCQkJaWYg cHJvZmlsaW5nOgoJCQkJaW1wb3J0IHByb2ZpbGUsIFByb2ZpbGVCcm93c2VyCgkJCQlwID0g cHJvZmlsZS5Qcm9maWxlKCkKCQkJCXAuc2V0X2NtZChmaWxlbmFtZSkKCQkJCXRyeToKCQkJ CQlwLnJ1bmN0eChjb2RlLCBnbG9iYWxzLCBsb2NhbHMpCgkJCQlmaW5hbGx5OgoJCQkJCWlt cG9ydCBwc3RhdHMKCQkJCQkKCQkJCQlzdGF0cyA9IHBzdGF0cy5TdGF0cyhwKQoJCQkJCVBy b2ZpbGVCcm93c2VyLlByb2ZpbGVCcm93c2VyKHN0YXRzKQoJCQllbHNlOgoJCQkJZXhlYyBj b2RlIGluIGdsb2JhbHMsIGxvY2FscwoJCWZpbmFsbHk6CgkJCWlmIG5vdCBoYXZlVGhyZWFk aW5nOgoJCQkJaWYgaGFzYXR0cihNYWNPUywgJ0VuYWJsZUFwcHN3aXRjaCcpOgoJCQkJCU1h Y09TLkVuYWJsZUFwcHN3aXRjaCgtMSkKCWV4Y2VwdCBXLkFsZXJ0RXJyb3IsIGRldGFpbDoK CQlyYWlzZSBXLkFsZXJ0RXJyb3IsIGRldGFpbAoJZXhjZXB0IChLZXlib2FyZEludGVycnVw dCwgQmRiUXVpdCk6CgkJcGFzcwoJZXhjZXB0IFN5c3RlbUV4aXQsIGFyZzoKCQlpZiBhcmcu Y29kZToKCQkJc3lzLnN0ZGVyci53cml0ZSgiU2NyaXB0IGV4aXRlZCB3aXRoIHN0YXR1cyBj b2RlOiAlc1xuIiAlIHJlcHIoYXJnLmNvZGUpKQoJZXhjZXB0OgoJCWlmIGhhdmVUaHJlYWRp bmc6CgkJCWltcG9ydCBjb250aW51YXRpb24KCQkJbG9jayA9IFd0aHJlYWRpbmcuTG9jaygp CgkJCWxvY2suYWNxdWlyZSgpCgkJaWYgZGVidWdnaW5nOgoJCQlzeXMuc2V0dHJhY2UoTm9u ZSkKCQkJUHlEZWJ1Z2dlci5wb3N0bW9ydGVtKHN5cy5leGNfdHlwZSwgc3lzLmV4Y192YWx1 ZSwgc3lzLmV4Y190cmFjZWJhY2spCgkJCXJldHVybgoJCWVsc2U6CgkJCXRyYWNlYmFja3dp bmRvdy50cmFjZWJhY2soMSwgZmlsZW5hbWUpCgkJaWYgaGF2ZVRocmVhZGluZzoKCQkJbG9j ay5yZWxlYXNlKCkKCWlmIGRlYnVnZ2luZzoKCQlzeXMuc2V0dHJhY2UoTm9uZSkKCQlQeURl YnVnZ2VyLnN0b3AoKQoKCl9pZGVudGlmaWVSRSA9IHJlLmNvbXBpbGUociJbQS1aYS16X11b QS1aYS16XzAtOV0qIikKCmRlZiBpZGVudGlmaWVSRV9tYXRjaChzdHIpOgoJbWF0Y2ggPSBf aWRlbnRpZmllUkUubWF0Y2goc3RyKQoJaWYgbm90IG1hdGNoOgoJCXJldHVybiAtMQoJcmV0 dXJuIG1hdGNoLmVuZCgpCgpkZWYgX2ZpbGVuYW1lX2FzX21vZG5hbWUoZm5hbWUpOgoJaWYg Zm5hbWVbLTM6XSA9PSAnLnB5JzoKCQltb2RuYW1lID0gZm5hbWVbOi0zXQoJCW1hdGNoID0g X2lkZW50aWZpZVJFLm1hdGNoKG1vZG5hbWUpCgkJaWYgbWF0Y2ggYW5kIG1hdGNoLnN0YXJ0 KCkgPT0gMCBhbmQgbWF0Y2guZW5kKCkgPT0gbGVuKG1vZG5hbWUpOgoJCQlyZXR1cm4gc3Ry aW5nLmpvaW4oc3RyaW5nLnNwbGl0KG1vZG5hbWUsICcuJyksICdfJykKCmRlZiBmaW5kZWRp dG9yKHRvcHdpbmRvdywgZnJvbXRvcCA9IDApOgoJd2lkID0gTXlGcm9udFdpbmRvdygpCglp ZiBub3QgZnJvbXRvcDoKCQlpZiB0b3B3aW5kb3cudyBhbmQgd2lkID09IHRvcHdpbmRvdy53 LndpZDoKCQkJd2lkID0gdG9wd2luZG93Lncud2lkLkdldE5leHRXaW5kb3coKQoJaWYgbm90 IHdpZDoKCQlyZXR1cm4KCWFwcCA9IFcuZ2V0YXBwbGljYXRpb24oKQoJaWYgYXBwLl93aW5k b3dzLmhhc19rZXkod2lkKTogIyBLZXlFcnJvciBvdGhlcndpc2UgY2FuIGhhcHBlbiBpbiBS b2JvRm9nIDotKAoJCXdpbmRvdyA9IFcuZ2V0YXBwbGljYXRpb24oKS5fd2luZG93c1t3aWRd CgllbHNlOgoJCXJldHVybgoJaWYgbm90IGlzaW5zdGFuY2Uod2luZG93LCBFZGl0b3IpOgoJ CXJldHVybgoJcmV0dXJuIHdpbmRvdy5lZGl0Z3JvdXAuZWRpdG9yCgoKY2xhc3MgX0VkaXRv ckRlZmF1bHRTZXR0aW5nczoKCQoJZGVmIF9faW5pdF9fKHNlbGYpOgoJCXNlbGYudGVtcGxh dGUgPSAiJXMsICVkIHBvaW50IgoJCXNlbGYuZm9udHNldHRpbmdzLCBzZWxmLnRhYnNldHRp bmdzLCBzZWxmLndpbmRvd3NpemUgPSBnZXRlZGl0b3JwcmVmcygpCgkJc2VsZi53ID0gVy5E aWFsb2coKDMyOCwgMTIwKSwgIkVkaXRvciBkZWZhdWx0IHNldHRpbmdzIikKCQlzZWxmLncu c2V0Zm9udGJ1dHRvbiA9IFcuQnV0dG9uKCg4LCA4LCA4MCwgMTYpLCAiU2V0IGZvbnRceGM5 Iiwgc2VsZi5kb2ZvbnQpCgkJc2VsZi53LmZvbnR0ZXh0ID0gVy5UZXh0Qm94KCg5OCwgMTAs IC04LCAxNCksIHNlbGYudGVtcGxhdGUgJSAoc2VsZi5mb250c2V0dGluZ3NbMF0sIHNlbGYu Zm9udHNldHRpbmdzWzJdKSkKCQkKCQlzZWxmLncucGlja3NpemVidXR0b24gPSBXLkJ1dHRv bigoOCwgNTAsIDgwLCAxNiksICJGcm9udCB3aW5kb3ciLCBzZWxmLnBpY2tzaXplKQoJCXNl bGYudy54c2l6ZWxhYmVsID0gVy5UZXh0Qm94KCg5OCwgMzIsIDQwLCAxNCksICJXaWR0aDoi KQoJCXNlbGYudy55c2l6ZWxhYmVsID0gVy5UZXh0Qm94KCgxNDgsIDMyLCA0MCwgMTQpLCAi SGVpZ2h0OiIpCgkJc2VsZi53LnhzaXplID0gVy5FZGl0VGV4dCgoOTgsIDQ4LCA0MCwgMjAp LCBgc2VsZi53aW5kb3dzaXplWzBdYCkKCQlzZWxmLncueXNpemUgPSBXLkVkaXRUZXh0KCgx NDgsIDQ4LCA0MCwgMjApLCBgc2VsZi53aW5kb3dzaXplWzFdYCkKCQkKCQlzZWxmLncuY2Fu Y2VsYnV0dG9uID0gVy5CdXR0b24oKC0xODAsIC0yNiwgODAsIDE2KSwgIkNhbmNlbCIsIHNl bGYuY2FuY2VsKQoJCXNlbGYudy5va2J1dHRvbiA9IFcuQnV0dG9uKCgtOTAsIC0yNiwgODAs IDE2KSwgIkRvbmUiLCBzZWxmLm9rKQoJCXNlbGYudy5zZXRkZWZhdWx0YnV0dG9uKHNlbGYu dy5va2J1dHRvbikKCQlzZWxmLncuYmluZCgnY21kLicsIHNlbGYudy5jYW5jZWxidXR0b24u cHVzaCkKCQlzZWxmLncub3BlbigpCgkKCWRlZiBwaWNrc2l6ZShzZWxmKToKCQlhcHAgPSBX LmdldGFwcGxpY2F0aW9uKCkKCQllZGl0b3IgPSBmaW5kZWRpdG9yKHNlbGYpCgkJaWYgZWRp dG9yIGlzIG5vdCBOb25lOgoJCQl3aWR0aCwgaGVpZ2h0ID0gZWRpdG9yLl9wYXJlbnR3aW5k b3cuX2JvdW5kc1syOl0KCQkJc2VsZi53LnhzaXplLnNldChgd2lkdGhgKQoJCQlzZWxmLncu eXNpemUuc2V0KGBoZWlnaHRgKQoJCWVsc2U6CgkJCXJhaXNlIFcuQWxlcnRFcnJvciwgIk5v IGVkaXQgd2luZG93IGZvdW5kIgoJCglkZWYgZG9mb250KHNlbGYpOgoJCWltcG9ydCBGb250 U2V0dGluZ3MKCQlzZXR0aW5ncyA9IEZvbnRTZXR0aW5ncy5Gb250RGlhbG9nKHNlbGYuZm9u dHNldHRpbmdzLCBzZWxmLnRhYnNldHRpbmdzKQoJCWlmIHNldHRpbmdzOgoJCQlzZWxmLmZv bnRzZXR0aW5ncywgc2VsZi50YWJzZXR0aW5ncyA9IHNldHRpbmdzCgkJCXN5cy5leGNfdHJh Y2ViYWNrID0gTm9uZQoJCQlzZWxmLncuZm9udHRleHQuc2V0KHNlbGYudGVtcGxhdGUgJSAo c2VsZi5mb250c2V0dGluZ3NbMF0sIHNlbGYuZm9udHNldHRpbmdzWzJdKSkKCQoJZGVmIGNs b3NlKHNlbGYpOgoJCXNlbGYudy5jbG9zZSgpCgkJZGVsIHNlbGYudwoJCglkZWYgY2FuY2Vs KHNlbGYpOgoJCXNlbGYuY2xvc2UoKQoJCglkZWYgb2soc2VsZik6CgkJdHJ5OgoJCQl3aWR0 aCA9IHN0cmluZy5hdG9pKHNlbGYudy54c2l6ZS5nZXQoKSkKCQlleGNlcHQ6CgkJCXNlbGYu dy54c2l6ZS5zZWxlY3QoMSkKCQkJc2VsZi53LnhzaXplLnNlbGVjdGFsbCgpCgkJCXJhaXNl IFcuQWxlcnRFcnJvciwgIkJhZCBudW1iZXIgZm9yIHdpbmRvdyB3aWR0aCIKCQl0cnk6CgkJ CWhlaWdodCA9IHN0cmluZy5hdG9pKHNlbGYudy55c2l6ZS5nZXQoKSkKCQlleGNlcHQ6CgkJ CXNlbGYudy55c2l6ZS5zZWxlY3QoMSkKCQkJc2VsZi53LnlzaXplLnNlbGVjdGFsbCgpCgkJ CXJhaXNlIFcuQWxlcnRFcnJvciwgIkJhZCBudW1iZXIgZm9yIHdpbmRvdyBoZWlnaHQiCgkJ c2VsZi53aW5kb3dzaXplID0gd2lkdGgsIGhlaWdodAoJCXNldGVkaXRvcnByZWZzKHNlbGYu Zm9udHNldHRpbmdzLCBzZWxmLnRhYnNldHRpbmdzLCBzZWxmLndpbmRvd3NpemUpCgkJc2Vs Zi5jbG9zZSgpCgpkZWYgZ2V0ZWRpdG9ycHJlZnMoKToKCWltcG9ydCBNYWNQcmVmcwoJcHJl ZnMgPSBNYWNQcmVmcy5HZXRQcmVmcyhXLmdldGFwcGxpY2F0aW9uKCkucHJlZmZpbGVwYXRo KQoJdHJ5OgoJCWZvbnRzZXR0aW5ncyA9IHByZWZzLnB5ZWRpdC5mb250c2V0dGluZ3MKCQl0 YWJzZXR0aW5ncyA9IHByZWZzLnB5ZWRpdC50YWJzZXR0aW5ncwoJCXdpbmRvd3NpemUgPSBw cmVmcy5weWVkaXQud2luZG93c2l6ZQoJZXhjZXB0OgoJCWZvbnRzZXR0aW5ncyA9IHByZWZz LnB5ZWRpdC5mb250c2V0dGluZ3MgPSAoIkdlbmV2YSIsIDAsIDEwLCAoMCwgMCwgMCkpCgkJ dGFic2V0dGluZ3MgPSBwcmVmcy5weWVkaXQudGFic2V0dGluZ3MgPSAoOCwgMSkKCQl3aW5k b3dzaXplID0gcHJlZnMucHllZGl0LndpbmRvd3NpemUgPSAoNTAwLCAyNTApCgkJc3lzLmV4 Y190cmFjZWJhY2sgPSBOb25lCglyZXR1cm4gZm9udHNldHRpbmdzLCB0YWJzZXR0aW5ncywg d2luZG93c2l6ZQoKZGVmIHNldGVkaXRvcnByZWZzKGZvbnRzZXR0aW5ncywgdGFic2V0dGlu Z3MsIHdpbmRvd3NpemUpOgoJaW1wb3J0IE1hY1ByZWZzCglwcmVmcyA9IE1hY1ByZWZzLkdl dFByZWZzKFcuZ2V0YXBwbGljYXRpb24oKS5wcmVmZmlsZXBhdGgpCglwcmVmcy5weWVkaXQu Zm9udHNldHRpbmdzID0gZm9udHNldHRpbmdzCglwcmVmcy5weWVkaXQudGFic2V0dGluZ3Mg PSB0YWJzZXR0aW5ncwoJcHJlZnMucHllZGl0LndpbmRvd3NpemUgPSB3aW5kb3dzaXplCglw cmVmcy5zYXZlKCkKCl9kZWZhdWx0U2V0dGluZ3NFZGl0b3IgPSBOb25lCgpkZWYgRWRpdG9y RGVmYXVsdFNldHRpbmdzKCk6CglnbG9iYWwgX2RlZmF1bHRTZXR0aW5nc0VkaXRvcgoJaWYg X2RlZmF1bHRTZXR0aW5nc0VkaXRvciBpcyBOb25lIG9yIG5vdCBoYXNhdHRyKF9kZWZhdWx0 U2V0dGluZ3NFZGl0b3IsICJ3Iik6CgkJX2RlZmF1bHRTZXR0aW5nc0VkaXRvciA9IF9FZGl0 b3JEZWZhdWx0U2V0dGluZ3MoKQoJZWxzZToKCQlfZGVmYXVsdFNldHRpbmdzRWRpdG9yLncu c2VsZWN0KCkKCmRlZiByZXNvbHZlYWxpYXNlcyhwYXRoKToKCXRyeToKCQlyZXR1cm4gbWFj ZnMuUmVzb2x2ZUFsaWFzRmlsZShwYXRoKVswXS5hc19wYXRobmFtZSgpCglleGNlcHQgKG1h Y2ZzLmVycm9yLCBWYWx1ZUVycm9yKSwgKGVycm9yLCBzdHIpOgoJCWlmIGVycm9yIDw+IC0x MjA6CgkJCXJhaXNlCgkJZGlyLCBmaWxlID0gb3MucGF0aC5zcGxpdChwYXRoKQoJCXJldHVy biBvcy5wYXRoLmpvaW4ocmVzb2x2ZWFsaWFzZXMoZGlyKSwgZmlsZSkKCnNlYXJjaGVuZ2lu ZSA9IFNlYXJjaEVuZ2luZSgpCnRyYWNlYmFja3dpbmRvdyA9IFd0cmFjZWJhY2suVHJhY2VC YWNrKCkK --B_3111327552_3212811-- --B_3111327557_3186067-- From Jack.Jansen@oratrix.com Sun Aug 4 21:40:24 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 4 Aug 2002 22:40:24 +0200 Subject: [Pythonmac-SIG] Bus error failure while building readline In-Reply-To: <20020803165303.A19012@redivi.com> Message-ID: <67117441-A7EA-11D6-89C3-003065517236@oratrix.com> On zaterdag, augustus 3, 2002, at 10:53 , Bob Ippolito wrote: > All they have to do is take the "source /sw/bin/init.csh" or > whatever the heck it is out of their ~/.cshrc and start up a > new terminal.. Good idea. I'll add this to the MacOSX section of the main README as a last-ditch suggestion. > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Aug 4 21:50:02 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 4 Aug 2002 22:50:02 +0200 Subject: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: Message-ID: On zondag, augustus 4, 2002, at 12:48 , Tony McDonald wrote: > % > /Library/Frameworks/Python.framework/Versions/Current/bin/python > setup.py > build > % > /Library/Frameworks/Python.framework/Versions/Current/bin/python > setup.py > install Someone already mentioned "make installunixprograms" in the Mac/OSX/Makefile, which will allow you to type "python" in stead of the 70-character full path. Question to everyone: should I add the "make installunixprograms" to the "make osxapps" of the main Makefile? I'm a bit reluctant to do so, as people may want to keep the unix tools point to a non-framework Python (for instance if Apple ships Python with Jaguar). Hmm, how about the following three targets (and getting rid of "make osxapps") in the main Makefile: make frameworkinstall - does what it does now make frameworkinstallapps - does what osxapps does now make frameworkinstallunixtools - does "make installunixprograms" in the Mac/OSX Makefile. Comments? > I've just run a quick MySQL python script in the IDE and it works :) Note that the IDE has an option to run its scripts with the command-line Python in a Terminal window from within the IDE. Check the menu on the righthandside of the file's window (where you also find "run as __main__" and such). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Aug 4 21:56:06 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 4 Aug 2002 22:56:06 +0200 Subject: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: Message-ID: <985FC560-A7EC-11D6-89C3-003065517236@oratrix.com> On zondag, augustus 4, 2002, at 08:56 , Donovan Preston wrote: > By the way, Jack or Just, how come this functionality was never > incorporated > into the base IDE? It has some funny behavior, but syntax > coloring alone is > totally worth it... I vaguely remember that Just didn't like it, but I'm not really sure (not even _what_ he didn't like, the idea or the implementation). I used to hate syntax coloring too (having only been exposed to the abysmal color and font schemes thought up by Unix hackers), but the subtle and useable coloring done by BBEdit and CodeWarrior changed my mind. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Aug 4 22:02:28 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 4 Aug 2002 23:02:28 +0200 Subject: [Pythonmac-SIG] Bus error failure while building readline In-Reply-To: <200208041955.PAA20315@snow.nrcc.cornell.edu> Message-ID: <7C1DAB91-A7ED-11D6-89C3-003065517236@oratrix.com> On zondag, augustus 4, 2002, at 09:55 , William Noon wrote: > On machine 1 I have readline and ncurses taken from the gnu-darwin > project (same as fink versions?). But I only installed the > libraries and > include files (no /usr/local/share/termcap...) or /usr/lib/termcap. > There is the /usr/share/misc/terminfo... defs from OSX. > > I will try installing only the readline libraries on machine 2 and see > if that builds the readline.so module without error. If you could come up with a recipe that would allow people to go from a virgin system to one where a simple "configure" (or possibly a configure --with-readline=xxx or so) would give them a readline-enabled Python that would be very nice! -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From petrucha@isnet.sk Sun Aug 4 23:32:15 2002 From: petrucha@isnet.sk (Stefan Petrucha) Date: Mon, 05 Aug 2002 00:32:15 +0200 Subject: [Pythonmac-SIG] Problem when embedding classic Message-ID: <3D4DAB6F.6A838162@isnet.sk> I apologize for this Mac-beginner's problem and for bothering with old stuff (Python 2.1.1, classic). I'm trying to embed Python into a classic application (I succeeded on Windows previously). The Mac port partially works, but: - MacPython opens its own window for standard and error output, which is not moveable and does update only when the application calls Python - redirecting outputs via sys.stdout=MyStream, where MyStream has a write method, does not work as on other platforms - MyStream gets nothing and Python's output window shows nothing too Is it possible to turn off the output window of Python and to redirect the standard and error output somewhere else? Stefan Petrucha -- http://www.isnet.sk/petrucha From mjb@uma.pt Mon Aug 5 10:27:50 2002 From: mjb@uma.pt (Michael J. Barber) Date: Mon, 5 Aug 2002 10:27:50 +0100 Subject: [Pythonmac-SIG] Python for Mac OS X (again) In-Reply-To: <4719FD1D-A598-11D6-9A79-003065517236@oratrix.com> Message-ID: <9C9C0580-A855-11D6-B32C-0050E4794D0F@uma.pt> On Thursday, August 1, 2002, at 10:47 PM, Jack Jansen wrote: > > On donderdag, augustus 1, 2002, at 05:41 , Aureli Soria Frisch wrote: >> Fink seems the most comfortable way to install unix-python on Mac OS >> X. Did you make some bad experiences with that? >> Could you compare a bit with other binary distributions of unix-python >> for Mac OS X? >> How about installing the following packages with fink: >> >> NumPy >> SciPy >> PIL >> Gnuplot >> Tkinter ? >> >> I have been using Tkinter for GUI development and thinking on changing >> to wxPython. The GUIs are not for complex user applications, but for >> experiment-tools internally used. > > Both for Tkinter and for wxPython you need a framework build of Python. > This rules out the current fink distribution, which is a static Python. > There's a good framework Python distribution at the wxPython site. > If you have X11 installed, you can use Tkinter and wxPython with the Fink install. I've been experimenting a bit with Tkinter in this way; it's a bit sluggish, but usable. NumPy and Gnuplot work fine. You don't need X11 for Gnuplot to be quite useful, thanks to Aquaterm (fink's gnuplot should include this). Consider using Atlas with Numpy. I haven't tried SciPy and PIL yet. From lists@netelligent.biz Mon Aug 5 10:50:14 2002 From: lists@netelligent.biz (tmk) Date: Mon, 5 Aug 2002 11:50:14 +0200 Subject: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: Message-ID: On Sunday, August 4, 2002, at 10:50 PM, Jack Jansen wrote: > > On zondag, augustus 4, 2002, at 12:48 , Tony McDonald wrote: >> % >> /Library/Frameworks/Python.framework/Versions/Current/bin/python >> setup.py >> build >> % >> /Library/Frameworks/Python.framework/Versions/Current/bin/python >> setup.py >> install > > Someone already mentioned "make installunixprograms" in the > Mac/OSX/Makefile, which will allow you to type "python" in stead > of the 70-character full path. > > Question to everyone: should I add the "make installunixprograms" > to the "make osxapps" of the main Makefile? I'm a bit reluctant to > do so, as people may want to keep the unix tools point to a > non-framework Python (for instance if Apple ships Python with > Jaguar). > > Hmm, how about the following three targets (and getting rid of > "make osxapps") in the main Makefile: > make frameworkinstall - does what it does now > make frameworkinstallapps - does what osxapps does now > make frameworkinstallunixtools - does "make installunixprograms" > in the Mac/OSX Makefile. > > Comments? > [snip] Seems like a reasonable idea. = tmk= From gherman@darwin.in-berlin.de Mon Aug 5 11:05:56 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Mon, 5 Aug 2002 12:05:56 +0200 Subject: [Pythonmac-SIG] PIL/JPEG trouble Message-ID: --Apple-Mail-1-842632747 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, I've got some trouble on OS X telling PIL where to find the JPEG library. This results in "IOError: decoder jpeg not available" errors. I've installed JIG's library libjpeg.a into /usr/local/lib and its tools into /usr/local/bin (wrjpgcom, rdjpgcom, jpegtran, djpeg, cjpeg). I've also tried a configure pass with --with-jpeg=/usr/local/lib but all in vain. I've attached a sample installation script which should automatically fetch zlib, jpeg and pil from the net and install them the "canonical" way... Below I've also pasted the results of running PIL's MiniTest/test.py. Does anybody have an idea? Thanks, Dinu [localhost:Imaging-1.1.3] dinu% python MiniTest/test.py ***************************************************************** Failure in example: _info(Image.open("Images/lena.jpg")) from line #24 of test.testimage Exception raised: Traceback (most recent call last): File "MiniTest/doctest.py", line 499, in _run_examples_inner exec compile(source, "", "single") in globs File "", line 1, in ? File "MiniTest/test.py", line 12, in _info im.load() File "PIL/ImageFile.py", line 140, in load d = Image._getdecoder(self.mode, d, a, self.decoderconfig) File "PIL/Image.py", line 255, in _getdecoder raise IOError("decoder %s not available" % decoder_name) IOError: decoder jpeg not available ***************************************************************** Failure in example: type(im.im) # internal image attribute from line #31 of test.testimage Expected: Got: 1 items had failures: 2 of 40 in test.testimage ***Test Failed*** 2 failures. *** 2 tests of 40 failed. --Apple-Mail-1-842632747 Content-Disposition: attachment; filename=install.py Content-Transfer-Encoding: 7bit Content-Type: application/text; x-mac-creator=522A6368; x-unix-mode=0644; x-mac-type=54455854; name="install.py" #! /usr/bin/env python """install.py - a funky install script. Sample usage: python install.py zlib jpeg pil python install.py pil """ import os, string, sys from os.path import basename, join from urllib import urlopen ############################################################################### # Package descriptions ############################################################################### jpeg = { "name": "JPEG Support for PIL", "homepage": "http://www.ijg.org", "download": "http://www.ijg.org/files/jpegsrc.v6b.tar.gz", "install": """\ tar xfz jpegsrc.v6b.tar.gz cd jpeg-6b ./configure make make test sudo make install sudo make install-lib """} zlib = { "name": "Zlib", "homepage": "http://www.gzip.org/zlib/", "download": "http://www.gzip.org/zlib/zlib-1.1.4.tar.gz", "install": """\ tar xfz zlib-1.1.4.tar.gz cd zlib-1.1.4 ./configure make sudo make install """} pil = { "name": "PythonWare's PIL 1.1.3", "homepage": "http://www.pythonware.com/products/python/index.htm", "download": "http://www.pythonware.com/downloads/Imaging-1.1.3.tar.gz", "install": """\ tar xfz Imaging-1.1.3.tar.gz cd Imaging-1.1.3 cd libImaging ./configure make cd .. python setup.py build sudo python setup.py install """} ############################################################################### # Installation ############################################################################### def install(packages): dir = os.getcwd() for p in packages: try: p = globals()[p] except: print "Skipping", p continue # get package details name = p['name'] url = p['download'] instructions = p['install'] # download, if needed path = join(dir, basename(url)) if not os.path.exists(path): print "Downloading", name data = urlopen(url).read() open(path, "wb").write(data) # install print "Installing", name open('install.sh', 'w').write(instructions) os.system('tcsh -f install.sh') if __name__ == '__main__': packages = sys.argv[1:] install(packages) --Apple-Mail-1-842632747-- From maccube@starpower.net Mon Aug 5 12:50:43 2002 From: maccube@starpower.net (Oguz Imre) Date: Mon, 5 Aug 2002 07:50:43 -0400 Subject: [Pythonmac-SIG] Regarding Python Database modules, what's best to use for Postgresql access? Message-ID: <92974841-A869-11D6-9C64-003065A215CC@starpower.net> Gentle people, I need to access Postgresql database on Mac OS X (10.1.5). Postgresql is up and running. I use DbVisualizer 3.0 to "administer". Best product I have tried on this issue. Obviously Python is up and running. (OS X). I have downloaded PyGresQL, but I get a lot of errors when attempting to build. Can anybody suggest any alternate or advise how to "install" these modules to a newbie? Kindly advise, Thanks, Oguz Imre From Jack.Jansen@cwi.nl Mon Aug 5 13:59:08 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 5 Aug 2002 14:59:08 +0200 Subject: [Pythonmac-SIG] PIL/JPEG trouble In-Reply-To: Message-ID: <2102E682-A873-11D6-B799-0030655234CE@cwi.nl> On Monday, August 5, 2002, at 12:05 , Dinu Gherman wrote: > Hi, I've got some trouble on OS X telling PIL where to find the JPEG > library. This results in "IOError: decoder jpeg not available" errors. > > I've installed JIG's library libjpeg.a into /usr/local/lib and its > tools into /usr/local/bin (wrjpgcom, rdjpgcom, jpegtran, djpeg, cjpeg). > I've also tried a configure pass with --with-jpeg=/usr/local/lib but > all in vain. Dinu, try asking this at the PIL mailing list (image-sig@python.org, isn't it?). The real question here is "how do I tell the PIL configure where my jpeg stuff is? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Mon Aug 5 14:05:26 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 5 Aug 2002 15:05:26 +0200 Subject: [Pythonmac-SIG] Problem when embedding classic In-Reply-To: <3D4DAB6F.6A838162@isnet.sk> Message-ID: <0239462F-A874-11D6-B799-0030655234CE@cwi.nl> On Monday, August 5, 2002, at 12:32 , Stefan Petrucha wrote: > I apologize for this Mac-beginner's problem and for bothering with old > stuff (Python 2.1.1, classic). Are you really using 2.1.1, not 2.2.1? And if you really are: why? > I'm trying to embed Python into a classic application (I succeeded on > Windows previously). The Mac port partially works, but: > > - MacPython opens its own window for standard and error output, which is > not moveable and does update only when the application calls Python In 2.2.1 you can make *very* sure that Python will never open a console window by using the PyMac_SetConsoleHandler() API defined in macglue.h. You can pass the courtesy routines PyMac_DummyReadHandler and PyMac_DummyWriteHandler also defined there to completely lose console I/O, or provide your own routines. You can call PyMac_SetConsoleHandler() even before initializing Python. Before 2.2.1 there wasn't a 100% safe method to get rid of the console, only a 99% safe method. In your Python script make sure that no output can go to the console, by redirecting sys.stdout and sys.stderr at an early stage. Also, drop the embedding program on EditPythonPrefs and set the "delay console window until needed" flag. But: > - redirecting outputs via sys.stdout=MyStream, where MyStream has a > write method, does not work as on other platforms - MyStream gets > nothing and Python's output window shows nothing too this part I don't understand, and my guess is that it's a bug in your code. I've done a similar thing various times, and it has always worked.... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tim.jarman@lineone.net Mon Aug 5 16:45:47 2002 From: tim.jarman@lineone.net (Tim Jarman) Date: Mon, 05 Aug 2002 16:45:47 +0100 Subject: [Pythonmac-SIG] Gadfly and virtual memory Message-ID: <3D4E9DA8.378C0A95@lineone.net> I'm hitting a MemoryError trying to use Gadfly on my Mac (Python 2.2.1, Gadfly 1.0.0, MacOS 8.6). I have 64Mb of 'real' memory on my Mac (beige PowerMac G3, if it matters) and whomping up VM to 255 Mb doesn/t seem to help. When my ship comes in I will be upgrading the RAM to 128 Mb, but I thought VM would work (albeit slowly). Here's the code: -- snip -- import gadfly import os import sys print "*" * 80 print "Test started..." dataDir = os.path.join(os.path.dirname(sys.argv[0]), "data") if not os.path.exists(dataDir): print "Creating data directory %s..." % dataDir os.mkdir(dataDir) suffix = 1 + len(os.listdir(dataDir)) newname = "db%d" % suffix dbpath = os.path.join(dataDir, newname) print "Creating new subdirectory %s..." % newname os.mkdir(dbpath) # Create the database in the new subdirectory. print "Creating new Gadfly database..." connection = gadfly.gadfly() connection.startup("test", dbpath) cursor = connection.cursor() # Create the ARTICLE table and its associated indices. print "Creating ARTICLE table..." cursor.execute("CREATE TABLE article (uid integer, msgid integer, subject varchar, author varchar, timestamp varchar, text varchar)") cursor.execute("CREATE UNIQUE INDEX uid_index ON article (uid)") cursor.execute("CREATE INDEX msgid_index ON article (msgid)") cursor.execute("CREATE INDEX subject_index ON article (subject)") cursor.execute("CREATE INDEX author_index ON article (author)") # Create the REFERENCE table and its associated indices. print "Creating REFERENCE table..." cursor.execute("CREATE TABLE reference (parent integer, child integer)") cursor.execute("CREATE INDEX parent_index ON reference (parent)") cursor.execute("CREATE INDEX child_index ON reference (child)") cursor.commit() print "Done." -- snip -- Here's the output: -- snip -- ******************************************************************************** Test started... Creating new subdirectory db3... Creating new Gadfly database... Traceback (most recent call last): File "Macintosh HD:Python Projects:Perkins:dbtest.py", line 20, in ? connection = gadfly.gadfly() File "Macintosh HD:Applications:Python 2.2.1:Lib:site-packages:gadfly:database.py", line 27, in __init__ sql = sql.getSQL() File "Macintosh HD:Applications:Python 2.2.1:Lib:site-packages:gadfly:sql.py", line 14, in getSQL SQLG = kjParser.UnMarshalGram(infile) File "Macintosh HD:Applications:Python 2.2.1:Lib:site-packages:gadfly:kjParser.py", line 1192, in UnMarshalGram UnMarshal = UnMarshaller(file, Grammar) File "Macintosh HD:Applications:Python 2.2.1:Lib:site-packages:gadfly:kjParser.py", line 1205, in __init__ marfile = __import__(modulename) MemoryError -- snip -- Is Gadfly and/or Python not taking advantage of virtual memory? Or is it not a memory isseue? Confused-ly yrs, Tim (not a bot) From rdacker@pacbell.net Mon Aug 5 16:44:21 2002 From: rdacker@pacbell.net (bob ackerman) Date: Mon, 05 Aug 2002 08:44:21 -0700 Subject: [Pythonmac-SIG] Regarding Python Database modules, what's best to use for Postgresql access? In-Reply-To: <92974841-A869-11D6-9C64-003065A215CC@starpower.net> Message-ID: <360261A2-A88A-11D6-B851-003065428126@pacbell.net> --Boundary_(ID_ipkonCD0Tn0GFoQZYTixgA) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On Monday, August 5, 2002, at 04:50 AM, Oguz Imre wrote: > Gentle people, > > I need to access Postgresql database on Mac OS X (10.1.5). Postgresql is > up and running. I use DbVisualizer 3.0 to "administer". Best product I > have tried on this issue. Obviously Python is up and running. (OS X). I > have downloaded PyGresQL, but I get a lot of errors when attempting to > build. Can anybody suggest any alternate or advise how to "install" these > modules to a newbie? > i am using pyPgSQL module, instead. works fine. i have the PyGresQL module, but don't remember if i had trouble getting it to work. i am using postgresql crossplatform with osx and openbsd - so the problem may have been with PyGresQL on the openbsd side. --Boundary_(ID_ipkonCD0Tn0GFoQZYTixgA) Content-type: text/enriched; charset=US-ASCII Content-transfer-encoding: 7BIT On Monday, August 5, 2002, at 04:50 AM, Oguz Imre wrote: Gentle people, I need to access Postgresql database on Mac OS X (10.1.5). Postgresql is up and running. I use DbVisualizer 3.0 to "administer". Best product I have tried on this issue. Obviously Python is up and running. (OS X). I have downloaded PyGresQL, but I get a lot of errors when attempting to build. Can anybody suggest any alternate or advise how to "install" these modules to a newbie? i am using pyPgSQL module, instead. works fine. i have the 0000,0000,DEDEPyGresQL module, but don't remember if i had trouble getting it to work. i am using postgresql crossplatform with osx and openbsd - so the problem may have been with 0000,0000,DEDEPyGresQL on the openbsd side. --Boundary_(ID_ipkonCD0Tn0GFoQZYTixgA)-- From Robin.Siebler@corp.palm.com Mon Aug 5 20:44:30 2002 From: Robin.Siebler@corp.palm.com (Robin Siebler) Date: Mon, 5 Aug 2002 12:44:30 -0700 Subject: [Pythonmac-SIG] Import Message-ID: <400CE9390E334A4393CEECDD6863120A04D0B3F5@ussccm003.corp.palm.com> When I first imported IPython (a unix python program) into MacPython, it created a folder named IPython in Python 2.2.1:Lib:lib-scriptpackages. I accidentally deleted this folder and when I try to import IPython, it does not recreate this folder. How do I get MacPython to recreate this folder? Robin L. Siebler Software Test Engineer Palm --------------------------------------- Homer Simpson: Two hours? Why'd they build this ghost town so far away? Lisa Simpson: Because they discovered gold right over there! Homer Simpson: It's because they're stupid, that's why. That's why everybody does everything. From Jack.Jansen@oratrix.com Mon Aug 5 21:14:09 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 5 Aug 2002 22:14:09 +0200 Subject: [Pythonmac-SIG] Import In-Reply-To: <400CE9390E334A4393CEECDD6863120A04D0B3F5@ussccm003.corp.palm.com> Message-ID: On maandag, augustus 5, 2002, at 09:44 , Robin Siebler wrote: > When I first imported IPython (a unix python program) into > MacPython, it > created a folder named IPython in Python > 2.2.1:Lib:lib-scriptpackages. I > accidentally deleted this folder and when I try to import > IPython, it does > not recreate this folder. How do I get MacPython to recreate > this folder? The folder you mention doesn't exist, at least not in a normal distribution of either MacPython 2.2.1 nor unix-Python 2.2.1. There is a directory :Mac:Lib:lib-scriptpackages, but I can't imagine how IPython would install something there. Possibly you mean :Lib:site-packages? This is where distutils-based packages normally install. If this is indeed the case then I think you should try re-running "python setup.py install" (which you probably also did the first time, even though you didn't mention it:-). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Tue Aug 6 10:40:16 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 6 Aug 2002 11:40:16 +0200 Subject: [Pythonmac-SIG] IBCarbon in the CVS sources Message-ID: <83D45F7A-A920-11D6-BE0E-0030655234CE@cwi.nl> Folks, I've added Donovan Preston's IBCarbon module to the repository, it now sits right besides all the other Carbon modules, i.e. import Carbon.IBCarbon does the trick; the definitions are in Carbon.IBCarbonRuntime. This module allows Python to use a .nib file created with Interface Builder in Carbon mode. I would like to have an example for this, preferably either a IB-based re-implementation of one of the examples in :Mac:Demo (the dnslookup of example1.html comes to mind) or a Python re-implementation of a well-known example from Apple or from the O'Reilly Carbon book. Any takers? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From joerg@kantel.de Tue Aug 6 19:28:52 2002 From: joerg@kantel.de (=?ISO-8859-1?Q?J=F6rg_Kantel?=) Date: Tue, 6 Aug 2002 20:28:52 +0200 Subject: [Pythonmac-SIG] New MacPython HowTo's - German Only (Sorry) Message-ID: <5C0CEECA-A96A-11D6-B504-003065AB9922@kantel.de> Two whom of you who can read German... I've added a few new and short How To's to my growing pages about Python in general and MacPython in special: 1. Python Library Modules related: Easy Dialogs File Dialogs 2. PiddleQD related: PiddleQD and Mac OS X Dancing Python Additionally I started a little discovering SVG. And I seems to me that at the moment the piddleSVG backend is without a maintainer. Maybe I can help? But be warned, my english is very bad ;o) Script different! J"org -- J"org Kantel joerg@kantel.de Der Schockwellenreiter Der Rollberg From gherman@darwin.in-berlin.de Tue Aug 6 19:56:10 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Tue, 6 Aug 2002 20:56:10 +0200 Subject: [Pythonmac-SIG] New MacPython HowTo's - German Only (Sorry) In-Reply-To: <5C0CEECA-A96A-11D6-B504-003065AB9922@kantel.de> Message-ID: <2C5FFD9D-A96E-11D6-A975-00039345C610@darwin.in-berlin.de> J=F6rg Kantel: > > Additionally I started a little discovering SVG. And I seems to me = that=20 > at the moment the piddleSVG backend is without a maintainer. Maybe I=20= > can help? But be warned, my english is very bad ;o) I admit I sort of lost contact with Piddle, but concerning SVG: are you aware of ReportLab's SVG capabilities? Its graphics package will save SVG (see demo below) and my external "svglib" extension lets you reuse existing SVG code (all within reason- able limits): http://www.reportlab.com http://www.reportlab.com/cgi-bin/graphics_demo.cgi http://python.net/~gherman/#svglib Regards, Dinu From Jack.Jansen@oratrix.com Tue Aug 6 23:19:19 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 7 Aug 2002 00:19:19 +0200 Subject: [Pythonmac-SIG] RTFM Message-ID: <8D4DB722-A98A-11D6-8D1F-003065517236@oratrix.com> If people are looking for ways to help out with MacPython: the documentation could do with some proofreading. The Mac section of the Python manual hasn't been updated in a while, and most of the terminology is still geared towards MacPython/OS9, not OSX. And bits are missing, too: I just happened to notice that macfs.FSRef's aren't featured at all, for instance. Even if people can just point out bits that are missing, wrong or confusing that would be a great help. But, of course, don't hesitate to write or rewrite stuff either.... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dan@danshafer.com Wed Aug 7 06:35:41 2002 From: dan@danshafer.com (Dan Shafer) Date: Tue, 06 Aug 2002 22:35:41 -0700 Subject: [Pythonmac-SIG] RTFM In-Reply-To: <8D4DB722-A98A-11D6-8D1F-003065517236@oratrix.com> References: <8D4DB722-A98A-11D6-8D1F-003065517236@oratrix.com> Message-ID: At 12:19 AM +0200 8/7/02, Jack Jansen wrote: >If people are looking for ways to help out with MacPython: the >documentation could do with some proofreading. The Mac section of >the Python manual hasn't been updated in a while, and most of the >terminology is still geared towards MacPython/OS9, not OSX. First quick read seems to me to indicate we need either two separate manuals at some points - one for OS9 and one for OSX - or we need to do the usual "if you're using OS9..." kind of qualifiers. I mean, I don't *think* we want to move entirely to an OSX orientation, right? >And bits are missing, too: I just happened to notice that >macfs.FSRef's aren't featured at all, for instance. > >Even if people can just point out bits that are missing, wrong or >confusing that would be a great help. But, of course, don't hesitate >to write or rewrite stuff either.... >-- >- Jack Jansen >http://www.cwi.nl/~jack - >- If I can't dance I don't want to be part of your revolution -- >Emma Goldman - > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Shafer Writer, Spiritual Student and Teacher Founder, Fellowship of One Mind, Monterey, CA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Jack.Jansen@cwi.nl Wed Aug 7 09:34:04 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 7 Aug 2002 10:34:04 +0200 Subject: [Pythonmac-SIG] RTFM In-Reply-To: Message-ID: <6E7170B1-A9E0-11D6-BE0E-0030655234CE@cwi.nl> On Wednesday, August 7, 2002, at 07:35 , Dan Shafer wrote: > > First quick read seems to me to indicate we need either two separate > manuals at some points - one for OS9 and one for OSX - or we need to do > the usual "if you're using OS9..." kind of qualifiers. I mean, I don't > *think* we want to move entirely to an OSX orientation, right? > I think that for now we should keep the tone neutral, not too OSX-biased. OTOH, if it's a choice between favoring OS9 or OSX I think we should favor OSX. After all that's the platform we expect to be around for a long time. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From just@letterror.com Wed Aug 7 10:49:48 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 7 Aug 2002 11:49:48 +0200 Subject: [Pythonmac-SIG] PIL/JPEG trouble In-Reply-To: Message-ID: Dinu Gherman wrote: > Hi, I've got some trouble on OS X telling PIL where to find the JPEG > library. This results in "IOError: decoder jpeg not available" errors. Check whether libImaging/ImConfig.h contains the line #define HAVE_LIBJPEG 1 Just From dan@grassi.org Wed Aug 7 13:18:18 2002 From: dan@grassi.org (Dan Grassi) Date: Wed, 7 Aug 2002 08:18:18 -0400 Subject: [Pythonmac-SIG] Re: Step-by-step howto for testing new Mach{ho}Python architecture Message-ID: > On Sunday, August 4, 2002, at 10:50 PM, Jack Jansen wrote: > Question to everyone: should I add the "make > installunixprograms" to the "make osxapps" of the main Makefile? > I'm a bit reluctant to do so, as people may want to keep the > unix tools point to a non-framework Python (for instance if > Apple ships Python with Jaguar). Yes, people who install a new version expect everything to reflect it by default. It would be very confusing to have the /Applications/Python tools use one version and the unix tools to use another (pre-install) version. > Hmm, how about the following three targets (and getting rid of > "make osxapps") in the main Makefile: > make frameworkinstall - does what it does now > make frameworkinstallapps - does what osxapps does now > make frameworkinstallunixtools - does "make installunixprograms" > in the Mac/OSX Makefile. > > Comments? I suggest one standard target: "install". Removing the OS X Applications is simple enough but why would this be desirable? Possibly a better place for the OS X Tools might be /Applications/Utilities/Python. The basic install should install the framework version, it is the OS X and Python default so no extra hints are needed in the target, they only beg the question of what other possibilities should be considered and that is not a good thing for the average user. The unix tools links are necessary so that various Python programs will just run else it will look like the Python install failed. Keep in mind that many people will use Python just to run Python programs without ever writing any Python code. Let's not complicate things and let's keep the "batteries included", by default. But there is another issue: versions. While OS X has a good way of maintaining multiple versions eventually it will be desirable to remove obsolete versions. In time this will become a problem and some thought might be given to it now. Dan From dan@grassi.org Wed Aug 7 13:39:34 2002 From: dan@grassi.org (Dan Grassi) Date: Wed, 7 Aug 2002 08:39:34 -0400 Subject: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: <985FC560-A7EC-11D6-89C3-003065517236@oratrix.com> Message-ID: I suggest including the syntax coloring into the IDE. Syntax coloring is now expected and it can be disabled easily. I would be willing to do the work. Also the default font need to change or be installed. Not all fonts handle bold-ing and with the default missing a font that does not work ends up as default. As I recall the one issue is that the code does not handle triple quotes correctly in all instances. Another is the time to initially color the text and the blinking while that is being done. Dan On Sunday, August 4, 2002, at 04:56 PM, Jack Jansen wrote: > > On zondag, augustus 4, 2002, at 08:56 , Donovan Preston wrote: >> By the way, Jack or Just, how come this functionality was never >> incorporated >> into the base IDE? It has some funny behavior, but syntax coloring >> alone is >> totally worth it... > > I vaguely remember that Just didn't like it, but I'm not really sure > (not even _what_ he didn't like, the idea or the implementation). I > used to hate syntax coloring too (having only been exposed to the > abysmal color and font schemes thought up by Unix hackers), but the > subtle and useable coloring done by BBEdit and CodeWarrior changed my > mind. From wddozier@mac.com Wed Aug 7 13:57:56 2002 From: wddozier@mac.com (William Dozier) Date: Wed, 7 Aug 2002 05:57:56 -0700 (PDT) Subject: [Pythonmac-SIG] Re: Step-by-step howto for testing new Mach{ho}Python architecture Message-ID: <2937973.1028725076645.JavaMail.wddozier@mac.com> On Wednesday, Aug 07, 2002, at 07:18AM, Dan Grassi wrote: >I suggest one standard target: "install". Removing the OS X >Applications is simple enough but why would this be desirable? Possibly >a better place for the OS X Tools might be >/Applications/Utilities/Python. > Or, perhaps: /Developer/Applications/Python From dan@grassi.org Wed Aug 7 14:20:53 2002 From: dan@grassi.org (Dan Grassi) Date: Wed, 7 Aug 2002 09:20:53 -0400 Subject: [Pythonmac-SIG] Re: Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: <2937973.1028725076645.JavaMail.wddozier@mac.com> Message-ID: <7FC99F3D-AA08-11D6-80CC-00039346A28A@grassi.org> On Wednesday, August 7, 2002, at 08:57 AM, William Dozier wrote: > Or, perhaps: /Developer/Applications/Python Not everyone who will/might use Python has the developer tools installed. Dan From just@letterror.com Wed Aug 7 14:44:58 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 7 Aug 2002 15:44:58 +0200 Subject: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: Message-ID: Dan Grassi wrote: > I suggest including the syntax coloring into the IDE. Syntax coloring > is now expected and it can be disabled easily. I would be willing to do > the work. A bad implementation of syntax coloring has been hiding in the IDE for a while: edit line 679 to read self.do_fontify = 1 (Re)start the IDE and you're laughing. It's bad in the sense that: 1) It doesn't do the right thing when editing triple quoted strings (That's why there is a secret shortcut which recolors the entire document:cmd-shift-d.) 2) It _sometimes_ traces back in PyFontify in some of the complex regexen (this is probably due to sre, but I never bothered to research the problem) 3) It is slow becuase it does it's work as idle callbacks, which are scheduled fairly low-frequently by the event loop. 4) Neither fonts nor colors are settable with a GUI. I now think that the whole PyFontify approach is flawed, and that it's not really suitable for live coloring. Either we need to copy what IDLE is doing, or, and THAT would be a MAJORLY exciting enhancement of the IDE, is to switch to Scintilla as the text component instead of waste. Then we get _folding_ for free as well! I usually don't like to shout in emails, but THIS WOULD BE EXTREMELY COOL ;-) Scintilla is what PythonWin uses. Problem is: it needs to be ported to Carbon. Problem #2 for _me_ is: it's in C++, which I can't write. Anyone, please check out http://www.scintilla.org/ if you're interested in a project. Just From gherman@darwin.in-berlin.de Wed Aug 7 16:06:36 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 7 Aug 2002 17:06:36 +0200 Subject: [Pythonmac-SIG] PIL/JPEG trouble In-Reply-To: Message-ID: <44CCA99B-AA17-11D6-8D5D-00039345C610@darwin.in-berlin.de> Just van Rossum: > > Check whether libImaging/ImConfig.h contains the line > > #define HAVE_LIBJPEG 1 Ok, a whole new try... set this in ImConfig.h.in, ran configure, checked ImConfig.h contained this line (it did), ran make, saw a complaint about ranlib, read the advice to rerun it on libjpeg.a, did that, typed make again (which now ran fine). Finally, the distutils part of the PIL install went just fine, the minitest sample works except for one single test, giving me this error below but that looks ok. ;-) I guess the mystery was in rerunning ranlib (I think I ran into this before). It's quite impossible not to see the compile error, so it's still a bit of a mystery to me. Could the ranlib thingy be a reason for configure not to find the JPEG lib? Regards and thanks, Dinu [localhost:/Imaging-1.1.3] dinu% python MiniTest/test.py ***************************************************************** Failure in example: type(im.im) # internal image attribute from line #31 of test.testimage Expected: Got: 1 items had failures: 1 of 40 in test.testimage ***Test Failed*** 1 failures. *** 1 tests of 40 failed. From Benjamin.Schollnick@usa.xerox.com Wed Aug 7 17:52:32 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Wed, 07 Aug 2002 12:52:32 -0400 Subject: [Pythonmac-SIG] IDE Comments Message-ID: > I now think that the whole PyFontify approach is flawed, and that it's not > really suitable for live coloring. Either we need to copy what IDLE is doing, > or, and THAT would be a MAJORLY exciting enhancement of the IDE, is to switch to > Scintilla as the text component instead of waste. Then we get _folding_ for free > as well! I usually don't like to shout in emails, but THIS WOULD BE EXTREMELY > COOL ;-) Scintilla is what PythonWin uses. Folding would be extremely cool and usable.... One of the main reasons I haven't been using the mac IDE (instead I'm using BBEDIT Lite), is that there is no syntax coloring.... But folding, even if it wasn't colored, would certainly demand my consideration... I'm not a C++ programmer either... But wanted to make sure it had my vote... - Benjamin -----Original Message----- From: Just van Rossum [mailto:just@letterror.com] Sent: Wednesday, August 07, 2002 9:45 AM To: Dan Grassi Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Step-by-step howto for testing new Mach{ho}Python architecture Dan Grassi wrote: > I suggest including the syntax coloring into the IDE. Syntax coloring > is now expected and it can be disabled easily. I would be willing to do > the work. A bad implementation of syntax coloring has been hiding in the IDE for a while: edit line 679 to read self.do_fontify = 1 (Re)start the IDE and you're laughing. It's bad in the sense that: 1) It doesn't do the right thing when editing triple quoted strings (That's why there is a secret shortcut which recolors the entire document:cmd-shift-d.) 2) It _sometimes_ traces back in PyFontify in some of the complex regexen (this is probably due to sre, but I never bothered to research the problem) 3) It is slow becuase it does it's work as idle callbacks, which are scheduled fairly low-frequently by the event loop. 4) Neither fonts nor colors are settable with a GUI. I now think that the whole PyFontify approach is flawed, and that it's not really suitable for live coloring. Either we need to copy what IDLE is doing, or, and THAT would be a MAJORLY exciting enhancement of the IDE, is to switch to Scintilla as the text component instead of waste. Then we get _folding_ for free as well! I usually don't like to shout in emails, but THIS WOULD BE EXTREMELY COOL ;-) Scintilla is what PythonWin uses. Problem is: it needs to be ported to Carbon. Problem #2 for _me_ is: it's in C++, which I can't write. Anyone, please check out http://www.scintilla.org/ if you're interested in a project. Just _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From dan@danshafer.com Wed Aug 7 19:06:26 2002 From: dan@danshafer.com (Dan Shafer) Date: Wed, 07 Aug 2002 11:06:26 -0700 Subject: [Pythonmac-SIG] RTFM In-Reply-To: <6E7170B1-A9E0-11D6-BE0E-0030655234CE@cwi.nl> References: <6E7170B1-A9E0-11D6-BE0E-0030655234CE@cwi.nl> Message-ID: At 10:34 AM +0200 8/7/02, Jack Jansen wrote: >On Wednesday, August 7, 2002, at 07:35 , Dan Shafer wrote: >> >>First quick read seems to me to indicate we need either two >>separate manuals at some points - one for OS9 and one for OSX - or >>we need to do the usual "if you're using OS9..." kind of >>qualifiers. I mean, I don't *think* we want to move entirely to an >>OSX orientation, right? >> >I think that for now we should keep the tone neutral, not too >OSX-biased. OTOH, if it's a choice between favoring OS9 or OSX I >think we should favor OSX. After all that's the platform we expect >to be around for a long time. Yeah, that's our hope anyway! ;-) My concern is focused on the install-and-launch stuff, I think. These are pretty different between the boxes. So I'm guessing the right thing to do is to write separate "If" paragraphs for these processes. I haven't dug into anything beyond that yet but it is likely that for now at least we have only editing and wording issues in the rest of the docs until a really native MachoPython with Carbon libs wrapped is available. >-- >- Jack Jansen >http://www.cwi.nl/~jack - >- If I can't dance I don't want to be part of your revolution -- >Emma Goldman - > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Shafer Writer, Spiritual Student and Teacher Founder, Fellowship of One Mind, Monterey, CA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Jack.Jansen@oratrix.com Wed Aug 7 21:57:33 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 7 Aug 2002 22:57:33 +0200 Subject: [Pythonmac-SIG] RTFM In-Reply-To: Message-ID: <4B61757B-AA48-11D6-BFE3-003065517236@oratrix.com> On woensdag, augustus 7, 2002, at 08:06 , Dan Shafer wrote: > My concern is focused on the install-and-launch stuff, I think. > These are pretty different between the boxes. So I'm guessing > the right thing to do is to write separate "If" paragraphs for > these processes. I haven't dug into anything beyond that yet > but it is likely that for now at least we have only editing and > wording issues in the rest of the docs until a really native > MachoPython with Carbon libs wrapped is available. Ok, then we misunderstood each other. The "highlevel documentation" will definitely have to be rewritten for OSX. My request was mainly for the "Macintosh" section of the Python Library Reference. This is the bit that should be useable on both platforms. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From richard@dcs.qmul.ac.uk Thu Aug 8 11:00:21 2002 From: richard@dcs.qmul.ac.uk (Richard Bornat) Date: Thu, 8 Aug 2002 11:00:21 +0100 Subject: [Pythonmac-SIG] building Aqua Tcl/Tk from source -- installation problems Message-ID: I'm trying to port a unix application which uses a python GUI toMacOS X. Of the two things I've tried (finked tcl/tk plus oroborosx; native Aqua port) the native Aqua port most nearly works. But not perfectly, so I thought I'd download the sources from CVS and install the latest version, and then I could maybe fix (what I hope might be) some minor problems. I downloaded it without problems, read the instructions, and it all builds perfectly (after I _really_ read the instructions, I have to confesss :-)). But then I run pbxbuild -activetarget install. The Tcl library installs fine (into /tmp, natch), but the Tk library install _always_ barfs at the point where an installation shell script issues source buildConfig. I can't find this file anywhere in the CVS repository (I looked in the attic in tcl/macosx and tk/macosx). The only mentions of that name are in the shellscript itself and the project folder: ./build/Wish.build/TkLibrary.build/BPTag008-script.sh:source buildConfig ./tk/macosx/Wish.pbproj/project.pbxproj: shellScript = "source buildConfig"; Anybody tell me what stupid thing I'm doing wrong? Richard Bornat From petrucha@isnet.sk Thu Aug 8 13:36:39 2002 From: petrucha@isnet.sk (Stefan Petrucha) Date: Thu, 08 Aug 2002 14:36:39 +0200 Subject: [Pythonmac-SIG] Problem when embedding classic References: <8103A600-A937-11D6-BE0E-0030655234CE@cwi.nl> Message-ID: <3D5265D7.D4B4179@isnet.sk> Jack Jansen wrote: > You may want to look at MacOS.SchedParams(), with which you > can disable the event > loop. I RTFM, looked at the implementation, but still don't know what parameters to MacOS.SchedParams() disable the event loop. Evidently I don't know something that everybody knows :-( Regards, Stefan Petrucha -- http://www.isnet.sk/petrucha From Robin.Siebler@corp.palm.com Thu Aug 8 23:33:49 2002 From: Robin.Siebler@corp.palm.com (Robin Siebler) Date: Thu, 8 Aug 2002 15:33:49 -0700 Subject: [Pythonmac-SIG] Clueless with CodeWarrior Message-ID: <400CE9390E334A4393CEECDD6863120A04D0B442@ussccm003.corp.palm.com> I have the following script which works perfectly in the interactive window. import CodeWarrior cw = CodeWarrior.CodeWarrior(start=1) cw.activate() cw.open (file1) cw.disassemble_file(file2) When I open the script in MacPython and run it, I get the follow error(s): MacOS.Error: (-600, 'no eligible process with specified descriptor') File "simplec.py", line 4, in ? cw.activate() File "aetools.py", line 199, in activate self.send('misc', 'actv') File "aetools.py", line 191, in send return self.sendevent(self.newevent(code, subcode, parameters, attributes)) File "aetools.py", line 185, in sendevent self.send_timeout Can anyone tell me what the errors mean and how to fix them? For future reference, is there a way to capture the contents of the traceback window so I don't have to type everything? Robin L. Siebler Software Test Engineer Palm --------------------------------------- Ralph Wiggum: Me fail English? That's unpossible! From Jack.Jansen@cwi.nl Fri Aug 9 09:20:50 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 9 Aug 2002 10:20:50 +0200 Subject: [Pythonmac-SIG] Clueless with CodeWarrior In-Reply-To: <400CE9390E334A4393CEECDD6863120A04D0B442@ussccm003.corp.palm.com> Message-ID: On Friday, August 9, 2002, at 12:33 , Robin Siebler wrote: > I have the following script which works perfectly in the interactive > window. > > import CodeWarrior > cw = CodeWarrior.CodeWarrior(start=1) > cw.activate() > cw.open (file1) > cw.disassemble_file(file2) > > When I open the script in MacPython and run it, I get the follow > error(s): > > MacOS.Error: (-600, 'no eligible process with specified descriptor') > File "simplec.py", line 4, in ? > cw.activate() > File "aetools.py", line 199, in activate > self.send('misc', 'actv') > File "aetools.py", line 191, in send > return self.sendevent(self.newevent(code, subcode, parameters, > attributes)) > File "aetools.py", line 185, in sendevent > self.send_timeout This happens to me once in every, uhm, 10 or so runs. I never bothered to debug it, as for my application simply restarting the application makes it work. The problem is that the CodeWarrior.CodeWarrior(start=1) returns before CodeWarrior is actually ready to listen to AppleEvents. Either the application needs to be started in a different way, or after starting it we should go into a loop for, say, 5 seconds waiting for the application to actually have come up (we could ping it with te noop AppleEvent). If you fix this: please submit a patch to sourceforge! > Can anyone tell me what the errors mean and how to fix them? For future > reference, is there a way to capture the contents of the traceback > window so > I don't have to type everything? After PythonInterpreter has exited you can't always copy from the console window anymore. The workaround is not to let PythonInterpreter exit: depress ALT while Python is starting, and select the "interactive mode after script" checkbox. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Aug 9 09:34:57 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 9 Aug 2002 10:34:57 +0200 Subject: [Pythonmac-SIG] Problem when embedding classic In-Reply-To: <3D5265D7.D4B4179@isnet.sk> Message-ID: On Thursday, August 8, 2002, at 02:36 , Stefan Petrucha wrote: > Jack Jansen wrote: > >> You may want to look at MacOS.SchedParams(), with which you >> can disable the event >> loop. > > I RTFM, looked at the implementation, but still don't know what > parameters to MacOS.SchedParams() disable the event loop. > Evidently I don't know something that everybody knows :-( On reading it the description is indeed rather technical. I'll add a quick section on the common use case. Here's what I'm adding, let me know if this still isn't good enough: A common use case is to completely disable the internal MacPython event loop. This can be done with SchedParams(0, 0). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From brownr@ucalgary.ca Thu Aug 8 16:23:17 2002 From: brownr@ucalgary.ca (Robb Brown) Date: Thu, 8 Aug 2002 09:23:17 -0600 Subject: [Pythonmac-SIG] IDLE and OS X Message-ID: I've got a fully Aqua enabled python system running (including VTK) but I'm missing an IDE. I tried IDLE a couple months ago but it refused to load any files (a problem with unix and mac path names and TK apparently). Does anyone know if this has been fixed? If not, is there another IDE that's easy to use with python framework? Thanks, Robb -- ______________________________ Robb Brown Seaman Family MR Research Centre Calgary, Alberta, Canada From Robin.Siebler@corp.palm.com Fri Aug 9 23:13:06 2002 From: Robin.Siebler@corp.palm.com (Robin Siebler) Date: Fri, 9 Aug 2002 15:13:06 -0700 Subject: [Pythonmac-SIG] AppleEvent examples Message-ID: <400CE9390E334A4393CEECDD6863120A04D0B454@ussccm003.corp.palm.com> I'm trying to learn how to automate some tasks in CodeWarrior using = MacPython. Well, really, I'm trying to puzzle out how to do them in = AppleScript and then pulling my hair out trying to figure out how to = convert what works in AppleScript into something that works in MacPython = (if only autocomplete worked on the Mac, that would help). Are there = any examples anywhere of using MacPython and AppleEvents? Robin L. Siebler Software Test Engineer Palm --------------------------------------- Bart Simpson: What a day, eh, Milhouse? The sun is out, birds are = singing, bees are trying to have sex with them -- as is my = understanding... From billb@mousa.demon.co.uk Sat Aug 10 00:17:04 2002 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Sat, 10 Aug 2002 00:17:04 +0100 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: <400CE9390E334A4393CEECDD6863120A04D0B454@ussccm003.corp.palm.com> References: <400CE9390E334A4393CEECDD6863120A04D0B454@ussccm003.corp.palm.com> Message-ID: At 3:13 pm -0700 09/08/02, Robin Siebler wrote: >I'm trying to learn how to automate some tasks in CodeWarrior using >MacPython. Well, really, I'm trying to puzzle out how to do them in >AppleScript and then pulling my hair out trying to figure out how to >convert what works in AppleScript into something that works in >MacPython (if only autocomplete worked on the Mac, that would help). >Are there any examples anywhere of using MacPython and AppleEvents? Not really, I've found that it is usually better to use python directly and only attempt the Apple events when you really need to communicate with an application. If you post what you are trying to do, I will try to help, though I have no knowledge of CodeWarrior. -- Bill Bedford A streaker streaks, and a nation shrugs at a saucer like disk in the sky A stag weekend is a poor weekend if the army is not on standby From Jack.Jansen@oratrix.com Sat Aug 10 23:25:32 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 11 Aug 2002 00:25:32 +0200 Subject: [Pythonmac-SIG] IDLE and OS X In-Reply-To: Message-ID: <1513D146-ACB0-11D6-B3D3-003065517236@oratrix.com> On donderdag, augustus 8, 2002, at 05:23 , Robb Brown wrote: > > I've got a fully Aqua enabled python system running (including > VTK) but I'm missing an IDE. I tried IDLE a couple months ago > but it refused to load any files (a problem with unix and mac > path names and TK apparently). Does anyone know if this has > been fixed? If not, is there another IDE that's easy to use > with python framework? If you're willing to build from CVS (or if you're willing to wait for 2.3) then the MacPython IDE will work fine with a standard unix-Python, as long as you do a framework build. The main readme file (Mac OS X section) and the readme in Mac/OSX should have all the relevant details (i.e. you would help me a lot if you tried this and reported if there were bits of information missing, unclear, etc). And, as to IDLE, you should probably submit a bug report to Sourceforge. This is the first I've heard about IDLE not working with AquaTk (but then, I never use it so I'm not tracking it very closely). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sat Aug 10 23:30:23 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 11 Aug 2002 00:30:23 +0200 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: <400CE9390E334A4393CEECDD6863120A04D0B454@ussccm003.corp.palm.com> Message-ID: On zaterdag, augustus 10, 2002, at 12:13 , Robin Siebler wrote: > I'm trying to learn how to automate some tasks in CodeWarrior > using MacPython. Well, really, I'm trying to puzzle out how to > do them in AppleScript and then pulling my hair out trying to > figure out how to convert what works in AppleScript into > something that works in MacPython (if only autocomplete worked > on the Mac, that would help). Are there any examples anywhere > of using MacPython and AppleEvents? Unfortunately there are no good examples:-( The Demo/applescript.html is about the only documentation there is, and the example it uses won't work under OSX... If anyone could come up with some good examples that would really be very welcome. I think AppleScripting could be one of the areas where Python can really shine, but there's still quite a bit of a hurdle you have to jump over to get started. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From ByronFormwalt@aaahawk.com Sat Aug 10 23:37:13 2002 From: ByronFormwalt@aaahawk.com (Byron Formwalt) Date: Sat, 10 Aug 2002 18:37:13 -0400 Subject: [Pythonmac-SIG] Building Embedded Applets & Applications on OS X Message-ID: Can someone please point out how to properly bundle up a python script into a *.app form? -Byron From ByronFormwalt@aaahawk.com Sat Aug 10 23:47:03 2002 From: ByronFormwalt@aaahawk.com (Byron Formwalt) Date: Sat, 10 Aug 2002 18:47:03 -0400 Subject: [Pythonmac-SIG] Message-ID: In IDLE, after partially entering a function call, a tooltip appears with a function descriptor. This is a handy feature. Unfortunately, key-window focus is removed, so that you cannot continue typing until after clicking the mouse in the window to make it key and front. The version info is listed below with an example of what I'm talking about. No response requested from the group. I just wanted to document the problem, and hopefully it can be fixed relatively easily for future releases. Python 2.2.1 (#2, Aug 10 2002, 16:01:08) [GCC 2.95.2 19991024 (release)] on darwin Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> from Tkinter import * >>> root = Tk( ^ |Here is where the auto help tip appears. Thanks, Byron From ByronFormwalt@aaahawk.com Sun Aug 11 03:56:08 2002 From: ByronFormwalt@aaahawk.com (Byron Formwalt) Date: Sat, 10 Aug 2002 22:56:08 -0400 Subject: [Pythonmac-SIG] Re: Building Embedded Applets & Applications on OS X In-Reply-To: Message-ID: On 8/10/02 6:37 PM, "Byron Formwalt" wrote: > Can someone please point out how to properly bundle up a python script into a > *.app form? > > -Byron Perhaps I should have provided specific info about the way I have python set up: I downloaded the Tcl/Tk framework snapshots for OS X from sourceforge and installed them, first. Then I used fink to grab and install X11 headers (needed for _tkinter). Next, downloaded the latest source files from sourceforge (Python-2.2.1). Then I did a command-line configure and install based on the instructions by Tony Lownds at http://tony.lownds.com/macosx/tkinter.html. Eventually I discovered the scripts for freezing and building applets/applications. I manually copied these into the framework site-packages directory. Then I executed `python BuildApplication.py /Users/formwalt/helloworld.py` from the command line. Here is what happened: After searching for modules, the following came up missing: {rour12path, SOCKS, mac, msvcrt, Finder}. A dialog pops up to offer cancellation and continuation options. I clicked to continue. Then a dialog pops up, stating, "Template 'PythonInterpreter' not found on sys.path'. So, ultimately, I guess what I am missing is this thing called a PythonInterpreter Template. Does anyone know anything more about this? Thanks, Byron From dan@grassi.org Sun Aug 11 06:16:55 2002 From: dan@grassi.org (Dan Grassi) Date: Sun, 11 Aug 2002 01:16:55 -0400 Subject: [Pythonmac-SIG] bsddb missing? In-Reply-To: Message-ID: <8D7DD82A-ACE9-11D6-A35A-00039346A28A@grassi.org> I noticed that bsddb is not included in Python 2.3, is there a reason or is this an oversight. I had it installed in 2.2.x but can't remember if it came that way or I added it. Dan From Jack.Jansen@oratrix.com Sun Aug 11 21:40:51 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 11 Aug 2002 22:40:51 +0200 Subject: [Pythonmac-SIG] In-Reply-To: Message-ID: <9FED07C4-AD6A-11D6-9656-003065517236@oratrix.com> On zondag, augustus 11, 2002, at 12:47 , Byron Formwalt wrote: > In IDLE, after partially entering a function call, a tooltip > appears with a > function descriptor. This is a handy feature. Unfortunately, > key-window > focus is removed, so that you cannot continue typing until > after clicking > the mouse in the window to make it key and front. The version info is > listed below with an example of what I'm talking about. No response > requested from the group. I just wanted to document the problem, and > hopefully it can be fixed relatively easily for future releases. > My guess (about 90% sure) is that this is a bug in AquaTk. Maybe you should ask on the MacTk mailing list whether this is a known problem? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Aug 11 21:43:59 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 11 Aug 2002 22:43:59 +0200 Subject: [Pythonmac-SIG] bsddb missing? In-Reply-To: <8D7DD82A-ACE9-11D6-A35A-00039346A28A@grassi.org> Message-ID: <0FC43830-AD6B-11D6-9656-003065517236@oratrix.com> On zondag, augustus 11, 2002, at 07:16 , Dan Grassi wrote: > I noticed that bsddb is not included in Python 2.3, is there a > reason or is this an oversight. I had it installed in 2.2.x > but can't remember if it came that way or I added it. If I remember correctly it was decided to drop bsddb because the module isn't up to snuff, and there are too many versions of the underlying bsddb library out there. But, on OSX the {n}dbm library is actually implemented with bsddb, so you can simply use the python anydbm module (or dbm or ndbm directly) to get a bsddb database. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Aug 11 21:46:30 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 11 Aug 2002 22:46:30 +0200 Subject: [Pythonmac-SIG] Re: Building Embedded Applets & Applications on OS X In-Reply-To: Message-ID: <6A3BD40E-AD6B-11D6-9656-003065517236@oratrix.com> On zondag, augustus 11, 2002, at 04:56 , Byron Formwalt wrote: > Eventually I discovered the scripts for freezing and building > applets/applications. I manually copied these into the framework > site-packages directory. Then I executed `python BuildApplication.py > /Users/formwalt/helloworld.py` from the command line. BuildApplication won't work for unix-Python yet. There's a couple of reasons for this, if you want the details check the archives for this mailing list, about a month ago this was discussed. But BuildApplet will work. At least, if you're building from CVS it will (there were a coupld of pretty recent changes to make it work). It has also gotten a command-line interface recently. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Aug 11 22:06:26 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 11 Aug 2002 23:06:26 +0200 Subject: [Pythonmac-SIG] Reorganize the Carbon package? Message-ID: <331823E0-AD6E-11D6-9656-003065517236@oratrix.com> Folks, The Carbon package is a bit of a mess right now. Or, let me rephrase that, there is stuff in there that isn't part of the Carbon framework in Apple's documentation: QuickTime and CoreFoundation. Moreover, everything inside it is grouped by the old MacOS9 toolbox names (Win, Res, Dlg, etc). This is something that will have to change at some point, but the question is, should we try to fix this before Python 2.3 is released, or should we wait until 2.4? Of course, any fix will have a 1-release backwards compatibility, as was done for the Res->Carbon.Res change in Python 2.2. I can see a couple of options, all with specific advantages and drawbacks, and I'd like some feedback. 1. Do nothing for 2.3, leave it for 2.4. Advantage is that I have enough work already. Disadvantage is that I expect 2.3 to be a turning-point release where we can significantly enlarge our audience. 2. Move QuickTime to its own package (QuickTime.Qt and QuickTime.QuickTime for the constants), move CF to its own package (CoreFoundation.CF and CoreFoundation.CoreFoundation) and leave it at that. Advantage is that it's fairly easy to do, disadvantage is that it's only a half-way solution. 3. In addition to (2) we could get rid of the funny distinction between constants and objects/methods that is an artefact of the way the modules are created. I.e. the user would always import Carbon.Windows and that module would contain both the constants and the methods and objects. Advantage is that QuickTime and CoreFoundation are then 100% compatible to the documentation, disadvantage is that Carbon isn't. Moreover, the namespaces of the various modules will become pretty big. 4. In addition to (3) we actually create a module Carbon.Carbon that imports everything from every Carbon module in the system. Advantage is that by using this module everything is 100% compatible with the Apple documentation. Disadvantage is that the namespace for this module is mindbogglingly large. And, if you really need only one single Carbon call you will still drag in all the extension modules, etc. 5. In stead of (4) we might be able to come up with some lazy dynamic scheme. I.e. the module (or module-like object) Carbon.Carbon doesn't import anything initially, but when you try to access, say, Carbon.Carbon.NewWindow it will somehow find out that this should come from Carbon.Win and at that point do the actual import (and populating its own namespace with all its symbols). Advantage is the same as for (4). Disadvantage is that I don't know how to do this:-), "from Carbon.Carbon import *" may be a problem, for instance, and that introspection (think of the IDE class browser) will work in a funny way. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From richard@dcs.qmul.ac.uk Mon Aug 12 11:03:32 2002 From: richard@dcs.qmul.ac.uk (Richard Bornat) Date: Mon, 12 Aug 2002 11:03:32 +0100 Subject: [Pythonmac-SIG] (silly newbie question) Bringing a process to the front Message-ID: My problem with native Aqua and python seems to have a peculiar root. What I see is that if I run the following command from Terminal /Library/Frameworks/Python.framework//Versions/2.2/bin/python ~/cvsdownloads/jape/jape/X/python/GUI/japeserver.py then I see a process window in the background, which won't come to the foreground. If I click on the window, I get the message SetFrontProcess failed,-600 (note, because of what follows, that the command is issued with absolute pathnames. If I run a similar command from a Unix process (actually, by issuing the absolute path of japeserver.py, which starts with #!/usr/bin/env python ) then the process runs -- I can see its messages on the console -- but I can't see a window at all. For this reason I downloaded the CVS source and (as my earlier message revealed) managed to build native Aqua, but failed to install it. Then, at last, a clue. Frustrated by python, I started to build an analogue in Java. When I run this process with a local pathname I get the same behaviour as with the python version ./japeserver [JavaAppLauncher Error] executable path must be an absolute path, or it cannot be brought to foreground Buckyball: Couldn't bring app to front, err=-600 (that is, a process which is clearly running in the background, but whose windows are invisible). Running it with an absolute pathname works fine -- I get to see the window, I can interact with the menus. I'd rather not spend a month or so transcribing the python code into Java (not yet, anyway). So can anybody suggest what commands I should be issuing -- from shell and from Unix process -- to start a python which I _can_ interact with? Richard Bornat From mps@utas.edu.au Mon Aug 12 14:07:35 2002 From: mps@utas.edu.au (Matthew Smith) Date: Mon, 12 Aug 2002 23:07:35 +1000 Subject: [Pythonmac-SIG] Callback function problems Message-ID: Hello If this is better suited to a general python list then sorry... I'm having problems setting up and using a callback function in my program that embeds python. I am using the following code: static PyObject *setTempCallback(PyObject *self, PyObject* args) { PyObject *result = NULL; PyObject *temp; if (PyArg_ParseTuple(args, "O:set_callback", &temp)) { if (!PyCallable_Check(temp)) { PyErr_SetString(PyExc_TypeError, "parameter must be callable"); return NULL; } Py_XINCREF(temp); /* Add a reference to new callback */ Py_XDECREF(pythonCallback); /* Dispose of previous callback */ pythonCallback = temp; /* Remember new callback */ // return none Py_INCREF(Py_None); result = Py_None; } return result; } Then when I want to use the python function: void callPythonFunc(long x, long y) { PyObject *arglist; PyObject *result; long smaller; arglist = Py_BuildValue("[l,l]", x, y); result = PyEval_CallObject(pythonCallback, arglist); Py_DECREF(arglist); if (result == NULL) return; // use result // get the arguments if (!PyArg_ParseTuple(result, "l", &smaller)) return; printf("the smaller number %d\n", smaller); Py_DECREF(result); } Only "if (result == NULL)" always fails... I tried to put the code in callPythonFunc into setTempCallback to see if the PyObject, pythonCallback is having trouble but to no avail. Any ideas?? I'm also attempting to load a module (myModule.py) from another (main.py) that is run using the following: err = !PyRun_SimpleString("execfile(\"main.py\")\n"); But I get this error: Traceback (most recent call last): File "", line 1, in ? File "main.py", line 12, in ? import myModule # import the python module ImportError: No module named myModule PythonBinder.app has exited with status 0. Both main.py and myModule.py are in the same directory as the executable... Thanks for any help, Matt Smith From mjb@uma.pt Mon Aug 12 14:56:40 2002 From: mjb@uma.pt (Michael J. Barber) Date: Mon, 12 Aug 2002 14:56:40 +0100 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: Message-ID: <53AEDB0A-ADFB-11D6-A5CD-0050E4794D0F@uma.pt> On Saturday, August 10, 2002, at 11:30 PM, Jack Jansen wrote: > > On zaterdag, augustus 10, 2002, at 12:13 , Robin Siebler wrote: > >> I'm trying to learn how to automate some tasks in CodeWarrior using >> MacPython. Well, really, I'm trying to puzzle out how to do them in >> AppleScript and then pulling my hair out trying to figure out how to >> convert what works in AppleScript into something that works in >> MacPython (if only autocomplete worked on the Mac, that would help). >> Are there any examples anywhere of using MacPython and AppleEvents? > > Unfortunately there are no good examples:-( The Demo/applescript.html > is about the only documentation there is, and the example it uses won't > work under OSX... > Nonetheless, I'd think that the example shown there is a pretty good one to look at - it's very simple and shows the basics of how the AppleScript verbs map onto the package structure. However, the example that I found to be most useful was findertools.py. The functions therein are all pretty short and easy to understand. The approach is exactly what Bill Bedford described: "...it is usually better to use python directly and only attempt the Apple events when you really need to communicate with an application." This strategy matches my own few uses of AppleEvents in MacPython, and makes me wonder if everyone does it that way? Better stated, does anyone have an example where they don't take this approach? > If anyone could come up with some good examples that would really be > very welcome. I think AppleScripting could be one of the areas where > Python can really shine, but there's still quite a bit of a hurdle you > have to jump over to get started. > Maybe we should consider using findertools as a case study in Pythonic AppleScripting? It's a "real world" usage and we know that all MacPython users will have it. I can have a go at writing a brief version, although it may have to wait a week or so (Anyone who is impatient should feel free to start without me!). From Jack.Jansen@cwi.nl Mon Aug 12 16:19:07 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 12 Aug 2002 17:19:07 +0200 Subject: [Pythonmac-SIG] (silly newbie question) Bringing a process to the front In-Reply-To: Message-ID: On Monday, August 12, 2002, at 12:03 , Richard Bornat wrote: > My problem with native Aqua and python seems to have a peculiar root. > > What I see is that if I run the following command from Terminal > > /Library/Frameworks/Python.framework//Versions/2.2/bin/python > ~/cvsdownloads/jape/jape/X/python/GUI/japeserver.py > > then I see a process window in the background, which won't come to the > foreground. If I click on the window, I get the message > > SetFrontProcess failed,-600 This is a well-known problem (albeit a somewhat mysterious one). The Python in ..../bin/python is a normal command-line interpreter, it cannot be used to run programs with a GUI. To run GUI programs you must use an interpreter that is embedded in a .app framework. But: this all has started working only recently, so you will have to build Python from CVS to get it to work. The you can run your script with /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/ MacOS/python, or with /usr/local/bin/pythonw (which calls the above program). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Mon Aug 12 16:27:33 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 12 Aug 2002 17:27:33 +0200 Subject: [Pythonmac-SIG] Callback function problems In-Reply-To: Message-ID: <0599FF48-AE08-11D6-99CF-0030655234CE@cwi.nl> On Monday, August 12, 2002, at 03:07 , Matthew Smith wrote: > Hello > > If this is better suited to a general python list then sorry... Probably yes, as these may well be non-Mac-specific questions (so you'll get more responses on a general list). > Only "if (result == NULL)" always fails... I tried to put the code in > callPythonFunc into setTempCallback to see if the PyObject, > pythonCallback > is having trouble but to no avail. Any ideas?? Are you holding the global interpreter lock when you're doing the callback? Something you could try is to print the current exception with PyErr_Print() if result == 0. This may show you what's going on. > > Traceback (most recent call last): > File "", line 1, in ? > File "main.py", line 12, in ? > import myModule # import the python module > ImportError: No module named myModule Some problem with sys.path. Try setting Py_Verbose to 2. This will print not only succesful imports but also all the places it tried to find a module. this should help tracking this down. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mwh@python.net Mon Aug 12 16:27:46 2002 From: mwh@python.net (Michael Hudson) Date: 12 Aug 2002 16:27:46 +0100 Subject: [Pythonmac-SIG] Callback function problems In-Reply-To: Matthew Smith's message of "Mon, 12 Aug 2002 23:07:35 +1000" References: Message-ID: <2msn1kumfh.fsf@starship.python.net> Matthew Smith writes: > Hello > > If this is better suited to a general python list then sorry... Yes, but ne'er mind. > I'm having problems setting up and using a callback function in my program > that embeds python. I am using the following code: > void callPythonFunc(long x, long y) > { > PyObject *arglist; > PyObject *result; > long smaller; > > arglist = Py_BuildValue("[l,l]", x, y); Try "Py_BuildValue("ll", x, y);" instead. You want a list, not a tuple. > result = PyEval_CallObject(pythonCallback, arglist); Or result = PyEval_CallFunction(pythonCallback, "ll", x, y); Cheers, M. -- FORD: Just pust the fish in your ear, come on, it's only a little one. ARTHUR: Uuuuuuuuggh! -- The Hitch-Hikers Guide to the Galaxy, Episode 1 From Jack.Jansen@oratrix.com Mon Aug 12 16:29:54 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 12 Aug 2002 17:29:54 +0200 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: <53AEDB0A-ADFB-11D6-A5CD-0050E4794D0F@uma.pt> Message-ID: <59A8834C-AE08-11D6-99CF-0030655234CE@oratrix.com> On Monday, August 12, 2002, at 03:56 , Michael J. Barber wrote: > Maybe we should consider using findertools as a case study in Pythonic > AppleScripting? It's a "real world" usage and we know that all > MacPython users will have it. I can have a go at writing a brief > version, although it may have to wait a week or so (Anyone who is > impatient should feel free to start without me!). Do you think you could add something to the findertools module that uses objects? Because that's the bit that *I* wouldn't mind having a manual for, I always forget how to say "set font of word 2 of paragraph 3 of window "Foo" to "Times Roman"" in Python. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From smithsm@samuelsmith.org Mon Aug 12 17:34:59 2002 From: smithsm@samuelsmith.org (Samuel Smith) Date: Mon, 12 Aug 2002 10:34:59 -0600 Subject: [Pythonmac-SIG] Reorganize the Carbon package? In-Reply-To: <331823E0-AD6E-11D6-9656-003065517236@oratrix.com> Message-ID: <7175F415-AE11-11D6-9BF3-00039346A274@samuelsmith.org> > > > 4. In addition to (3) we actually create a module Carbon.Carbon that > imports everything from every Carbon module in the system. Advantage is > that by using this module everything is 100% compatible with the Apple > documentation. Disadvantage is that the namespace for this module is > mindbogglingly large. And, if you really need only one single Carbon call > you will still drag in all the extension modules, etc. > I am just naive enough to wonder why the Carbon module can't be a hierarchical package of modules instead of just one module. That way one only needs import the parts needed. Of course if someone needed most of carbon they would import the top level of the package __all__ and get the whole namespace, but is than any different than building it in? > 5. In stead of (4) we might be able to come up with some lazy dynamic > scheme. I.e. the module (or module-like object) Carbon.Carbon doesn't > import anything initially, but when you try to access, say, Carbon.Carbon. > NewWindow it will somehow find out that this should come from Carbon.Win > and at that point do the actual import (and populating its own namespace > with all its symbols). Advantage is the same as for (4). Disadvantage is > that I don't know how to do this:-), "from Carbon.Carbon import *" may be > a problem, for instance, and that introspection (think of the IDE class > browser) will work in a funny way. wouldn't the setup functions at each level of the package hierarchy obviate the need for a lazy scheme. > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > ************************************************************************** ************************ Samuel M. Smith Ph.D. President & Founder Adept Systems Incorporated 360 W. 920 N. Orem, Utah 84042 801.226.7607 x112 (voice) 801.226.7608 (fax) mailto: smithsm@adeptsystemsinc.com (email) http://www.adeptsystemsinc.com/ (web) ************************************************************************** *********************** NOTICE: This electronic mail message, together with any attachments contains information that may be copyrighted, confidential, proprietary, and/or legally privileged of and/or by Adept Systems Incorporated. This electronic mail message is intended solely for the use of the individual or entity originally named as the intended recipient. If you are not the intended recipient, and have received this message in error, please return immediately this message by email and delete it. ************************************************************************** ************************* From managan@llnl.gov Mon Aug 12 17:54:05 2002 From: managan@llnl.gov (Rob Managan) Date: Mon, 12 Aug 2002 09:54:05 -0700 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: <89402CF1-A62E-11D6-9D96-0030655234CE@cwi.nl> References: <89402CF1-A62E-11D6-9D96-0030655234CE@cwi.nl> Message-ID: Jack, This note and the REAMDE in Mac/OSX need updating. The current CVS repository seems to have merged step 4 into step 3. In fact there no longer is a target osxapps. It seems to have been replaced with frameworkinstallapps in the main Makefile and installapps in the Mac/OSX/Makefile. Thanks for the details about waste in the Mac/OSX/README. Now I have a working IDE under OSX. >Folks, >if you check out the current head of the CVS repository you'll get >all the applet and >launcher and other stuff that I plan to include in 2.3. Let me know >what you think. > >Here's the quick instructions: >1. configure --enable-framework >2. make >3. make frameworkinstall >4. make osxapps > >The last step will do all the goodies. It'll create a folder >/Applications/Python >that contains PythonLauncher, PythonIDE and BuildApplet. Also, there >will be a hidden >application >/Library/Frameworks/Python.framework/Versions/Current/Resources/Python.app >that is >used both for executing .pyw scripts by PythonLauncher and as the >applet template by BuildApplet >and PythonIDE. > -- *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan LLNL ph: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From Chris.Barker@noaa.gov Mon Aug 12 18:55:38 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Mon, 12 Aug 2002 10:55:38 -0700 Subject: [Pythonmac-SIG] AppleEvent examples References: Message-ID: <3D57F699.759BC0B@noaa.gov> Jack Jansen wrote: > If anyone could come up with some good examples that would > really be very welcome. And put them in the Official Doc too! (see the RTFM thread) -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker@noaa.gov Mon Aug 12 18:59:45 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Mon, 12 Aug 2002 10:59:45 -0700 Subject: [Pythonmac-SIG] Reorganize the Carbon package? References: <331823E0-AD6E-11D6-9656-003065517236@oratrix.com> Message-ID: <3D57F791.6BE1A851@noaa.gov> Jack Jansen wrote: > Disadvantage is that I expect 2.3 to > be a turning-point release where we can significantly enlarge > our audience. I agree. It sould be really nice if 2.3 provided an API that will be stable in the future. If you don't have time, however, you don't have time. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker@noaa.gov Mon Aug 12 18:53:21 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Mon, 12 Aug 2002 10:53:21 -0700 Subject: [Pythonmac-SIG] RTFM References: <4B61757B-AA48-11D6-BFE3-003065517236@oratrix.com> Message-ID: <3D57F611.4A3DF655@noaa.gov> Jack Jansen wrote: > Ok, then we misunderstood each other. The "highlevel > documentation" will definitely have to be rewritten for OSX. My > request was mainly for the "Macintosh" section of the Python > Library Reference. Do you mean the "MacPython Modules" section of the "Macintosh Library Modules" Doc? (http://www.python.org/dev/doc/devel/mac/mac.html). That doc was edited an reorganised by me a year or so ago (or two, I don't remember!). It still needs a lot of help, and, of course updates for OS-X. I think the "Using Python on the Macintosh" section should be re-written, and perhaps broken into two setions, one for OS-X and one for OS-9. I'd be glad to help edit and deal with the LaTeX stuff, but I don't have the time or OS-X experience tpo really do any writing at the moment. The target for the OS-X stuff should be 2.3, and the new framework Mach-O build structure. A mention of Unix Python should probably be put in, but since it is Unix- Python, it doesn't really need to be documented much there. I really would like to see this "Official" doc be put into good shape! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Jack.Jansen@oratrix.com Mon Aug 12 20:30:36 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 12 Aug 2002 21:30:36 +0200 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: <59A8834C-AE08-11D6-99CF-0030655234CE@oratrix.com> Message-ID: On maandag, augustus 12, 2002, at 05:29 , Jack Jansen wrote: > Do you think you could add something to the findertools module > that uses objects? Because that's the bit that *I* wouldn't > mind having a manual for, I always forget how to say "set font > of word 2 of paragraph 3 of window "Foo" to "Times Roman"" in > Python. Hmm, idea: would it make a nice example if we could come up with findertools.savewindowstate() and restorewindowstate(), which would respectively return a datastructure containing the current state of all the finder windows (position, layout, folder opened, etc) and rebuild the finder windows from that state? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mday@mac.com Mon Aug 12 20:55:45 2002 From: mday@mac.com (Mark Day) Date: Mon, 12 Aug 2002 12:55:45 -0700 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: <59A8834C-AE08-11D6-99CF-0030655234CE@oratrix.com> Message-ID: <7D56D416-AE2D-11D6-8D58-00039354009A@mac.com> On Monday, August 12, 2002, at 08:29 AM, Jack Jansen wrote: > Do you think you could add something to the findertools module that > uses objects? Because that's the bit that *I* wouldn't mind having a > manual for, I always forget how to say "set font of word 2 of > paragraph 3 of window "Foo" to "Times Roman"" in Python. For really simple AppleScripting stuff, the OSAm module in :Mac:Contrib: is very handy since you can take ordinary AppleScript source and pass it to CompileAndExecute. For some uses, it may be simpler to use Python to build up the AppleScript source on the fly and then let AppleScript compile and execute the actual AppleEvents rather than try to build up the AppleEvents inside Python. -Mark From dan@danshafer.com Mon Aug 12 21:19:38 2002 From: dan@danshafer.com (Dan Shafer) Date: Mon, 12 Aug 2002 13:19:38 -0700 Subject: [Pythonmac-SIG] RTFM In-Reply-To: <3D57F611.4A3DF655@noaa.gov> References: <4B61757B-AA48-11D6-BFE3-003065517236@oratrix.com> <3D57F611.4A3DF655@noaa.gov> Message-ID: >Jack Jansen wrote: >> Ok, then we misunderstood each other. The "highlevel >> documentation" will definitely have to be rewritten for OSX. My >> request was mainly for the "Macintosh" section of the Python >> Library Reference. > >Do you mean the "MacPython Modules" section of the "Macintosh Library >Modules" Doc? >(http://www.python.org/dev/doc/devel/mac/mac.html). > >That doc was edited an reorganised by me a year or so ago (or two, I >don't remember!). It still needs a lot of help, and, of course updates >for OS-X. I think the "Using Python on the Macintosh" section should be >re-written, and perhaps broken into two setions, one for OS-X and one >for OS-9. I'd be glad to help edit and deal with the LaTeX stuff, but I >don't have the time or OS-X experience tpo really do any writing at the >moment. I'd be delighted to work on this project as I have time. I do have some OS X experience (expertise is probably an overstatement) and I would benefit from understanding Python on Mac better in any case. >The target for the OS-X stuff should be 2.3, and the new framework >Mach-O build structure. A mention of Unix Python should probably be put >in, but since it is Unix- Python, it doesn't really need to be >documented much there. I could certainly buy into this. >I really would like to see this "Official" doc be put into good shape! > >-Chris > >-- >Christopher Barker, Ph.D. >Oceanographer > >NOAA/OR&R/HAZMAT (206) 526-6959 voice >7600 Sand Point Way NE (206) 526-6329 fax >Seattle, WA 98115 (206) 526-6317 main reception > >Chris.Barker@noaa.gov > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Shafer Writer, Spiritual Student and Teacher Founder, Fellowship of One Mind, Monterey, CA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Jack.Jansen@oratrix.com Mon Aug 12 21:51:30 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 12 Aug 2002 22:51:30 +0200 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: Message-ID: <474236A4-AE35-11D6-B7D6-003065517236@oratrix.com> On maandag, augustus 12, 2002, at 06:54 , Rob Managan wrote: > Jack, > This note and the REAMDE in Mac/OSX need updating. The current > CVS repository seems to have merged step 4 into step 3. In fact > there no longer is a target osxapps. It seems to have been > replaced with frameworkinstallapps in the main Makefile and > installapps in the Mac/OSX/Makefile. Ah, you're right, I forgot to update the README! It's done now. Thanks! I've implemented what I viewed as the consensus here: "make frameworkinstall" installs everything: the framework, the apps and the unix tools. There are subtargets if you want partial installs. And I think I've also enabled what the Fink people asked for: the ability to install in a different root. If you do "configure --enable- framework=/tmp/foo/Library/Frameworks" the apps will go to /tmp/foo/Applications/Python and the unix tools to /tmp/foo/usr/local/bin. So /tmp/foo should be usable to create a distribution that is untainted by the local system. A minor drawback of this is that if you do --enable- framework=$HOME/Library/Frameworks the framework and the apps will be deposited in the expected locations, but your unix tools will end up in $HOME/usr/local/bin, whereas $HOME/bin would be the more logical place. Suggestions on fixing this are welcome. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Mon Aug 12 22:00:43 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 12 Aug 2002 23:00:43 +0200 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: <7D56D416-AE2D-11D6-8D58-00039354009A@mac.com> Message-ID: <9103E344-AE36-11D6-B7D6-003065517236@oratrix.com> On maandag, augustus 12, 2002, at 09:55 , Mark Day wrote: > For really simple AppleScripting stuff, the OSAm module in > :Mac:Contrib: is very handy since you can take ordinary > AppleScript source and pass it to CompileAndExecute. For some > uses, it may be simpler to use Python to build up the > AppleScript source on the fly and then let AppleScript compile > and execute the actual AppleEvents rather than try to build up > the AppleEvents inside Python. If this is true then we're doing something wrong. For static scripts, okay, but if it is easier to dynamically create Applescript code than it is to use Python's own OSA API then we have to rethink the way the API is structured. Do you have examples of it being easier to go via Applescript? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Mon Aug 12 21:57:23 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 12 Aug 2002 22:57:23 +0200 Subject: [Pythonmac-SIG] Reorganize the Carbon package? In-Reply-To: <7175F415-AE11-11D6-9BF3-00039346A274@samuelsmith.org> Message-ID: <19E5037A-AE36-11D6-B7D6-003065517236@oratrix.com> On maandag, augustus 12, 2002, at 06:34 , Samuel Smith wrote: >> >> >> 4. In addition to (3) we actually create a module >> Carbon.Carbon that imports everything from every Carbon module >> in the system. Advantage is that by using this module >> everything is 100% compatible with the Apple documentation. >> Disadvantage is that the namespace for this module is >> mindbogglingly large. And, if you really need only one single >> Carbon call you will still drag in all the extension modules, >> etc. >> > I am just naive enough to wonder why the Carbon module can't be > a hierarchical package of modules instead of just one module. > That way one only needs import the parts needed. This is the current situation, where you import Carbon.Win or Carbon.Res. Or do you mean something different? The "problem" with the current situation is that the Apple documentation is moving away from the toolbox organization. I.e. will a new Apple developer, someone who doesn't remember MacOS9, know that ClearKeyboardFocus() is in Carbon.Ctl and not in Carbon.Win? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From billb@mousa.demon.co.uk Mon Aug 12 22:51:00 2002 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Mon, 12 Aug 2002 22:51:00 +0100 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: <59A8834C-AE08-11D6-99CF-0030655234CE@oratrix.com> References: <59A8834C-AE08-11D6-99CF-0030655234CE@oratrix.com> Message-ID: At 5:29 pm +0200 12/08/02, Jack Jansen wrote: > >Do you think you could add something to the findertools module that >uses objects? Because that's the bit that *I* wouldn't mind having a >manual for, I always forget how to say "set font of word 2 of >paragraph 3 of window "Foo" to "Times Roman"" in Python. The way I remember it is Commands in applescript are methods of the application class in python. Properties in applescript are classes of the application module in python Which has always seemed to me to be a bit counter intuitive So your example for application 'App' would be ap = App.App() ap.set(App.font(App.word(2, App.paragraph(3, App.window("Foo")))), 'to'='Times Roman') That's assuming that 'font', 'word', 'paragraph' and 'window' are all classes of App. For some applications this would not be true and the classes have to be called from Standard Suites. -- Bill Bedford A streaker streaks, and a nation shrugs at a saucer like disk in the sky A stag weekend is a poor weekend if the army is not on standby From mday@mac.com Tue Aug 13 00:06:44 2002 From: mday@mac.com (Mark Day) Date: Mon, 12 Aug 2002 16:06:44 -0700 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: <9103E344-AE36-11D6-B7D6-003065517236@oratrix.com> Message-ID: <2B924FA2-AE48-11D6-8D58-00039354009A@mac.com> On Monday, August 12, 2002, at 02:00 PM, Jack Jansen wrote: > On maandag, augustus 12, 2002, at 09:55 , Mark Day wrote: >> For really simple AppleScripting stuff, the OSAm module in >> :Mac:Contrib: is very handy since you can take ordinary AppleScript >> source and pass it to CompileAndExecute. For some uses, it may be >> simpler to use Python to build up the AppleScript source on the fly >> and then let AppleScript compile and execute the actual AppleEvents >> rather than try to build up the AppleEvents inside Python. > > If this is true then we're doing something wrong. For static scripts, > okay, but if it is easier to dynamically create Applescript code than > it is to use Python's own OSA API then we have to rethink the way the > API is structured. > > Do you have examples of it being easier to go via Applescript? For background, I was sending an AppleEvent to one application to create a file, having Python massage the data a bit, then sending an AppleEvent to a second application to open the modified file. I already knew AppleScript's syntax to get the events I wanted. The only part that needed to be dynamic was a filename or two, and that was trivial as long as I assumed that I could ignore quoting issues (which was true for the few systems it was deployed on). To be honest, I put very little effort into trying to understand how to do it directly in the Python OSA API. I read :Mac:Demo:applescript.html and took a quick peek at the Disk Copy demo. Right after that, I found the OSAm module. It sounded like it would take a bit of effort to get started using the Python OSA API, compared to a simple string substitution in an existing AppleScript (via OSAm.CompileAndExecute). If it needed to be more robust with volume/folder/file names, or if I had to do something more complex with the applications, I think I would have made the extra effort to understand and use the Python OSA API rather than spend a lot of time trying to build up scripts that AppleScript would parse properly. -Mark From ByronFormwalt@aaahawk.com Tue Aug 13 01:58:27 2002 From: ByronFormwalt@aaahawk.com (Byron Formwalt) Date: Mon, 12 Aug 2002 20:58:27 -0400 Subject: [Pythonmac-SIG] (silly newbie question) Bringing a process to the front In-Reply-To: Message-ID: On 8/12/02 6:03 AM, "Richard Bornat" wrote: > My problem with native Aqua and python seems to have a peculiar root. > > What I see is that if I run the following command from Terminal > > /Library/Frameworks/Python.framework//Versions/2.2/bin/python > ~/cvsdownloads/jape/jape/X/python/GUI/japeserver.py > > then I see a process window in the background, which won't come to the > foreground. If I click on the window, I get the message > > SetFrontProcess failed,-600 > > (note, because of what follows, that the command is issued with absolute > pathnames. > > If I run a similar command from a Unix process (actually, by issuing the > absolute path of japeserver.py, which starts with > > #!/usr/bin/env python > > ) then the process runs -- I can see its messages on the console -- but > I can't see a window at all. > > For this reason I downloaded the CVS source and (as my earlier message > revealed) managed to build native Aqua, but failed to install it. > > Then, at last, a clue. Frustrated by python, I started to build an > analogue in Java. When I run this process with a local pathname I get > the same behaviour as with the python version > > ./japeserver > [JavaAppLauncher Error] executable path must be an absolute path, or it > cannot be brought to foreground > Buckyball: Couldn't bring app to front, err=-600 > > (that is, a process which is clearly running in the background, but > whose windows are invisible). Running it with an absolute pathname > works fine -- I get to see the window, I can interact with the menus. > > I'd rather not spend a month or so transcribing the python code into > Java (not yet, anyway). So can anybody suggest what commands I should > be issuing -- from shell and from Unix process -- to start a python > which I _can_ interact with? > > Richard Bornat > > > Hi, Richard. I just ran into the exact same problem. Apparently you can't launch a tkinter app from the command line. You can, however launch a wxWindows app from the command line, (MachoPython with wxMacPython) using the pythonw script/link. But there seem to be several problems with wxWindows, still. So, I'm trying to figure out how to get wxWindows working with carbon MacPython in OS X, while the MachoPython version is being fixed. I just started working with this about a week ago. If you want to collaborate in more detail offline from the group, just email me directly. Byron From jwblist@olympus.net Tue Aug 13 05:59:23 2002 From: jwblist@olympus.net (John W Baxter) Date: Mon, 12 Aug 2002 21:59:23 -0700 Subject: [Pythonmac-SIG] Re: Step-by-step howto for testing new Mach{ho}Python architecture In-Reply-To: References: Message-ID: At 8:18 -0400 8/7/2002, Dan Grassi wrote: >I suggest one standard target: "install". Removing the OS X >Applications is simple enough but why would this be desirable? Possibly >a better place for the OS X Tools might be >/Applications/Utilities/Python. > >The basic install should install the framework version, it is the OS X >and Python default so no extra hints are needed in the target, they only >beg the question of what other possibilities should be considered and >that is not a good thing for the average user. All I need is to build Python to run as it does in a non-GUI situation on the machines at work, so I can move programs back and forth. (We don't run X-windows at work...I don't need the Mac stuff [GUI, Mac-specific tools, etc] at home.) I don't mind having to use a non-obvious make target ("install" is obvious) to do that...I don't see why I should build extra stuff only to toss it out, hoping that tossing it out "works". --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From mwh@python.net Tue Aug 13 12:33:21 2002 From: mwh@python.net (Michael Hudson) Date: 13 Aug 2002 12:33:21 +0100 Subject: [Pythonmac-SIG] Reorganize the Carbon package? In-Reply-To: Jack Jansen's message of "Sun, 11 Aug 2002 23:06:26 +0200" References: <331823E0-AD6E-11D6-9656-003065517236@oratrix.com> Message-ID: <2mr8h3q9ha.fsf@starship.python.net> Jack Jansen writes: > 5. In stead of (4) we might be able to come up with some lazy > dynamic scheme. I.e. the module (or module-like object) > Carbon.Carbon doesn't import anything initially, but when you > try to access, say, Carbon.Carbon.NewWindow it will somehow find > out that this should come from Carbon.Win and at that point do > the actual import (and populating its own namespace with all its > symbols). Advantage is the same as for (4). Disadvantage is that > I don't know how to do this:-), "from Carbon.Carbon import *" > may be a problem, for instance, and that introspection (think of > the IDE class browser) will work in a funny way. I think playing games like this is a bad idea. I think the _xmlplus hacks in the core are regretted now, are they not? Cheers, M. -- If you have too much free time and can't think of a better way to spend it than reading Slashdot, you need a hobby, a job, or both. -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq From just@letterror.com Tue Aug 13 15:36:32 2002 From: just@letterror.com (Just van Rossum) Date: Tue, 13 Aug 2002 16:36:32 +0200 Subject: [Pythonmac-SIG] Reorganize the Carbon package? In-Reply-To: <331823E0-AD6E-11D6-9656-003065517236@oratrix.com> Message-ID: Jack Jansen wrote: > The Carbon package is a bit of a mess right now. Or, let me > rephrase that, there is stuff in there that isn't part of the > Carbon framework in Apple's documentation: QuickTime and > CoreFoundation. Moreover, everything inside it is grouped by the > old MacOS9 toolbox names (Win, Res, Dlg, etc). > > This is something that will have to change at some point, but > the question is, should we try to fix this before Python 2.3 is > released, or should we wait until 2.4? Of course, any fix will > have a 1-release backwards compatibility, as was done for the > Res->Carbon.Res change in Python 2.2. > > I can see a couple of options, all with specific advantages and > drawbacks, and I'd like some feedback. > > 1. Do nothing for 2.3, leave it for 2.4. Advantage is that I > have enough work already. Disadvantage is that I expect 2.3 to > be a turning-point release where we can significantly enlarge > our audience. > > 2. Move QuickTime to its own package (QuickTime.Qt and > QuickTime.QuickTime for the constants), move CF to its own > package (CoreFoundation.CF and CoreFoundation.CoreFoundation) > and leave it at that. Advantage is that it's fairly easy to do, > disadvantage is that it's only a half-way solution. My vote would be for #2 or #1, in order of preference. > 3. In addition to (2) we could get rid of the funny distinction > between constants and objects/methods that is an artefact of the > way the modules are created. I.e. the user would always import > Carbon.Windows and that module would contain both the constants > and the methods and objects. Advantage is that QuickTime and > CoreFoundation are then 100% compatible to the documentation, > disadvantage is that Carbon isn't. Moreover, the namespaces of > the various modules will become pretty big. Big, but not as big as a merged Carbon module would become. > 4. In addition to (3) we actually create a module Carbon.Carbon > that imports everything from every Carbon module in the system. > Advantage is that by using this module everything is 100% > compatible with the Apple documentation. Disadvantage is that > the namespace for this module is mindbogglingly large. And, if > you really need only one single Carbon call you will still drag > in all the extension modules, etc. -1. Waaay too much stuff. This is Python, not C after all. We _have_ multiple namespaces... > 5. In stead of (4) we might be able to come up with some lazy > dynamic scheme. I.e. the module (or module-like object) > Carbon.Carbon doesn't import anything initially, but when you > try to access, say, Carbon.Carbon.NewWindow it will somehow find > out that this should come from Carbon.Win and at that point do > the actual import (and populating its own namespace with all its > symbols). Advantage is the same as for (4). Disadvantage is that > I don't know how to do this:-), "from Carbon.Carbon import *" > may be a problem, for instance, and that introspection (think of > the IDE class browser) will work in a funny way. -1. Agree completely with Michael Hudson. This kind of magic is evil. Just (who is on vacation, so will only sporadically be able to check his email, let alone answer it) From richard@dcs.qmul.ac.uk Tue Aug 13 17:30:35 2002 From: richard@dcs.qmul.ac.uk (Richard Bornat) Date: Tue, 13 Aug 2002 17:30:35 +0100 Subject: [Pythonmac-SIG] installation problem? Message-ID: Checked out python from CVS a couple of hours ago, using MacCVS and making almost everything look like a BBEdit file. configure worked fine (once I'd chmod +x'd it). Make worked perfectly. make frameworkinstall seemed to be going fine (once I'd chmod +x'd ./Lib/plat-darwin/regen) but it didn't complete ... I get the message /usr/bin/install -c -m 644 ./Mac/OSX/Mac.pth /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ ./python.exe ./Mac/scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib /Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools Traceback (most recent call last): File "./Mac/scripts/cachersrc.py", line 44, in ? main() File "./Mac/scripts/cachersrc.py", line 41, in main os.path.walk(dir, handler, (verbose, force)) File "./Lib/posixpath.py", line 284, in walk walk(name, func, arg) File "./Lib/posixpath.py", line 276, in walk func(arg, top, names) File "./Mac/scripts/cachersrc.py", line 23, in handler macresource.open_pathname(os.path.join(dirname, fn), verbose=verbose) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/macresource.py" , line 84, in open_pathname refno = Res.FSOpenResourceFile(pathname, u'', 1) MacOS.Error: (-39, 'Mac OS error code -39') make[1]: *** [installmacsubtree] Error 1 make: *** [frameworkinstallmaclib] Error 2 Others report that it all builds and installs fine. Please, what am I doing wrong? Richard Bornat From richard@dcs.qmul.ac.uk Tue Aug 13 17:47:35 2002 From: richard@dcs.qmul.ac.uk (Richard Bornat) Date: Tue, 13 Aug 2002 17:47:35 +0100 Subject: [Pythonmac-SIG] more on installation problem ... Message-ID: <5E939AD0-AEDC-11D6-B8EE-00039343CD2E@dcs.qmul.ac.uk> Of course MacCVS is checking out the .rsrc files as proper resource forks ... is that the source of my problem? Ought I to check them out more lamely? Richard Bornat From Robin.Siebler@corp.palm.com Tue Aug 13 17:52:13 2002 From: Robin.Siebler@corp.palm.com (Robin Siebler) Date: Tue, 13 Aug 2002 09:52:13 -0700 Subject: [Pythonmac-SIG] Applescript Example Message-ID: <400CE9390E334A4393CEECDD6863120A04D0B46E@ussccm003.corp.palm.com> I am trying to figure out how to convert the below AppleScript line into = something Python/CodeWarrior can deal with. I'm new to AppleScript = (which might be a part of the problem), I don't have a *clue* as to how = things are laid out in the package (or whatever for CodeWarrior). Could = someone tell me *how* I would go about converting the below line into = Python, i.e. what I need to be looking for? Here is the line: set dText to (get text of document 1) -- of CodeWarrior. Thanks!=20 Robin L. Siebler Software Test Engineer Palm --------------------------------------- Lisa: Dad, is it all right to take things from people you don't like? = Homer: Sure it is, honey. You *do* mean stealing, don't you? From aparente@adobe.com Tue Aug 13 17:54:48 2002 From: aparente@adobe.com (Alexandre Parenteau) Date: Tue, 13 Aug 2002 09:54:48 -0700 Subject: [Pythonmac-SIG] installation problem? In-Reply-To: Message-ID: Richard, The problem is that MacPython is not calibrated anymore to be checked-out with MacCvs or MacCvsPro. I'm able to do it, but I have to play with src/Mac/OSX/Makefile (see below). In particular, resource fork are not created with the raw cvs. So my modification assume that .rsrc files are in fact 2 fork files (like the one created by MacCvs and MacCvsPro). Note that some other changes are in fact related to Jaguar. Note also that if you use MacCvs, you want to check-out with ISO-8559 using "MacCvsPro encoding" (in the preferences) (BTW if people are using the default cvs, it doesn't have a ISO8559 encoding, but I thought several files were requiring it). Also use MacCvsX (machO) on OSX rather than MacCvs (CFM). I'm using the cvs command bundled with MacCvsX in place of the default outdated /usr/bin/cvs. Hope it helps, Alex. Index: Makefile =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/OSX/Makefile,v retrieving revision 1.21 diff -r1.21 Makefile 24c24,25 < INSTALL_SYMLINK=/usr/bin/install -l as --- > #INSTALL_SYMLINK=/usr/bin/install -l as > INSTALL_SYMLINK=ln -s 96,99c97,102 < $(PYTHON) $(RFCONVERTER) -r $(RESOURCEDIR)/dialogs.rsrc dialogs.rsrc < $(PYTHON) $(RFCONVERTER) -r $(RESOURCEDIR)/errors.rsrc errors.rsrc < $(DEREZ) -useDF -skip ckid dialogs.rsrc > dialogs.r < $(DEREZ) -useDF -skip ckid errors.rsrc > errors.r --- > # $(PYTHON) $(RFCONVERTER) -r $(RESOURCEDIR)/dialogs.rsrc dialogs.rsrc > # $(PYTHON) $(RFCONVERTER) -r $(RESOURCEDIR)/errors.rsrc errors.rsrc > # $(DEREZ) -useDF -skip ckid dialogs.rsrc > dialogs.r > # $(DEREZ) -useDF -skip ckid errors.rsrc > errors.r > $(DEREZ) -skip ckid $(RESOURCEDIR)/dialogs.rsrc > dialogs.r > $(DEREZ) -skip ckid $(RESOURCEDIR)/errors.rsrc > errors.r 104c107,109 < @if $(INSTALLED_PYTHONW) -c "import waste"; then ; else \ --- > @if $(INSTALLED_PYTHONW) -c "import waste"; then \ > echo "OK"; \ > else \ 212a218,224 > *.rsrc) \ > echo $(DEREZ) -skip ckid $$i; \ > $(DEREZ) -skip ckid $$i > $$b/__temp.r; \ > c=`basename $$i`; \ > echo $(REZ) -useDF -o $$b/$$c $$b/__temp.r; \ > $(REZ) -useDF -o $$b/$$c $$b/__temp.r; \ > rm $$b/__temp.r;; \ From Robin.Siebler@corp.palm.com Tue Aug 13 18:09:55 2002 From: Robin.Siebler@corp.palm.com (Robin Siebler) Date: Tue, 13 Aug 2002 10:09:55 -0700 Subject: [Pythonmac-SIG] Clearing the Interactive Window Message-ID: <400CE9390E334A4393CEECDD6863120A04D0B471@ussccm003.corp.palm.com> Short of restarting MacPython, is there a way do this? I tried = Edit|Clear, but that didn't work. Nor can you select all of the text = and delete it. Robin L. Siebler Software Test Engineer Palm --------------------------------------- Homer Simpson: Maybe, just once, someone will call me "sir" without = adding, "you're making a scene." From billb@mousa.demon.co.uk Tue Aug 13 18:12:54 2002 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Tue, 13 Aug 2002 18:12:54 +0100 Subject: [Pythonmac-SIG] Applescript Example In-Reply-To: <400CE9390E334A4393CEECDD6863120A04D0B46E@ussccm003.corp.palm.com> References: <400CE9390E334A4393CEECDD6863120A04D0B46E@ussccm003.corp.palm.com> Message-ID: At 9:52 am -0700 13/08/02, Robin Siebler wrote: >I am trying to figure out how to convert the below AppleScript line >into something Python/CodeWarrior can deal with. I'm new to >AppleScript (which might be a part of the problem), I don't have a >*clue* as to how things are laid out in the package (or whatever for >CodeWarrior). Could someone tell me *how* I would go about >converting the below line into Python, i.e. what I need to be >looking for? Here is the line: > >set dText to (get text of document 1) -- of CodeWarrior. See my reply of yesterday dText = cw.get(CodeWarrior.text(CodeWarrior.document(1))) but you can do it just as easily and quicker by using python's open() -- Bill Bedford A streaker streaks, and a nation shrugs at a saucer like disk in the sky A stag weekend is a poor weekend if the army is not on standby From Robin.Siebler@corp.palm.com Tue Aug 13 19:43:52 2002 From: Robin.Siebler@corp.palm.com (Robin Siebler) Date: Tue, 13 Aug 2002 11:43:52 -0700 Subject: [Pythonmac-SIG] AppleScript Example Message-ID: <400CE9390E334A4393CEECDD6863120A04D0B477@ussccm003.corp.palm.com> With help from viewers like you, I now have the following script which *should* work (or so I believe). However, it doesn't. Am I doing something wrong, or is there a bug somewhere? Here is the code: import CodeWarrior cw = CodeWarrior.CodeWarrior(start=1) cw.activate() cw.open (file1) cw.disassemble_file(file2) text = cw.get(CodeWarrior.text(CodeWarrior.document(1))) After I run this, text is None, so either I am doing something wrong (my guess) or there is a bug. Any takers? Robin L. Siebler Software Test Engineer Palm --------------------------------------- Homer Simpson: Bart, I'm not asking you to give blood for free. That would be crazy! You may not realize it now, but when you save a rich guy's life, he showers you with riches! Don't you know the story of Hercules and the Lion? Bart Simpson: Is it a Bible story? Homer Simpson: Yeah, probably. Anyway, once upon a time, there was a big, mean lion who got a thorn in his paw. All the villagers tried to pull it out, but nobody was strong enough, so they got Hercules and he used his mighty strength, and bingo! Anyway, the moral is, is that the lion was so happy, that he gave Hercules this big... thing... of riches! Bart Simpson: How did a lion get riches? Homer Simpson: It was the olden days! Bart Simpson: Oh! From jay@heynow.com Tue Aug 13 22:35:51 2002 From: jay@heynow.com (Jay Koutavas) Date: Tue, 13 Aug 2002 17:35:51 -0400 Subject: [Pythonmac-SIG] more on MacPython/OSX/shared lib In-Reply-To: <5.1.0.14.2.20011220143046.0230c608@cedar.he.net> References: <5.1.0.14.2.20011220132600.02149470@cedar.he.net> <5.1.0.14.2.20011220143046.0230c608@cedar.he.net> Message-ID: Hi Paul. Long time no see. :) What was the resolution on this? My Mac OS X Carbon application is failing the same way when I like to PythonCoreCarbon. It barfs at initialization time. /Jay At 2:31 PM -0600 on 12/20/01, Paul Miller wrote: >>Hmm, my guess would be either a bug in CodeWarrior, or (probably more >>likely) you using the wrong runtime library. Especially if you use C++ >>you have to be careful with which runtime library you use where, >>because the zero-overhead exception handling will fail otherwise. And >>you shouldn't use Python as an example, because it doesn't follow the >>rules (but gets away with it being a C program). You might want to >>spell out the MW Targeting MacOS manual. > >That's what I thought, but how much harder does it get than to link >with MSL_All_Carbon and CarbonLib? > > >-- >Paul T. Miller | paul@fxtech.com | http://www.fxtech.com > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Jay Koutavas mailto:jay@heynow.com Heynow Software http://www.heynow.com Windham, New Hampshire, USA ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' From paul@fxtech.com Tue Aug 13 22:42:00 2002 From: paul@fxtech.com (Paul Miller) Date: Tue, 13 Aug 2002 16:42:00 -0500 Subject: [Pythonmac-SIG] more on MacPython/OSX/shared lib In-Reply-To: References: <5.1.0.14.2.20011220143046.0230c608@cedar.he.net> <5.1.0.14.2.20011220132600.02149470@cedar.he.net> <5.1.0.14.2.20011220143046.0230c608@cedar.he.net> Message-ID: <5.1.0.14.2.20020813164025.04326dc0@cedar.he.net> >Long time no see. :) Hey Jay - how are things out east? >What was the resolution on this? My Mac OS X Carbon application is failing >the same way when I like to PythonCoreCarbon. It barfs at initialization time. I think it may have been the way Mac Python needs to be initialized. Are you using the "Mac" way of init? ::PyMac_Initialize(); instead of ::Py_Initialize(); ? -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From aparente@adobe.com Wed Aug 14 00:14:34 2002 From: aparente@adobe.com (Alexandre Parenteau) Date: Tue, 13 Aug 2002 16:14:34 -0700 Subject: [Pythonmac-SIG] Jaguar and CVS Python Message-ID: Jack and friends, I wonder how many of you guys played with Jaguar (OSX 10.2). It is also my first glance at gcc 3.1 that comes with 10.2. Everything was fine for building Python, except for waste which has an obsolete libWaste.a (even in August 1st Waste 2.1b1) which won't compile with gcc3.1. After I recompiled waste with CodeWarrior 8.2 (MPTP: early access), it came OK. I then run into some problems of checked out files because I'm using MacCvs (see earlier message). I used the 'make frameworkinstall' scheme. Now I'm experiencing the nice new architecture. I mostly use python from the command line to invoke CodeWarrior thru AppleScripts, so I almost immeditly run into a hanging problems of python : _err = AESend(&_self->ob_itself, &reply, sendMode, sendPriority, timeOutInTicks, 0L/*upp_AEIdleProc*/, (AEFilterUPP)0); I had to comment out upp_AEIdleProc (I tried several things, but that is the only thing which helped). Jack, you might want to remember this one if the problem is still in Jaguar. It hangs and finally times out. I've looked inside this function and I can see the signal handling, but I'm not sure what it is for. I didn't test on 10.1.3: but it could be the same. Well I'm lost... So It works for me now ! Thanks for all this nice new stuff. Alex. -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From ByronFormwalt@aaahawk.com Wed Aug 14 00:33:52 2002 From: ByronFormwalt@aaahawk.com (Byron Formwalt) Date: Tue, 13 Aug 2002 19:33:52 -0400 Subject: [Pythonmac-SIG] New Start Proposal: NXPython In-Reply-To: <20020813160003.2793.74526.Mailman@mail.python.org> Message-ID: MacPython enthusiasts, I am proposing to head up a new effort to revamp Python for OS X. This effort will be done in Objective-C/Cocoa, using Apple's Project Builder/IB in the Developers' Toolkit that comes free with OS X. There will be seven large modules/subprojects to this major undertaking. If anyone else has been waiting anxiously for this to start happening, please speak up. Encouragement, advice, expression of interest, and programming support are all equally welcome. A brief overview of the project are laid out below. NXPython: Python Implementation Native to Mac OS X Pronounced 'Native X Python' Written entirely in Objective-C. Components: 1) Framework Python Interpreter -- used for execution of Python commands and as the core interpreter for inside user-generated generating applets and applications. 2) Framework Python Debugger -- framework for interactively debugging Python scripts/scripted modules. 3) Framework wxWindows -- used for implementing wxWindows on top of Aqua/Cocoa. 4) Framework wxPython -- framework layer used for making wxWindows accessible to NXPython. 5) NXPythonWrapper -- Cocoa tool for wrapping traditional Un*x shared/static libraries into frameworks directly usable by NXPython. 6) NXPython -- Cocoa IDE application for developing Python scripts/scripted modules and generating NXPython applications and applets native to Mac OS X (Cocoa). 7) nxpython -- Foundation tool, serving as the interactive command-line interface to the Framework Python Interpreter. Plan of attack: 1) Design the interfaces for the Framework Python Interpreter, Framework Python Debugger, and External Python Frameworks. 2) Design and implement the nxpython command-line interface tool and the Framework Python Interpreter. **MILESTONE 1** 31 December 2002 3) Design and implement NXPythonWrapper Cocoa GUI app for wrapping Un*x libraries into framework form, with an interface usable by NXPython. (Note: these are not Carbon libraries specifically designed for MacPython. They are non-X11 Un*x libraries, such as libjpeg.a or zlib.a. **MILESTONE 2** 30 April 2003 4) Design and implement the Framework Python Debugger and add hooks into the nxpython tool for interactive debugging of Python scripts. 5) Design and implement the NXPython IDE without support for generating user apps and applets. **MILESTONE 3** 30 August 2003 6) Add automatic application/applet generation capability to NXPython. (Note: no support is planned for making self-contained distributable command-line executables, since presumably, anyone using command-line-only Python tools has Python already installed.) **MILESTONE 4** 30 October 2003 7) If no-one has made a good, solid, working native implementation of wxWindows by this point, then design and implement it. (Hopefully this will not be necessary.) 8) Create the NXPython accessible Framework for interfacing with wxWindows, using the semi-automated NXPythonWrapper tool. **MILESTONE 5** TBD (Possibly as early as 01 January 2004) 9) Enjoy Pythoning on the Mac... Carbon will probably be a thing of the past by now. Byron From jay@heynow.com Wed Aug 14 02:52:47 2002 From: jay@heynow.com (Jay Koutavas) Date: Tue, 13 Aug 2002 21:52:47 -0400 Subject: [Pythonmac-SIG] more on MacPython/OSX/shared lib In-Reply-To: <5.1.0.14.2.20020813164025.04326dc0@cedar.he.net> References: <5.1.0.14.2.20011220143046.0230c608@cedar.he.net> <5.1.0.14.2.20011220132600.02149470@cedar.he.net> <5.1.0.14.2.20011220143046.0230c608@cedar.he.net> <5.1.0.14.2.20020813164025.04326dc0@cedar.he.net> Message-ID: I am using PyMac_Initialize(). It's barfing at *application initialization* time. Before the debugger even comes up, before main() even gets called. I think it has something to do with all those resources on the DLL. Seems to me, it's kind of bad form to weak-link to a DLL with resources by dropping the DLL (PythonCoreCarbon) into the CW project. I think what I want is a stub library to link to, and then have PythonCoreCarbon load at runtime? /Jay At 4:42 PM -0500 on 8/13/02, Paul Miller wrote: >>Long time no see. :) > >Hey Jay - how are things out east? > >>What was the resolution on this? My Mac OS X Carbon application is >>failing the same way when I like to PythonCoreCarbon. It barfs at >>initialization time. > >I think it may have been the way Mac Python needs to be initialized. >Are you using the "Mac" way of init? > > ::PyMac_Initialize(); > >instead of > > ::Py_Initialize(); > >? > >-- >Paul T. Miller | paul@fxtech.com | http://www.fxtech.com > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Jay Koutavas mailto:jay@heynow.com Heynow Software http://www.heynow.com Windham, New Hampshire, USA ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' From footrot@mac.com Wed Aug 14 03:07:43 2002 From: footrot@mac.com (Matthew Smith) Date: Wed, 14 Aug 2002 12:07:43 +1000 Subject: [Pythonmac-SIG] pebinding python Message-ID: <9E63C532-AF2A-11D6-A17C-003065F5537E@mac.com> --Apple-Mail-1--555944044 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Thanks for the help with python callbacks, i have a more mac oriented question now. I'd like to prebind the python framework into my app, but to do this I need to prebind the python first. following the instructions in PB's release notes, I set the environment variable LD_PREBIND variable and attempted to recompile the framework in the command line, but this didn't seem to work. Is python dependent on non prebound libs? or is there a better way of prebinding python... Thanks Matt Smith --Apple-Mail-1--555944044 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Thanks for the help with python callbacks, i have a more mac oriented question now. I'd like to prebind the python framework into my app, but to do this I need to prebind the python first. following the instructions in PB's release notes, I set the environment variable CourierLD_PREBIND variable and attempted to recompile the framework in the command line, but this didn't seem to work. Is python dependent on non prebound libs? or is there a better way of prebinding python... Thanks Matt Smith --Apple-Mail-1--555944044-- From ByronFormwalt@aaahawk.com Wed Aug 14 04:49:17 2002 From: ByronFormwalt@aaahawk.com (Byron Formwalt) Date: Tue, 13 Aug 2002 23:49:17 -0400 Subject: [Pythonmac-SIG] RE: New Start Proposal: NXPython Message-ID: Objective-C Advocacy: I should point out two important distinctions between the proposed NXPython and existing Python implementations. NXPython will adhere to every letter of the Python language. However, it will have a radically different API than the current open source Python implementations share. For one, the API will be in Objective-C. This is why I mentioned the need to provide the semi-automated wrapping utility. Obj-C enthusiasts wishing to write new modules may do so with ease, using Apple's modified gcc to extending NXPython with Obj-C frameworks. At the same time, this does not preclude traditional users from auto-wrapping their existing legacy extensions. Since Cocoa is only available to Java and Obj-C programmers, this seemed like the most reasonable path to take for future Python implementations on the Mac. While Python could remain only in C, it makes more sense to take advantage of the inherent objective nature in Obj-C to implement the objective nature of Python. Objective-C Portability: The other thing I wanted to point out, in case some may not be aware, is that the Obj-C source code for GCC compiler is available at GNU, and has been successfully compiled for Linux, Un*x, cgwin, and of course, Mac OS X. This means that the nxpython command-line interface, API, and interpreter can be made open source, also. The only question of portability is specifying the build type based on the build platform. Frameworks would be DLLs on windows, and on the Un*x flavored machines, non-framework options would need to be provided. While I'm not planning to make this implementation port over to the other platforms, I don't want to stand in the way of someone who really wants to do it. The Obj-C version of GCC is at ftp://ftp.cis.ohio-state.edu/mirror/gnu/gcc/gcc-3.1.1/gcc-objc-3.1.1.tar.gz Byron From oussoren@cistron.nl Wed Aug 14 06:14:06 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Wed, 14 Aug 2002 07:14:06 +0200 Subject: [Pythonmac-SIG] RE: New Start Proposal: NXPython In-Reply-To: Message-ID: Byron, I'm not sure how usefull this project will be, it will probably be an awfull lot of work with at most minor benefits w.r.t. the default python implementation. If you want to access existing objective-C frameworks you can do some with PyObjC (pyobjc.sourceforge.net). The existing release is a bit limited, but we're working on an improved version (see http://www.cistron.nl/~oussoren/pyobjc for a pre-pre-release) Greetings, Ronald On Wednesday, August 14, 2002, at 05:49 , Byron Formwalt wrote: > Objective-C Advocacy: > > I should point out two important distinctions between the proposed > NXPython > and existing Python implementations. NXPython will adhere to every > letter > of the Python language. However, it will have a radically different API > than the current open source Python implementations share. For one, > the API > will be in Objective-C. This is why I mentioned the need to provide the > semi-automated wrapping utility. Obj-C enthusiasts wishing to write new > modules may do so with ease, using Apple's modified gcc to extending > NXPython with Obj-C frameworks. At the same time, this does not > preclude > traditional users from auto-wrapping their existing legacy extensions. > Since Cocoa is only available to Java and Obj-C programmers, this seemed > like the most reasonable path to take for future Python implementations > on > the Mac. While Python could remain only in C, it makes more sense to > take > advantage of the inherent objective nature in Obj-C to implement the > objective nature of Python. > > Objective-C Portability: > > The other thing I wanted to point out, in case some may not be aware, is > that the Obj-C source code for GCC compiler is available at GNU, and has > been successfully compiled for Linux, Un*x, cgwin, and of course, Mac > OS X. > This means that the nxpython command-line interface, API, and > interpreter > can be made open source, also. The only question of portability is > specifying the build type based on the build platform. Frameworks > would be > DLLs on windows, and on the Un*x flavored machines, non-framework > options > would need to be provided. While I'm not planning to make this > implementation port over to the other platforms, I don't want to stand > in > the way of someone who really wants to do it. > > The Obj-C version of GCC is at > ftp://ftp.cis.ohio-state.edu/mirror/gnu/gcc/gcc-3.1.1/gcc- > objc-3.1.1.tar.gz > > Byron > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Jack.Jansen@cwi.nl Wed Aug 14 09:42:40 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 14 Aug 2002 10:42:40 +0200 Subject: [Pythonmac-SIG] more on MacPython/OSX/shared lib In-Reply-To: Message-ID: On Wednesday, August 14, 2002, at 03:52 , Jay Koutavas wrote: > I am using PyMac_Initialize(). It's barfing at *application > initialization* time. Before the debugger even comes up, before main() > even gets called. I think it has something to do with all those > resources on the DLL. Seems to me, it's kind of bad form to weak-link > to a DLL with resources by dropping the DLL (PythonCoreCarbon) into the > CW project. I think what I want is a stub library to link to, and then > have PythonCoreCarbon load at runtime? This sounds vaguely plausible, except for the fact that then I would have expected other people to run into the problem too. Why don't you try creating the stub library, and if it solves your problem put a patch in sourceforge and I'll add it to the general distribution... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Wed Aug 14 09:44:31 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 14 Aug 2002 10:44:31 +0200 Subject: [Pythonmac-SIG] pebinding python In-Reply-To: <9E63C532-AF2A-11D6-A17C-003065F5537E@mac.com> Message-ID: <0D353296-AF62-11D6-AAC0-0030655234CE@cwi.nl> On Wednesday, August 14, 2002, at 04:07 , Matthew Smith wrote: > Thanks for the help with python callbacks, i have a more mac oriented > question now. > > I'd like to prebind the python framework into my app, but to do this I > need to prebind the python first. following the instructions in PB's > release notes, I set the environment variable LD_PREBIND variable and > attempted to recompile the framework in the command line, but this > didn't seem to work. > > Is python dependent on non prebound libs? or is there a better way of > prebinding python... I've so far stayed away from prebinding, there's more than enough other new stuff in MacOSX. But I think it would indeed be beneficial if Python could be prebound. If you can come up with a recipe or, even better, a patch to Makefile.pre.in I'll happily incorporate it. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Wed Aug 14 10:16:17 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 14 Aug 2002 11:16:17 +0200 Subject: [Pythonmac-SIG] New Start Proposal: NXPython In-Reply-To: Message-ID: <7D7D48DD-AF66-11D6-AAC0-0030655234CE@cwi.nl> On Wednesday, August 14, 2002, at 01:33 , Byron Formwalt wrote: > MacPython enthusiasts, > I am proposing to head up a new effort to revamp Python for OS X. > This > effort will be done in Objective-C/Cocoa, using Apple's Project > Builder/IB > in the Developers' Toolkit that comes free with OS X. There will be > seven > large modules/subprojects to this major undertaking. If anyone else has > been waiting anxiously for this to start happening, please speak up. > Encouragement, advice, expression of interest, and programming support > are > all equally welcome. A brief overview of the project are laid out > below. Byron, I think that you're trying to do too many things lumped together into one big project, whereas if you structured it as a couple of smaller projects you would make much more rapid progress, and it may turn out that some of the things don't need doing anyway. A lot of the things you propose are re-implementations of functionality that is already available to Python, in one way or another. It might not, in it's current form, be ideal for use on MacOSX, but in those cases I think your time is better spent on adapting that functionality in stead of starting from scratch. > Plan of attack: > > 1) Design the interfaces for the Framework Python Interpreter, Framework > Python Debugger, and External Python Frameworks. I think this phase should start with two questions: - What's wrong with the current interfaces - What will I break by changing the current interfaces, and is it worth it. Especially the second question is important: if you change anything substantial in the API that is used by Python extension modules it means you're cutting yourself off from all the third party extension modules that are out there. Jython has this problem too: there's lots more stuff available for Python than for Jython. And then Jython has the advantage that it can use Java extension modules, which your NXPython hasn't... > > 2) Design and implement the nxpython command-line interface tool and the > Framework Python Interpreter. > > **MILESTONE 1** 31 December 2002 You're extremely optimistic here... > 3) Design and implement NXPythonWrapper Cocoa GUI app for wrapping Un*x > libraries into framework form, with an interface usable by NXPython. > (Note: > these are not Carbon libraries specifically designed for MacPython. > They > are non-X11 Un*x libraries, such as libjpeg.a or zlib.a. First: there are a couple of tools that do this already: bgen, swig, pyrite and more. Second, I would guess that this was one of the components where you wouldn't need a GUI, or are you envisioning an interactive wrapping process? If you indeed want something where you interactively steer the process: why not add a Cocoa front end to bgen? Bgen already knows all the details about passing parameters to/from C, parsing header files, etc etc etc. What makes it difficult to use right now is the convoluted procedure of finding out what all the types are, deciding whether you want to implement them or leave them out for now, adding the conversion rules, etc. An interactive front end for this would be very welcome. > **MILESTONE 2** 30 April 2003 > > 4) Design and implement the Framework Python Debugger and add hooks > into the > nxpython tool for interactive debugging of Python scripts. The IDE has a pretty nice debugger. It's Carbon-based, but rewriting it to Cocoa would be a nice exercise. And even if you do this with the current PyObjC bridge and not with your NXPython it should be fairly trivial to go from one to the other lateron. > > 5) Design and implement the NXPython IDE without support for generating > user > apps and applets. Same as for 4. > **MILESTONE 3** 30 August 2003 > > 6) Add automatic application/applet generation capability to NXPython. > (Note: no support is planned for making self-contained distributable > command-line executables, since presumably, anyone using > command-line-only > Python tools has Python already installed.) Again, we have it already. Why would NXPython need a different BuildApplet than current Python? > **MILESTONE 4** 30 October 2003 > > 7) If no-one has made a good, solid, working native implementation of > wxWindows by this point, then design and implement it. (Hopefully this > will > not be necessary.) > > 8) Create the NXPython accessible Framework for interfacing with > wxWindows, > using the semi-automated NXPythonWrapper tool. This is where it starts to bite you that you changed the APIs in step one: all the work done by other people over the year you've spent on this project can't be incorporated in NXPython... All in all I think you shouldn't get carried away by too much enthusiasm to "do everything different". Why ont start with one of the smaller subprojects (I would suggest a GUI for bgen, but then I'm not unbiased:-) and work from there? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Wed Aug 14 10:18:21 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 14 Aug 2002 11:18:21 +0200 Subject: [Pythonmac-SIG] Jaguar and CVS Python In-Reply-To: Message-ID: On Wednesday, August 14, 2002, at 01:14 , Alexandre Parenteau wrote: > Now I'm experiencing the nice new architecture. I mostly use python > from the > command line to invoke CodeWarrior thru AppleScripts, so I almost > immeditly > run into a hanging problems of python : > > _err = AESend(&_self->ob_itself, > &reply, > sendMode, > sendPriority, > timeOutInTicks, > 0L/*upp_AEIdleProc*/, > (AEFilterUPP)0); > > I had to comment out upp_AEIdleProc (I tried several things, but that > is the > only thing which helped). This sounds reasonable. The main reason to have upp_AEIdleProc is for MacPython. I'll have a look at it. Could you file a bug report? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Wed Aug 14 10:23:17 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 14 Aug 2002 11:23:17 +0200 Subject: [Pythonmac-SIG] installation problem? In-Reply-To: Message-ID: <7768B47D-AF67-11D6-AAC0-0030655234CE@cwi.nl> On Tuesday, August 13, 2002, at 06:54 , Alexandre Parenteau wrote: > Richard, > > The problem is that MacPython is not calibrated anymore to be > checked-out > with MacCvs or MacCvsPro. Ah, good one! Fixing the Makefile (Alexandre's problem) is fairly easy, probably. Fixing the .rsrc files (Richard's problem) in the installed Lib is a bit more difficult but I'll have a look. (The difficult bit is that the unix "install" currently used dumped the resource fork on the floor, so there's nothing left to unpack). It would be nice if we could use a MacCVS-based Python tree for Unix development, then I could use a single tree for MacPython and unix-Python building. Which is messy for everyday use, but very handy if you want to try patches, etc. Could you post a feature request, and please attach the Makefile you modified (as an example, I think I want to do things slightly different so it works with any CVS tree. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From billb@mousa.demon.co.uk Wed Aug 14 10:54:05 2002 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Wed, 14 Aug 2002 10:54:05 +0100 Subject: [Pythonmac-SIG] Faqwiz Message-ID: Does anyone know of a public site using Faqwiz apart from the Python FAQ on python.org? -- Bill Bedford A streaker streaks, and a nation shrugs at a saucer like disk in the sky A stag weekend is a poor weekend if the army is not on standby From Benjamin.Schollnick@usa.xerox.com Wed Aug 14 12:44:37 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Wed, 14 Aug 2002 07:44:37 -0400 Subject: [Pythonmac-SIG] AppleEvent examples Message-ID: | For really simple AppleScripting stuff, the OSAm module in | :Mac:Contrib: is very handy since you can take ordinary AppleScript | source and pass it to CompileAndExecute. You can do this already?!?!?!? I admit I didn't look into the OSAm module... (Or at least I don't remember doing so) But this defintely needs to be documented!!! I've been kind of looking into doing something like this....... Thanks Mark! - Benjamin -----Original Message----- From: Mark Day [mailto:mday@mac.com] Sent: Monday, August 12, 2002 3:56 PM To: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] AppleEvent examples On Monday, August 12, 2002, at 08:29 AM, Jack Jansen wrote: > Do you think you could add something to the findertools module that > uses objects? Because that's the bit that *I* wouldn't mind having a > manual for, I always forget how to say "set font of word 2 of > paragraph 3 of window "Foo" to "Times Roman"" in Python. For really simple AppleScripting stuff, the OSAm module in :Mac:Contrib: is very handy since you can take ordinary AppleScript source and pass it to CompileAndExecute. For some uses, it may be simpler to use Python to build up the AppleScript source on the fly and then let AppleScript compile and execute the actual AppleEvents rather than try to build up the AppleEvents inside Python. -Mark _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.com Wed Aug 14 20:22:21 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 14 Aug 2002 21:22:21 +0200 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: Message-ID: <2801DA17-AFBB-11D6-8B4E-003065517236@oratrix.com> On woensdag, augustus 14, 2002, at 01:44 , Schollnick, Benjamin wrote: > | For really simple AppleScripting stuff, the OSAm module in > | :Mac:Contrib: is very handy since you can take ordinary AppleScript > | source and pass it to CompileAndExecute. > > You can do this already?!?!?!? > > I admit I didn't look into the OSAm module... (Or at least I don't > remember doing so) > > But this defintely needs to be documented!!! I've been kind of looking > into doing something like this....... I've never really tried to use the OSAm module, but as people are so enthusiastic about it: should I include it in the standard set of modules in stead of in Contrib? How complete is it? Anyone willing to write documentation? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From aparente@adobe.com Wed Aug 14 20:57:21 2002 From: aparente@adobe.com (Alexandre Parenteau) Date: Wed, 14 Aug 2002 12:57:21 -0700 Subject: [Pythonmac-SIG] installation problem? In-Reply-To: <7768B47D-AF67-11D6-AAC0-0030655234CE@cwi.nl> Message-ID: Jack, > Fixing the Makefile (Alexandre's problem) is fairly easy, probably. > Fixing the .rsrc files (Richard's problem) in the installed Lib is a bit > more difficult but I'll have a look. (The difficult bit is that the unix > "install" currently used dumped the resource fork on the floor, so > there's nothing left to unpack). Well, I'm already using a single checked out sand box for compiling both mach-O and CFM, and the changes I did in the Makefile are the only changes I had to do. In order to copy resources, I end up doing what you partly do : Derez then Rez again to the final location. > It would be nice if we could use a MacCVS-based Python tree for Unix > development, then I could use a single tree for MacPython and > unix-Python building. Which is messy for everyday use, but very handy if > you want to try patches, etc. > > Could you post a feature request, and please attach the Makefile you > modified (as an example, I think I want to do things slightly different > so it works with any CVS tree. That would be awesome ! What is a feature request ? Is it a bug or a patch ? Is-it on SourceForge ? Thanks, Alex. > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From Robin.Siebler@corp.palm.com Wed Aug 14 21:28:22 2002 From: Robin.Siebler@corp.palm.com (Robin Siebler) Date: Wed, 14 Aug 2002 13:28:22 -0700 Subject: [Pythonmac-SIG] AppleEvent examples Message-ID: <400CE9390E334A4393CEECDD6863120A04D0B491@ussccm003.corp.palm.com> On woensdag, augustus 14, 2002, at 01:44 , Schollnick, Benjamin wrote: > | For really simple AppleScripting stuff, the OSAm module in > | :Mac:Contrib: is very handy since you can take ordinary AppleScript > | source and pass it to CompileAndExecute. > > You can do this already?!?!?!?> So far this is the *only* way that I have been able to use MacPython to perform what is a simple script in AppleScript. From Jack.Jansen@oratrix.com Thu Aug 15 20:52:39 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 15 Aug 2002 21:52:39 +0200 Subject: [Pythonmac-SIG] AppleScript Example In-Reply-To: <400CE9390E334A4393CEECDD6863120A04D0B477@ussccm003.corp.palm.com> Message-ID: <8D95FFC6-B088-11D6-A10D-003065517236@oratrix.com> On dinsdag, augustus 13, 2002, at 08:43 , Robin Siebler wrote: > With help from viewers like you, I now have the following script which > *should* work (or so I believe). However, it doesn't. Am I > doing something > wrong, or is there a bug somewhere? > > Here is the code: > > import CodeWarrior > cw = CodeWarrior.CodeWarrior(start=1) > cw.activate() > cw.open (file1) > cw.disassemble_file(file2) > text = cw.get(CodeWarrior.text(CodeWarrior.document(1))) > > After I run this, text is None, so either I am doing something > wrong (my > guess) or there is a bug. Any takers? Definitely sounds like a bug. Did you try it in AppleScript? If it works there then please post a bug report to sourceforge (preferrably with a complete script + sample document + working applescript) and I'll have a look. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Thu Aug 15 20:57:32 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 15 Aug 2002 21:57:32 +0200 Subject: [Pythonmac-SIG] Clearing the Interactive Window In-Reply-To: <400CE9390E334A4393CEECDD6863120A04D0B471@ussccm003.corp.palm.com> Message-ID: <3C59E37C-B089-11D6-A10D-003065517236@oratrix.com> On dinsdag, augustus 13, 2002, at 07:09 , Robin Siebler wrote: > Short of restarting MacPython, is there a way do this? I tried > Edit|Clear, but that didn't work. Nor can you select all of > the text and delete it. I don't think you can. For anything more then very basic output you want to get rid of the console window and use your own text window, based on W or FrameWork or raw waste or textedit or whatever. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Thu Aug 15 22:43:02 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 15 Aug 2002 23:43:02 +0200 Subject: [Pythonmac-SIG] Building in a MacCVS sourcetree Message-ID: Alexandre, I think that tonight's checkin to Mac/OSX/Makefile should enable you to build from a source tree checked out with MacCVS (or it's cvs tool) as opposed to standard unix cvs. But: could you please check? I don't have the diskspace (or the time) right now to test it... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From barry@python.org Fri Aug 16 07:29:44 2002 From: barry@python.org (Barry A. Warsaw) Date: 16 Aug 2002 02:29:44 -0400 Subject: [Pythonmac-SIG] Re: Python and Jaguar References: <1023710195.3d0493f349f89@webmail.in-berlin.de> Message-ID: >>>>> "JJ" == Jack Jansen writes: JJ> If people haven't answered this because of their JJ> non-disclosure-agreement: please let me know in private (I'm a JJ> developer, you can trust me:-). I would be especially JJ> interested in knowing whether they've included a JJ> framework-build or a non-framework-build. I've heard the same rumor about Jaguar and Python 2.2. I don't know anything more than that, but I was told that it was 2.2.1. No NDA here, or AFAIK, my source. -Barry From barry@python.org Fri Aug 16 07:26:20 2002 From: barry@python.org (Barry A. Warsaw) Date: 16 Aug 2002 02:26:20 -0400 Subject: [Pythonmac-SIG] Re: Python, Jython, Cocoa and Charleroi References: <3D0D93ED.EAC4806@darwin.in-berlin.de> Message-ID: | I'm not sure there is a formal convention. Obj-C signatures | are "richer" in a sense that you can say: DG> [obj doItWithFoo:arg1 andBar:arg2 andQuit]; DG> which in Java would probably become: DG> obj.doItWithFooAndBarAndQuit(arg1, arg2); | The Java Cocoa-API tries hard to come as close as possible | to the "original meaning" of Obj-C signatures, but in some | cases this might be difficult to achieve. It's so ironic and cool to see ObjC bindings and NeXTSTEP coming back to haunt us. One of the original motivations for us (CNRI) hiring Guido all those years ago was to have him help us support ObjC and NS, our intended Knowbot development platforms. He quickly disavoid us of that notion but it's fun to see all that technology resurrected in MacOSX. -Barry From dan@grassi.org Fri Aug 16 13:46:03 2002 From: dan@grassi.org (Dan Grassi) Date: Fri, 16 Aug 2002 08:46:03 -0400 Subject: [Pythonmac-SIG] Re: Python and Jaguar In-Reply-To: Message-ID: <1FB67C16-B116-11D6-A598-00039346A28A@grassi.org> > JJ> I would be especially > JJ> interested in knowing whether they've included a > JJ> framework-build or a non-framework-build. Check the Darwin cvs: http://www.opensource.apple.com/cgi-bin/registered/cvs/src/live/python/ It appears that Python is considered a part of Darwin. Registration (free) and login are required. The Makefile: ## # Makefile for python ## Project =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D python Extra_Configure_Flags =3D --enable-ipv6 --with-threads Extra_Install_Flags =A0 =3D DESTDIR=3D${DSTROOT}=20 MANDIR=3D${DSTROOT}/usr/share/man GnuAfterInstall =A0 =A0 =A0 =3D strip-installed-files # It's a GNU Source project include $(MAKEFILEPATH)/CoreOS/ReleaseControl/GNUSource.make Install_Target =3D install strip-installed-files: =A0 =A0 =A0 =A0strip -x ${DSTROOT}/usr/bin/python* =A0 =A0 =A0 =A0rm ${DSTROOT}/usr/lib/python2.2/config/*.a =A0 =A0 =A0 =A0rm ${DSTROOT}/usr/lib/python2.2/config/python.o =A0 =A0 =A0 =A0rm -rf ${DSTROOT}/usr/lib/python2.2/test =A0 =A0 =A0 =A0strip -x ${DSTROOT}/usr/lib/python2.2/lib-dynload/*.so From Jack.Jansen@oratrix.com Sun Aug 18 22:12:42 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 18 Aug 2002 23:12:42 +0200 Subject: [Pythonmac-SIG] Which installer to use for MacPython-OSX? Message-ID: <3BEAB585-B2EF-11D6-A155-003065517236@oratrix.com> Folks, I finally got around to reading up on Package Maker, and I'm a bit disappointed. While it would be almost trivial to create a package with it that installs the right stuff into /Library/Frameworks, /Applications/Python and /usr/local/bin I can't see a way in which I can give the user the option to install everything in their home directory. I could enable the folder selection option, but that would allow them to install anywhere (meaning they could install in lots of locations where stuff simply won't work). Moreover, I get the impression that the "require admin privileges" is a global property of the package, whereas what I would really want is only require those if the user installs in the default (system-wide) location. Has anyone any bright ideas for how to solve this? If I can share the data between sub-packages I could make identical subpackages where one installs into /, the other in $HOME. But obviously if this means we need to carry two copies of everything it's overkill... If it can't be solved I can see two possibilities: 1. Create two installers, one for system-wide installation, one for home-directory installation. This seems rather silly, though. 2. Check whether Installer Vise can do what I want. It probably can, and I have a freeware license for it, but it would make it more difficult for others to create an installer. Any opinions? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From aparente@adobe.com Sun Aug 18 23:56:01 2002 From: aparente@adobe.com (Alexandre Parenteau) Date: Sun, 18 Aug 2002 15:56:01 -0700 Subject: [Pythonmac-SIG] Which installer to use for MacPython-OSX? In-Reply-To: <3BEAB585-B2EF-11D6-A155-003065517236@oratrix.com> Message-ID: > 2. Check whether Installer Vise can do what I want. It probably > can, and I have a freeware license for it, but it would make it > more difficult for others to create an installer. Yes. Although some have to choose realistic tools. > Any opinions? What about an installer written in Python ? Using a minimal application such as an applet, it sounds possible to write everything in Python, especially now that the things are still not too complicated to install. Alex. > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- > Emma Goldman - > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From owen@astro.washington.edu Mon Aug 19 18:42:24 2002 From: owen@astro.washington.edu (Russell E Owen) Date: Mon, 19 Aug 2002 10:42:24 -0700 Subject: [Pythonmac-SIG] Which installer to use for MacPython-OSX? Message-ID: >I finally got around to reading up on Package Maker, and I'm a bit >disappointed. While it would be almost trivial to create a package >with it that installs the right stuff into /Library/Frameworks, >/Applications/Python and /usr/local/bin I can't see a way in which I >can give the user the option to install everything in their home >directory... How important is it to support users that want to install Python in their home directory? I'm wondering if it matters enough for you to go to extra work to support it, especially as users can always run the unix installer if they want to do something fancy. How important is it for other uses to be able to create a double-clickable MacOS X installer of Python? If this is an issue of making it easy for other folks to help you, then it sounds important. Otherwise, perhaps not? On the other hand, I've heard rumors that the package installer is not very smart about handling permissions, pre-existing files and things like that. This is hearsay coupled with MacFixIt reports of early installers (from Apple and others) causing lots of problems. It does seem that the installer is smarter now or folks have figured out how to work around the worst of the problems, because reports of problems now are rare. Could anybody with more experience comment? Personally, I would suggest that you do whatever is easiest for you. If the resulting installer cannot do everything, so be it. -- Russell From Chris.Barker@noaa.gov Tue Aug 20 18:47:53 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Tue, 20 Aug 2002 10:47:53 -0700 Subject: [Pythonmac-SIG] Pepper is no more :-( References: Message-ID: <3D6280C9.BE06E225@noaa.gov> Hi folks, I just took a look at Maarten Hekkelman's web site (http://www.hekkelman.com), and found the following note: ........................... End of story I'm no longer taking orders for my software. Thanks to all who supported me and my software over the last years. I had a great time, esp. in the beginning. However, recent changes in the various OS's and several not so nice experiences with less than honest 'clients' combined with negative feedback on my software have forced me to stop. -Maarten Hekkelman ................................... I was about to buy a copy of Pepper, as it looks like the best option for Python editing on the Mac, and he had recently released versions for Linux and Windows as well. I was so exited to find a powerful editor with all the features I need/want, that was available on all three platforms that I use. I'm sorry that the business didn't work out for him, and I'm sorry that the MacPython community has lost a nice text editor. He does have links to download the latest version of Pepper, but it doesn't look like it will work without an existing registration key. -CHB -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob@redivi.com Tue Aug 20 22:09:52 2002 From: bob@redivi.com (Bob Ippolito) Date: Tue, 20 Aug 2002 17:09:52 -0400 Subject: [Pythonmac-SIG] Which installer to use for MacPython-OSX? In-Reply-To: <3BEAB585-B2EF-11D6-A155-003065517236@oratrix.com> Message-ID: <2B5CF14B-B481-11D6-9128-0003938210D6@redivi.com> One idea would be to use the post-installer script to allow the user to move it to / .. it's not hard to write an app that uses the security framework to ask for an admin password. Another possible idea is to allow the user to install to a network location.. I don't remember the exact paths and stuff because I don't use OS X Server anywhere, but I think it's /Network/* or something of the like. On Sunday, August 18, 2002, at 05:12 PM, Jack Jansen wrote: > Folks, > I finally got around to reading up on Package Maker, and I'm a bit > disappointed. While it would be almost trivial to create a package with > it that installs the right stuff into /Library/Frameworks, > /Applications/Python and /usr/local/bin I can't see a way in which I > can give the user the option to install everything in their home > directory. > > I could enable the folder selection option, but that would allow them > to install anywhere (meaning they could install in lots of locations > where stuff simply won't work). > > Moreover, I get the impression that the "require admin privileges" is a > global property of the package, whereas what I would really want is > only require those if the user installs in the default (system-wide) > location. > > Has anyone any bright ideas for how to solve this? If I can share the > data between sub-packages I could make identical subpackages where one > installs into /, the other in $HOME. But obviously if this means we > need to carry two copies of everything it's overkill... > > If it can't be solved I can see two possibilities: > 1. Create two installers, one for system-wide installation, one for > home-directory installation. This seems rather silly, though. > 2. Check whether Installer Vise can do what I want. It probably can, > and I have a freeware license for it, but it would make it more > difficult for others to create an installer. > > Any opinions? > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From R.Niemeijer@NiemConsult.com Tue Aug 20 23:27:52 2002 From: R.Niemeijer@NiemConsult.com (Rudo Niemeijer) Date: Wed, 21 Aug 2002 00:27:52 +0200 Subject: [Pythonmac-SIG] Re: Which installer to use for MacPython-OSX? In-Reply-To: <20020820160003.11227.64998.Mailman@mail.python.org> References: <20020820160003.11227.64998.Mailman@mail.python.org> Message-ID: At 12:00 -0400 19-08-2002, Jack Jansen wrote: >I could enable the folder selection option, but that would allow >them to install anywhere (meaning they could install in lots of >locations where stuff simply won't work). Basically I see nothing wrong in that. It would make installation much simpler, other mac oriented programs work that way (which of course differs from the unix heritage. It would requite that a user (unless working from within that same directory) would have the reponsibility to set the appropriate paths). Within a mac model everything should work regardless of the installation directory. Beyond that the application might make a preference file or might put a support dikrectory somewhere, but the number of place things get installed to is certainly reducing a mac-like experience. The user should (ideally) also not be punished for moving this installation folder to another location or even different hard disk. Personally, I think this aspect of installation should be a first priority and not something that comes as an afterthought. Sorry. I do not intend any criticism here, just expressing my philosophy, I have no idea what the actual problems are and what it takes to resolve them. I only know how python could be most mac-like and easy to understand to mac users. Codewarrior is a good example of a complex installation made very simple and completely independent of location. -- Rudo Niemeijer +31 3560 33287 (tel) Niemeijer Consult +31 3560 28120 (fax) R.Niemeijer@NiemConsult.com (e-mail) http://www.niemconsult.com/ From tony@lownds.com Wed Aug 21 00:01:02 2002 From: tony@lownds.com (Tony Lownds) Date: Tue, 20 Aug 2002 16:01:02 -0700 Subject: [Pythonmac-SIG] Mac{ho}Python architecture ready for review In-Reply-To: <474236A4-AE35-11D6-B7D6-003065517236@oratrix.com> References: <474236A4-AE35-11D6-B7D6-003065517236@oratrix.com> Message-ID: >And I think I've also enabled what the Fink people asked for: the >ability to install >in a different root. If you do "configure --enable- >framework=/tmp/foo/Library/Frameworks" the apps will go to >/tmp/foo/Applications/Python and the unix tools to >/tmp/foo/usr/local/bin. So /tmp/foo should be usable to create a >distribution that is untainted by the local system. > >A minor drawback of this is that if you do --enable- >framework=$HOME/Library/Frameworks the framework and the apps will >be deposited in the expected locations, but your unix tools will end >up in $HOME/usr/local/bin, whereas $HOME/bin would be the more >logical place. Suggestions on fixing this are welcome. Hi Jack, It sounds like we need two variables to control the destinations. The --prefix option could be re-used logically as a second variable. How about making these combos work in the following ways: --prefix=/usr/local --enable-framework=/tmp/foo # does what Fink wants --prefix=/ --enable-framework=$HOME # install in my home dir --prefix=/usr/local --enable-framework=/ # the default. i.e. given --prefix=$pre --enable-framework=$fw Application goes in $fw/Applications/Python/ Framework goes in $fw/Library/Frameworks/ Unix binaries go in $fw/$pre If there's interest I can work on a patch (after catching up from 3 weeks of vacation). -Tony From Jack.Jansen@cwi.nl Wed Aug 21 09:32:53 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 21 Aug 2002 10:32:53 +0200 Subject: [Pythonmac-SIG] Re: Which installer to use for MacPython-OSX? In-Reply-To: Message-ID: <95B15C36-B4E0-11D6-8137-0030655234CE@cwi.nl> On Wednesday, August 21, 2002, at 12:27 , Rudo Niemeijer wrote: > At 12:00 -0400 19-08-2002, Jack Jansen wrote: >> I could enable the folder selection option, but that would allow them >> to install anywhere (meaning they could install in lots of locations >> where stuff simply won't work). > > Basically I see nothing wrong in that. [...] > Within a mac model everything should work regardless of the > installation directory. Rudo, these two remarks are in contradiction: there are exactly three locations where the user can install Python so that it will work: /, /Network or $HOME. All other locations will result in a non-functional installation. You shouldn't really think of these as locations, but more as answers the the question "For whom do you want to instal the software?": for everyone on the machine, for everyone on the network or for yourself only. > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Benjamin.Schollnick@usa.xerox.com Wed Aug 21 15:17:47 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Wed, 21 Aug 2002 10:17:47 -0400 Subject: [Pythonmac-SIG] Re: Which installer to use for MacPython-OSX? Message-ID: >> I could enable the folder selection option, but that would allow them >> to install anywhere (meaning they could install in lots of locations >> where stuff simply won't work). Rudo, | these two remarks are in contradiction: there are exactly three | locations where the user can install Python so that it will work: /, | /Network or $HOME. All other locations will result in a non-functional | installation. | You shouldn't really think of these as locations, but more as answers | the the question "For whom do you want to instal the software?": for | everyone on the machine, for everyone on the network or for yourself | only. Then quite simply there is your answer.... When the "installer" starts, you ask simply that question with three radio buttons. One Radio button corresponding to "Global for this machine", "Everyone on the network", "For this local user only". Depending on which radio button is chosen, you place it in that location. If memory serves me correctly, that is very similar to the method that TinkerTool uses for it's installer... - Benjamin From Martina@Oefelein.de Wed Aug 21 21:19:55 2002 From: Martina@Oefelein.de (Martina Oefelein) Date: Wed, 21 Aug 2002 22:19:55 +0200 Subject: [Pythonmac-SIG] Re: Which installer to use for MacPython-OSX? In-Reply-To: <95B15C36-B4E0-11D6-8137-0030655234CE@cwi.nl> References: <95B15C36-B4E0-11D6-8137-0030655234CE@cwi.nl> Message-ID: --============_-1182161255==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hello Jack, >>Within a mac model everything should work regardless of the >>installation directory. I think Rudo meant this as a requirement for a true Mac software, not as a description of the current state of MacPython This is a requirement from the Aqua Human Interface Guidelines (page 246): >Always let users choose a specific folder (or the Desktop) as the installation >destination. Don't require your application to be installed in a particular >location. and it's a quite reasonable requirement. For example, one might install to some "Applications to be tested" folder first, and move it to the Applications software later. >there are exactly three locations where the user can install Python >so that it will work: /, /Network or $HOME. All other locations will >result in a non-functional installation. If this is the current state, I would consider it as a bug, which should be fixed. This bug shouldn't influence which installation tool to choose. ciao Martina --============_-1182161255==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Pythonmac-SIG] Re: Which installer to use for Mac
Hello Jack,

Within a mac model everything should work regardless of the installation directory.

I think Rudo meant this as a requirement for a true Mac software, not as a description of the current state of MacPython

This is a requirement from the Aqua Human Interface Guidelines (page 246):
Always let users choose a specific folder (or the Desktop) as the installation
destination. Don't require your application to be installed in a particular
location.

and it's a quite reasonable requirement. For example, one might install to some "Applications to be tested" folder first,  and move it to the Applications software later.

there are exactly three locations where the user can install Python so that it will work: /, /Network or $HOME. All other locations will result in a non-functional installation.

If this is the current state, I would consider it as a bug, which should be fixed. This bug shouldn't influence which installation tool to choose.

ciao
Martina
--============_-1182161255==_ma============-- From bfancher@mac.com Wed Aug 21 22:12:00 2002 From: bfancher@mac.com (bill fancher) Date: Wed, 21 Aug 2002 14:12:00 -0700 Subject: [Pythonmac-SIG] Re: Which installer to use for MacPython-OSX? In-Reply-To: Message-ID: On Wednesday, August 21, 2002, at 07:17 AM, Schollnick, Benjamin wrote: > >>> I could enable the folder selection option, but that would allow them >>> to install anywhere (meaning they could install in lots of locations >>> where stuff simply won't work). Make a nice "Welcome.txt" that explains the common options that work. Installer will display it for you. Then let people do what they like. Least effort, maximum flexibility. (There may be good reasons to install in "odd" places.) > > Rudo, > | these two remarks are in contradiction: there are exactly three > | locations where the user can install Python so that it will work: /, > | /Network or $HOME. All other locations will result in a non-functional > | installation. This isn't strictly true: You could install to some other home directory and stuff would work for that account. You could be bad and install to /System/Library. You could set DYLD_FRAMEWORK_PATH so that the framework would be found in odd places. It might even be useful to do so in some circumstances (not that I can think of any convincing examples). > | You shouldn't really think of these as locations, but more as answers > | the the question "For whom do you want to instal the software?": for > | everyone on the machine, for everyone on the network or for yourself > | only. Or for someone else (or one of your other accounts) only. Or (generally a bad idea) as part of the system. Or... > Then quite simply there is your answer.... > > When the "installer" starts, you ask simply that > question with three radio buttons. One Radio button > corresponding to "Global for this machine", "Everyone on the > network", "For this local user only". Depending on which > radio button is chosen, you place it in that location. AFAIK, there's no way to do that with Apple's Installer. And, as pointed about above, allowing only three choices might be unnecessarily restrictive. (Of course, you can drag the framework wherever you like, so it's not THAT restrictive.) > If memory serves me correctly, that is very similar to the > method that TinkerTool uses for it's installer... He wrote an installer for Preference Panes. A custom installer is a possibility, but that wasn't under discussion in the quoted context. Python would require something considerably more general. -- bill > > - Benjamin > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bfancher@mac.com Wed Aug 21 22:30:16 2002 From: bfancher@mac.com (bill fancher) Date: Wed, 21 Aug 2002 14:30:16 -0700 Subject: [Pythonmac-SIG] Re: Which installer to use for MacPython-OSX? In-Reply-To: Message-ID: <2F8ECF4E-B54D-11D6-AAEA-0005029E8B13@mac.com> On Wednesday, August 21, 2002, at 01:19 PM, Martina Oefelein wrote: > Hello Jack, > > Within a mac model everything should work regardless of the = installation=20 > directory. > > > I think Rudo meant this as a requirement for a true Mac software, not = as=20 > a description of the current state of MacPython > > This is a requirement from the Aqua Human Interface Guidelines (page = 246) > : > > Always let users choose a specific folder (or the Desktop) as the=20 > installation > > destination. Don't require your application to be installed in a=20 > particular > > location. You're right about isolated applications, but we're talking about=20 installing several applications, a framework, and various other bits. = The=20 main issue here is the framework. Frameworks are not as relocatable as=20= applications. They generally need to live in certain "well-known"=20 locations to work. > and it's a quite reasonable requirement. For example, one might = install=20 > to some "Applications to be tested" folder first,=A0 and move it to = the=20 > Applications software later. > > there are exactly three locations where the user can install Python so=20= > that it will work: /, /Network or $HOME. All other locations will = result=20 > in a non-functional installation. > > > If this is the current state, I would consider it as a bug, which = should=20 > be fixed. This bug shouldn't influence which installation tool to = choose. As explained above, not a bug, but a requirement. In light of that, it=20= does bear somewhat on the choice of an installation tool. -- bill > > ciao > Martina From help@colonize.com Wed Aug 21 21:38:31 2002 From: help@colonize.com (help@colonize.com) Date: Wed, 21 Aug 2002 15:38:31 -0500 Subject: [Pythonmac-SIG] Thank you for writing In-Reply-To: References: Message-ID: <200208212038.PAA08690@server.colonize.com> Hello, We have received your email. Thank you for writing. This message is an automatic response to your email. It is intended to answer many commonly asked questions regarding our service and the particular offers that you receive. If you have further questions or comments after reading this email, there is a different address below that you may use. If you need instructions for unsubscribing, see the information below. __________________________________________ General F.A.Q. (answers to these questions are below) o My email address has changed. How do I make sure that I continue to receive your mailings? o The link that you have sent me does not work. What should I do? o The page cannot be displayed / an error message appears. Now what? o What exactly is Colonize.com and is there a charge for using it? o What if I do not have a credit card? Can I still participate in your offers? o I am not a United States citizen. Can I participate in your offers? o I have a question about one of the offers. Who do I direct it to? o I would like to suggest an offer or comment on one of the offers that I received, what should I do? o Can you tell me how the shopping spree works? o How do I unsubscribe from this mailing? ___________________________________________ My email address has changed. How do I make sure that I continue to receive your mailings? -------------------------------- The easiest way to make sure you continue to receive our mailings at your new address is to simply visit http://www.colonize.com and register with your new address. If you no longer wish to receive our mailings at your old address, simply send a blank email to the unsubscribe address at the bottom of one of our past mailings. The link that you have sent me does not work. What should I do? -------------------------------- We test all links prior to sending them out to ensure that they do work. If you have America Online please be sure that you are using the link labeled for AOL users. You can also type the address of the link in if you are unable to use the link. The page cannot be displayed / an error message appears. Now what? -------------------------------- If the page is not coming up our computer system may be temporarily unavailable or it may be operating at maximum capacity. Please try again at a later time. What exactly is Colonize.com and is there a charge for using it? -------------------------------- Colonize.com is a service that notifies their customers of exciting offers and promotions that are currently available on the Internet. These offers are for discounted items, $ off amounts or free items. We are not an Internet Service Provider. There is never any charge to become a member of Colonize.com or to use our services. You are never under any obligation to purchase any of the offers that we notify you of. After all, they are just offers! What if I do not have a credit card? Can I still participate in your offers? -------------------------------- That depends on the individual merchants. Some of the merchants will only accept credit cards but some do have alternate payment arrangements. You'll need to check the offers that interest you to determine this fact. I am not a United States citizen. Can I participate in your offers? -------------------------------- Again, this depends on the individual merchants. You'll need to check the site of the offers to determine which ones are available to international residents. I have a question about one of the offers. Who do I direct it to? -------------------------------- If you have a question about one of the offers that we have notified you of you'll need to direct it to the merchant who is making the offer. If you use the link that we provided to you for the offer, you'll go to the site where you can find all the information for contacting the Customer Service team of that merchant. I would like to suggest an offer or comment on one of the offers that I received, what should I do? -------------------------------- If you would like to suggest an offer or make a comment on one of the offers you received, please send an email to offer@colonize.com. If a reply is necessary, we will try to respond as soon as we can. Please be patient though. Can you tell me how the shopping spree works? -------------------------------- Usually, within 24 hours of registering for our service you will receive an e-mail that details the shopping spree. Included in the e-mail are links for each of the offers. You click on the links for the offers that interest you. The links will open to the page that displays the offer. You then follow the steps as they are outlined on the site. Please be sure to read over the terms and conditions of the offers to ensure a positive shopping experience. How do I unsubscribe from this mailing? -------------------------------- The EASIEST way to unsubscribe is to click in the unsubscribe link that is included at the bottom of all the offers that we send out to you. This link is encoded with your email and ensures that you will be unsubscribed with the email address you originally gave us. IMPORTANT NOTE: You must use the above-mentioned method to unsubscribe. Due to the volume of email that we receive, we are not able to process manual unsubscribe requests through email. -------------------------------- If your question has not been answered through this auto responder, please send an email to questions@colonize.com. We will try to reply to you as soon as possible. Please be patient though, as we get many emails a day. Thanks for your support! Colonize.com Customer Support Team From Robin.Siebler@palmsource.com Wed Aug 21 23:22:15 2002 From: Robin.Siebler@palmsource.com (Robin Siebler) Date: Wed, 21 Aug 2002 15:22:15 -0700 Subject: [Pythonmac-SIG] Using the HTML help? Message-ID: <3271DBB88437ED41A0AB239E6C2554A43EF858@ussunm001.palmsource.com> I installed the HTML help so that I could use it in the interactive = window. For the command-line version of Python, this works fine. = However, it doesn't work for MacPython. What do I have to do to get = this to work? Robin L. Siebler Software Test Engineer Palm --------------------------------------- Marge Simpson: Only your father could take a part-time job at a small = town paper and wind up the target of international assassins. From Jack.Jansen@oratrix.com Thu Aug 22 21:39:32 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 22 Aug 2002 22:39:32 +0200 Subject: [Pythonmac-SIG] Re: Which installer to use for MacPython-OSX? In-Reply-To: <2F8ECF4E-B54D-11D6-AAEA-0005029E8B13@mac.com> Message-ID: <43AB648C-B60F-11D6-9035-003065517236@oratrix.com> On woensdag, augustus 21, 2002, at 11:30 , bill fancher wrote: >> I think Rudo meant this as a requirement for a true Mac >> software, not as a description of the current state of >> MacPython >> >> This is a requirement from the Aqua Human Interface Guidelines >> (page 246) >> : >> >> Always let users choose a specific folder (or the Desktop) as >> the installation >> >> destination. Don't require your application to be installed in >> a particular >> >> location. > > You're right about isolated applications, but we're talking > about installing several applications, a framework, and various > other bits. The main issue here is the framework. Frameworks > are not as relocatable as applications. They generally need to > live in certain "well-known" locations to work. ... but still, Rudo and Martina have a point. It would be nice if we could set things up in such a way that people can install into any location and have it work from there. Not only would it allow people to install Python in, say, Desktop Folder, because they want to try it out before committing, but it would also allow you to carry a fully functional Python installation with you on removable media such as a CDROM or solidstate usb disk. The DYLD_FRAMEWORK_PATH might point to a solution for this, but can we exploit it? Is there a way in which we could modify the environment when the user double-clicks PythonIDE so that the interpreter inside it will find Python.framework? Can we set environment variables from the plist file, or something similar? Alternative idea: could we pull a trick with relative paths? the interpreter is built with a relative path to the framework, if we create a symlink Python.framework beside the interpreter deep inside PythonIDE's app bundle, would that work? The installer (probably the post-install script) would have to know that the framework is installed in a place where it won't be found by the normal framework search process and add the symlink. BuildApplet would have to do the same. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Thu Aug 22 21:44:11 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 22 Aug 2002 22:44:11 +0200 Subject: [Pythonmac-SIG] Using the HTML help? In-Reply-To: <3271DBB88437ED41A0AB239E6C2554A43EF858@ussunm001.palmsource.com> Message-ID: On donderdag, augustus 22, 2002, at 12:22 , Robin Siebler wrote: > I installed the HTML help so that I could use it in the > interactive window. For the command-line version of Python, > this works fine. However, it doesn't work for MacPython. What > do I have to do to get this to work? Robin, you've lost me here, or probably you know something about a new exciting Python feature that I'm not aware of. What do you mean by "HTML help", the HTML version of the Python docs? Something else? How do you use it from commandline Python? What happens if you try to do the same in MacPython? Which version of Python? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Robin.Siebler@palmsource.com Thu Aug 22 21:50:18 2002 From: Robin.Siebler@palmsource.com (Robin Siebler) Date: Thu, 22 Aug 2002 13:50:18 -0700 Subject: [Pythonmac-SIG] Using the HTML help? Message-ID: <3271DBB88437ED41A0AB239E6C2554A43EF867@ussunm001.palmsource.com> If you download the HTML docs from python.org and set an environmental = variable PYTHONDOCS to the locations of the HTML docs, you can get help = in the interactive window. For instance typing help('for') would give = you help on the FOR command. All of this is mentioned in the Python = docs. However, there doesn't appear to be the equivalent of an = environmental variable for MacPython. There should be a setting for = this in EditPythonPrefs. -----Original Message----- From: Jack Jansen [mailto:Jack.Jansen@oratrix.com] Sent: Thursday, August 22, 2002 1:44 PM To: Robin Siebler Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Using the HTML help? On donderdag, augustus 22, 2002, at 12:22 , Robin Siebler wrote: > I installed the HTML help so that I could use it in the=20 > interactive window. For the command-line version of Python,=20 > this works fine. However, it doesn't work for MacPython. What=20 > do I have to do to get this to work? Robin, you've lost me here, or probably you know something about a new=20 exciting Python feature that I'm not aware of. What do you mean=20 by "HTML help", the HTML version of the Python docs? Something=20 else? How do you use it from commandline Python? What happens if=20 you try to do the same in MacPython? Which version of Python? -- - Jack Jansen =20 http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution --=20 Emma Goldman - From Robin.Siebler@palmsource.com Thu Aug 22 21:57:18 2002 From: Robin.Siebler@palmsource.com (Robin Siebler) Date: Thu, 22 Aug 2002 13:57:18 -0700 Subject: [Pythonmac-SIG] Using the HTML help? Message-ID: <3271DBB88437ED41A0AB239E6C2554A43EF868@ussunm001.palmsource.com> I guess I should also mention that you can use the help for anything = that has a doc string: >>> import logging >>> help(logging.getLevelName) Help on function getLevelName in module logging: ... -----Original Message----- From: Robin Siebler=20 Sent: Thursday, August 22, 2002 1:50 PM To: Jack Jansen Cc: pythonmac-sig@python.org Subject: RE: [Pythonmac-SIG] Using the HTML help? If you download the HTML docs from python.org and set an environmental = variable PYTHONDOCS to the locations of the HTML docs, you can get help = in the interactive window. For instance typing help('for') would give = you help on the FOR command. All of this is mentioned in the Python = docs. However, there doesn't appear to be the equivalent of an = environmental variable for MacPython. There should be a setting for = this in EditPythonPrefs. -----Original Message----- From: Jack Jansen [mailto:Jack.Jansen@oratrix.com] Sent: Thursday, August 22, 2002 1:44 PM To: Robin Siebler Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Using the HTML help? On donderdag, augustus 22, 2002, at 12:22 , Robin Siebler wrote: > I installed the HTML help so that I could use it in the=20 > interactive window. For the command-line version of Python,=20 > this works fine. However, it doesn't work for MacPython. What=20 > do I have to do to get this to work? Robin, you've lost me here, or probably you know something about a new=20 exciting Python feature that I'm not aware of. What do you mean=20 by "HTML help", the HTML version of the Python docs? Something=20 else? How do you use it from commandline Python? What happens if=20 you try to do the same in MacPython? Which version of Python? -- - Jack Jansen =20 http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution --=20 Emma Goldman - _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From sint@oeaw.ac.at Fri Aug 23 14:24:14 2002 From: sint@oeaw.ac.at (Peter Paul Sint) Date: Fri, 23 Aug 2002 15:24:14 +0200 Subject: [Pythonmac-SIG] Umlaut/nonASCII in python2.2.1 from fink Message-ID: Installed python2.2.1 from fink on MacOS10.1.5 http://fink.sourceforge.net/pdb/package.php/python Unix terminals do not allow entering Umlauts/non-ascii xu=3D"=E4=F6=FC=DF" # "Umlaut a, umlaut o, umlaut u, unvoiced s" In a script I can write x=3D"abcd" print x xu=3Du"=E4=F6=FC=DF" xu =3Dxu.encode("latin-1") print xu In Terminal this results in psint% python scriptpython.py abcd ???? % However, python scriptpython.py > newfile.txt results in a file with readable non-ascii (as long as Latin-1). This is a solution, although non interactively. Obviously there are two IDE solutions which may solve the problem http://www.cwi.nl/~jack/macpython.html Do they? As I assume you need to download a separate python for this. I am not= especially keen to remove the existing fink-python or to install a second o= ne. Is there a simple solution with the line-interface python automating the= editor to pyton to editor process. XDarwin+WindowMaker is installed but I= have no experience with it. Does emacs support umlauts/non-ascii (I guess= it could be used to support the transfer but I know near to nothing about= its advanced features to achieve this). There seems to be a similar solution for TeX (tetex) and BBEdit http://www.kiffe.com/textools.html or http://www.cs.man.ac.uk/~franconi/mac-emacs/ . There is a Python FAQ entry (4.01.) http://www.python.org/cgi-bin/faqw.py?req=3Dshow&file=3Dfaq04.102.htp which may hint to a more direct solution avoiding Latin-1 but I am not yet= quite sure how. (This does not change terminal but maybe output to files?) Peter From Benjamin.Schollnick@usa.xerox.com Fri Aug 23 15:35:42 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 23 Aug 2002 10:35:42 -0400 Subject: [Pythonmac-SIG] AppleEvent examples Message-ID: Folks, I'm running v2.21 right now, and I can't seem to import OSAm into my python scripts... I've placed copies of the slb files in to the extension folder, and that hasn't changed anything... Is there something beyond that, that I would need to do? - Benjamin -----Original Message----- From: Jack Jansen [mailto:Jack.Jansen@oratrix.com] Sent: Wednesday, August 14, 2002 3:22 PM To: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] AppleEvent examples On woensdag, augustus 14, 2002, at 01:44 , Schollnick, Benjamin wrote: > | For really simple AppleScripting stuff, the OSAm module in > | :Mac:Contrib: is very handy since you can take ordinary AppleScript > | source and pass it to CompileAndExecute. > > You can do this already?!?!?!? > > I admit I didn't look into the OSAm module... (Or at least I don't > remember doing so) > > But this defintely needs to be documented!!! I've been kind of looking > into doing something like this....... I've never really tried to use the OSAm module, but as people are so enthusiastic about it: should I include it in the standard set of modules in stead of in Contrib? How complete is it? Anyone willing to write documentation? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From lists@netelligent.biz Fri Aug 23 15:41:54 2002 From: lists@netelligent.biz (tmk) Date: Fri, 23 Aug 2002 16:41:54 +0200 Subject: [Pythonmac-SIG] Re: Which installer to use for MacPython-OSX? In-Reply-To: <43AB648C-B60F-11D6-9035-003065517236@oratrix.com> Message-ID: <77D6442C-B6A6-11D6-8CB9-000393A49442@netelligent.biz> Yo, I seem to remember that the great folks at OmniGroup had devised a mechanism where an app embeds all related stuff *including* its framework (meaning you don't need to install the framework in one of the three usual domains). E.g. OmniWeb is packaged with all the frameworks within OmniWeb.app. That way one can be sure that the app will work regardless of where it's installed but, OTOH, other apps can *NOT* easily leverage the already installed "private" frameworks. For a tool such as python this is definitely a HUGE inconvenience so I'm no advocating this configuration except perhaps as a special optional packaging of Python on Mac OS X. I'd vote for an install that puts the library under either of the three regular locations and the apps wherever the user wants to put them. Just my 0,02 euros. = tmk = On Thursday, August 22, 2002, at 10:39 PM, Jack Jansen wrote: > > On woensdag, augustus 21, 2002, at 11:30 , bill fancher wrote: >>> I think Rudo meant this as a requirement for a true Mac software, >>> not as a description of the current state of MacPython >>> >>> This is a requirement from the Aqua Human Interface Guidelines >>> (page 246) >>> : >>> >>> Always let users choose a specific folder (or the Desktop) as the >>> installation >>> >>> destination. Don't require your application to be installed in a >>> particular >>> >>> location. >> >> You're right about isolated applications, but we're talking about >> installing several applications, a framework, and various other >> bits. The main issue here is the framework. Frameworks are not as >> relocatable as applications. They generally need to live in >> certain "well-known" locations to work. > > ... but still, Rudo and Martina have a point. It would be nice if > we could set things up in such a way that people can install into > any location and have it work from there. Not only would it allow > people to install Python in, say, Desktop Folder, because they > want to try it out before committing, but it would also allow you > to carry a fully functional Python installation with you on > removable media such as a CDROM or solidstate usb disk. > > The DYLD_FRAMEWORK_PATH might point to a solution for this, but > can we exploit it? Is there a way in which we could modify the > environment when the user double-clicks PythonIDE so that the > interpreter inside it will find Python.framework? Can we set > environment variables from the plist file, or something similar? > > Alternative idea: could we pull a trick with relative paths? the > interpreter is built with a relative path to the framework, if we > create a symlink Python.framework beside the interpreter deep > inside PythonIDE's app bundle, would that work? The installer > (probably the post-install script) would have to know that the > framework is installed in a place where it won't be found by the > normal framework search process and add the symlink. BuildApplet > would have to do the same. > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- > Emma Goldman - > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From mday@mac.com Fri Aug 23 18:36:34 2002 From: mday@mac.com (Mark Day) Date: Fri, 23 Aug 2002 10:36:34 -0700 Subject: [Pythonmac-SIG] AppleEvent examples In-Reply-To: Message-ID: On Friday, August 23, 2002, at 07:35 AM, Schollnick, Benjamin wrote: > I'm running v2.21 right now, and I can't seem to import OSAm > into my python scripts... I've placed copies of the slb files in > to the extension folder, and that hasn't changed anything... > > Is there something beyond that, that I would need to do? I copy OSAm.carbon.slb (for Carbon MacPython) or OSAm.ppc.slb (for non-Carbon MacPython) in the :Lib:site-packages: folder inside the MacPython folder. Then just "import OSAm". I imagine OSAm would have to be rebuilt if you're using one of the Unix command line variants of Python (eg., from Fink, or compiling the Unix sources from the Python web site). -Mark From Jack.Jansen@oratrix.com Fri Aug 23 20:52:41 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 23 Aug 2002 21:52:41 +0200 Subject: [Pythonmac-SIG] Re: Which installer to use for MacPython-OSX? In-Reply-To: <77D6442C-B6A6-11D6-8CB9-000393A49442@netelligent.biz> Message-ID: On vrijdag, augustus 23, 2002, at 04:41 , tmk wrote: > Yo, > > I seem to remember that the great folks at OmniGroup had > devised a mechanism where an app embeds all related stuff > *including* its framework (meaning you don't need to install > the framework in one of the three usual domains). > > E.g. OmniWeb is packaged with all the frameworks within OmniWeb.app. > > That way one can be sure that the app will work regardless of > where it's installed but, OTOH, other apps can *NOT* easily > leverage the already installed "private" frameworks. > > For a tool such as python this is definitely a HUGE > inconvenience so I'm no advocating this configuration except > perhaps as a special optional packaging of Python on Mac OS X. The Omni tools indeed don't share their frameworks. If you check in two or more of their tools you'll see a lot of duplication. Not good for Python, especially with the applets:-( And I've rather a high opinion of the Omni folks, so if they're not sharing their frameworks I think there's probably a good reason for it... In a private discussion Rudo suggested I look at the SharedFrameworks, but I haven't been able to find anything that actually uses it, and the documentation I've seen is very vague (only listing it as a possibility, without explanation for how it would work). Does anyone have any experience with this? Does it actually work, or is it a vaporware feature like the role=shell plist value? Would it be suitable for Python given the fact that we need to cater for the interpreter, the IDE, applets and embedding applications (and non-applications, like the OSA component)? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bfancher@mac.com Fri Aug 23 21:20:20 2002 From: bfancher@mac.com (bill fancher) Date: Fri, 23 Aug 2002 13:20:20 -0700 Subject: [Pythonmac-SIG] Re: Which installer to use for MacPython-OSX? In-Reply-To: <43AB648C-B60F-11D6-9035-003065517236@oratrix.com> Message-ID: On Thursday, August 22, 2002, at 01:39 PM, Jack Jansen wrote: > > On woensdag, augustus 21, 2002, at 11:30 , bill fancher wrote: >>> I think Rudo meant this as a requirement for a true Mac software, not >>> as a description of the current state of MacPython >>> >>> This is a requirement from the Aqua Human Interface Guidelines (page >>> 246) >>> : >>> >>> Always let users choose a specific folder (or the Desktop) as the >>> installation >>> >>> destination. Don't require your application to be installed in a >>> particular >>> >>> location. >> >> You're right about isolated applications, but we're talking about >> installing several applications, a framework, and various other bits. >> The main issue here is the framework. Frameworks are not as relocatable >> as applications. They generally need to live in certain "well-known" >> locations to work. > > ... but still, Rudo and Martina have a point. It would be nice if we > could set things up in such a way that people can install into any > location and have it work from there. I wish I could install Apple's Developer Tools to a different partition. > Not only would it allow people to install Python in, say, Desktop Folder, > because they want to try it out before committing, And I wish I could do THAT with the new Jaguar Developer Tools. Seriously, though, this is the KIND of thing I had in mind when I said that it might make sense to allow installation to "non-standard" locations. I wouldn't go so far as to advocate coding things specifically in the apps or installer scripts to support it. > but it would also allow you to carry a fully functional Python > installation with you on removable media such as a CDROM or solidstate > usb disk. Ah, there's the example I was looking for. You can (should be able to?) do that now. In sh, just do: prefix=/Volumes/yourCD/Library/Frameworks/Python.framework/Versions/2.X make make frameworkinstall Then set your PATH (if you use command-line stuff), and DYLD_FRAMEWORK_PATH (or DYLD_FALLBACK_FRAMEWORK_PATH). You could do that in a shell and launch stuff from there or make a nice ~/.MacOS/environment. plist and double-click the apps. But see below about DYLD_FRAMEWORK_PATH. One thing to ponder is what such an "installation" looks like. I believe people will be unpleasantly surprised. If we install to /tmp, e.g., we end up with stuff in /tmp/Applications/Python, tmp/Library/Frameworks/Python.framework and, maybe, /tmp/usr/local/bin. I'd rather see an un-install package for the shoppers. That would be generally useful as well. And I'd let people who want to carry an installation around deal with their own environments. Providing some details on how to do that down near the bottom of "Welcome.txt" might be desirable. > The DYLD_FRAMEWORK_PATH might point to a solution for this, but can we > exploit it? Is there a way in which we could modify the environment when > the user double-clicks PythonIDE so that the interpreter inside it will > find Python.framework? Can we set environment variables from the plist > file, or something similar? AFAIK, info.plist files are only used by other apps, and the "info" in an info.plist is not conveyed by startup code to the app whose info.plist it is. I don't think any user code gets called before libraries are loaded so setting DYLD_FRAMEWORK_PATH would have to be done, e.g., in some process that modifies the environment and then execs the REAL app. But how would THAT code know where to find the framework? (You could also create or modify ~/.MacOS/environment.plist during installation, and have people log out/in so that it would get read. But that stops working if the framework is moved, and is probably rude to begin with. Nor does it help the person who installs to a CD and wants to run Python on another machine.) The other thing to note here is that DYLD_FRAMEWORK_PATH is (at least in my reading of the docs) more of a special purpose tool than a variable intended for general use. It doesn't, e.g., get transfered with the rest of the environment to processes run by sudo, so Python would fail to run in such circumstances. From "man dyld": "DYLD_FRAMEWORK_PATH This is a colon separated list of directories that contain frameworks. The dynamic linker searches these directories before it searches for the framework by its install name. It allows you to test new versions of existing frameworks." DYLD_FRAMEWORK_PATH is also useful for things like building Python, where you need to use a framework that isn't yet installed in one of the "usual places". DYLD_FALLBACK_FRAMEWORK_PATH would probably be better, but I'm not convinced solutions involving either one are a good idea. > Alternative idea: could we pull a trick with relative paths? the > interpreter is built with a relative path to the framework, if we create > a symlink Python.framework beside the interpreter deep inside PythonIDE's > app bundle, would that work? The installer (probably the post-install > script) would have to know that the framework is installed in a place > where it won't be found by the normal framework search process and add > the symlink. BuildApplet would have to do the same. It might work until the path to the framework changes. Worst case: the shopper decides Python is nice and "finishes" the installation by dragging apps to ~/Applications and dragging the apparently useless Python.framework to the trash (or any other non-standard location). To sloganize a bit: Tell us what works in the Welcome screen. Let us install where we like (like good "conservatives", we'll "take personal responsibility for our actions"). If you want to be REALLY nice, provide an uninstall package, so we can change our minds, and some tips on making things work with "non-standard" installation locations. No tricks needed. Minimal labor. (We might also consider tmk's suggestion about an optional self-contained app.) -- bill From Jack.Jansen@oratrix.com Fri Aug 23 21:22:21 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 23 Aug 2002 22:22:21 +0200 Subject: [Pythonmac-SIG] Private frameworks - BINGO! Message-ID: <0741907C-B6D6-11D6-B228-003065517236@oratrix.com> Just after sending my previous mail I though I'd have a look at how OmniGraffle links to its frameworks (by using "otool -l"), and it uses the "@executable_path/../Frameworks/" construct we've discussed here before. Feeling adventurous I decided to first move one of its frameworks off into the void. As expected it didn't start. Then I moved that framework into /Library/Frameworks and, lo and behold, everything works!! So, this may point us to a way to have our cake and eat it too. Some problems remain, though. I think that building everything with the @executable_path would work equally well as what we currently have *if you install the framework in one of the standard locations*. It will also immediately solve the BuildApplication problem: in that case we will copy selected parts of the normal Python framework into a private framework in the output application. Unfortunately it doesn't necessarily solve the problem we're looking at: installing the whole bunch in a random location. The reason is that we have a number of programs that refer to the framework: PythonIDE.app, PythonLauncher.app (although it currently has a hardcoded path it could link against the framework, even if only to obtain it's pathname) and the hidden Python.app. And then there's the python commandline tool, also hidden inside the framework at the moment. We could solve this be sprinkling symlinks all over the place, but I'm not sure I like that.... Hmm, maybe it isn't such a good idea after all. But feel free to ponder about it and come up with nifty solutions.... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mday@mac.com Fri Aug 23 21:58:21 2002 From: mday@mac.com (Mark Day) Date: Fri, 23 Aug 2002 13:58:21 -0700 Subject: [Pythonmac-SIG] Private frameworks - BINGO! In-Reply-To: <0741907C-B6D6-11D6-B228-003065517236@oratrix.com> Message-ID: <0E909014-B6DB-11D6-9456-00039354009A@mac.com> On Friday, August 23, 2002, at 01:22 PM, Jack Jansen wrote: > Just after sending my previous mail I though I'd have a look at how > OmniGraffle links to its frameworks (by using "otool -l"), and it uses > the "@executable_path/../Frameworks/" construct we've discussed here > before. I wonder if you could make the frameworks be a peer of the top-level applications, and put enough "../"s in the the above path? So, a tree looking like: Python 2.3/ Python 2.3/Frameworks/ ... Python 2.3/PythonIDE.app/ ... Presumably, the user could move the whole Python 2.3 folder around, but can't move the items inside the folder unless the frameworks were in one of the standard locations. But when would you move/copy the frameworks to one of the standard locations? Via some menu item in the interpretter or IDE? Ask them on first launch if they're "just trying it out" or "I'm hooked; keep it around for me" (probably too annoying)? > We could solve this be sprinkling symlinks all over the place, but I'm > not sure I like that.... Not all volume formats support symlinks. For example, they couldn't copy to their iDisk on WebDAV, or DOS FAT, or SMB. But then again, don't packages currently require symlinks (eg., for the "Current" version to point to the actual version that is current). Sigh. > Hmm, maybe it isn't such a good idea after all. But feel free to > ponder about it and come up with nifty solutions.... Could there be a runnable version of the apps on a disk image? They could try it out by running from the disk image. Could it then be installed without needing yet another copy of the image? I suppose once the user has copied the application to a writable volume, you could just move the frameworks to a standard spot automatically. -Mark From bob@redivi.com Fri Aug 23 22:07:02 2002 From: bob@redivi.com (Bob Ippolito) Date: Fri, 23 Aug 2002 17:07:02 -0400 Subject: [Pythonmac-SIG] Private frameworks - BINGO! In-Reply-To: <0741907C-B6D6-11D6-B228-003065517236@oratrix.com> Message-ID: <45350A04-B6DC-11D6-A3FB-0003938210D6@redivi.com> There's also the scary yet possible alternative to have a launcher stub that finds all of the frameworks wherever they may be (possibly via an HFS-alias type system which survives so long as it doesn't move from one volume to another) and mangles the DYLD_* environment variables accordingly before it launches python. -bob On Friday, August 23, 2002, at 04:22 PM, Jack Jansen wrote: > Just after sending my previous mail I though I'd have a look at how > OmniGraffle links to its frameworks (by using "otool -l"), and it uses > the "@executable_path/../Frameworks/" construct we've discussed here > before. > > Feeling adventurous I decided to first move one of its frameworks off > into the void. As expected it didn't start. Then I moved that framework > into /Library/Frameworks and, lo and behold, everything works!! So, > this may point us to a way to have our cake and eat it too. > > Some problems remain, though. I think that building everything with > the @executable_path would work equally well as what we currently have > *if you install the framework in one of the standard locations*. It > will also immediately solve the BuildApplication problem: in that case > we will copy selected parts of the normal Python framework into a > private framework in the output application. > > Unfortunately it doesn't necessarily solve the problem we're looking > at: installing the whole bunch in a random location. The reason is that > we have a number of programs that refer to the framework: > PythonIDE.app, PythonLauncher.app (although it currently has a > hardcoded path it could link against the framework, even if only to > obtain it's pathname) and the hidden Python.app. And then there's the > python commandline tool, also hidden inside the framework at the moment. > > We could solve this be sprinkling symlinks all over the place, but I'm > not sure I like that.... > > Hmm, maybe it isn't such a good idea after all. But feel free to ponder > about it and come up with nifty solutions.... From tony@lownds.com Fri Aug 23 22:16:07 2002 From: tony@lownds.com (Tony Lownds) Date: Fri, 23 Aug 2002 14:16:07 -0700 Subject: [Pythonmac-SIG] Private frameworks - BINGO! In-Reply-To: <0741907C-B6D6-11D6-B228-003065517236@oratrix.com> References: <0741907C-B6D6-11D6-B228-003065517236@oratrix.com> Message-ID: >Unfortunately it doesn't necessarily solve the problem we're looking >at: installing the whole bunch in a random location. The reason is >that we have a number of programs that refer to the framework: >PythonIDE.app, PythonLauncher.app (although it currently has a >hardcoded path it could link against the framework, even if only to >obtain it's pathname) and the hidden Python.app. And then there's >the python commandline tool, also hidden inside the framework at the >moment. The shared modules in lib-dynload also refer back to the framework. When trying things out do an "import array"... >We could solve this be sprinkling symlinks all over the place, but >I'm not sure I like that.... Maybe a small launcher program could find the Python.app bundle - perhaps using CFBundleGetBundleWithIdentifier("org.python.Python") - then augment DYLD_FRAMEWORK_PATH and finally exec the Python executable in the Python.app bundle. Here is perhaps another reason to try to make something like this work: when I upgraded to Jaguar, it cleared out the /Library/Frameworks directory and Python.framework was "archived" in /Previous Systems I see Bob already posted something about DYLD_FRAMEWORK_PATH :) -Tony From Jack.Jansen@oratrix.com Sat Aug 24 00:25:39 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 24 Aug 2002 01:25:39 +0200 Subject: [Pythonmac-SIG] Private frameworks - BINGO! In-Reply-To: Message-ID: On vrijdag, augustus 23, 2002, at 11:16 , Tony Lownds wrote: > The shared modules in lib-dynload also refer back to the > framework. When trying things out do an "import array"... Hmm, that could be showstopper... They refer back to the framework because you can't specify a framework as the bundle_loader (which is what I really wanted to do). Bummer... Unless someone has a real bright idea (and don't even think of suggesting we link extensions with a flat namespace:-) I think we have to live with the framework living in one of the standard locations. It is probably also the end of any aspirations at BuildApplication for OSX-Python. [thinks a while] That is: what would happen if the shared modules also referred to the framework with the @executable cookie? If by any chance the cookie would be replaced by the pathname of the *hosting* application (i.e. python) then it might still work... Anyone feels like trying this out? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bob@redivi.com Sat Aug 24 01:19:21 2002 From: bob@redivi.com (Bob Ippolito) Date: Fri, 23 Aug 2002 20:19:21 -0400 Subject: [Pythonmac-SIG] Private frameworks - BINGO! In-Reply-To: Message-ID: <22F894B4-B6F7-11D6-A3FB-0003938210D6@redivi.com> I don't think this is a showstopper at all... You have full control over all this stuff for post-startup dynamic linking.. It's trivial for python to stuff whatever it needs to stuff into DYLD_* environment variables when it's bootstrapping the interpreter.. python surely can figure out where its own framework is if it started up correctly. I really think this is a non-issue, you just have to make sure python itself starts, because we've already demonstrated that if the "otool path" is incorrect it'll search through the default framework paths (or, if documentation serves us correctly, whatever they're overrided with via the environment). -bob On Friday, August 23, 2002, at 07:25 PM, Jack Jansen wrote: > > On vrijdag, augustus 23, 2002, at 11:16 , Tony Lownds wrote: >> The shared modules in lib-dynload also refer back to the framework. >> When trying things out do an "import array"... > > Hmm, that could be showstopper... > > They refer back to the framework because you can't specify a framework > as the bundle_loader (which is what I really wanted to do). Bummer... > > Unless someone has a real bright idea (and don't even think of > suggesting we link extensions with a flat namespace:-) I think we have > to live with the framework living in one of the standard locations. It > is probably also the end of any aspirations at BuildApplication for > OSX-Python. > > [thinks a while] > That is: what would happen if the shared modules also referred to the > framework with the @executable cookie? If by any chance the cookie > would be replaced by the pathname of the *hosting* application (i.e. > python) then it might still work... > > Anyone feels like trying this out? From junkster@rochester.rr.com Sat Aug 24 13:34:13 2002 From: junkster@rochester.rr.com (Benjamin Schollnick) Date: Sat, 24 Aug 2002 08:34:13 -0400 Subject: [Pythonmac-SIG] Odd Problem w/Jaguar In-Reply-To: <22F894B4-B6F7-11D6-A3FB-0003938210D6@redivi.com> Message-ID: Jack & Everyone, I've run into a problem, but I'm not positive of the cause... I just finished install Jaguar... Well, I have MacPython (v2.21) installed on a different hard drive... So I attempted to run a python app from the Python Interpreter (Drag & Drop)... But it doesn't seem to work, the output window comes up, waits a second and goes to terminated... No tracebacks, etc. Has anyone else seen this? The file is *not* saved in a Unix or MS-DOS CR/LF format... I've checked in BBEDIT.... I've modified the program to write a simple text line out immediately, with no change... I believe this was happening before my Jaguar install, but I don't usually do development on this machine. Of note, if I do a buildapplication and manually select the Carbon core the resulting application will work.... - Benjamin From lists@netelligent.biz Sat Aug 24 18:50:03 2002 From: lists@netelligent.biz (tmk) Date: Sat, 24 Aug 2002 19:50:03 +0200 Subject: [Pythonmac-SIG] Private frameworks - BINGO! In-Reply-To: <0E909014-B6DB-11D6-9456-00039354009A@mac.com> Message-ID: Yo, On Friday, Aug 23, 2002, at 22:58 Europe/Brussels, Mark Day wrote: > On Friday, August 23, 2002, at 01:22 PM, Jack Jansen wrote: > >> Just after sending my previous mail I though I'd have a look at how >> OmniGraffle links to its frameworks (by using "otool -l"), and it >> uses the "@executable_path/../Frameworks/" construct we've discussed >> here before. > > I wonder if you could make the frameworks be a peer of the top-level > applications, and put enough "../"s in the the above path? So, a tree > looking like: > Python 2.3/ > Python 2.3/Frameworks/ > ... > Python 2.3/PythonIDE.app/ > ... > > Presumably, the user could move the whole Python 2.3 folder around, > but can't move the items inside the folder unless the frameworks were > in one of the standard locations. > > But when would you move/copy the frameworks to one of the standard > locations? Via some menu item in the interpretter or IDE? Ask them > on first launch if they're "just trying it out" or "I'm hooked; keep > it around for me" (probably too annoying)? I really like the idea though not the idea of having the frameworks visible they should be buried either under the app wrapper or the chosen Library domain. End user should not be able to easily fool around with frameworks. How about building everything like the Omni folks do ( with Python.app/Frameworks/...) Then the install becomes simple. At first the user has two options 1. "Test install". For testing purposes as a self-contained app with private frameworks. *BUT* the installer displays a message explaining how to make the install permanent (which should be doable easily ie via a simple command or menu option) 2. "Permanent install". Here we have 3 sub-options the installer would ask in what domain to install python (with the machine domain as the default) = tmk = From Jack.Jansen@oratrix.com Sat Aug 24 23:04:27 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 25 Aug 2002 00:04:27 +0200 Subject: [Pythonmac-SIG] Re: Odd Problem w/Jaguar In-Reply-To: Message-ID: <7558CEE8-B7AD-11D6-9A38-003065517236@oratrix.com> On zaterdag, augustus 24, 2002, at 02:34 , Benjamin Schollnick wrote: > Jack & Everyone, > > I've run into a problem, but I'm not positive of the cause... > > I just finished install Jaguar... > > Well, I have MacPython (v2.21) installed on a different > hard drive... > So I attempted to run a python app from the Python > Interpreter (Drag & > Drop)... > > But it doesn't seem to work, the output window comes up, > waits a second > and goes to terminated... No tracebacks, etc. Wild guess: the preferences have gone missing, or point to the wrong location. Try running ConfigurePythonCarbon again. You could also try option-starting the interpreter, turning on the verbose and inspect option, hope for a prompt and inspect sys.prefix and sys.path. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dan@grassi.org Sat Aug 24 23:31:29 2002 From: dan@grassi.org (Dan Grassi) Date: Sat, 24 Aug 2002 18:31:29 -0400 Subject: Fwd: [Pythonmac-SIG] Private frameworks - BINGO! Message-ID: <3BB2CED0-B7B1-11D6-ADEE-00039346A28A@grassi.org> On Friday, August 23, 2002, at 07:25 PM, Jack Jansen wrote: > I think we have to live with the framework living in one of the > standard locations. Keep in mind that Apple is installing Python with OS X. Thus other install locations will just install an _additional_ Python. With the versioning system present in frameworks multiple versions can be easily be installed already. Why do we wnat to confuse this standard behaviour? IMO we should just be updating the already present Python, not installing additional Pythons in various places, this will just create confusion. We should follow Apple's lead. Perhaps this is why Apple has created these restrictions on Frameworks. Dan From dan@grassi.org Mon Aug 26 02:02:57 2002 From: dan@grassi.org (Dan Grassi) Date: Sun, 25 Aug 2002 21:02:57 -0400 Subject: [Pythonmac-SIG] Private frameworks - BINGO! In-Reply-To: <7C8E28D8-B86B-11D6-9B3D-000393A49442@mac.com> Message-ID: <8F43D4E0-B88F-11D6-ADEE-00039346A28A@grassi.org> On Sunday, August 25, 2002, at 04:44 PM, tmk wrote: > On Sunday, Aug 25, 2002, at 22:00 Europe/Brussels, Dan Grassi wrote: > >> On Sunday, August 25, 2002, at 03:31 PM, tmk wrote: >> >>> In fact, I'd advocate that we rather leave Apple's install untouched >>> and provide our own, different. The main reason being that Apple may >>> upgrade its version at anytime and we don't want anything to break. >> >> Should Python be a special case, that is handled differently than >> perl, tcl, OpenSSH, OpenSSL, apache, ruby, php, etc? Consider what >> a mess if all these also followed the same method of installing >> separate versions. Following such a policy is little different than >> the old days when many applications installed SimpleText and there >> were so many copies and versions that it became a nightmare. >> Installing multiple versions of Python by default creates confusion on >> the part of the user. > > From what I see around the Web (e.g. Fink), people usually take great > care *NOT* to install stuff over Apple's. So the exception would be to > "update" Apple's installation :-). From what I've seen the Fink phylosphy has created problems even for building Python. Other than Fink installations do indeed install into the Apple standard locations. It is also unix/Linux phylosphy to install into the standard locations. > I would not be surprised if there were Apple guidelines to that effect > (especially because in most case, it's totally easy stuff without > touching Apple's stuff e.g. look at what Fink does) IMO it is a mistake to take Fink's phylosphy as the gold standard, they are not Apple. > There's a reason for the current layout of the filesystem both from > Apple and from the Unix side of things. Separation of responsibility. Yes, the unix (BSD) side of thinks are in the Darwin cvs and that includes Python. >> >> Let's say that we install a new version of Python and then Apple in >> their stupidity updates their version to an older version and updates >> symlinks in /usr/local/bin, etc. Now the user gets Apple's version >> anyway. Further if the user may well execute different version of >> Python based on _how_ it is called. This should _not_ be the default >> case. > > First the problem is not that Apple would do stupid things. For example > you could have a tuned version of Python with additionnal modules. > You'd rather install it under /usr/local/ instead of replacing Apple's. While this can be done it is not the usual install and should not be considered as a default. Anyone wanting to do this should be on their own in the same manner that putting Apache in a non-standard location is possible but not a default. > It's only normal that when Apple upgrades they only upgrade their > version and leave yours untouched. >> There is a versioning system in place in frameworks that allows >> multiple versions for those who are astute enough and handles the >> default case for the average user as well. > > Well, you could have a tuned version of python with additional modules > but with the same version. They're different but have the same version > number. The versioning does not handle this case (neither does it > handle minor point releases IIRC) There is an implicit assumption that Apple will _remove_ things, why should we assume this? >> IMO we should not fight Apple, not assume that Apple is going to do >> the stupid thing and we must follow the path best suited to the base >> user, that is run programs developed by others. > > I agree. But than again what you advocate goes contrary to this > philosophy. Don't you think that "fighting Apple" would be installing > over their version? No, fighting Apple, IMO, is for all the various package maintainers to make their individual idiosyncratic decisions, this is exactly what the problem that Linux Standard is addressing. With such a situation one would not see any consistancy and it would make things more difficult. >> KISS > > Exactly. Suppose two different providers each install their own version > of python over Apple's, or your own fine tuned one, would you be happy? If I do the install yes. Consider Perl, I don't want to write programs in it but I do have Perl programs that I use -- the last thing I want is even more confusion about using Perl. KISS -- put it where people expect it. Dan From footrot@mac.com Mon Aug 26 23:13:35 2002 From: footrot@mac.com (Matthew Smith) Date: Tue, 27 Aug 2002 08:13:35 +1000 Subject: [Pythonmac-SIG] 10.2 and python Message-ID: If someone doesn't mind helping me clarify this... It seems python comes installed with 10.2, but not the python framework. To embed a python app using 10.2 I'd need to install the python framework?? What about running the framework on a 10.2 machine? Thanks Matt Sorry about the cross-post but I want to here both groups ideas/responses From stephenm@humongous.com Tue Aug 27 01:55:38 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Mon, 26 Aug 2002 17:55:38 -0700 Subject: [Pythonmac-SIG] problem with EditPythonPrefs Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE806@sea-horse.humongous.com> I am trying to run EditPythonPrefs and get the following error. Traceback (most recent call last): File "Mac OS X:Applications:Python 2.2.1:Mac:scripts:EditPythonPrefs.py", line 212, in ? main() File "Mac OS X:Applications:Python 2.2.1:Mac:scripts:EditPythonPrefs.py", line 205, in main edit_preferences() File "Mac OS X:Applications:Python 2.2.1:Mac:scripts:EditPythonPrefs.py", line 187, in edit_preferences options = handler.load() File "Mac OS X:Applications:Python 2.2.1:Mac:Lib:pythonprefs.py", line 83, in load dict['creator'], dict['type'] = self.gusi.load() File "Mac OS X:Applications:Python 2.2.1:Mac:Lib:pythonprefs.py", line 40, in load self.data = self.loader.load() File "Mac OS X:Applications:Python 2.2.1:Mac:Lib:preferences.py", line 57, in load self.data = self.default.load() File "Mac OS X:Applications:Python 2.2.1:Mac:Lib:preferences.py", line 119, in load self.data = self.default.load() File "Mac OS X:Applications:Python 2.2.1:Mac:Lib:preferences.py", line 21, in load raise Error, "No default given" Preferences.Error: No default given Can someone tell me what is going wrong? I am able to run ConfigurePythonCarbon, but after that EditPythonPrefs fails. Thanks, Stephen Magladry From smithsm@samuelsmith.org Tue Aug 27 06:31:53 2002 From: smithsm@samuelsmith.org (Samuel Smith) Date: Mon, 26 Aug 2002 23:31:53 -0600 Subject: [Pythonmac-SIG] Which version of Python comes preinstalled with 10.2? In-Reply-To: Message-ID: <4B4EF4DA-B97E-11D6-900A-00039346A274@samuelsmith.org> Which version of python comes preinstalled with 10.2. MachO or Unix? ********************************************************************** Samuel M. Smith Ph.D. 360 W. 920 N. Orem, Utah 84057 801-226-7607 x112 (voice) 801-226-7608 (fax) ********************************************************************** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ********************************************************************** From dkwolfe@pacbell.net Tue Aug 27 06:53:07 2002 From: dkwolfe@pacbell.net (Dan Wolfe) Date: Mon, 26 Aug 2002 22:53:07 -0700 Subject: [Pythonmac-SIG] Which version of Python comes preinstalled with 10.2? In-Reply-To: <4B4EF4DA-B97E-11D6-900A-00039346A274@samuelsmith.org> Message-ID: <426DD154-B981-11D6-AF9B-003065ABC53C@pacbell.net> Version 2.2, Unix - Dan On Monday, August 26, 2002, at 10:31 PM, Samuel Smith wrote: > Which version of python comes preinstalled with 10.2. MachO or Unix? From mps@utas.edu.au Tue Aug 27 06:56:52 2002 From: mps@utas.edu.au (Matthew Smith) Date: Tue, 27 Aug 2002 15:56:52 +1000 Subject: [Pythonmac-SIG] Which version of Python comes preinstalled with 10.2? In-Reply-To: <426DD154-B981-11D6-AF9B-003065ABC53C@pacbell.net> Message-ID: That means no framework? I suppose I'll need to compile it regardless for 10.2 if I want to embed in my app (see my earlier question) Cheers Matt On Tuesday, August 27, 2002, at 03:53 PM, Dan Wolfe wrote: > Version 2.2, Unix > > - Dan > > On Monday, August 26, 2002, at 10:31 PM, Samuel Smith wrote: > >> Which version of python comes preinstalled with 10.2. MachO or Unix? > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From dinu@mac.com Tue Aug 27 07:33:34 2002 From: dinu@mac.com (Dinu Gherman) Date: Tue, 27 Aug 2002 08:33:34 +0200 Subject: [Pythonmac-SIG] Which version of Python comes preinstalled with 10.2? In-Reply-To: Message-ID: Matthew Smith: > That means no framework? That's what it means: no framework. > I suppose I'll need to compile it regardless for 10.2 if I want to > embed in my app (see my earlier question) That depends on how you want to use it. I have apps which simply call the external Unix-built interpreter. It would really be nice to learn who is responsible at Apple for "maintaining" Python... Dinu From Benjamin.Schollnick@usa.xerox.com Tue Aug 27 13:42:14 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Tue, 27 Aug 2002 08:42:14 -0400 Subject: [Pythonmac-SIG] Which version of Python comes preinstalled wi th 10.2? Message-ID: >From what I see....I believe it's the straight Unix version... - Benjamin -----Original Message----- From: Samuel Smith [mailto:smithsm@samuelsmith.org] Sent: Tuesday, August 27, 2002 1:32 AM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] Which version of Python comes preinstalled with 10.2? Which version of python comes preinstalled with 10.2. MachO or Unix? ********************************************************************** Samuel M. Smith Ph.D. 360 W. 920 N. Orem, Utah 84057 801-226-7607 x112 (voice) 801-226-7608 (fax) ********************************************************************** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ********************************************************************** _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From gherman@darwin.in-berlin.de Tue Aug 27 21:58:47 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Tue, 27 Aug 2002 22:58:47 +0200 (CEST) Subject: [Pythonmac-SIG] Script for building OS X disk image archives (.dmg) Message-ID: <1030481927.3d6be80729193@webmail.in-berlin.de> Hi, I've started to understand a little bit more about how to generate .dmg archives on OS X. So I coded this into a simple script which is very much beta, but some of you might want to test and/or improve that. It's currently here: http://python.net/~gherman/projects/buildpkg/builddmg.dmg This is a 72 KB file generated with builddmg.py contained inside. ;-) I'm not sure yet if it should merge one day with my other script named buildpkg or not... Eventually all this should go into distutils, but that hasn't reached a state where I could understand how to extend it. ;-) Feedback is welcome, especially on how to use the "really" needed maximum archive size in blocks and on how to get rid off the nasty messages by hdiutil. Regards, Dinu From Jack.Jansen@oratrix.com Wed Aug 28 22:41:15 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 28 Aug 2002 23:41:15 +0200 Subject: [Pythonmac-SIG] Need help debugging Python documentation install Message-ID: Folks, I just checked in a couple of things that allow you to create a version of the Python documentation that is viewable from Apple Help Viewer and Project Builder. Special thanks go to Bill Fancher, who created the script to make this all work. Now, however, I need to debug the way I'm installing the documentation, and I can't do that myself, because it seems that once you've told Apple help Viewer about a documentation set there is absolutely no way to make it forget that documentation again, so my system is tainted. Here's the setup of things: - There's a script Mac/OSX/setupDocs.py. Call "python setupDocs.py build" to build the documentation, wait until the Help indexing tool is done, then call "python setupDocs.py install". For the moment, for testing purposes, this will install the 2.2.1 documentation. The script should only be used with a framework Python, and it will install the docs in the framework (in Resources/English.lproj/Documentation). - This is good enough for Project Builder (although the documentation does not show up in the help window it is viewable if you add Python.framework to your project and then open the reveal triangle of Python.framework). It isn't good enough for Help Viewer, though, it wants the documentation to be referred to from a .app bundle. For this reason Python.app contains the magic words in its Info.plist file, and has a symlink Resources/English.lproj/Documentation that points to the location above. Now, all this may be good enough, and it may not be, and I can't test it anymore. If someone could do the following: - cvs update - make frameworkinstall - python setupDocs.py build - python setupDocs.py install - Run a script with Python.app, something that stays open for a while so you can see the menu bar. Something like import EasyDialogs EasyDialogs.Message("Hello World") should do the trick. - Check whether there's a help menu, and whether the "Python Help" entry will open the Python docs in help viewer. - Open Help Viewer manually and check whether the Python documentation is mentioned in the index page. - Report your findings back here. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From jwblist@olympus.net Wed Aug 28 23:12:31 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 28 Aug 2002 15:12:31 -0700 Subject: [Pythonmac-SIG] Need help debugging Python documentation install In-Reply-To: References: Message-ID: At 23:41 +0200 8/28/2002, Jack Jansen wrote: >Now, however, I need to debug the way I'm installing the >documentation, and I can't do that myself, because it seems that >once you've told Apple help Viewer about a documentation set >there is absolutely no way to make it forget that documentation >again, so my system is tainted. Are you saying that removing, for example, com.apple.iChat iChatHelp file://localhost/Applications/iChat.app/Contents/Resources/English.lproj/iChatHelp/ (that file URL is wrapped...it aligns with the line above) from ~/Library/Preferences/com.apple.help.plist isn't sufficient? Or creating a fresh user? (I didn't notice anything related to Help Viewer in /Library/Preferences...there are a couple of other per-user help-related preferences which didn't look promising...one keeps the prior language, the other seems tied up with the recent items stuff. -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From paul@fxtech.com Thu Aug 29 14:31:39 2002 From: paul@fxtech.com (Paul Miller) Date: Thu, 29 Aug 2002 08:31:39 -0500 Subject: [Pythonmac-SIG] Install issue on Mac OS 10.2 In-Reply-To: Message-ID: <5.1.0.14.2.20020829083033.041e3a98@cedar.he.net> the installer seems to work fine on a 10.2 machine with no previous version installed. When you run the ConfigurePythonCarbon (which is described in the docs/readme, and which fixes some odd configuration issues for people), it opens a window whose title bar says "<>" with a blinking cursor in the window. I can't tell whether it finished or not, so i just quit it. i couldn't find anything on the macpython page or on google about why this window appears. have you ever seen this window? -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From mesveldt@slc.edu Thu Aug 29 15:56:21 2002 From: mesveldt@slc.edu (Michael Esveldt) Date: Thu, 29 Aug 2002 10:56:21 -0400 Subject: [Pythonmac-SIG] Testing MachoPython Message-ID: <7B52BC16-BB5F-11D6-A4F9-00039315F436@slc.edu> This is a fairly basic question, but its answer might be of some small use to MacPython: How safe is it to perform test builds? I follow the list closely and, in the interest of a working MachoPython, I frequently would like to help perform some of the basic tests that are requested by Jack and others. I'm a little wary, however, because this is all very new stuff. I have an existing installation of python by fink, will I still be able to use that if I install MacPython from CVS? Will installing a test version cause problems when a neatly packaged installation eventually comes along? I do some fairly silly things with this box, considering it's my work computer, but what can I say? I'm a reckless student. (Apparently not quite /that/ reckless.) Thanks, Michael Hail Eris. Michael Esveldt Sarah Lawrence College, Bronxville, NY, USA http://raptor.slc.edu/~dante / http://extraneous.livejournal.com/ From tony@lownds.com Thu Aug 29 17:10:58 2002 From: tony@lownds.com (Tony Lownds) Date: Thu, 29 Aug 2002 09:10:58 -0700 Subject: [Pythonmac-SIG] Need help debugging Python documentation install In-Reply-To: References: Message-ID: >- cvs update >- make frameworkinstall This step failed for me; the error I get is below. This bug may be manifesting itself because I build in a separate tree from the source. I did remove the existing /Library/Frameworks/Python.framework and /Applications/Python/ first. -Tony /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/python ../python/dist/src/Mac/scripts/BuildApplet.py \ --output /Library/Frameworks/../../Applications/Python/BuildApplet.app \ ../python/dist/src/Mac/scripts/BuildApplet.py Traceback (most recent call last): File "../python/dist/src/Mac/scripts/BuildApplet.py", line 127, in ? main() File "../python/dist/src/Mac/scripts/BuildApplet.py", line 22, in main buildapplet() File "../python/dist/src/Mac/scripts/BuildApplet.py", line 94, in buildapplet rsrcname=rsrcfilename, others=extras, raw=raw, progress=verbose) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/buildtools.py", line 119, in process copy_codefragment, raw, others) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/buildtools.py", line 144, in process_common is_update, raw, others) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/buildtools.py", line 300, in process_common_macho copyapptree(template, destname, exceptlist, progress) File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/buildtools.py", line 521, in copyapptree shutil.copy2(srcpath, dstpath) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/shutil.py", line 73, in copy2 copyfile(src, dst) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/shutil.py", line 28, in copyfile fsrc = open(src, 'rb') IOError: [Errno 2] No such file or directory: '/Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/Resources/English.lproj/Documentation' From Jack.Jansen@oratrix.com Thu Aug 29 21:12:38 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 29 Aug 2002 22:12:38 +0200 Subject: [Pythonmac-SIG] Testing MachoPython In-Reply-To: <7B52BC16-BB5F-11D6-A4F9-00039315F436@slc.edu> Message-ID: On donderdag, augustus 29, 2002, at 04:56 , Michael Esveldt wrote: > This is a fairly basic question, but its answer might be of > some small use to MacPython: How safe is it to perform test > builds? > > I follow the list closely and, in the interest of a working > MachoPython, I frequently would like to help perform some of > the basic tests that are requested by Jack and others. I'm a > little wary, however, because this is all very new stuff. > I have an existing installation of python by fink, will I still > be able to use that if I install MacPython from CVS? If fink still installs everything in /sw (as it did the last time I checked it) then the two won't bite each other. if you have /usr/local/bin in your $PATH before /sw/bin your build will be preferred, otherwise the fink build will be preferred. > Will installing a test version cause problems when a neatly > packaged installation eventually comes along? It shouldn't, the packaged installer should install over the version you built. But, even so, uninstalling is fairly simple. For non-framework Python remove /usr/local/bin/python* and recursively /usr/local/lib/python*. For framework Python remove /usr/local/bin/python* and recursively /Library/Frameworks/Python.framework and /Applications/Python. I guess this should be documented somewhere, but I'm not quite sure where... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Thu Aug 29 21:20:31 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 29 Aug 2002 22:20:31 +0200 Subject: [Pythonmac-SIG] Need help debugging Python documentation install In-Reply-To: Message-ID: On donderdag, augustus 29, 2002, at 06:10 , Tony Lownds wrote: >> - cvs update >> - make frameworkinstall > > This step failed for me; the error I get is below. This bug may > be manifesting itself because I build in a separate tree from > the source. I did remove the existing > /Library/Frameworks/Python.framework and /Applications/Python/ > first. Not your problem, this is a genuine bug. BuildApplet has to be told that it should skip the Documentation symlink when copying Python.app. I just checked in a fix in CVS. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bfancher@mac.com Thu Aug 29 21:33:09 2002 From: bfancher@mac.com (bill fancher) Date: Thu, 29 Aug 2002 13:33:09 -0700 Subject: [Pythonmac-SIG] Need help debugging Python documentation install In-Reply-To: Message-ID: <87E2F9AD-BB8E-11D6-B085-0005029E8B13@mac.com> On Thursday, August 29, 2002, at 09:10 AM, Tony Lownds wrote: >> - cvs update >> - make frameworkinstall > > This step failed for me; the error I get is below. This bug may be > manifesting itself because I build in a separate tree from the source. > I did remove the existing /Library/Frameworks/Python.framework and > /Applications/Python/ first. Same here, but I was just doing an "out of the box" build. (Just saw announcement of fix, will give it a try.) Another problem I had is, I think, Jaguar related: if you run things a second time, it's unable to replace info.plist and PkgInfo files in the previously installed apps (no write permission, even for owner). So a second try at installing doesn't even get as far as the first. The only workaround I've seen suggested (by Scott Tooker from Apple) is a shell script build phase to fix permissions. Seems like there should be a better way. Haven't had a chance to investigate. -- bill > > -Tony > > /Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python.app/Contents/MacOS/python > ../python/dist/src/Mac/scripts/BuildApplet.py \ > --output > /Library/Frameworks/../../Applications/Python/BuildApplet.app \ > ../python/dist/src/Mac/scripts/BuildApplet.py > Traceback (most recent call last): > File "../python/dist/src/Mac/scripts/BuildApplet.py", line 127, in ? > main() > File "../python/dist/src/Mac/scripts/BuildApplet.py", line 22, in > main > buildapplet() > File "../python/dist/src/Mac/scripts/BuildApplet.py", line 94, in > buildapplet > rsrcname=rsrcfilename, others=extras, raw=raw, progress=verbose) > File > "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/ > buildtools.py", line 119, in process > copy_codefragment, raw, others) > File > "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/ > buildtools.py", line 144, in process_common > is_update, raw, others) > File > "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/ > buildtools.py", line 300, in process_common_macho > copyapptree(template, destname, exceptlist, progress) > File > "/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/ > buildtools.py", line 521, in copyapptree > shutil.copy2(srcpath, dstpath) > File > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ > shutil.py", line 73, in copy2 > copyfile(src, dst) > File > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ > shutil.py", line 28, in copyfile > fsrc = open(src, 'rb') > IOError: [Errno 2] No such file or directory: > '/Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python.app/Contents/Resources/English.lproj/Documentation' > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Jack.Jansen@oratrix.com Thu Aug 29 21:47:24 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 29 Aug 2002 22:47:24 +0200 Subject: [Pythonmac-SIG] Need help debugging Python documentation install In-Reply-To: Message-ID: <862704E0-BB90-11D6-AADF-003065517236@oratrix.com> On donderdag, augustus 29, 2002, at 12:12 , John W Baxter wrote: > At 23:41 +0200 8/28/2002, Jack Jansen wrote: >> Now, however, I need to debug the way I'm installing the >> documentation, and I can't do that myself, because it seems that >> once you've told Apple help Viewer about a documentation set >> there is absolutely no way to make it forget that documentation >> again, so my system is tainted. > > > Are you saying that removing, for example, > com.apple.iChat > > > iChatHelp > > file://localhost/Applications/iChat.app/Contents/Resources/English. > lproj/iChatHelp/ > > > > (that file URL is wrapped...it aligns with the line above) > from ~/Library/Preferences/com.apple.help.plist > > isn't sufficient? Ah! Yet another preference place for Apple help Viewer! What I had done was removed the directory ~/Library/Apple Help Prefs, but that didn't help. The next time I started AHV it rebuilt the whole directory and the Python docs were there again (even though the docs themselves were gone, or at least moved to a different location). No, your trick doesn't help either:-( I've now done the following: - Moved the documentation (in the framework) from Documentation to Documentation-xx. - Removed the lines referring to it from ~/Library/Preferences/com.apple.help.plist - Removed and rebuilt my Apple Help Prefs folder. And, lo and behold, AHV not only lists the Python documentation in its menu, it is even still able to display it! This means that it must have stashed an alias away somewhere. (I guess it must be an alias: a symlink would have survived me moving Documentation to Documentation-xx). I guess this tells us that Apple is treating access to documentation Religiously Serious:-) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tony@lownds.com Thu Aug 29 22:18:21 2002 From: tony@lownds.com (Tony Lownds) Date: Thu, 29 Aug 2002 14:18:21 -0700 Subject: [Pythonmac-SIG] Need help debugging Python documentation install In-Reply-To: References: Message-ID: At 10:20 PM +0200 8/29/02, Jack Jansen wrote: >On donderdag, augustus 29, 2002, at 06:10 , Tony Lownds wrote: > >>>- cvs update >>>- make frameworkinstall >> >>This step failed for me; the error I get is below. This bug may be >>manifesting itself because I build in a separate tree from the >>source. I did remove the existing >>/Library/Frameworks/Python.framework and /Applications/Python/ >>first. > >Not your problem, this is a genuine bug. BuildApplet has to be told >that it should skip the Documentation symlink when copying >Python.app. > >I just checked in a fix in CVS. Thanks! I ran into another snag, fixed by this diff: install_IDE: $(INSTALLED_PYTHONW) - @if $(INSTALLED_PYTHONW) -c "import waste"; then ; else \ + @if $(INSTALLED_PYTHONW) -c "import waste"; then true; else \ echo PythonIDE needs the \"waste\" extension module; \ echo See Mac/OSX/README for details; \ exit 1; \ ...apparently /bin/sh requires a statement in the "then" clause. And just hit a third snag: /usr/bin/install -l as /Library/Frameworks/Python.framework/Versions/2.3/bin/python /Library/Frameworks/../../usr/local/bin/python /usr/bin/install: illegal option -- l usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 ... fileN directory install -d [-v] [-g group] [-m mode] [-o owner] directory ... make[1]: *** [installunixtools] Error 64 make: *** [frameworkinstallunixtools] Error 2 The install on my Linux box does not have an -l option either. This partial diff fixes it: installunixtools: $(INSTALLED_PYTHON) $(INSTALLED_PYTHONW) $(srcdir)/Mac/OSX/pythonw.sh $(INSTALL) -d $(bindir) - $(INSTALL_SYMLINK) $(INSTALLED_PYTHON) $(bindir)/python + $(LN) -fsn $(INSTALLED_PYTHON) $(bindir)/python $(INSTALL) $(srcdir)/Mac/OSX/pythonw.sh $(bindir)/pythonw Here is a complete diff on the Mac/OSX/Makefile -Tony Index: Mac/OSX/Makefile =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/OSX/Makefile,v retrieving revision 1.23 diff -u -r1.23 Makefile --- Mac/OSX/Makefile 28 Aug 2002 21:27:01 -0000 1.23 +++ Mac/OSX/Makefile 29 Aug 2002 21:16:17 -0000 @@ -21,7 +21,6 @@ # Items more-or-less copied from the main Makefile DIRMODE=755 INSTALL=/usr/bin/install -c -INSTALL_SYMLINK=/usr/bin/install -l as INSTALL_PROGRAM=${INSTALL} INSTALL_SCRIPT= ${INSTALL_PROGRAM} INSTALL_DATA= ${INSTALL} -m 644 @@ -122,7 +121,7 @@ install_IDE: $(INSTALLED_PYTHONW) - @if $(INSTALLED_PYTHONW) -c "import waste"; then ; else \ + @if $(INSTALLED_PYTHONW) -c "import waste"; then true; else \ echo PythonIDE needs the \"waste\" extension module; \ echo See Mac/OSX/README for details; \ exit 1; \ @@ -273,7 +272,7 @@ installunixtools: $(INSTALLED_PYTHON) $(INSTALLED_PYTHONW) $(srcdir)/Mac/OSX/pythonw.sh $(INSTALL) -d $(bindir) - $(INSTALL_SYMLINK) $(INSTALLED_PYTHON) $(bindir)/python + $(LN) -fsn $(INSTALLED_PYTHON) $(bindir)/python $(INSTALL) $(srcdir)/Mac/OSX/pythonw.sh $(bindir)/pythonw # This is for development purposes: create a Mac.pth that refers to the source From Jack.Jansen@oratrix.com Thu Aug 29 23:09:40 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 30 Aug 2002 00:09:40 +0200 Subject: [Pythonmac-SIG] Need help debugging Python documentation install In-Reply-To: <87E2F9AD-BB8E-11D6-B085-0005029E8B13@mac.com> Message-ID: <03A18682-BB9C-11D6-AADF-003065517236@oratrix.com> On donderdag, augustus 29, 2002, at 10:33 , bill fancher wrote: > Another problem I had is, I think, Jaguar related: if you run > things a second time, it's unable to replace info.plist and > PkgInfo files in the previously installed apps (no write > permission, even for owner). So a second try at installing > doesn't even get as far as the first. I had only a quick glance, but I think they replaced the unix install tool by a different one. It could be that it screws up permissions. I mean "handles them differently", of course. I will investigate, could you put a bug report in sourceforge? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dev@brotsky.com Fri Aug 30 08:29:07 2002 From: dev@brotsky.com (Daniel Brotsky) Date: Fri, 30 Aug 2002 00:29:07 -0700 Subject: [Pythonmac-SIG] Need help debugging Python documentation install In-Reply-To: Message-ID: <2B22E424-BBEA-11D6-ADD5-0003931036B4@brotsky.com> 0. I'm on 10.1.5 1. I tried this right after you asked and was able to work around the BuildApplet.py problem reported (before you fixed it) by running the doc make and install and then rerunning the framework install: enough had been installed that the doc make and install worked fine; then since the doc was there the BuildApplet run worked fine. 2. Unfortunately, the install does not seem to have made the Python help available via Mac Help. It doesn't show in any Python-related app's Help menu; it doesn't show up in the main Help list of know modules, nor does a search for Python return anything (other than BBEdit help). Sorry this didn't seem to work. I'm happy to try something else :^). dan From Jack.Jansen@oratrix.com Fri Aug 30 09:05:05 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 30 Aug 2002 10:05:05 +0200 Subject: [Pythonmac-SIG] Need help debugging Python documentation install In-Reply-To: <2B22E424-BBEA-11D6-ADD5-0003931036B4@brotsky.com> Message-ID: <312B0245-BBEF-11D6-B9DE-0030655234CE@oratrix.com> On Friday, August 30, 2002, at 09:29 , Daniel Brotsky wrote: > 0. I'm on 10.1.5 > > 1. I tried this right after you asked and was able to work around the > BuildApplet.py problem reported (before you fixed it) by running the > doc make and install and then rerunning the framework install: enough > had been installed that the doc make and install worked fine; then > since the doc was there the BuildApplet run worked fine. > > 2. Unfortunately, the install does not seem to have made the Python > help available via Mac Help. It doesn't show in any Python-related > app's Help menu; it doesn't show up in the main Help list of know > modules, nor does a search for Python return anything (other than > BBEdit help). Dan, thanks for the help! I was sort-of expecting this (the documentation states that Carbon programs need to go through the extra step of calling AHRegisterHelpBook()), I'll be adding that call (plus a help menu) to the IDE shortly, so then documentation should show up after you run the IDE the first time. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Aug 30 11:23:29 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 30 Aug 2002 03:23:29 -0700 Subject: [Pythonmac-SIG] Install issue on Mac OS 10.2 In-Reply-To: <5.1.0.14.2.20020829083033.041e3a98@cedar.he.net> Message-ID: <871E50C6-BC02-11D6-AE00-0030655234CE@cwi.nl> On Thursday, Aug 29, 2002, at 06:31 US/Pacific, Paul Miller wrote: > the installer seems to work fine on a 10.2 machine with no previous > version installed. > > When you run the ConfigurePythonCarbon (which is described in the > docs/readme, and which fixes some odd configuration issues for > people), it opens a window whose title bar says "<>" with > a blinking cursor in the window. I can't tell whether it finished or > not, so i just quit it. i couldn't find anything on the macpython page > or on google about why this window appears. have you ever seen this > window? Here's a workaround: After installing MacPython 2.2.1, and after the attempt to run ConfigurePythonCarbon fails, remove ~/Library/Preferences/Python. Then run ConfigurePythonCarbon again. I'm not sure what is going on, but I think the Vise's attempt to run ConfiurePythonCarbon, which has always failed on OSX, fails more seriously on Jaguar. I'll investigate, and in the mean time I'll put up this workaround on the MacPython page. From Jack.Jansen@cwi.nl Fri Aug 30 11:29:00 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 30 Aug 2002 03:29:00 -0700 Subject: [Pythonmac-SIG] Need help debugging Python documentation install In-Reply-To: <03A18682-BB9C-11D6-AADF-003065517236@oratrix.com> Message-ID: <4C49569C-BC03-11D6-AE00-0030655234CE@cwi.nl> On Thursday, Aug 29, 2002, at 15:09 US/Pacific, Jack Jansen wrote: > > On donderdag, augustus 29, 2002, at 10:33 , bill fancher wrote: > >> Another problem I had is, I think, Jaguar related: if you run things >> a second time, it's unable to replace info.plist and PkgInfo files >> in the previously installed apps (no write permission, even for >> owner). So a second try at installing doesn't even get as far as the >> first. > > I had only a quick glance, but I think they replaced the unix install > tool by a different one. It could be that it screws up permissions. I > mean "handles them differently", of course. I will investigate, could > you put a bug report in sourceforge? It turns out this is indeed the problem: the new "install" tool copies in stead of moves files. So r--r--r-- files can't be overwritten. The quick fix is to edit the Makefile to set INSTALL to "${srcdir}/install-sh -c" (without the quotes). This does make installs a factor 5 or so slower, however:-( So, I'm interested in other fixes for this. From skim@adobe.com Sat Aug 31 01:40:06 2002 From: skim@adobe.com (Sung Kim) Date: Fri, 30 Aug 2002 17:40:06 -0700 Subject: [Pythonmac-SIG] Embedding & C utility routine question Message-ID: <323E4E76-BC7A-11D6-A3C8-003065B90A20@adobe.com> I have a C app which puts up a GUI, and calls Python scripts. The Python scripts write to stdout. After all is done, I see both the GUI and the console window. But I'm having trouble making the console active. I'm guessing there are routines which disable/enable things (i.e. event loop), and I will look into that. If anybody can help narrow my search, I would appreciate that very much! Thank you. --Sung H. Kim skim@adobe.com From bfancher@mac.com Sat Aug 31 22:23:20 2002 From: bfancher@mac.com (bill fancher) Date: Sat, 31 Aug 2002 14:23:20 -0700 Subject: [Pythonmac-SIG] Configure question Message-ID: I'm running 10.2 and upgraded autoconf to 2.53 so that I can regenerate=20= configure from configure.in. Having done so, I now notice that I get=20 the following line in configure output: checking LINKCC... ld: Undefined symbols: ___gxx_personality_v0 Should I worry? Is it just something I overlooked before? Is anyone=20 else seeing this? (He asked, hoping to avoid having to isolate, and=20 perhaps remedy, the underlying cause.) -- bill "They laughed at Columbus, they laughed at Fulton, they laughed at the=20= Wright brothers. But they also laughed at Bozo the Clown."=A0 Carl Sagan=