From andrew.straw@adelaide.edu.au Sat Mar 1 00:40:19 2003 From: andrew.straw@adelaide.edu.au (Andrew Straw) Date: Sat, 1 Mar 2003 11:10:19 +1030 Subject: [Pythonmac-SIG] question about how 2.3 GUI apps will work Message-ID: <60CF8872-4B7E-11D7-BFC2-00039311EA24@adelaide.edu.au> Hi fellow Mac and Python philes: I have recently been using Robin Dunn's Python 2.3a1 distribution with Tkinter and recently downloaded Tcl and Tk frameworks (from the tcl project download page). I have been very impressed with increase in ease of use in most regards since Python 2.2. (Thanks *heaps* to Jack and everyone else!) There is one question I have, which I think went around the mailing list a few weeks back, but I didn't get the final result. (Possibly because I just got lazy and didn't follow the thread, but I'm not actually sure if there was a final answer then, and it may have changed.) What happens when you double-click a .py file that has Tkinter stuff (i.e. open it with PythonLauncher)? With Robin Dunn's Python 2.3a1 distribution for wxPython, this opens a Terminal window which displays stdout and stderr (good), but clicking on the Tkinter window results in the dreaded "SetFrontProcess failed,-606" error (bad). Has this been resolved? Can it be resolved? Or shall I now incorporate some sort of automatic .py to .pyw copying script? (Double clicking .pyw files works fine.) I ask now because I just read Jack's description about how his focus is now on getting everything ready for 2.3 final, and I think this is an important issue. As I said, I'm probably being too lazy on this and should just download the latest CVS version, configure, make, install, and test this myself, but... Cheers! Andrew From matsakis@mit.edu Sat Mar 1 07:01:48 2003 From: matsakis@mit.edu (Nick Matsakis) Date: Sat, 1 Mar 2003 02:01:48 -0500 (EST) Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: <9A06500C-4B76-11D7-9BD7-000A27B19B96@oratrix.com> References: <9A06500C-4B76-11D7-9BD7-000A27B19B96@oratrix.com> Message-ID: On Sat, 1 Mar 2003, Jack Jansen wrote: > If people want to read the "in development" part of the documentation: > please do so and let me know the problems. Where is this? In CVS? Perhaps it could be put on the web somewhere to lower the barrier to people perusing it. Just write *DRAFT* all over it... >> If all goes well, a future Mac-python programmer will like have sets of >> modules that correspond roughly to "Cocoa" (pyobjc), "Carbon" >> (MacPython), "Applescript/OSA" (MacPython), and "standard python OS >> abstractions" (os, sys). > Is this the way it should be structured, or would a problem-oriented > approach be better? The reason I suggested they be grouped by framework is that these frameworks have relatively independent pedigrees. I expect that programs will generally fall primarily into a single category, while still taking functionality from the others where needed. For example, if a program requires access to a network resource, which abstraction should they use? The Cocoa one? The Carbon one? The Python/Unix one? I think it really depends on what the primary technology the rest of the program is using. If it is a highly-interactive GUI app, the programmer may chose pyobjc and Cocoa. In this case, it would make sense to utilize the Cocoa networking API, since this will likely interface well with the GUI components. On the other hand, if the app is going to download web pages and extract information to process as a batch job, the standard Python APIs would probably be sufficient. So, perhaps it would be best to combine the "framework-centered" approach with the "problem-centered" approach by first describing the frameworks, and the describing what problems are amenable to what frameworks. Perhaps as an example I should offer a script I wrote to do system backups in conjunction with Retrospect. Basically, what I wanted was a way to mount my attached Firewire backup drive, run the backup with Retrospect, and then unmount the drive. This requires the ability to poll for attached but unmounted drives and to find out whether a Mac OS X application is running (when you don't necessarily know the name or location of the app). In the end, I wound up scripting the command-line utility "diskutil" to do the device discovery and mounting/unmounting and using the utility "osascript" to compile and execute Applescripts to find out if Retrospect was running. However, it feels rather kludgy to me. Parsing the output of diskutil is a pain, and my script doesn't deal with volume names that have spaces or non-ASCII characters, and I'd rather just send the Apple events directly, rather than compiling Applescript on the fly. I suspect that for this problem I could use the Carbon-based modules for managing the attached disks and the OSA modules for finding out if Retrospect is still running. Later, I may wish to add email functionality to send me email when there is a problem with the backup. I think in this case, smtplib is probably the way to go (Even though I could script Mail or perhaps use Carbon or Cocoa). Anyway, this is the kind of how I'm thinking about this at the moment. With MacOS X being a blend of NeXTStep, MacOS, and Unix, there is often more than one way to do things. Thus, some guidance should be given to programmers to help them choose the _right_ way to do what they want. Nick Matsakis From borgempath@Phreaker.net Sat Mar 1 09:23:10 2003 From: borgempath@Phreaker.net (Joel Rodrigues) Date: Sat, 1 Mar 2003 14:53:10 +0530 Subject: [Pythonmac-SIG] error running test.py in 4Suite-0.12.0a3 In-Reply-To: <42C89F17-4B03-11D7-9908-0030655234CE@cwi.nl> Message-ID: <6BEFEF80-4BC7-11D7-AFC5-0005024EF27F@Phreaker.net> On Friday, February 28, 2003, at 03:29 , Jack Jansen wrote: > > On Friday, Feb 28, 2003, at 07:12 Europe/Amsterdam, Joel > Rodrigues wrote: >> This may the source of my problems : >> ncurses-5.2X.pkg, package built by Chris Roberts. I don't know >> where I got it. ANyone have a tip on an ncurses to download >> and for OS X ? > > There's a good chance you run into errors with curses on MacOSX 10.1. > > 10.1 ships with an ancient curses, which isn't good enough for > the Python curses module, so it is manually disabled. However, > the curses implementation lives in libc, and because Python on > 10.1 lives with a flat namespace for all globals even > installing ncurses yourself and linking the curses module > against that isn't guaranteed to work: if another extension > module that was loaded earlier somehow refers to the old curses > in libc your ncurses module will pick up that symbol and you're > going to be hosed. All in all it's a pretty messy situation. > > All this has been fixed for 10.2, where ncurses is included, it > doesn't live in libc anymore and we have two-level namespaces. > Each of these alone would have fixed the problem:-) > > If you do want to try and continue with ncurses on 10.1: I had > some success with the fink ncurses at the time. Thank you for the information ! What a headache inducing problem. No choice about the system I use right now. I'm stuck with my current system, 233MHz G3 desktop running OS X 10.1.5 for at least another 5 or 6 months. I've just spent 2 hours trying to build ncurses 5.3, no luck so far. > If I can't dance I don't want to be part of your revolution -- > Emma Goldman Nice sentiment. People should dance more. Not war dances ;-) - Joel From ranch1@earthlink.net Sat Mar 1 11:12:04 2003 From: ranch1@earthlink.net (Tom Fetherston) Date: Sat, 1 Mar 2003 06:12:04 -0500 Subject: [Pythonmac-SIG] Q on Robin Dunn's installer Message-ID: This is a forward of a question on a sourceforge list: ========================================================= The MacPython OS X installer does not work for me. When I try to install it it says: You cannot install this software on this disk. (null) I'm not sure what the problem is. Does your pythonw script say simply #!/bin/sh exec /usr/local/bin/python "$@" That is the script I have found and it doesn't seem to work for me (with a source build of python 2.3a and TkAqua 8.4.1). When I try to bring a Tk window to front I get the error: SetFrontProcess failed, -606 ========================================================== Any ideas? From matsakis@mit.edu Sat Mar 1 15:45:24 2003 From: matsakis@mit.edu (Nick Matsakis) Date: Sat, 1 Mar 2003 10:45:24 -0500 (EST) Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: References: <9A06500C-4B76-11D7-9BD7-000A27B19B96@oratrix.com> Message-ID: On Sat, 1 Mar 2003, Nick Matsakis wrote: > With MacOS X being a blend of NeXTStep, MacOS, and Unix, there is often > more than one way to do things. Thus, some guidance should be given to > programmers to help them choose the _right_ way to do what they want. I should also emphasis that guidance should be given on where these frameworks are now, where they are going, and how fast. There is nothing like the frustration of starting a programming project and realizing halfway in that you need some capability that the platform/framework/tools you choose doesn't offer you. (Yes, this is why open-source software is so important, but that is another discussion). Most projects have a deadline of some sort, and the state of the frameworks will let programmers know whether or not Python on the Mac is the right solution for their problem. Nick Matsakis From Jack.Jansen@oratrix.com Sat Mar 1 17:00:09 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 1 Mar 2003 18:00:09 +0100 Subject: [Pythonmac-SIG] question about how 2.3 GUI apps will work In-Reply-To: <60CF8872-4B7E-11D7-BFC2-00039311EA24@adelaide.edu.au> Message-ID: <42A08B07-4C07-11D7-AF8F-000A27B19B96@oratrix.com> On zaterdag, maa 1, 2003, at 01:40 Europe/Amsterdam, Andrew Straw wrote: > Hi fellow Mac and Python philes: > > I have recently been using Robin Dunn's Python 2.3a1 distribution with > Tkinter and recently downloaded Tcl and Tk frameworks (from the tcl > project download page). I have been very impressed with increase in > ease of use in most regards since Python 2.2. (Thanks *heaps* to Jack > and everyone else!) > > There is one question I have, which I think went around the mailing > list a few weeks back, but I didn't get the final result. (Possibly > because I just got lazy and didn't follow the thread, but I'm not > actually sure if there was a final answer then, and it may have > changed.) > > What happens when you double-click a .py file that has Tkinter stuff > (i.e. open it with PythonLauncher)? In 2.3a2 this will work, i.e. you won't get the 606 error. In 2.3a1 this is also easy to fix: set the PythonLauncher preference for ".py" files to use "pythonw" in stead of the default "python". In 2.3a2 this is the default. -- - 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 Mar 1 17:16:32 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 1 Mar 2003 18:16:32 +0100 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: Message-ID: <8C7C3854-4C09-11D7-AF8F-000A27B19B96@oratrix.com> On zaterdag, maa 1, 2003, at 08:01 Europe/Amsterdam, Nick Matsakis wrote: > > On Sat, 1 Mar 2003, Jack Jansen wrote: > >> If people want to read the "in development" part of the documentation: >> please do so and let me know the problems. > > Where is this? In CVS? Perhaps it could be put on the web somewhere > to > lower the barrier to people perusing it. Just write *DRAFT* all over > it... It's on www.python.org. Go to the "documentation" page, then follow the link that says something like "browse in-development version of the docs". >>> If all goes well, a future Mac-python programmer will like have sets >>> of >>> modules that correspond roughly to "Cocoa" (pyobjc), "Carbon" >>> (MacPython), "Applescript/OSA" (MacPython), and "standard python OS >>> abstractions" (os, sys). > >> Is this the way it should be structured, or would a problem-oriented >> approach be better? > > The reason I suggested they be grouped by framework is that these > frameworks have relatively independent pedigrees. I expect that > programs > will generally fall primarily into a single category, while still > taking > functionality from the others where needed. > > For example, if a program requires access to a network resource, which > abstraction should they use? The Cocoa one? The Carbon one? The > Python/Unix one? I think it really depends on what the primary > technology > the rest of the program is using. If it is a highly-interactive GUI > app, > the programmer may chose pyobjc and Cocoa. In this case, it would make > sense to utilize the Cocoa networking API, since this will likely > interface well with the GUI components. On the other hand, if the app > is > going to download web pages and extract information to process as a > batch > job, the standard Python APIs would probably be sufficient. > > So, perhaps it would be best to combine the "framework-centered" > approach with the "problem-centered" approach by first describing the > frameworks, and the describing what problems are amenable to what > frameworks. Sounds reasonable... > Perhaps as an example I should offer a script I wrote to do system > backups > in conjunction with Retrospect. [...] The description sounds interesting, but there's one problem with this as an example: not everyone has retrospect. This is a problem the MacOS9 MacPython scripting examples have also had for a long time. I think I do have an interesting example that can be used to demonstrate sysadmin-like tasks: a script that looks for text files (either .txt extension or TEXT type) that have non-native end of line convention. This would be easy to understand as a script, and moreover could be extended with a GUI to demonstrate Cocoa, wxPython and Tkinter. But for scripting I don't have any ideas yet. Something with Mail or Address book or iTunes or so springs to mind, but I'm not really sure what. Best would be something that is difficult or impossible to do in the host 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 berkowit@silcom.com Sat Mar 1 17:34:42 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Sat, 01 Mar 2003 09:34:42 -0800 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: <8C7C3854-4C09-11D7-AF8F-000A27B19B96@oratrix.com> Message-ID: On 3/1/03 9:16 AM, "Jack Jansen" wrote: > But for scripting I don't have any ideas yet. Something with Mail or > Address book > or iTunes or so springs to mind, but I'm not really sure what. Best > would be something that > is difficult or impossible to do in the host program. Mail's AppleScripting cannot get text selection. Same for other Cocoa apps. That's a big complaint. (It will probably be fixed in OS 10.3, however.) Can Python do that? Address Book cannot import contacts from a tab-delimited text file, only from a silly LDIF file or vCards. With enough work, AppleScript can parse the tab-text file and convert it to LDIF, but it would be very slow. Python could do that much faster - or maybe you could do it within AB somehow with a Cocoa combination. -- Paul Berkowitz From matsakis@mit.edu Sat Mar 1 21:46:10 2003 From: matsakis@mit.edu (Nick Matsakis) Date: Sat, 1 Mar 2003 16:46:10 -0500 (EST) Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: <8C7C3854-4C09-11D7-AF8F-000A27B19B96@oratrix.com> References: <8C7C3854-4C09-11D7-AF8F-000A27B19B96@oratrix.com> Message-ID: On Sat, 1 Mar 2003, Jack Jansen wrote: > It's on www.python.org. Go to the "documentation" page, then follow the > link that says something like "browse in-development version of the > docs". Woah. I didn't know that was there. Good to know. > The description sounds interesting, but there's one problem with this as > an example: not everyone has retrospect. Again, while a tutorial with example code would be most excellent, all I am suggesting is just a few short paragraphs explaining some different types of uses for Python and which frameworks would be best. Something that could be up next week rather than in 6 months. The main categories I'm interested in for my own uses are: Shell scripts, system maintenance scripts Server scripts, cgi GUI application scripting (stuff typically done with Applescript) Though another obvious one is: Full GUI application development Another thing that I would be interested in seeing in a "state of python" document is a short discussion of the relationship between pyobjc and Mac Python. Nick From borgempath@Phreaker.net Sun Mar 2 11:11:34 2003 From: borgempath@Phreaker.net (Joel Rodrigues) Date: Sun, 2 Mar 2003 16:41:34 +0530 Subject: [Pythonmac-SIG] installing libxml2-python-2.5.4 Message-ID: I downloaded the foll. : libxml2-2.5.4 libxslt-1.0.27 libxml2-python-2.5.4 Built & installed libxml2-2.5.4 & libxslt-1.0.27 using './configure', 'make', 'make check', 'sudo make install'. So how do I build & install libxml2-python-2.5.4 ? 'sudo python setup.py build install' does not work. No luck finding instructions anywhere (not any of any use anyway, especially not in the docs). Was it too much trouble to add a small not about how to install it in the README, one wonders. Any & all suggestions welcome ! Cheers, Joel From borgempath@Phreaker.net Sun Mar 2 19:24:02 2003 From: borgempath@Phreaker.net (Joel Rodrigues) Date: Mon, 3 Mar 2003 00:54:02 +0530 Subject: [Pythonmac-SIG] Re: installing libxml2-python-2.5.4 In-Reply-To: Message-ID: <86C971A5-4CE4-11D7-AA2C-0005024EF27F@Phreaker.net> > I downloaded the foll. : > > libxml2-2.5.4 > libxslt-1.0.27 > libxml2-python-2.5.4 > > Built & installed libxml2-2.5.4 & libxslt-1.0.27 using > './configure', 'make', 'make check', 'sudo make install'. > > So how do I build & install libxml2-python-2.5.4 ? > > 'sudo python setup.py build install' does not work. These instructions from xmlsoft.org do not work , well, they're also hard to decipher. "... use the libxml2-python module distribution corresponding to your installed version of libxml2 and libxslt. Note that to install it you will need both libxml2 and libxslt installed and run "python setup.py build install" in the module tree. Ok, I seem to have succeeded. I don't quite know how or why, as I did the same earlier several times but with many errors. I ran 'python setup.py build install' in the 'libxml2-python-2.5.4' directory after moving 'drv_libxml2.py' into it from the libxml2-2.5.4 python build directory. - Joel From just@letterror.com Sun Mar 2 19:50:17 2003 From: just@letterror.com (Just van Rossum) Date: Sun, 2 Mar 2003 20:50:17 +0100 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: Message-ID: Paul Berkowitz wrote: > On 3/1/03 9:16 AM, "Jack Jansen" wrote: > > > But for scripting I don't have any ideas yet. Something with Mail > > or Address book or iTunes or so springs to mind, but I'm not really > > sure what. Best would be something that is difficult or impossible > > to do in the host program. > > Mail's AppleScripting cannot get text selection. Same for other Cocoa > apps. That's a big complaint. (It will probably be fixed in OS 10.3, > however.) Can Python do that? If the limitation is in the AppleEvent support of Mail.app, then no, as Python will use the same stuff. > Address Book cannot import contacts > from a tab-delimited text file, only from a silly LDIF file or > vCards. With enough work, AppleScript can parse the tab-text file and > convert it to LDIF, but it would be very slow. Python could do that > much faster - or maybe you could do it within AB somehow with a Cocoa > combination. FWIW, in the PyObjC project there's an interface to the AddressBook framework plus a simple demo. Just From Jack.Jansen@oratrix.com Sun Mar 2 20:04:37 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 2 Mar 2003 21:04:37 +0100 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] Python as an AppleScript Replacement? In-Reply-To: <870DDE62-4C91-11D7-9E25-00039376B1AE@mac.com> Message-ID: <322FA03C-4CEA-11D7-BFC8-000A27B19B96@oratrix.com> Taking this over to pythonmac-sig too, in the hope someone knows the solution. On zondag, maa 2, 2003, at 10:29 Europe/Amsterdam, Donovan Preston wrote: [talking about gensuitemodule] > 1) It currently asks you to select an application with a Carbon file > picker. The Carbon file picker exposed by python requires a > type/creator mask, and won't let you pick application bundles. > > 2) It currently opens the resource fork of the application you chose > and reads the binary data off disk, which it then parses to discover > the english names and corresponding four character codes. > > The solution to these problems is to instead send the 'ascr' 'gdte' > event directly to the application you wish to create a python module > for, by addressing the application's four character code. I would love to do this in gensuitemodule, but there's bits and pieces I don't know. Maybe someone can enlighten me? 1. Where is the ascr/gdte described? What is the return value, just raw AEUT/AETE data, or is it somehow encoded in OSA objects? 2. It appears there's a higher level interface too, because if I do "get dictionary" in the script editor some applications are indeed fired up, but some are not. So, it seems that sometimes the ascr/gdte event is used to get the dictionary, but sometimes it's grabbed from the resource fork. At least, it seems that way... 3. Is there an API to get the "pick application" dialog that script editor puts up when you do a get dictionary? The way it seems to find scriptable applications all over the place I get the impression it works together with launch services or something... -- - 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 Mar 2 20:29:22 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 2 Mar 2003 21:29:22 +0100 Subject: [Pythonmac-SIG] Carbon.framework versus ApplicationServices.framework Message-ID: I'm working at putting things that are currently in Carbon in the "right" framework, and while this works fine for something like CG, which doesn't depend on Carbon.framework but really on ApplicationServices.framework, it doesn't work for AE and QD. If I link the AE module against ApplicationServices I get various undefined routines (for Qd I get only one: GetWindowPort), so it seems that these toolkits have two distinct sets of routines: some defined in both ApplicationServices and Carbon, but some only defined in Carbon. Does anyone know how I can distinguish between the two? -- - 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 Mar 2 20:47:45 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 2 Mar 2003 21:47:45 +0100 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: Message-ID: <3850B768-4CF0-11D7-BFC8-000A27B19B96@oratrix.com> On zondag, maa 2, 2003, at 20:50 Europe/Amsterdam, Just van Rossum wrote: >> Address Book cannot import contacts >> from a tab-delimited text file, only from a silly LDIF file or >> vCards. With enough work, AppleScript can parse the tab-text file and >> convert it to LDIF, but it would be very slow. Python could do that >> much faster - or maybe you could do it within AB somehow with a Cocoa >> combination. > > FWIW, in the PyObjC project there's an interface to the AddressBook > framework plus a simple demo. This would make a nice demo of the two technologies, then. There could be a Cocoa-based version that uses the AdressBook framework and a Cocoa GUI and a Carbon version that uses AppleScript to talk to Address Book. And possibly there could be a command line tool that requires that the TSV file has the exact names of the fields in the first line of the file. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From zen@shangri-la.dropbear.id.au Sun Mar 2 22:38:16 2003 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Mon, 3 Mar 2003 09:38:16 +1100 Subject: [Pythonmac-SIG] installing libxml2-python-2.5.4 In-Reply-To: Message-ID: On Sunday, March 2, 2003, at 10:11 PM, Joel Rodrigues wrote: > I downloaded the foll. : > > libxml2-2.5.4 > libxslt-1.0.27 > libxml2-python-2.5.4 > > Built & installed libxml2-2.5.4 & libxslt-1.0.27 using './configure', > 'make', 'make check', 'sudo make install'. > > So how do I build & install libxml2-python-2.5.4 ? > > 'sudo python setup.py build install' does not work. And the output would be helpful. > No luck finding instructions anywhere (not any of any use anyway, > especially not in the docs). Was it too much trouble to add a small > not about how to install it in the README, one wonders. Worked for me after altering both the includes_dir and libdirs lists. The docs and setup.py doesn't mention you may need to update libdirs. -- Stuart Bishop http://shangri-la.dropbear.id.au/ From jwblist@olympus.net Mon Mar 3 00:54:09 2003 From: jwblist@olympus.net (John W Baxter) Date: Sun, 2 Mar 2003 16:54:09 -0800 Subject: [Pythonmac-SIG] Re: MacPython 2.3a2 on OSX 10.1 In-Reply-To: References: <1046446506.1551.14.camel@sparrow> Message-ID: At 11:29 -0500 2/28/2003, Nick Matsakis wrote: >> It would be nice to support 10.1, particularly since 10.2 is not a free >> upgrade and some people never upgrade the OS after they buy their >> computer. > >Some Macs shipped with 10.0. I don't see that as a reason to support it. >Mac OS X has developed a lot, but I think it is clear that much has firmed >up in 10.2. While I find it very annoying that Apple both charged full >price and provided no 10.1 -> 10.2 upgrade path, I think that the >installed base will move from 10.1 in short order. > >So many of Apple's new programs are 10.2 only: Safari, Keynote, X11, etc. >and this seems to be the case with a lot of third-party software. I think >it will be hard to for many people to stay on 10.1 when 10.2 offers so >much. Actually, we're reaching a time when it may make sense NOT to go from 10.1.x to 10.2.x, but to wait for "Panther" (whether that's 10.3 or 10.5 when it emerges). Is Apple going to pull the same pricing stunt with Panther than they did with Jaguar? If so, then it probably no longer makes sense to buy Jaguar unless one *needs* it right away. If the coupons which came in the Jaguar box will actually mean something, then there's less reason to wait. How will we find out? If Jaguar is the guide, then we'll know a few minutes after the deadline expires. (I would have been unhappy about the pay-for nature of Jaguar, but I had already decided to pay for it fresh rather than trying to patch yet another update onto the old 10.0 updated.) All that said: the future is more important than the past. Efforts to support 10.1 should not stand in the way of being ready for Panther. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jwblist@olympus.net Mon Mar 3 01:04:29 2003 From: jwblist@olympus.net (John W Baxter) Date: Sun, 2 Mar 2003 17:04:29 -0800 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: <3850B768-4CF0-11D7-BFC8-000A27B19B96@oratrix.com> References: <3850B768-4CF0-11D7-BFC8-000A27B19B96@oratrix.com> Message-ID: And, just to stir things up (actually, it's a serious question), what impact will Apple's X11 implementation have, when it becomes part of the Mac OS X install CDs (really optional? pseudo-optional like BSD subsystem? part of the base?)? Or final but acquired separately. Should person hours being devoted to making X11 things work in Cocoa be shifted to something else? If X11 will be "acquired separately" probably not. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From bob@redivi.com Mon Mar 3 01:51:11 2003 From: bob@redivi.com (Bob Ippolito) Date: Sun, 2 Mar 2003 20:51:11 -0500 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: Message-ID: <9C01F002-4D1A-11D7-8330-000A95686CD8@redivi.com> On Sunday, Mar 2, 2003, at 20:04 America/New_York, John W Baxter wrote: > And, just to stir things up (actually, it's a serious question), what > impact will Apple's X11 implementation have, when it becomes part of > the > Mac OS X install CDs (really optional? pseudo-optional like BSD > subsystem? > part of the base?)? Or final but acquired separately. > > Should person hours being devoted to making X11 things work in Cocoa be > shifted to something else? If X11 will be "acquired separately" > probably > not. As far as I can tell, it's pretty worthless without fink, because it doesn't come with any useful libraries (gnome, kde, etc). Also, I don't think these libraries are available anywhere without fink. If you need fink anyways, what good is Apple's X11 distribution? I don't particularly want to install fink. -bob From njriley@uiuc.edu Mon Mar 3 02:02:17 2003 From: njriley@uiuc.edu (Nicholas Riley) Date: Sun, 2 Mar 2003 20:02:17 -0600 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: <9C01F002-4D1A-11D7-8330-000A95686CD8@redivi.com> References: <9C01F002-4D1A-11D7-8330-000A95686CD8@redivi.com> Message-ID: <20030303020217.GA1306886@uiuc.edu> On Sun, Mar 02, 2003 at 08:51:11PM -0500, Bob Ippolito wrote: > On Sunday, Mar 2, 2003, at 20:04 America/New_York, John W Baxter wrote: > > >And, just to stir things up (actually, it's a serious question), > >what impact will Apple's X11 implementation have, when it becomes > >part of the Mac OS X install CDs (really optional? pseudo-optional > >like BSD subsystem? part of the base?)? Or final but acquired > >separately. > > > >Should person hours being devoted to making X11 things work in Cocoa be > >shifted to something else? If X11 will be "acquired separately" > >probably not. > > As far as I can tell, it's pretty worthless without fink, because it > doesn't come with any useful libraries (gnome, kde, etc). Also, I > don't think these libraries are available anywhere without fink. > > If you need fink anyways, what good is Apple's X11 distribution? I > don't particularly want to install fink. An example Apple used to demonstrate its X11 port was MATLAB, a commercial X11-based app. There are several other large non-GNOME and KDE applications which are commonly distributed as binary-only, such as OpenOffice. That said, I don't think Apple should ship X11 as a standard part of the install - it'll encourage even more half-hearted ports such as MATLAB. X11 is not 'native' for OS X, and I prefer to use Carbon/Cocoa ports of things such as Tk and GNU Emacs wherever possible. As is, I can do all my Python work without having to run X11, and I would prefer to keep it that way. -- =Nicholas Riley | Pablo Research Group, Department of Computer Science and Medical Scholars Program, University of Illinois at Urbana-Champaign From pversteegen@gcnetmail.net Mon Mar 3 03:09:00 2003 From: pversteegen@gcnetmail.net (Pete Versteegen) Date: Sun, 02 Mar 2003 22:09:00 -0500 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: <9C01F002-4D1A-11D7-8330-000A95686CD8@redivi.com> Message-ID: Hi Bob, You seem to imply having a problem with Fink. Could you elaborate on the reservations you have about Fink? Thanks! Pete Versteegen pversteegen@gcnetmail.net __________________________ On 3/2/03 8:51 PM, "Bob Ippolito" wrote: > On Sunday, Mar 2, 2003, at 20:04 America/New_York, John W Baxter wrote: > >> And, just to stir things up (actually, it's a serious question), what >> impact will Apple's X11 implementation have, when it becomes part of >> the >> Mac OS X install CDs (really optional? pseudo-optional like BSD >> subsystem? >> part of the base?)? Or final but acquired separately. >> >> Should person hours being devoted to making X11 things work in Cocoa be >> shifted to something else? If X11 will be "acquired separately" >> probably >> not. > > As far as I can tell, it's pretty worthless without fink, because it > doesn't come with any useful libraries (gnome, kde, etc). Also, I > don't think these libraries are available anywhere without fink. > > If you need fink anyways, what good is Apple's X11 distribution? I > don't particularly want to install fink. > > -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob@redivi.com Mon Mar 3 06:33:31 2003 From: bob@redivi.com (Bob Ippolito) Date: Mon, 3 Mar 2003 01:33:31 -0500 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: Message-ID: <0D30E0C0-4D42-11D7-8330-000A95686CD8@redivi.com> Pete, First of all, It's not easy to redistribute. Otherwise, most of the packages I'd really want to use are nonfunctional, not present, or just wouldn't install right. For example, I wanted to see if glade would work on top of Apple's X11 with fink.. it wasn't in stable, couldn't get it to work otherwise. I didn't have the time or need to mess around with it for very long, I was hoping fink would just do it, but I resorted to using a linux box instead because I had more important things to do at the time. I've pretty much gotten used to the fact that if I want to run X11 software (rarely) I should just do it on a linux box. -bob On Sunday, Mar 2, 2003, at 22:09 America/New_York, Pete Versteegen wrote: > Hi Bob, > > You seem to imply having a problem with Fink. Could you elaborate on > the > reservations you have about Fink? > > Thanks! > > On 3/2/03 8:51 PM, "Bob Ippolito" wrote: > >> On Sunday, Mar 2, 2003, at 20:04 America/New_York, John W Baxter >> wrote: >> >>> And, just to stir things up (actually, it's a serious question), what >>> impact will Apple's X11 implementation have, when it becomes part of >>> the >>> Mac OS X install CDs (really optional? pseudo-optional like BSD >>> subsystem? >>> part of the base?)? Or final but acquired separately. >>> >>> Should person hours being devoted to making X11 things work in Cocoa >>> be >>> shifted to something else? If X11 will be "acquired separately" >>> probably >>> not. >> >> As far as I can tell, it's pretty worthless without fink, because it >> doesn't come with any useful libraries (gnome, kde, etc). Also, I >> don't think these libraries are available anywhere without fink. >> >> If you need fink anyways, what good is Apple's X11 distribution? I >> don't particularly want to install fink. >> >> -bob >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@cwi.nl Mon Mar 3 09:41:31 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 3 Mar 2003 10:41:31 +0100 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: Message-ID: <505EE8D2-4D5C-11D7-9525-0030655234CE@cwi.nl> On Monday, Mar 3, 2003, at 04:09 Europe/Amsterdam, Pete Versteegen wrote: > Hi Bob, > > You seem to imply having a problem with Fink. Could you elaborate on > the > reservations you have about Fink? I'm not 100% happy with fink either. I'm using it now on one machine, because it's the only reasonable way to get readline support in Python at the moment (not to mention latex so I can finally work on the Python documentation myself), but it's already been breaking the Python build in subtle ways. Nothing serious, but just a bit of work each time. Every time I install something new with fink something else will be pulled in along, which is then used for the Python build but which has subtly different header files or something. And I'm not really aware I installed a new libncurses, just because some other fink package needs it... And it broke something seriously too: it put a new tar in /sw/bin/tar which is 100% incompatible with Apple's tar in /usr/bin (tarfiles created with /sw/bin/tar will yield 8.3 filenames when unpacked with Apple's tar. For crying out loud.....) But I'm only using it on one machine, so I can be reasonably sure that I don't contaminate the Python source tree with fink-isms. All that said, I think that fink is a brilliant tool for some category of people. Myself included, probably, I wouldn't have bothered installing LaTex and all that jazz without it. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Benjamin.Schollnick@usa.xerox.com Mon Mar 3 13:59:42 2003 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Mon, 03 Mar 2003 08:59:42 -0500 Subject: [Pythonmac-SIG] State of Python on the Mac Message-ID: <51B62EFFBC83D6118ADA00096BB030A11B35FE@USAMCMS7> Jack, > But for scripting I don't have any ideas yet. Something with Mail or > Address book or iTunes or so springs to mind, but I'm not really sure what. > Best would be something that is difficult or impossible to do in the host program. How about something so obvious it's funny? A perfect example for scripting with the Address book, is a application to print out a single record, with a "address book" look. It's possible to print a "directory" style listing, of *ALL* the entries... i.e. first1 last1 phone # address etc first2 last2 phone # address etc first3 last3 phone # address etc first4 last4 phone # address etc But I'd like to be able to highlite a single entry and have it print the equivalent of the address books single view... You could also demo easy dialogs, by asking what type of output... (i.e. export it to a PDF) i.e. first1 last1 company title phone1 phone2 .... mobile address notes I'm rather annoyed that the address book doesn't have this built in... (or at least the last time I tried this, it didn't).... - Benjamin From bob@redivi.com Mon Mar 3 16:13:18 2003 From: bob@redivi.com (Bob Ippolito) Date: Mon, 3 Mar 2003 11:13:18 -0500 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: <505EE8D2-4D5C-11D7-9525-0030655234CE@cwi.nl> Message-ID: <0C167960-4D93-11D7-84F6-000A95686CD8@redivi.com> On Monday, Mar 3, 2003, at 04:41 America/New_York, Jack Jansen wrote: > > On Monday, Mar 3, 2003, at 04:09 Europe/Amsterdam, Pete Versteegen > wrote: > >> Hi Bob, >> >> You seem to imply having a problem with Fink. Could you elaborate on >> the >> reservations you have about Fink? > > I'm not 100% happy with fink either. I'm using it now on one machine, > because it's the only reasonable way > to get readline support in Python at the moment (not to mention latex > so I can finally work on > the Python documentation myself), but it's already been breaking the > Python build in subtle ways. Nothing serious, but just a bit of work > each time. Every time I install > something new with fink something else will be pulled in along, which > is then used for the Python build > but which has subtly different header files or something. And I'm not > really aware I installed > a new libncurses, just because some other fink package needs it... Well, for TeX without Fink, I've always used TexShop -- http://www.uoregon.edu/~koch/texshop/texshop.html And for readline without Fink, have you seen /System/Library/PrivateFrameworks/readline.framework? I know bill bumgardner put together a package to build readline for the stock jaguar python using this framework (but www.friday.com is down). Perhaps this nasty little path can make it into the Python ./configure script or something? -bob From eppstein@ics.uci.edu Mon Mar 3 17:16:53 2003 From: eppstein@ics.uci.edu (David Eppstein) Date: Mon, 03 Mar 2003 09:16:53 -0800 Subject: [Pythonmac-SIG] Re: State of Python on the Mac References: <505EE8D2-4D5C-11D7-9525-0030655234CE@cwi.nl> Message-ID: In article <505EE8D2-4D5C-11D7-9525-0030655234CE@cwi.nl>, Jack Jansen wrote: > All that said, I think that fink is a brilliant tool for some category > of people. Myself included, probably, > I wouldn't have bothered installing LaTex and all that jazz without it. LaTeX, specifically, can be installed by the i-installer instead of fink: http://www.uoregon.edu/~koch/texshop/texshop.html -- David Eppstein http://www.ics.uci.edu/~eppstein/ Univ. of California, Irvine, School of Information & Computer Science From managan@llnl.gov Mon Mar 3 17:45:07 2003 From: managan@llnl.gov (Rob Managan) Date: Mon, 3 Mar 2003 09:45:07 -0800 Subject: [Pythonmac-SIG] Re: Readline on the Mac In-Reply-To: <0C167960-4D93-11D7-84F6-000A95686CD8@redivi.com> References: <0C167960-4D93-11D7-84F6-000A95686CD8@redivi.com> Message-ID: At 11:13 AM -0500 3/3/03, Bob Ippolito wrote: >And for readline without Fink, have you seen >/System/Library/PrivateFrameworks/readline.framework? I know bill >bumgardner put together a package to build readline for the stock >jaguar python using this framework (but www.friday.com is down). >Perhaps this nasty little path can make it into the Python >./configure script or something? > >-bob I know I tried this with one of my unix programs that uses readline and I could not straighten out how to point to the headers and stuff consistently. For Unix it wanted the headers in a readline directory and I could not figure out to coerce that from the framework setup which was different. I would love it of someone could tell me how to make this work! -- *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan LLNL ph: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From dsposx@mac.com Mon Mar 3 19:38:40 2003 From: dsposx@mac.com (Donovan Preston) Date: Mon, 3 Mar 2003 11:38:40 -0800 Subject: [Pythonmac-SIG] gensuitemodule on OS X Message-ID: --Apple-Mail-12--306356391 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hello, PythonMac. It's good to be back. Regarding modernizing gensuitemodule for use on Mac OS X, Jack, I have been working on this for a while (over a year in fact) but since I am doing it in my spare time I haven't polished it to the point where it's generally useful. I should have posted about it earlier, but I've been busy :-) Jack Jansen wrote: > I would love to do this in gensuitemodule, but there's bits and pieces > I don't know. Maybe someone can enlighten me? > > 1. Where is the ascr/gdte described? What is the return value, just > raw AEUT/AETE data, or is it somehow encoded in OSA objects? It doesn't seem to be formally described in any Apple documentation, at least not that I have been able to find. It seems to be a relatively well known event in both the Frontier and Perl communities, and the page that lead me to it's discovery is here: http://use.perl.org/~pudge/journal/3454 As for the return value, it comes back as an object with a data attribute containing the raw aete data. Check out this interactive session with the MacPython IDE 2.3 framework build: Python 2.3a1 (#1, Jan 21 2003, 13:46:55) [GCC 3.1 20020420 (prerelease)] Type "copyright", "credits" or "license" for more information. MacPython IDE 1.0.1 >>> import aetools >>> import sys >>> sys.path.append('/Users/dsp/python/dist/src/Mac/Scripts') >>> import gensuitemodule for_ >>> mail = aetools.TalkTo('emal') >>> mail._start() >>> aete = mail.send("ascr", "gdte") >>> decoded = gensuitemodule.decode(aete[1]['----'].data) >>> gensuitemodule.compileaete(decoded, None, "Mail") And after running compileaete and choosing all the correct folders, you have a module for talking to Mail. Totally cool! > 2. It appears there's a higher level interface too, because if I do > "get dictionary" in the script editor some applications are indeed > fired up, but some are not. So, it seems that sometimes the ascr/gdte > event is used to get the dictionary, but sometimes it's grabbed from > the resource fork. At least, it seems that way... Yes, I believe there is a higher level C interface for doing this as well. However, documentation is extremely lacking, and google is not terribly helpful in this regard :( Here is what I know: There appear to be two very similar functions, OSAGetAppTerminology and ASGetAppTerminology, which one can theoretically use to get back what I believe is the same object we got back in the interactive session above. I have attached an archive with a very simple extension module I was using to experiment with these APIs. I apologize in advance for inflicting this code on the world, as it is very incomplete and barely works. What the differences are between the APIs I am not sure, and why it works for some applications and not others I am also not sure. I think at this point the main stumbling block is that PromptGetFile, which I was using to get a filename to attempt to generate a suite module for, doesn't allow you to select bundles. With this code I am able to select InDesign and create a python module for it, and that's all I needed to do, so I didn't push any farther with it ;-) I'm not sure if Script Editor et al uses various methods for getting terminology or just one; if it tries the above API, then tries sending the ascr/gdte event and falls back to the resource fork if it doesn't work... > 3. Is there an API to get the "pick application" dialog that script > editor puts up when you do a get dictionary? The way it seems to find > scriptable applications all over the place I get the impression it > works together with launch services or something... I have no idea. This must be the case, because if you look at for example Address Book, it's creator code is '????' (Look inside the bundle at the PkgInfo file where the type and creator are cached; if it's not there, look in the plist) and it's therefore impossible to construct a TalkTo that talks to it. It must be possible, but the magic required to do it is beyond me. By the way, I submitted an OSCON proposal for a 45 minute talk on using Python to send AppleEvents on OS X. Hopefully, if it gets accepted and I therefore have to take the time to get some demos up and running with something other than InDesign, I will have a justifiable reason for working on this more. Also, there may be some people at the talk (perhaps from Apple) who would be able to shed some more light on some of these questions, and perhaps it would spark enough interest that other people would start helping too. I think Guido is responsible for picking proposals that get accepted, so let's hope he sees the value in all this :-) --Apple-Mail-12--306356391 Content-Disposition: attachment; filename=pyosa.tgz Content-Transfer-Encoding: base64 Content-Type: application/x-gzip; x-unix-mode=0644; name="pyosa.tgz" H4sIAAAAAAAAA+1a3U/bSBB3uD4Q3wuP97iXUxsH+YJNPizBcSJ8tIcENGq4vnDIZ+wNuDi2tV63 jRASf/rNfsQxSVtUqQnVdX8iGnt2dnZ2Zj07a5OOk8zb0BYKy2pbjuMAtSyn2+XU2mwLKqBBQ8ty NjutTkuzbMuxOhrqLNYsgTyjHkFIC7L0i3IgNhwuw6DlIuXxbx4M3AFNCF7IGBDPL8TfbsP6mIn/ ZqvraMhaiDUz+MHjD6js5YGtaWtwuaoJqj3/tOiq/M1hpaxP6lBQUFBQUFD4vlERZPXnpzVDQUHh OwTLD0jSXUnvBa3I9hVJn5X6rEmKJN2V9F7QipRbkfSZpKuSrkmKJN2V9F5QmbQq8vBRkSNX5Aml Ik8hFSTp7ldNWUHhh8FPgqyx/f9Q++z5X0FB4X+MyrODwcGeVhwI5gXg92/p+l77fBGwIl4W/lLq iyTdlfReUFUIKCgoKCwb4vuf64ZxSF23mY4XMAb7/tdttx/7/mvb3bbt2Pz7n+PY6vvfMiDif4Wp l6YUk1EYJ1FyNf6mC+GR+Nul77+tFpOzO7AEVPyXgSFJRsjDNEmiDIWjNCEUreucO/L8YYmny6v+ +PWgN7m5wnGWhxSPkiCPsK4Ps8xEyQ3aQX1QkdJXmL4MI2zUBzjCPkW9NI1C36NhEm/VTVTv9fvH 9QboHkKvLb3q4QBnfnL5zkSRl8f+NQ6YLjZkE3RB97PpIjVgtIZeTUkYU1T01KvE+wCd8jj1/Buj 4BeS0KxXYUAm5sUBo+fWRTPwqAcWMBPgChQIPnCKAYBf3NaOphbSa4zg+dmqTa3WqyAJfwH2k4BP 4qGrmqLBEFr54A3eZ0bMBy+CAyFC2JC6THSaxNhEMPuml7mpR69jb4SNBijAUYa35rWkJPFxlg1Z KOa7PfUaVHg6iPwvHjB/QWM8kv9blu3w/b9tt6x2l+V/W+3/S8JvYexHeYDRH/0xvU7iDUGa13/q 06Z9j1xCkyAPm2SvdAy7BdtELpOPTECHFXX5jmX8dZG93fnsPRFZRxmOhiaa3nvkKmugW73aOzyA 5I0gj6XbevXlYJBicScut1nG3IcMCfkwpkcxxCj2MQrw0MsjWjSA2MAnYUrD+Kpgig0pISx5n41T zISOYmp3J91LpkLbHswNezEKwuCYp3g+NkzskBBQggnhjNK0CaY5id96EW+A/cb4tT/ukSu375EM n+Up5GI2URPVXr+osemfeD5zk5ibiV5MJ9poSHXo9O/jY6YQzc0StpjXKY4PZtnGDVhZ3LKpmrBB ABBH3ct8Um9s6xsbJS7r8wrHmIT+J1yXX1JQA33ADJg5jAxmz8VBeMaYtRO6iS10aNQ+ZfAWeh78 E4NDQDOTFQNwe+h+TgiIHIQeC96cavDZfPDK40Gd6wsVgVDxpcEeLldk6Mwx1fkxBZ957AS259M8 iia8UgQnrHn7CuFiaT3orleZnzfWpWm9wVdb9q2sWN/QH3jy4YlhxpNQhU3WPy/g3L08jAK4yzGE /UVY44tQPN/uKf4gl7s5fcBYOOSiLz1Kd8wXYNk6Og4zipIhGmHIQEHGnocwhkorjHk9JitSBFbD cqShjzJKcp/Vrye8B6w7mZqkhvMLtKPfwqRva3M+rglvQM7afwnGsfq18bnEZjLJk8Ozv9y3vTe9 N68GnMF0QrnJ6sRJBZwhWg6Al7F2mfISnkaatTuTPWS37LE3Z4YXPMvkF3f6HThdf5+Egc7O8tw2 g902YE6Ql9wj4J5wpxg13spzTmn+4PC7p96OFJYMUf9l8ICli3n5oz3+/mezY0P91247XafjWPz9 T9tW//+9FPCTfgCpNKdhlMFxk+DJkZ8vChMdfqRwmISMo3OGwQ6NO0UGeY8Ja9up2U2LJf+P1BWZ N9s514uu04xzXpNnjdoFlyaeG4XxjcsqoZ3z+u9DAuo/JOSGvR0QBWf9onHR0J/aUQoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgrfOf4DVXBnwwBQAAA= --Apple-Mail-12--306356391-- From macpython@lopan.dccs.upenn.edu Tue Mar 4 20:23:08 2003 From: macpython@lopan.dccs.upenn.edu (John Speno) Date: Tue, 4 Mar 2003 15:23:08 -0500 Subject: [Pythonmac-SIG] Tkinter and the Help menu In-Reply-To: <20030228182439.GI1992@isc.upenn.edu> References: <20030228182439.GI1992@isc.upenn.edu> Message-ID: <20030304202308.GE10708@isc.upenn.edu> My original post is below. The gist of the problem was a funky 'Help' menu. It turns out that this only happened when running my script with pythonw. If I launched the script in its own application bundle, the 'Help' menu was correct. So, it looks like I can't count on pythonw to test my code. I don't get the difference between the two methods on the back end. Can somone explain it to me? Now, on to the next set of exceptions! *sigh* Thanks! On Fri, Feb 28, 2003 at 01:24:39PM -0500, John Speno wrote: > Platform: MacOS X 10.2.4, Python 2.3a2, Tcl and Tk 8.4.1 jaguar. > > Issue: In my application's Help menu, the first item is an extraneous 'x' > which I didn't put there, and can't seem to get rid of. Actually, when I > first switch to the application, each item in my Help menu is an 'x'. If I > switch to another app then back, my menu items have their names back, and > there's still the first mysterious 'x'. > > Anyone encounter that before? I suppose I can try the TOT build of > Tcl/Tk... > > Thanks! > > #!/usr/local/bin/pythonw > import Tkinter > > def hello(): > print "hello" > > root = Tkinter.Tk() > root.title('menubar test') > menubar = Tkinter.Menu(root) > helpmenu = Tkinter.Menu(menubar, name='help', tearoff=0) > menubar.add_cascade(label="Help", menu=helpmenu, underline=0) > addhelp = helpmenu.add_command > addhelp(label='Window Help', underline=0, command=hello, state='normal') > addhelp(label='Menu Help', underline=9, command=hello, state='normal') > helpmenu.add_separator() > addhelp(label='About Assignments', underline=0, command=hello) > root.configure(menu=menubar) > root.mainloop() From macpython@lopan.dccs.upenn.edu Tue Mar 4 21:50:56 2003 From: macpython@lopan.dccs.upenn.edu (John Speno) Date: Tue, 4 Mar 2003 16:50:56 -0500 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: <20030225222212.GH17602@cnri.reston.va.us> References: <20030225222212.GH17602@cnri.reston.va.us> Message-ID: <20030304215056.GG10708@isc.upenn.edu> On Tue, Feb 25, 2003 at 05:22:12PM -0500, Jason Petrone wrote: > On Tue, Feb 25, 2003 at 10:50:34PM +0100, Just van Rossum wrote: > > Jack Jansen wrote: > > > Yes, you should be able to get this to work, but you will have to > > > build the Python.framework yourself. I've been looking at creating > > > the framework in such a way that it would allow just copying > > > /Library/Frameworks/Python.framework > > > into a private frameworks directory, but I haven't gotten it to work. > > > (Or, in other words: if you *did* get this to work I would be very > > > interested). I think it is working already. See below. Or maybe you mean something different? > > > If you could write a howto document for doing this that would be very > > > helpful, I'd love to put such information on the MacPython website. > > > > My request would be simpler: write it down in simple steps so I can > > automate it in bundlebuilder.py ;-) > > I've been distributing a package from a framework build. I might be > doing something silly, but it works. I'm also using wxWindows, not > Tkinter. > > Basically, I just use bundlebuilder.py, but with three minor changes: > > 0) Under MyApp.app/Contents/MacOS I create a directory 'lib' and copy > any libraries needed(in my case, /usr/local/lib/libwx_mac-2.4*) > > 1) Under that new lib dir I also create a subdirectory > /Python.framework/Versions/2.3 and copy > /Library/Frameworks/Python.framework/Versions/2.3/Python to it. > > 2) I add the following lines to the start script generated by bundlebuilder: > DYLD_LIBRARY_PATH=${execdir}/lib > export DYLD_LIBRARY_PATH > DYLD_FRAMEWORK_PATH=${execdir}/lib > export DYLD_FRAMEWORK_PATH Since I started this thread, I had time to play around with this. It seems to be working just fine. I put the Python, Tcl and Tk frameworks in my app's Frameworks directory and set the DYLD*PATHs to match. I copied it to another machine and it launched normally. That was nice. From jpetrone@cnri.reston.va.us Tue Mar 4 22:33:23 2003 From: jpetrone@cnri.reston.va.us (Jason Petrone) Date: Tue, 4 Mar 2003 17:33:23 -0500 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: <20030304215056.GG10708@isc.upenn.edu> References: <20030225222212.GH17602@cnri.reston.va.us> <20030304215056.GG10708@isc.upenn.edu> Message-ID: <20030304223323.GE2113@cnri.reston.va.us> On Tue, Mar 04, 2003 at 04:50:56PM -0500, John Speno wrote: > On Tue, Feb 25, 2003 at 05:22:12PM -0500, Jason Petrone wrote: > > On Tue, Feb 25, 2003 at 10:50:34PM +0100, Just van Rossum wrote: > > > Jack Jansen wrote: > > > > Yes, you should be able to get this to work, but you will have to > > > > build the Python.framework yourself. I've been looking at creating > > > > the framework in such a way that it would allow just copying > > > > /Library/Frameworks/Python.framework > > > > into a private frameworks directory, but I haven't gotten it to work. > > > > (Or, in other words: if you *did* get this to work I would be very > > > > interested). > > I think it is working already. See below. > > Or maybe you mean something different? At any rate, it would be nice to see this go in bundlebuilder. I spent WAY too much time figuring out that little bit and it would be some consolation if I could save other people the trouble. If this approach isn't flawed, I'm happy to send diffs. Jason > > > > If you could write a howto document for doing this that would be very > > > > helpful, I'd love to put such information on the MacPython website. > > > > > > My request would be simpler: write it down in simple steps so I can > > > automate it in bundlebuilder.py ;-) > > > > I've been distributing a package from a framework build. I might be > > doing something silly, but it works. I'm also using wxWindows, not > > Tkinter. > > > > Basically, I just use bundlebuilder.py, but with three minor changes: > > > > 0) Under MyApp.app/Contents/MacOS I create a directory 'lib' and copy > > any libraries needed(in my case, /usr/local/lib/libwx_mac-2.4*) > > > > 1) Under that new lib dir I also create a subdirectory > > /Python.framework/Versions/2.3 and copy > > /Library/Frameworks/Python.framework/Versions/2.3/Python to it. > > > > 2) I add the following lines to the start script generated by bundlebuilder: > > DYLD_LIBRARY_PATH=${execdir}/lib > > export DYLD_LIBRARY_PATH > > DYLD_FRAMEWORK_PATH=${execdir}/lib > > export DYLD_FRAMEWORK_PATH > > Since I started this thread, I had time to play around with this. > > It seems to be working just fine. I put the Python, Tcl and Tk frameworks > in my app's Frameworks directory and set the DYLD*PATHs to match. I copied > it to another machine and it launched normally. That was nice. From Jack.Jansen@oratrix.com Tue Mar 4 23:27:36 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 5 Mar 2003 00:27:36 +0100 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: <20030304223323.GE2113@cnri.reston.va.us> Message-ID: You've just earned yourself a very large beer (or other beverage of your choice)! The DYLD_FRAMEWORK_PATH was investigated a long time ago, but at the time it wouldn't fly, because there really wasn't a place where we could set the variable. But now that applets are built with bundlebuilder and use a script for startup we *do* have such a place! Thanks for finding this! And, Just, in case you had thought of this already: yes, you can also have a beer. You know what: you can *all* come over to Amsterdam and have a beer:-) -- - 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 johann@surfbest.net Wed Mar 5 00:19:15 2003 From: johann@surfbest.net (Johann Hibschman) Date: Tue, 4 Mar 2003 16:19:15 -0800 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: Message-ID: <192E5C40-4EA0-11D7-A08A-003065B5C6B6@surfbest.net> On Tuesday, March 4, 2003, at 03:27 PM, Jack Jansen wrote: > You know what: you can *all* come over to Amsterdam and have a beer:-) Queensday! Party at Jack's place! Dibs on the couch! --Johann, who really should follow all of his crypto-geek friends to Amsterdam for Queensday one of these days From robin@alldunn.com Wed Mar 5 03:49:12 2003 From: robin@alldunn.com (Robin Dunn) Date: Tue, 04 Mar 2003 19:49:12 -0800 Subject: [Pythonmac-SIG] Tkinter and the Help menu In-Reply-To: <20030304202308.GE10708@isc.upenn.edu> References: <20030228182439.GI1992@isc.upenn.edu> <20030304202308.GE10708@isc.upenn.edu> Message-ID: <3E6573B8.90303@alldunn.com> John Speno wrote: > My original post is below. The gist of the problem was a funky 'Help' menu. > > It turns out that this only happened when running my script with pythonw. > If I launched the script in its own application bundle, the 'Help' menu was > correct. > > So, it looks like I can't count on pythonw to test my code. I don't get the > difference between the two methods on the back end. Can somone explain it > to me? > wxPython apps run with pythonw get it too. I assume it's because the resources for Python.app have it defined. Jack, can this be removed? -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From robin@alldunn.com Wed Mar 5 03:50:32 2003 From: robin@alldunn.com (Robin Dunn) Date: Tue, 04 Mar 2003 19:50:32 -0800 Subject: [Pythonmac-SIG] Q on Robin Dunn's installer In-Reply-To: References: Message-ID: <3E657408.8020803@alldunn.com> Tom Fetherston wrote: > This is a forward of a question on a sourceforge list: > ========================================================= > > The MacPython OS X installer does not work for me. When I try to install > it it says: > > You cannot install this software on this disk. (null) > > I'm not sure what the problem is. I used a directive stating that it could only be installed on the root partition, but apparently that cased problems on some systems. > > Does your pythonw script say simply > > #!/bin/sh > exec /usr/local/bin/python "$@" It should have a lot more in it than that it should exec the python that is in the Python.app deep down in the Python.framework... > > That is the script I have found and it doesn't seem to work for me (with > a source build of python 2.3a and TkAqua 8.4.1). When I try to bring a > Tk window to front I get the error: > > SetFrontProcess failed, -606 > ========================================================== > Any ideas? > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From robin@alldunn.com Wed Mar 5 03:55:06 2003 From: robin@alldunn.com (Robin Dunn) Date: Tue, 04 Mar 2003 19:55:06 -0800 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: References: Message-ID: <3E65751A.4030300@alldunn.com> Jack Jansen wrote: > You've just earned yourself a very large beer (or other beverage of your > choice)! > > The DYLD_FRAMEWORK_PATH was investigated a long time ago, but at the > time it > wouldn't fly, because there really wasn't a place where we could set the > variable. > But now that applets are built with bundlebuilder and use a script for > startup we > *do* have such a place! Thanks for finding this! > There's already a patch at SF to add part of this to bundlebuilder. See #681927. It was submitted by me, but the patch was written by Kevin Oliver. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From Jack.Jansen@cwi.nl Wed Mar 5 09:26:25 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 5 Mar 2003 10:26:25 +0100 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: <192E5C40-4EA0-11D7-A08A-003065B5C6B6@surfbest.net> Message-ID: <892019BB-4EEC-11D7-8E6A-0030655234CE@cwi.nl> On Wednesday, Mar 5, 2003, at 01:19 Europe/Amsterdam, Johann Hibschman wrote: > On Tuesday, March 4, 2003, at 03:27 PM, Jack Jansen wrote: > >> You know what: you can *all* come over to Amsterdam and have a beer:-) > > Queensday! Party at Jack's place! Dibs on the couch! Good idea, but be warned that you will be forced to listen to *both* my bands (Uit de Sloot and Chemical War Babies) playing. At least that will probably up the beer-intake:-) -- 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 Wed Mar 5 17:33:04 2003 From: managan@llnl.gov (Rob Managan) Date: Wed, 5 Mar 2003 09:33:04 -0800 Subject: [Pythonmac-SIG] Re: Readline on the Mac In-Reply-To: References: <0C167960-4D93-11D7-84F6-000A95686CD8@redivi.com> Message-ID: I finally answered my own question! I am able to use the framework version of readline with standard Unix apps when I put these sym links in ln -s /System/Library/PrivateFrameworks/readline.framework/Headers readline ln -s /System/Library/PrivateFrameworks/readline.framework/readline /usr/local/lib/libreadline.a This gives the #include syntax that is needed. The second line lets my old makefile find the library. > >I know I tried this with one of my unix programs that uses readline >and I could not straighten out how to point to the headers and stuff >consistently. For Unix it wanted the headers in a readline directory >and I could not figure out to coerce that from the framework setup >which was different. > -- *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan LLNL ph: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From webmaster@pferdemarkt.ws Thu Mar 6 14:13:13 2003 From: webmaster@pferdemarkt.ws (webmaster@pferdemarkt.ws) Date: Thu, 6 Mar 2003 06:13:13 -0800 Subject: [Pythonmac-SIG] Pferdemarkt.ws informiert! Newsletter 03/2003 http://www.pferdemarkt.ws Message-ID: <200303061413.GAA26339@eagle.he.net> http://www.pferdemarkt.ws Wir sind in 2003 erfolgreich in des neue \"Pferdejahr 2003 gestartet. Für den schnellen Erfolg unseres Marktes möchten wir uns bei Ihnen bedanken. Heute am 06.03.2003 sind wir gut 2 Monate Online! Täglich wächst unsere Datenbank um 30 Neue Angebote. Stellen auch Sie als Privatperson Ihre zu verkaufenden Pferde direkt und vollkommen kostenlos ins Internet. Zur besseren Sichtbarmachung Ihrer Angebote können Sie bis zu ein Bild zu Ihrer Pferdeanzeige kostenlos einstellen! Wollen Sie direkt auf die erste Seite, dann können wir Ihnen unser Bonussystem empfehlen. klicken Sie hier: http://www.pferdemarkt.ws/bestellung.html Ihr http://Pferdemarkt.ws Team Klicken Sie hier um sich direkt einzuloggen http://www.Pferdemarkt.ws Kostenlos Anbieten, Kostenlos Suchen! Direkt von Privat zu Privat! Haben Sie noch Fragen mailto: webmaster@pferdemarkt.ws From csmith@blakeschool.org Thu Mar 6 14:43:25 2003 From: csmith@blakeschool.org (Christopher Smith) Date: Thu, 06 Mar 2003 08:43:25 -0600 Subject: [Pythonmac-SIG] problems reloading modules from desktop Message-ID: Some time ago, someone posted a function that refreshes the namespace. I incorporated this function into the _run function of PyEdit so the namespace is automatically refreshed when "Run" is pressed in the IDE. This has been really useful for the Intro Comp Sci class that I am teaching. I have now uncovered a problem: In a nut shell: the refreshing algorithm works if it occurs within the script being run, but if the refreshing is done in the _run of PyEdit, it does not work when the module to be imported is on the desktop (but it does work if the module is in Python's Lib folder). It appears that Python loses track of the desktop as a place to look for the module. I have this problem under OS 9.2 with Python 2.2 and 2.2.2. Here's a more detailed set of circumstances that do and don't work. This works to reload a modified module from the desktop: ### #unmodified PyEdit import myModule reload(myModule) ### This works, too: ### #unmodified PyEdit def reset(namespace): for item in namespace.keys(): if str(type(namespace[item]))=="": exec "reload("+item+")" in namespace reset(vars()) import myModule ### The following only works if myModule is put into the Lib folder instead of being on the desktop. If it is on the desktop, the file loads the first time but then it doesn't load the 2nd time--a complaint is made: ImportError: no module named myModule #This is how PyEdit has been modified . . . def _run(self): if self.run_with_interpreter: . . unmodified . else: pytext = self.editgroup.editor.get() globals, file, modname = self.getenvironment() #-------cps addition---------------------------------- for item in globals.keys(): if str(type(globals[item]))=="": exec "reload("+item+")" in globals #-------end cps addition---------------------------------- self.execstring(pytext, globals, globals, file, modname) . . . # here is the main script import myModule ### It seems that Python is loosing track of the desktop (the location of the current script) as part of the searchpath. Does anyone have an idea how to remedy this or what the problem might actually be? /c From just@letterror.com Thu Mar 6 15:52:34 2003 From: just@letterror.com (Just van Rossum) Date: Thu, 6 Mar 2003 16:52:34 +0100 Subject: [Pythonmac-SIG] problems reloading modules from desktop In-Reply-To: Message-ID: Christopher Smith wrote: > #This is how PyEdit has been modified > .. > .. > .. > def _run(self): > if self.run_with_interpreter: > . > . unmodified > . > else: > pytext = self.editgroup.editor.get() > globals, file, modname = self.getenvironment() > #-------cps addition---------------------------------- > for item in globals.keys(): > if str(type(globals[item]))=="": > exec "reload("+item+")" in globals > #-------end cps addition---------------------------------- > self.execstring(pytext, globals, globals, file, modname) > .. While this may work in some cases, it's not doing it recursively. But that's quite a dangerous thing to do, as when you reload a module in which there's a class that the IDE itself subclasses, you may break the IDE... Btw. _running_ a module source in the IDE is more or less equivalent to reloading it. My workflow goes like this: edit a module, run it, run script. It's not perfect, but works quite well. (I think you can read between the lines that I'm not eager to accept a patch that does automatic reloading...) Btw. if you still insist on auto reloading: you really shouldn't use exec here. This should work just as well: reload(globals[item]) Just From JAMES.E.SCARBOROUGH@saic.com Thu Mar 6 19:34:10 2003 From: JAMES.E.SCARBOROUGH@saic.com (James E. Scarborough) Date: Thu, 6 Mar 2003 14:34:10 -0500 Subject: [Pythonmac-SIG] Pmw.OptionMenu woes Message-ID: <9AD00DB2-500A-11D7-BAED-000A9575F3AC@saic.com> Hi, Here's a puzzle that has me stumped. The following code segment (which works fine on our Linux box) shows that you can't open a dialog as a result of the command event on a Pmw.OptionMenu, and then change the value of the Pmw.OptionMenu that pops up in the resulting window. I'm running MacOS X with Python 2.2.2, Pmw 1.1, and Tk 8.4.1. Why this example? I've developed a Python app on the Linux box and am trying to port it to the Mac. With hardly any effort it seems to work - except for this detail - and the menu bar shows up across the top of the root window implemented as Pmw.OptionMenu items. Several menu items open dialog boxes that use Pmw.OptionMenus. I tried launching a new thread with thread.start_new_thread(...) and immediately got a spectacular crash - apparently start_new_thread isn't the right approach. Did I miss something obvious? Has my mostly-Java background led me astray? Any hints on how I might get this example - or something very much like it - to work are much appreciated. Many thanks, Jim import Pmw from Tkinter import * def execute(result): dialog.deactivate(result) print "Result=" + `result` def _simpleDialogTest(*argv): globals()['dialog']=dialog=Pmw.Dialog( root.winfo_toplevel(), buttons=['Ok','Cancel'], defaultbutton='Ok', title='test', command=execute) hull=dialog.component('hull') menu=Pmw.OptionMenu(hull,items=['a','b','c','d'],initialitem='b') menu.pack(fill=BOTH,expand=1) dialog.activate() root=Tk() rootMenu=Pmw.OptionMenu(root,items=['greetings','salutations','hi'],comm and=_simpleDialogTest) rootMenu.pack(fill=BOTH,expand=1) root.mainloop() From jackjansen@mac.com Fri Mar 7 10:10:50 2003 From: jackjansen@mac.com (Jack Jansen) Date: Fri, 7 Mar 2003 11:10:50 +0100 Subject: [Pythonmac-SIG] Reloading modules in the IDE Message-ID: <12C61137-5085-11D7-B6EA-0030655234CE@mac.com> On donderdag, maa 6, 2003, at 16:52 Europe/Amsterdam, Just van Rossum wrote: > Btw. _running_ a module source in the IDE is more or less equivalent to > reloading it. My workflow goes like this: edit a module, run it, run > script. It's not perfect, but works quite well. That's a good one! How about warning for this on save, and offering to do the "run" for you? It should be easy enough to loop over sys.moduledict and look at __file__ attributes... -- 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 jharmon@adobe.com Fri Mar 7 16:21:21 2003 From: jharmon@adobe.com (JR) Date: Fri, 07 Mar 2003 08:21:21 -0800 Subject: [Pythonmac-SIG] comp.lang.python ?: startup script Message-ID: Is there a method whereby one can trigger a script at interpreter init without going to extremes like hacking into site.py et al.? Inquisitively yours, JR From dsposx@mac.com Fri Mar 7 18:08:11 2003 From: dsposx@mac.com (Donovan Preston) Date: Fri, 7 Mar 2003 10:08:11 -0800 Subject: [Pythonmac-SIG] comp.lang.python ?: startup script In-Reply-To: Message-ID: On Friday, March 7, 2003, at 08:21 AM, JR wrote: > Is there a method whereby one can trigger a script at interpreter init > without going to extremes like hacking into site.py et al.? > > Inquisitively yours, > JR There are two techniques I like to use. One is to set the PYTHONSTARTUP environment variable which, surprise surprise, runs the specified script each time you start the interpreter. :) The other, which you should note overrides the PYTHONSTARTUP value, is to pass the script on the command line like so: python -i foo.py Which runs foo.py and then drops you into the interpreter afterwards. Of course, I'm assuming you're using raw unix python or Framework python -- for OS 9/CFM Carbon MacPython the process is probably different, and I don't know what it is. Donovan From jharmon@adobe.com Fri Mar 7 19:09:24 2003 From: jharmon@adobe.com (JR) Date: Fri, 07 Mar 2003 11:09:24 -0800 Subject: [Pythonmac-SIG] comp.lang.python ?: startup script In-Reply-To: Message-ID: on 2003/03/07 10:08 AM, Donovan Preston mentioned: > There are two techniques I like to use. One is to set the PYTHONSTARTUP > environment variable which, surprise surprise, runs the specified > script each time you start the interpreter. :) The other, which you > should note overrides the PYTHONSTARTUP value, is to pass the script on > the command line like so: > > python -i foo.py > > Which runs foo.py and then drops you into the interpreter afterwards. > > Of course, I'm assuming you're using raw unix python or Framework > python -- for OS 9/CFM Carbon MacPython the process is probably > different, and I don't know what it is. While we use various forms of Python. On Mac OS we currently are required to leverage MacPython (for CFM vs. MachO reasons). How does one make MacPython respond to the various PYTHON env variables? Does PYTHONSTARTUP exec after all "normal" interpreter intialization completes? JR From just@letterror.com Fri Mar 7 20:09:29 2003 From: just@letterror.com (Just van Rossum) Date: Fri, 7 Mar 2003 21:09:29 +0100 Subject: [Pythonmac-SIG] comp.lang.python ?: startup script In-Reply-To: Message-ID: JR wrote: > While we use various forms of Python. On Mac OS we currently are > required to leverage MacPython (for CFM vs. MachO reasons). How does > one make MacPython respond to the various PYTHON env variables? > > Does PYTHONSTARTUP exec after all "normal" interpreter intialization > completes? I don't think you can. But there's sitecustomize.py: create one, place it somewhere along sys.path, it will be imported by site.py. Just From robin@alldunn.com Sat Mar 8 01:04:29 2003 From: robin@alldunn.com (Robin Dunn) Date: Fri, 07 Mar 2003 17:04:29 -0800 Subject: [Pythonmac-SIG] ANNOUNCE: wxPython 2.4.0.4 Message-ID: <3E69419D.7060100@alldunn.com> wxPython 2.4.0.4 is now available for download at http://wxpython.org/download.php wxPython is a popular cross platform GUI toolkit for the Python language that supports running Python apps on Win32, Mac OSX, and Linux/Unix systems, using native widgets and therefore natiove look and feel on the respective plafroms. From the webpage given above you can download source code, documentation and pre-built wxPython packages for various platforms and for various versions of Python (2.1, 2.2 or 2.3, except for OS X which only has a build for 2.3) Here is a list of changes since the last release: 2.4.0.4 ------- Added missing wxRect methods Add OOR support for wxApp objects too. Added wxCursorFromImage, which works on wxMSW and wxGTK so far. All platforms now send EVT_DESTROY_WINDOW. Be warned that at the time the event is sent the window is in the process of being deconstructed, and so calling some (most?) methods of the window itself may cause problems. Fixed SF Bug #689481, a method in the OGL wrappers was using the wrong return type. Fixed SF Bug #689958, an endless loop in printout.py. Added EVT_WINDOW_CREATE_ID and EVT_WINDOW_DESTROY_ID so these events can be associated with a specific window ID and more easily caught by the parent window. Fixed copy-paste error in wxListCtrl.GetFirstSelected. Added missing Init method (and an overloading wrapper) to wxLocale wrapper. Added a wxBitmap.SetMaskColour convenience method. Changed how the dynamic event tables (used for all Python wx classes, C++ wx classes typically use static event tables) are searched such that they behave from a Python perspective more like the static tables in C++. Namely that if there are identical event bindings in a base Python class and a derived Python class that the one in the derived class will be found first and that if Skip is called that the one in the base class will still be found instead of skipping directly to the static stable in the C++ class. Switched to using True/False in the wxPython lib and demo instead of true/false or TRUE/FALSE to prepare for the new boolean type and constants being added to Python. Added code to wx.py to test for the existence of the new constants and to create suitable values if not present. Added some static wxApp functions that help with integration with the Mac UI. They are no-ops on other platforms so it doesn't hurt to always call them. The functions are: wxApp_GetMacDefaultEncodingIsPC wxApp_GetMacSupportPCMenuShortcuts wxApp_GetMacAboutMenuItemId wxApp_GetMacPreferencesMenuItemId wxApp_GetMacExitMenuItemId wxApp_GetMacHelpMenuTitleName wxApp_SetMacDefaultEncodingIsPC wxApp_SetMacSupportPCMenuShortcuts wxApp_SetMacAboutMenuItemId wxApp_SetMacPreferencesMenuItemId wxApp_SetMacExitMenuItemId wxApp_SetMacHelpMenuTitleName Refactored, enhanced and added capabilites for the DrawXXXList functions, inspired by code from Chris Barker. The wxWindows .mo language catalog files are now installed in a subdirectory of the wxPython package dir on MSW since that platform doesn't have a standard place for them. Added missing deselect methods for wxGrid. Fixed typemaps for wxGridCellCoordsArray. Updated to the 0.9a version of PyCrust -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From andrew.straw@adelaide.edu.au Sat Mar 8 04:35:56 2003 From: andrew.straw@adelaide.edu.au (Andrew Straw) Date: Sat, 8 Mar 2003 15:05:56 +1030 Subject: [Pythonmac-SIG] Re: Readline on the Mac In-Reply-To: Message-ID: <74389029-511F-11D7-BE1D-00039311EA24@adelaide.edu.au> I've gotten readline to work doing this: 1) Use the setup.py listed below (slightly modified from one Bill Bumgartner posted several months ago) 2) Download and un-tgz the GNU readline package in /path/to/readline 3) Get the python source code for your current version of python in /path/to/python 4) follow the following commands: mkdir my_python_readline_module_src cd my_python_readline_module_src # copy the setup.py (listed below) into this directory # point ./readline/readline.h to the readline.h you just downloaded ln -s /path/to/readline readline # point ./readline.c to the readline.c from the Python source ln -s /path/to/python/Modules/readline.c readline.c sudo python setup.py install ========== setup.py ================ #!/usr/bin/env python from distutils.core import setup, Extension import os import sys if not (sys.platform == 'darwin') or \ not os.path.exists('/System/Library/PrivateFrameworks/readline.framework'): print "no point running this on a system other than OS X w/dev tools." sys.exit(1) setup (name = "readline", description = "readline package for OS X python", author = "readline.c came straight from Python source", author_email = "bbum@codefab.com", url = "http://www.python.org", ext_modules = [ Extension("readline", ["readline.c"], include_dirs=['.'], extra_compile_args=[ "-g", "-O0", "-DMACOSX", ], extra_link_args=[ '-g', '-F/System/Library/PrivateFrameworks/', '-framework', 'readline' ]) ] ) ======== end of setup.py ============= PS My version of /System/Library/PrivateFrameworks/readline.framework/ doesn't have the Headers directory, which is why you have to download the GNU headers. PPS How does Apple deal with the GPL-ness of readline? I don't see any mention of GNU or the GPL in the PrivateFrameworks version. Maybe they've got a private, non-GNU, readline-compatible library? If so, why don't they make their own headers? (Maybe because it would be difficult/impossible to make a readline header without violating the copyright?) On Thursday, March 6, 2003, at 04:03 AM, Rob Managan wrote: > I finally answered my own question! > > I am able to use the framework version of readline with standard Unix > apps when I put these sym links in > > ln -s /System/Library/PrivateFrameworks/readline.framework/Headers > readline > ln -s /System/Library/PrivateFrameworks/readline.framework/readline > /usr/local/lib/libreadline.a > > This gives the #include syntax that is needed. > The second line lets my old makefile find the library. > >> >> I know I tried this with one of my unix programs that uses readline >> and I could not straighten out how to point to the headers and stuff >> consistently. For Unix it wanted the headers in a readline directory >> and I could not figure out to coerce that from the framework setup >> which was different. >> > > -- > *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- > Rob Managan > LLNL ph: 925-423-0903 > P.O. Box 808, L-095 FAX: 925-422-3389 > Livermore, CA 94551-0808 > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From deleeuw@stat.ucla.edu Sun Mar 9 02:43:26 2003 From: deleeuw@stat.ucla.edu (Jan de Leeuw) Date: Sat, 8 Mar 2003 18:43:26 -0800 Subject: [Pythonmac-SIG] IDLE problem with Tcl/Tk 8.5 Message-ID: I have a problem with IDLE and Tcl/Tk 8.5 (using framework builds). Any mouse or keyboard event in IDLE gives Exception in Tkinter callback Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- tk/Tkinter.py", line 1311, in __call__ args = apply(self.subst, args) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- tk/Tkinter.py", line 1046, in _substitute e.height = getint(h) ValueError: invalid literal for int(): ?? On the other hand double-clicking Tkinter.py does run it from the terminal and puts up the usual dialog. === Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; Editor: Journal of Multivariate Analysis, Journal of Statistical Software US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554 phone (310)-825-9550; fax (310)-206-5658; email: deleeuw@stat.ucla.edu homepage: http://gifi.stat.ucla.edu ------------------------------------------------------------------------ ------------------------- No matter where you go, there you are. --- Buckaroo Banzai http://gifi.stat.ucla.edu/sounds/nomatter.au ------------------------------------------------------------------------ ------------------------- From macpython@lopan.dccs.upenn.edu Sun Mar 9 03:51:25 2003 From: macpython@lopan.dccs.upenn.edu (John Speno) Date: Sat, 8 Mar 2003 22:51:25 -0500 Subject: [Pythonmac-SIG] IDLE problem with Tcl/Tk 8.5 In-Reply-To: References: Message-ID: <20030309035125.GQ14781@isc.upenn.edu> On Sat, Mar 08, 2003 at 06:43:26PM -0800, Jan de Leeuw wrote: > I have a problem with IDLE and Tcl/Tk 8.5 (using framework > builds). Any mouse or keyboard event in IDLE gives > > Exception in Tkinter callback > Traceback (most recent call last): > File > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- > tk/Tkinter.py", line 1311, in __call__ > args = apply(self.subst, args) > File > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- > tk/Tkinter.py", line 1046, in _substitute > e.height = getint(h) > ValueError: invalid literal for int(): ?? It's a new "feature" of Tk 8.4.2. I filled a Python bug on it: http://sourceforge.net/tracker/index.php?func=detail&aid=698517&group_id=5470&atid=105470 I wrapped every call to getint() in Tkinter.py's _substitute function like so: try: e.height = getint(h) except ValueError: pass And that seems to work fine. From leoweb@cox.net Sun Mar 9 07:43:17 2003 From: leoweb@cox.net (Leo) Date: Sat, 08 Mar 2003 23:43:17 -0800 Subject: [Pythonmac-SIG] printing , in interpreter vs. IDE - both wrong? Message-ID: Hi. I just joined this list as I'm doing work on Python on the Mac. I hope this forum is suitable for these questions. Couldn't find the Mac FAQ, and dejanews didn't quite answer this (although I found other issues with ) and couldn't find anything relevant in Release notes or other docs. Problem: I get a blank line where there should be text, when I print a simple (HTTP request) string containing \r\n\r\n. Similarly, I get blank lines when I print the response I get from the remote server (which also contains several pairs). For debugging purposes (see testcrlf), (1) when running in the interpreter, I get a blank line instead of a string, when the string ends in \r\n ; (2) Python_IDE does not substitute blank line for the string but prints an additional blank line - and why is running via the IDE giving different output than via Interpeter? I'm using Mac distribution 2.2.2 (on Mac OS 9.2.2 / G4 with 300+ MB's of RAM.) THE DEBUG CODE: def testcrlf(): print "===" #one blank line between two lines #with sequence (NOTE ORDER of \r, \n) #Note disappearing first line in output, #in PythonInterpreter but not in PythonIDE msg = "One Line Followed by\r\n\r\nOneBlankLine" print msg print "===" #one blank line between two lines #with sequence (NOTE ORDER of \r, \n) #Output is correct on screen, #but order would not be proper for HTTP request msg = "One Line Followed by\n\r\n\rOneBlankLine" print msg print "===" THE OUTPUT ON INTERPRETER: === OneBlankLine === One Line Followed by OneBlankLine === THE OUTPUT ON Python_IDE: === One Line Followed by OneBlankLine === One Line Followed by OneBlankLine === For what it's worth, here's the ultimate use of all the above: def httpget(theUrl): # using code from "Python Cookbook" remote_host=theUrl remote_port=80 msg = "GET / HTTP/1.0\r\n\r\n" # Create a socket sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # Connect to the remote host and port sock.connect ((remote_host, remote_port)) #Send a request to the host sock.send(msg) print msg print "Here is the response" #Get the host's response, no more than, say, 1024 bytes response_data = sock.recv(1024) print response_data #Terminate sock.close() From Jack.Jansen@oratrix.com Sun Mar 9 23:34:44 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 10 Mar 2003 00:34:44 +0100 Subject: [Pythonmac-SIG] Proofreaders needed - minimal intro to the IDE Message-ID: Folks, I adapted Danny Yoo's "One day of IDLE toying" for the MacPython IDE, and I could use proofreaders. If you have a moment please visit http://www.cwi.nl/~jack/macpython_ide_tutorial and let me know what you think. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bugbee@seanet.com Mon Mar 10 07:45:19 2003 From: bugbee@seanet.com (bugs) Date: Sun, 9 Mar 2003 23:45:19 -0800 Subject: [Pythonmac-SIG] 2.3a2 and Tk 8.4 -- missing Buttons Message-ID: <3DE9B06D-52CC-11D7-AB8D-000393DB272E@seanet.com> --Apple-Mail-19-255642921 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Here is a minimalist program to demonstrate a problem of missing buttons when using Tkinter. This and the parent program run just fine under Windows. Can someone else confirm the problem? ...and let me know where I should file the bug report. Tk? MacPython? Thanks Larry --Apple-Mail-19-255642921 Content-Disposition: attachment Content-Type: multipart/appledouble; boundary=Apple-Mail-20-255642921 --Apple-Mail-20-255642921 Content-Disposition: attachment; filename=noOKbtn.py Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="noOKbtn.py" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAJAAAAMgAAAAoAAAADAAAAPAAAAApURVhUZG9z YQEAbm9PS2J0bi5weQ== --Apple-Mail-20-255642921 Content-Disposition: attachment; filename=noOKbtn.py Content-Transfer-Encoding: quoted-printable Content-Type: text/x-setext; x-mac-creator=646F7361; x-unix-mode=0700; x-mac-type=54455854; name="noOKbtn.py" #!/Library/Frameworks/Python.framework/Versions/2.3/bin/python=0D =0D """=0D This is a minimalist program to demonstrate a problem with = Tkinter not=0D painting all the widgets in a window, in this case, an OK = button. This =0D code works fine with Python 2.2.2 under Windows.=0D =0D Larry Bugbee=0D March 2003=0D """=0D =0D import os, sys, string=0D from Tkinter import *=0D =0D = #-------------------------------------------------------------------------= ------=0D =0D class TkDemo:=0D =0D pgmname =3D 'noOKbtn'=0D =0D def __init__(self):=0D self.buildGUI()=0D self.root.mainloop()=0D =0D def buildGUI(self):=0D root =3D Tk()=0D root.title(self.pgmname)=0D root.geometry('+200+100') # screen = location=0D pallet =3D Frame(root)=0D Label(pallet, text=3D'\nPlease click the Demo = button.\n').pack(side=3DTOP)=0D button2 =3D Button(pallet, text=3D"Demo...", = command=3Dself.showMsg, width=3D8)=0D button2.pack(side=3DLEFT, padx=3D20, pady=3D10)=0D button5 =3D Button(pallet, text=3D'Quit', = command=3Droot.destroy, width=3D8)=0D button5.pack(side=3DRIGHT, padx=3D20, pady=3D10)=0D pallet.pack()=0D self.root =3D root=0D =0D def showMsg(self):=0D msgtxt =3D 'No OK button?\nClick in resize (lower right) = to see it.'=0D msgDlg =3D Toplevel(self.root)=0D msgDlg.title('Message')=0D msgDlg.geometry('+190+100') # screen = location=0D msg =3D Label(msgDlg, text=3Dmsgtxt)=0D msg.pack(side=3DTOP, padx=3D20, pady=3D10)=0D btn =3D Button(msgDlg, text=3D'OK', = command=3Dself.msgDlgOK, width=3D8)=0D btn.pack(side=3DBOTTOM, pady=3D10)=0D # btn.bind('', self.msgDlgOK)=0D # btn.focus_set()=0D self.msgDlg =3D msgDlg=0D # msgDlg.mainloop()=0D =0D def msgDlgOK(self, event=3DNone):=0D self.msgDlg.destroy()=0D =0D = #-------------------------------------------------------------------------= ------=0D =0D #if __name__ =3D=3D '__main__':=0D if 1:=0D # which version? ...should there be multiple versions = installed.=0D import sys=0D print '\nPython', sys.version=0D =0D import _tkinter=0D print 'Tk: ', float(_tkinter.TK_VERSION)=0D print 'Tcl:', float(_tkinter.TCL_VERSION)=0D =0D print '\nsys.argv:', sys.argv=0D print '\nSearchlist:'=0D for i in sys.path:=0D print ' ', i=0D print '-'*80=0D =0D TkDemo()=0D =0D = #-------------------------------------------------------------------------= ------=0D = #-------------------------------------------------------------------------= ------=0D = #-------------------------------------------------------------------------= ------=0D --Apple-Mail-20-255642921-- --Apple-Mail-19-255642921 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-19-255642921-- From Jack.Jansen@cwi.nl Mon Mar 10 10:10:03 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 10 Mar 2003 11:10:03 +0100 Subject: [Pythonmac-SIG] 2.3a2 and Tk 8.4 -- missing Buttons In-Reply-To: <3DE9B06D-52CC-11D7-AB8D-000393DB272E@seanet.com> Message-ID: <75BFA6A4-52E0-11D7-A7CA-0030655234CE@cwi.nl> On Monday, Mar 10, 2003, at 08:45 Europe/Amsterdam, bugs wrote: > Here is a minimalist program to demonstrate a problem of missing > buttons when using Tkinter. This and the parent program run just fine > under Windows. > > Can someone else confirm the problem? I see the same problem (Python 2.3 from CVS). My guess is that this is a Tk error, but to confirm that the program would have to be converted to Tcl, so we could forward it to the MacTk folks. At the very least, could you file a Python bug report, and attach your script? -- 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 Mar 10 15:41:13 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 10 Mar 2003 16:41:13 +0100 Subject: [Pythonmac-SIG] More proofreading - MacPython Help Message-ID: Folks, more proofreading to be done: I've finished a first draft of what is going to be the "MacPython Help" in the 2.3 installer. If you can spare half an hour please read it at . Don't hesitate to comment on anything (my ego is small, especially wrt. writing documentation, and my skin is thick too:-): text, layout, organization, whether anything essential is missing, etc etc etc. The quick IDE tour is now integrated into this set of pages. -- 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 dyoo@hkn.eecs.berkeley.edu Mon Mar 10 16:51:40 2003 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Mon, 10 Mar 2003 08:51:40 -0800 (PST) Subject: [Pythonmac-SIG] More proofreading - MacPython Help In-Reply-To: Message-ID: On Mon, 10 Mar 2003, Jack Jansen wrote: > Folks, more proofreading to be done: I've finished a first draft of what > is going to be the "MacPython Help" in the 2.3 installer. If you can > spare half an hour please read it at > . Don't hesitate to comment on > anything (my ego is small, especially wrt. writing documentation, and my > skin is thick too:-): text, layout, organization, whether anything > essential is missing, etc etc etc. > > The quick IDE tour is now integrated into this set of pages. Hi Jack, It looks great! I like your screenshots a lot. I've noticed that the 'IDE Toying page' is slightly shorter because it doesn't mention how to open a source file; is this something that we can assume is already known to the user? Also, on the last line: The File->Save as Applet menu command saves your script... got me slightly confused for a moment; I was parsing it as: The "File->Save as" Applet menu command saves your script... I read it that way because "Save As" is very common in Mac applications, but "Save as Applet" is less so. Would it be possible to reword this as: The Application Saver (File->Save as Applet) menu command saves your script... This fits in more closely with the style of the description of the module browser. Alternatively, distinguishing the menu commands typographically would be another way to avoid potential confusion. From p.oberndoerfer@urheberrecht.org Mon Mar 10 17:39:53 2003 From: p.oberndoerfer@urheberrecht.org (Pascal Oberndoerfer) Date: Mon, 10 Mar 2003 18:39:53 +0100 Subject: [Pythonmac-SIG] More proofreading - MacPython Help In-Reply-To: Message-ID: Jack Jansen at Jack.Jansen@cwi.nl: > Folks, > more proofreading to be done: I've finished a first draft of what is > going to be > the "MacPython Help" in the 2.3 installer. If you can spare half an > hour please > read it at . Don't hesitate to > comment > on anything (my ego is small, especially wrt. writing documentation, > and my skin > is thick too:-): text, layout, organization, whether anything essential > is missing, > etc etc etc. > > The quick IDE tour is now integrated into this set of pages. Very nice! Concerning "Running Python scripts from the Unix Shell": As far as I know /usr/local/bin was included on the path for 10.1.5 . At least on my machine. Pascal From owen@astro.washington.edu Mon Mar 10 18:01:24 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Mon, 10 Mar 2003 10:01:24 -0800 Subject: [Pythonmac-SIG] 2.3a2 and Tk 8.4 -- missing Buttons Message-ID: I see the same bug here (framework Python 2.2.2, aqua Tk 8.4.1). I reduced your demo to a minimal Tk script (appended) which proves the bug is in aqua Tk 8.4.1. I submitted bug report 219419 on the "Tk Toolkit". -- Russell button .demo -text "Demo" -command { toplevel .dlg label .dlg.txt -text "No OK button?\nClick in resize (lower right) to see it." pack .dlg.txt button .dlg.but -text "OK" -command { destroy .msgdlg } pack .dlg.but } pack .demo From zen@shangri-la.dropbear.id.au Tue Mar 11 07:16:16 2003 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Tue, 11 Mar 2003 18:16:16 +1100 Subject: [Pythonmac-SIG] Mail.app and python prompt munging Message-ID: <59759284-5391-11D7-BC8B-000393B63DDC@shangri-la.dropbear.id.au> Has anyone worked out how to configure the Mail application shipped with OS X to not munge '>' characters in email into coloured '|' characters? If I can solve this and force text in the message composer to wrap on 80 characters I'll finally have a Mail client I won't bitch at. -- Stuart Bishop http://shangri-la.dropbear.id.au/ From jbelog@mac.com Tue Mar 11 15:48:40 2003 From: jbelog@mac.com (Joel Belog) Date: Tue, 11 Mar 2003 10:48:40 -0500 Subject: [Pythonmac-SIG] MacCvsX multiple menu items ... also cannot quit Message-ID: --Apple-Mail-2-371043802 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello All After installing Python 2.3a2 and TCL/TK 8.4.2, I'm running into some=20 weird menu errors on MacCvsX 3.3a2 (which requires Python 2.3). I am getting 2 Menus of MacCvsX, File, and Edit.=A0 Each pair has=20 different commands in them. The first MacCvsX menu item has About MacCVS,=A0 Credits, and Copyrights ... the second has About TCL & TK and the normal mac application menu items (preferences, quit, etc).=A0 Has anyone seen this?=A0 Is there a fix? Could it be that I'm running = the=20 latest TCL & TK frameworks and there's something going on between the=20 TCL/TK and MacCVS? Any information or help would be much appreciated. Thank you in advance. Joel Belog= --Apple-Mail-2-371043802 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=ISO-8859-1 Hello All After installing Python 2.3a2 and TCL/TK 8.4.2, I'm running into some weird menu errors on MacCvsX 3.3a2 (which requires Python 2.3). I am getting 2 Menus of MacCvsX, File, and Edit.=A0 Each pair has different commands in them. The first MacCvsX menu item has About MacCVS,=A0 Credits, and Copyrights ... the second has About TCL & TK and the normal mac application menu items (preferences, quit, etc).=A0=20 Has anyone seen this?=A0 Is there a fix? Could it be that I'm running the latest TCL & TK frameworks and there's something going on between the TCL/TK and MacCVS? Any information or help would be much appreciated. Thank you in advance. Joel Belog= --Apple-Mail-2-371043802-- From andy@reportlab.com Tue Mar 11 18:18:05 2003 From: andy@reportlab.com (Andy Robinson) Date: Tue, 11 Mar 2003 18:18:05 -0000 Subject: [Pythonmac-SIG] Building PPC Mac extension modules - newbie help! Message-ID: I am trying to port a Python-and-C library to the Mac (Classic) for a customer. If I succeed, ReportLab will be doing binary distributions of our Open Source software on OS 9 (Classic) and OS X henceforth. If I fail, I get hung drawn and quartered by an angry customer. We potentially have the help of one of the main MacPython luminaries, but he's away this week and I have to at least make a start by myself. First of all let me explain just how little I know about this platform. I just bought a Mac (iMac 600, dual boot OS X 10.2 and 9.2) and CodeWarrior 8) and did a full developer install of Python 2.2.2 (configured as Classic running under OS 9 for now). Unfortunately there's just too many "new" things about this platform. For example I spent 1.5 hours last night figuring out how to type a # sign so I could do 'hello world' in C :-) First task is to build some standard extension modules we have. These build fine with distutils on Windows and Unix. The docs (Mac/Demos/building.html) tell me I don't need to rebuild Python first, and to look at "xx.prj". The nearest match I can find to this is Mac/Build/ which contains xx.mcp and its kin. Is this the same thing? If so, CodeWarrior converts this template to version 8 and complains about lack of GUSI. So, do I need to download all the components and rebuild Python first to build extensions? Second stage is to build an embedded example. There seems to be an example in the source, which I'll tackle after step 1. Third stage is to make a compact distribution. I'm looking for a way to do something like freeze or BuildApplication, but making a -library- not an -application-. Can anyone give hints on how this is possible? I am very happy to send in patches to docco as a result of this work, and we are obliged to publish detailed how-to's for our customer, so I'll try to make sure this ends up as good published documentation for beginners if I succeed. Thanks very much in advance, Andy Robinson CEO/Chief Architect, ReportLab Inc. From Martina@Oefelein.de Tue Mar 11 19:02:31 2003 From: Martina@Oefelein.de (Martina Oefelein) Date: Tue, 11 Mar 2003 20:02:31 +0100 Subject: [Pythonmac-SIG] Mail.app and python prompt munging In-Reply-To: <59759284-5391-11D7-BC8B-000393B63DDC@shangri-la.dropbear.id.au> Message-ID: <02F1775C-53F4-11D7-92A2-000A27979162@Oefelein.de> Hi Stuart, > Has anyone worked out how to configure the Mail application shipped > with OS X to not munge '>' characters in email into coloured '|' > characters? I don't know whether you can configure it, but you can always use Cmd+Option+U to view the raw text (with >>> characters) ciao Martina From Jack.Jansen@oratrix.com Tue Mar 11 21:46:23 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 11 Mar 2003 22:46:23 +0100 Subject: [Pythonmac-SIG] Building PPC Mac extension modules - newbie help! In-Reply-To: Message-ID: On dinsdag, maa 11, 2003, at 19:18 Europe/Amsterdam, Andy Robinson wrote: > The docs (Mac/Demos/building.html) tell me I don't need to > rebuild Python first, and to look at "xx.prj". The nearest > match I can find to this is Mac/Build/ which contains xx.mcp > and its kin. Is this the same thing? Yes, it's the same thing. .prj was the old name, I'll change the documentation. That file was *horribly* outdated, I'm sorry for that. I don't have time to do a real rewrite, but I'll update it a bit. > If so, CodeWarrior converts this template to version 8 and complains > about lack of GUSI. So, do I need to download all the components and > rebuild Python first to build extensions? Yes, in your case I think you need GUSI. Download it via , you need a rather special GUSI to build Python. See :Mac:Demo:building.html for how to build it and where to put it. > Second stage is to build an embedded example. There seems to > be an example in the source, which I'll tackle after step 1. > > Third stage is to make a compact distribution. I'm looking > for a way to do something like freeze or BuildApplication, > but making a -library- not an -application-. Can anyone > give hints on how this is possible? See :Mac:Demo:freezing.html. This isn't a recipe for what you want to do, but it does contain most of the interesting information. Bascially, you want to end up with the Python PYC resources (the stuff that is normally in .pyc files) in the resource fork of your library, and you want the library to be on sys.path. This latter is a bit of MacPython-magic: if there is a file on sys.path (as opposed to a directory) we start looking for PYC resources in that file. Here's a quick and dirty idea that might work: 1. Run BuildApplication on your main Python script. This creates a useless application (because you want a shared library), but you can now easily grab all the 'PYC ' resources from this application, and put them in a resource file (let's call it andy.rsrc). If you don't want to manually fiddle the BuildApplication output it should be reasonably simple to adapt BuildApplication so it creates this .rsrc file for you in stead of a fullblown application. 2. Create a project for your shared library. I'd say start with the PythonCore project, and add your own stuff and andy.rsrc. See embed.html for how to embed on the mac (the initialization entry point is different). 3. Now you only need to get your shared library in sys.path. It's a bit tricky to get at the filename for a shared library form within that shared library, basically you ned to define an initialization entrypoint routine and in that routine stow away the FSSpec for your library. You can then pick this up later, turn it into a filename and put it on sys.path. For an example of something similar (although this code only wants to open the resource fork of the shared lib) look in _tkinter.c, routines init_tkinter_shlib (which is used as the shared lib init routine) and mac_addlibresources. If anything doesn't work as you expect (or as I say here:-) don't hesitate to contact me. This should all be possibly, but i don't know whether it has actually ever been done by anyone. -- - 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 andy@reportlab.com Tue Mar 11 23:22:29 2003 From: andy@reportlab.com (Andy Robinson) Date: Tue, 11 Mar 2003 23:22:29 -0000 Subject: [Pythonmac-SIG] Building PPC Mac extension modules - newbie help! In-Reply-To: Message-ID: > Yes, it's the same thing. .prj was the old name, I'll change the > documentation. > That file was *horribly* outdated, I'm sorry for that. I don't have > time to do > a real rewrite, but I'll update it a bit. Thanks, Jack! No need to rewrite now, I'll do a document for you and everyone once this works. > Yes, in your case I think you need GUSI. Download it via > , > you need a rather special GUSI to build Python. > See :Mac:Demo:building.html for how to build it and where to put it. What misled me was the bullet point in "odds and ends" about only needing standard Python to build extensions. I interpreted this to mean "I don't need GUSI" but that was wrong. I hope you don't mind me asking REALLY obvious sounding things but these are usually the ones people get wrong on a new platform. 1. Your document suggests "GUSI2" and "GUSI2Carbon" directories. I presume this is just a matter of duplicating the contents of your SIT file, so one can build all the bits twice, and that I should not have found 2 different downloads? 2. I am now using your GUSI and your MacPython source distribution. Most things (GUSI, buildlibs) start to build but give loads of error messages. The most common one is this: Error: identifier time_t redeclared, was "unsigned long" now "long" Does this mean changes are needed for CodeWarrior 8 because MetroWerks updated their libraries? Are there any standard settings or preferences one needs to set in CodeWarrior to start building things? Are you actually using version 8? Thanks, Andy p.s. Thanks very much for your suggestions below. It all sounds like it will be great once I get set up properly and in general I think the documentation and examples are excellent... From kevino@tulane.edu Wed Mar 12 22:01:33 2003 From: kevino@tulane.edu (Kevin Ollivier) Date: Wed, 12 Mar 2003 14:01:33 -0800 Subject: [Pythonmac-SIG] Working with the PPM Message-ID: <303105C4-54D6-11D7-AA54-000A9575C8EE@tulane.edu> Hi all, I've gotten a chance to work with the Python Package Manager, and thought I'd post my comments/experiences here. First, the bug: =) When I ran the PPM, I tried to install the Python Imaging Library. The install seems to have gone correctly (all the files are there), but the program froze up and I had to perform a "force quit". PPM showed the package as installed when I restarted it. Now, I will admit I'm trying this on a non-standard setup. My iMac's video card choked and the new part was back-ordered, so I'm booting the iMac HD by hooking it up to my Powerbook via Firewire target mode while I await the new part. =) So it could be the situation is unique to booting from other volumes than the root volume. Now, the questions: 1. Will it really install the Apple Dev Tools if you don't have them??? This would really, really, rock. =) Just van Rossum was discussing the use of otool for bundlebuilder.py, but otool only comes with the ADT, so having the ability to install prereq apps in general would be very cool. 2. Where's the database? =) I'm curious to see how it is set up, but sniffing through the PPM code I don't see any filename listed. I could be missing something, but it seems to just magically know where to load the file from. 3. Is this compatible with the new "Python Package Index" on the Python web site? I know these are both very new initiatives, so I was just wondering. =) 4. What's the timeframe for a 2.3 Python final release, and how much further were you hoping/planning on going with it before then? That's it for now. I think this tool has great potential - just clicking a button to install makes the whole process a no brainer. Thanks for taking the time out to put this together! Kevin From andy@reportlab.com Wed Mar 12 00:37:00 2003 From: andy@reportlab.com (Andy Robinson) Date: Wed, 12 Mar 2003 00:37:00 -0000 Subject: [Pythonmac-SIG] Building PPC Mac extension modules - newbie help! In-Reply-To: Message-ID: > 2. I am now using your GUSI and your MacPython source distribution. > Most things (GUSI, buildlibs) start to build but give loads of error > messages. The most common one is this: > Error: identifier time_t redeclared, was "unsigned long" now "long" > As a quick hack I commented out "typedef long time_t" in MSL:MSL_C:MSL_Common:Include:ctime and things get a LOT further. - The 'xx' example actually builds and imports into Python. So, it seems one can build extensions without building full Python - The PythonStandAloneSmall project now gets a very long way, but complains about the GUSI lib files. - GUSI gets much further too but still gives lots of errors that are beyond me. The last 2 are beyond my C abilities to fix now but I can at least make progress on the extensions. If anyone does have working project files for CW8 that would be great, if not I will try to make them myself in due course. Thanks, Andy Robinson From robin@alldunn.com Wed Mar 12 06:30:43 2003 From: robin@alldunn.com (Robin Dunn) Date: Tue, 11 Mar 2003 22:30:43 -0800 Subject: [Pythonmac-SIG] ANNOUNCE: wxPython 2.4.0.5 Message-ID: <3E6ED413.2070103@alldunn.com> Close on the heels of 2.4.04, wxPython 2.4.0.5 is now available for download at http://wxpython.org/download.php wxPython is a popular cross platform GUI toolkit for the Python language that supports running Python apps on Win32, Mac OSX, and Linux/Unix systems, using native widgets and therefore natiove look and feel on the respective plafroms. From the webpage given above you can download source code, documentation and pre-built wxPython packages for various platforms and for various versions of Python (2.1, 2.2 or 2.3, except for OS X which only has a build for 2.3) The 2.4.0.5 release solves several small but annoying bugs, and includes updates of the colourchooser and PyCrust pacakges. For details of the 2.4.0.4 or earlier releases please look here: http://wxpython.org/CHANGES.txt -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From Jack.Jansen@cwi.nl Wed Mar 12 11:05:32 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 12 Mar 2003 12:05:32 +0100 Subject: [Pythonmac-SIG] Building PPC Mac extension modules - newbie help! In-Reply-To: Message-ID: <8ABAAFF4-547A-11D7-B4B7-0030655234CE@cwi.nl> On Wednesday, Mar 12, 2003, at 00:22 Europe/Amsterdam, Andy Robinson wrote: >> Yes, in your case I think you need GUSI. Download it via >> , >> you need a rather special GUSI to build Python. >> See :Mac:Demo:building.html for how to build it and where to put it. > > What misled me was the bullet point in "odds and ends" about only > needing standard Python to build extensions. I interpreted this > to mean "I don't need GUSI" but that was wrong. You can do without GUSI, but only if you build only an extension module, and if you're 100% sure that that extension module does no Unix I/O calls (sockets, select, low-level open/close/read/write I/O, etc). In your case you're going to need GUSI anyways, because you're going to embed Python later on, so you might as well build it up front. > 1. Your document suggests "GUSI2" and "GUSI2Carbon" directories. > I presume this is just a matter of duplicating the contents of > your SIT file, so one can build all the bits twice, and that I > should not have found 2 different downloads? Nowadays there's only one GUSI directory, the contents are what you downloaded from the MacPython page. The project files in the "projects" folder will build all flavors of the libraries. > 2. I am now using your GUSI and your MacPython source distribution. > Most things (GUSI, buildlibs) start to build but give loads of error > messages. The most common one is this: > Error: identifier time_t redeclared, was "unsigned long" now "long" > > Does this mean changes are needed for CodeWarrior 8 because MetroWerks > updated their libraries? Are there any standard settings or > preferences > one needs to set in CodeWarrior to start building things? Are you > actually using version 8? I think CW7 versus CW8 could be the problem. I'm still using 7, and I don't think I'll shell out the money to upgrade. Alexandre Parenteau is using 8, though, I think, so maybe he can answer this? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen@cwi.nl Wed Mar 12 13:06:25 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 12 Mar 2003 14:06:25 +0100 Subject: [Pythonmac-SIG] Working with the PPM In-Reply-To: <303105C4-54D6-11D7-AA54-000A9575C8EE@tulane.edu> Message-ID: <6E5C5C15-548B-11D7-B4B7-0030655234CE@cwi.nl> On Wednesday, Mar 12, 2003, at 23:01 Europe/Amsterdam, Kevin Ollivier wrote: > Hi all, > > I've gotten a chance to work with the Python Package Manager, and > thought I'd post my comments/experiences here. Thanks!! This is only the second report I got, so I'd really want to press the point again to the rest of the people on the list: please try the PackageManager, and send feedback! > > When I ran the PPM, I tried to install the Python Imaging Library. The > install seems to have gone correctly (all the files are there), but > the program froze up and I had to perform a "force quit". PPM showed > the package as installed when I restarted it. I haven't seen anything like this. Could you try to repeat it? Repeating should be easy: remove the stuff in site-packages and try again. Maybe try with Verbose "on" this time. If it fails again on the second try I'd like some more information: - Which Python (2.3a2 or current CVS) - Which MacOS version - Did you use the standalone PackageManager or the one in the IDE? I did just notice that there's a bug with the PIL setup script if you have Tk installed, if this causes your problem too the Verbose should make that clear. And I have to do something about this fact not being communicated to the end user if verbose is off. > 1. Will it really install the Apple Dev Tools if you don't have > them??? This would really, really, rock. =) Just van Rossum was > discussing the use of otool for bundlebuilder.py, but otool only comes > with the ADT, so having the ability to install prereq apps in general > would be very cool. Try it:-) The answer is: no, PackageManager will not install it for you, but it will give you some pointers on how to get it. The intention is that PackageManager does one thing well, in stead of being a be-all-end-all solution. > 2. Where's the database? =) I'm curious to see how it is set up, but > sniffing through the PPM code I don't see any filename listed. I could > be missing something, but it seems to just magically know where to > load the file from. Look in Lib/plat-mac/pimp.py, DEFAULT_PIMPDATABASE. The URL for the database is constructed from a static part plus distutils-style platform name. > 3. Is this compatible with the new "Python Package Index" on the > Python web site? I know these are both very new initiatives, so I was > just wondering. =) They are complementary. After 2.3 is out I'm going to do a PEP on an install manager for Python, and I'll use the experience with pimp as input for that. > 4. What's the timeframe for a 2.3 Python final release, and how much > further were you hoping/planning on going with it before then? I assume 2.3 final is going to happen some time this summer. I'm not planning to do much with pimp before that time, except for fixing bugs. I do want to have a fairly generous set of packages available by the time 2.3 comes out, though. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From ryanwilcox@mac.com Wed Mar 12 15:37:56 2003 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Wed, 12 Mar 2003 10:37:56 -0500 Subject: [Pythonmac-SIG] Working with the PPM In-Reply-To: <6E5C5C15-548B-11D7-B4B7-0030655234CE@cwi.nl> Message-ID: On Wednesday, March 12, 2003, at 2:06 PM, Jack Jansen wrote: > >On Wednesday, Mar 12, 2003, at 23:01 Europe/Amsterdam, Kevin Ollivier >wrote: > >> Hi all, >> >> I've gotten a chance to work with the Python Package Manager, and >> thought I'd post my comments/experiences here. As much as I hate to be stupid, here are some questions... #1: Will pimp build wxPython? ;) #2: What is required to get pimp set up on a machine? Downloading the unix release of 2.3a? Checking out from CVS? As I was going to try out 2.3(MachO) wxWindows hopefully this weekend, I'll let Jack know about my experiences... maybe I'll even write some documentation (if it's lacking) Thanks!, -Ryan Wilcox --------------------------------- Wilcox Design: Understanding Data From kevino@tulane.edu Wed Mar 12 15:07:01 2003 From: kevino@tulane.edu (Kevin Ollivier) Date: Wed, 12 Mar 2003 07:07:01 -0800 Subject: [Pythonmac-SIG] Working with the PPM In-Reply-To: Message-ID: <47050FF8-549C-11D7-AA55-000A9575C8EE@tulane.edu> On Wednesday, March 12, 2003, at 07:37 AM, Ryan Wilcox wrote: > On Wednesday, March 12, 2003, at 2:06 PM, Jack Jansen wrote: > >> >> On Wednesday, Mar 12, 2003, at 23:01 Europe/Amsterdam, Kevin Ollivier >> wrote: >> >>> Hi all, >>> >>> I've gotten a chance to work with the Python Package Manager, and >>> thought I'd post my comments/experiences here. > > As much as I hate to be stupid, here are some questions... > > #1: Will pimp build wxPython? ;) Not yet, but it should in future releases. That's one of the reasons I'm playing with it right now. =) > #2: What is required to get pimp set up on a machine? Downloading the > unix release of 2.3a? Checking out from CVS? Robin Dunn has built a package of MacPython 2.3a2 for OS X, which includes the PIMP. =) Get it from the Mac OS X binaries section of wxPython.org: http://www.wxpython.org/download.php#binaries Of course, the latest wxPython will work with this build! ;-) > As I was going to try out 2.3(MachO) wxWindows hopefully this weekend, > I'll let Jack know about my experiences... maybe I'll even write some > documentation (if it's lacking) Thanks! Kevin From kevino@tulane.edu Wed Mar 12 15:51:28 2003 From: kevino@tulane.edu (Kevin Ollivier) Date: Wed, 12 Mar 2003 07:51:28 -0800 Subject: [Pythonmac-SIG] Working with the PPM In-Reply-To: <6E5C5C15-548B-11D7-B4B7-0030655234CE@cwi.nl> Message-ID: <7C9E5B4F-54A2-11D7-AA55-000A9575C8EE@tulane.edu> On Wednesday, March 12, 2003, at 05:06 AM, Jack Jansen wrote: > > On Wednesday, Mar 12, 2003, at 23:01 Europe/Amsterdam, Kevin Ollivier > wrote: > >> Hi all, >> >> I've gotten a chance to work with the Python Package Manager, and >> thought I'd post my comments/experiences here. > > Thanks!! This is only the second report I got, so I'd really want to > press the point again to the rest of the > people on the list: please try the PackageManager, and send feedback! >> >> When I ran the PPM, I tried to install the Python Imaging Library. >> The install seems to have gone correctly (all the files are there), >> but the program froze up and I had to perform a "force quit". PPM >> showed the package as installed when I restarted it. > > I haven't seen anything like this. Could you try to repeat it? > Repeating should be easy: remove the stuff in site-packages > and try again. Maybe try with Verbose "on" this time. If it fails > again on the second try I'd like some more information: > - Which Python (2.3a2 or current CVS) > - Which MacOS version > - Did you use the standalone PackageManager or the one in the IDE? > > I did just notice that there's a bug with the PIL setup script if you > have Tk installed, if this causes your problem too the Verbose should > make that clear. And I have to do something about this fact not being > communicated to the end user if verbose is off. Oddly enough, I can't reproduce this. After deleting and re-installing, both with and without the verbose options, it works fine. I've installed most of the other packages on the list without problems as well. If I can figure out what I did, I'll let you know. ^_^; BTW, I don't have Tkinter installed. Related to this, is it possible to move the install scripts to a separate thread? WIth or without the verbose option, I get the spinning beachball over the main window during the entire install. (i.e. No status updates, etc.) Most of the modules are pretty small, but some of the bigger ones may make it look like the app is frozen. > >> 1. Will it really install the Apple Dev Tools if you don't have >> them??? This would really, really, rock. =) Just van Rossum was >> discussing the use of otool for bundlebuilder.py, but otool only >> comes with the ADT, so having the ability to install prereq apps in >> general would be very cool. > > Try it:-) > > The answer is: no, PackageManager will not install it for you, but it > will give you some pointers on how to get it. > The intention is that PackageManager does one thing well, in stead of > being a be-all-end-all solution. This in itself is very helpful. Being able to list ADT (or other system libraries) as a prereq will let users know what they need to do to get everything going. >> 2. Where's the database? =) I'm curious to see how it is set up, but >> sniffing through the PPM code I don't see any filename listed. I >> could be missing something, but it seems to just magically know where >> to load the file from. > > Look in Lib/plat-mac/pimp.py, DEFAULT_PIMPDATABASE. The URL for the > database is constructed from a static part plus distutils-style > platform name. Ah, so it is on the web! =) Thanks, I'll take a look at the format! >> 3. Is this compatible with the new "Python Package Index" on the >> Python web site? I know these are both very new initiatives, so I was >> just wondering. =) > > They are complementary. After 2.3 is out I'm going to do a PEP on an > install manager for Python, and I'll use the > experience with pimp as input for that. > >> 4. What's the timeframe for a 2.3 Python final release, and how much >> further were you hoping/planning on going with it before then? > > I assume 2.3 final is going to happen some time this summer. I'm not > planning to do much with pimp before that time, except for fixing > bugs. I do want to have a fairly generous set of packages available by > the time 2.3 comes out, though. I'll see about what it would take to add wxPython, and probably pyXML as well. These are the packages I'm familiar with installing on MacPython. Two small suggestions: 1. Is it possible to shrink the space used for the "package installed" row (the yes/no row)? It seems the fields are given equal percentages of the screen space. 2. I wasn't really sure about what the Recursive and Force options did at first. What do you think about changing the names to "Install Dependencies" and "Overwrite"? Thanks, Kevin From kevin@macosx.com Wed Mar 12 18:19:55 2003 From: kevin@macosx.com (kevin parks) Date: Thu, 13 Mar 2003 03:19:55 +0900 Subject: [Pythonmac-SIG] Both pythons living in harmony? In-Reply-To: <20030312165201.13179.85231.Mailman@mail.python.org> Message-ID: <39AEDF1D-54B7-11D7-BBE0-003065555ABC@macosx.com> Hi. I have a remedial question. I have been living and working with the python that comes built in with Jaguar, with the addition of bbbbbbum's readlines, but i am a bit anxious to try Jack's Python fork/built/flavor/whatever. However i am afraid installing this will somehow clobber my preexisting jaguar python. Will the "Jack Python" play nice with my "Apple python" or will it fondle my system create more havoc than my life needs now. I wanna try the pretty IDE (even if it still doesn't have any syntax coloring). But i don't want to ruin my ability to hack Python in BBedit and execute scripts in the terminal, which i am happily doing now. I finally got my path and cr*p all set. 2. do i gots to build it meself or is there a package I can just double click on? If it is a hassle maybe i ought to just keep on keeping on with the Apple supplied no frills build... Perhaps i am being to careful.... cheers, kevin (dreams of a single integrated unix/mac python w/IDE... w/syntax coloring) From owen@astro.washington.edu Wed Mar 12 19:22:09 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Wed, 12 Mar 2003 11:22:09 -0800 Subject: [Pythonmac-SIG] More proofreading - MacPython Help Message-ID: Pascal wrote: >Concerning "Running Python scripts from the Unix Shell": >As far as I know /usr/local/bin was included on the path for 10.1.5 . At >least on my machine. I am sure /usr/local/bin is not part of the standard path in Jaguar (at least on my system). I had to add it myself. I added it to .cshrc as follows: setenv PATH "/usr/local/bin:"$PATH I think I had to do that for my installation of 10.1.x, as well, but I wouldn't swear to it. -- Russell From larry.bugbee@boeing.com Wed Mar 12 19:34:34 2003 From: larry.bugbee@boeing.com (Bugbee, Larry) Date: Wed, 12 Mar 2003 11:34:34 -0800 Subject: [Pythonmac-SIG] More proofreading - MacPython Help Message-ID: <8CFC81BC2CC2A74F88BAB7180F00B779E06709@XCH-NW-29.nw.nos.boeing.com> It is my recollection that /usr/local/bin was part of the PATH on = install. ...moving it to the front is non-standard. But then again, I could be having a senior moment... =20 Larry -----Original Message----- From: Russell E Owen [mailto:owen@astro.washington.edu] Sent: Wednesday, March 12, 2003 11:22 AM To: Mac Python mailing list Subject: Re: [Pythonmac-SIG] More proofreading - MacPython Help Pascal wrote: >Concerning "Running Python scripts from the Unix Shell": >As far as I know /usr/local/bin was included on the path for 10.1.5 . = At >least on my machine. I am sure /usr/local/bin is not part of the standard path in Jaguar=20 (at least on my system). I had to add it myself. I added it to .cshrc=20 as follows: setenv PATH "/usr/local/bin:"$PATH I think I had to do that for my installation of 10.1.x, as well, but=20 I wouldn't swear to it. -- Russell _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From oussoren@cistron.nl Wed Mar 12 19:42:10 2003 From: oussoren@cistron.nl (Ronald Oussoren) Date: Wed, 12 Mar 2003 20:42:10 +0100 Subject: [Pythonmac-SIG] More proofreading - MacPython Help In-Reply-To: <8CFC81BC2CC2A74F88BAB7180F00B779E06709@XCH-NW-29.nw.nos.boeing.com> Message-ID: On Wednesday, Mar 12, 2003, at 20:34 Europe/Amsterdam, Bugbee, Larry wrote: > It is my recollection that /usr/local/bin was part of the PATH on > install. ...moving it to the front is non-standard. On a system with an empty profile/cshrc I do not have /usr/local/bin on my PATH (OSX 10.2). I'm pretty sure it was on the PATH in 10.1. Ronald From francois.granger@free.fr Wed Mar 12 20:14:21 2003 From: francois.granger@free.fr (Francois Granger) Date: Wed, 12 Mar 2003 21:14:21 +0100 Subject: [Pythonmac-SIG] Both pythons living in harmony? In-Reply-To: <39AEDF1D-54B7-11D7-BBE0-003065555ABC@macosx.com> References: <39AEDF1D-54B7-11D7-BBE0-003065555ABC@macosx.com> Message-ID: At 03:19 +0900 13/03/2003, in message [Pythonmac-SIG] Both pythons living in harmony?, kevin parks wrote: >Hi. I have a remedial question. I have been living and working with >the python that comes built in with Jaguar, with the addition of >bbbbbbum's readlines, but i am a bit anxious to try Jack's Python >fork/built/flavor/whatever. However i am afraid installing this will >somehow clobber my preexisting jaguar python. Will the "Jack Python" >play nice with my "Apple python" or will it fondle my system create >more havoc than my life needs now. I wanna try the pretty IDE (even >if it still doesn't have any syntax coloring). But i don't want to >ruin my ability to hack Python in BBedit and execute scripts in the >terminal, which i am happily doing now. I finally got my path and >cr*p all set. > >2. do i gots to build it meself or is there a package I can just >double click on? I have three Python almost happily living on my Mac: - Old Mac Python, Apple Python and new MacOSX Python. I got the latest from: http://sourceforge.net/project/showfiles.php?group_id=10718 bottom of the page. -- Hofstadter's Law : It always takes longer than you expect, even when you take into account Hofstadter's Law. From andrew.straw@adelaide.edu.au Thu Mar 13 07:24:54 2003 From: andrew.straw@adelaide.edu.au (Andrew Straw) Date: Thu, 13 Mar 2003 17:54:54 +1030 Subject: [Pythonmac-SIG] pygame/PyOpenGL "kitchensink" distribution of Python2.3a2 available Message-ID: I have recently released a Python2.3a2 "kitchensink" build featuring pygame and PyOpenGL for Mac OS X. I would like for people to test this and get back to me with any comments. It's currently available through the Vision Egg website at . After a test period, we are planning on moving it to the pygame site, and then hopefully integrate it into PacakageManager. After you've gotten pygame (the API), you might want some pygames. The pygame website at is a great starting point. I recommend SolarWolf at Cheers! Andrew From jjb5@cornell.edu Thu Mar 13 14:42:24 2003 From: jjb5@cornell.edu (Joel Bender) Date: Thu, 13 Mar 2003 09:42:24 -0500 Subject: [Pythonmac-SIG] 4Suite install - linker issues Message-ID: Hi, I'm working with someone at Fourthought to get the current version of 4Suite XML tools to install. Truth be told, he's doing most of the work since I'm clueless. The current problem is to resolve symbol conflicts in PyXML's pyexpat and 4Suite's cDomlette. The patch that he sent me uses an ld flag called -exported_symbols_list, but my version of ld doesn't have it. He wrote: > Unfortunately, it looks like this is a feature added Oct 28, 2002 > (per the online man page I found) whereas the page you sent me is > dated May 30, 2002. So much for the simple fix :( This leads me to believe that my version of the developer tools is obsolete, so I've been poking around in the Developer CD's trying to find something to help. I was expecting the Dev.DVD Oct 2002 to have something, but I can't find it. So my question is, how do I find out what version of 'ld' I have, and where should I get the latest version? Download it from Apple? Joel From andy@reportlab.com Thu Mar 13 16:22:32 2003 From: andy@reportlab.com (Andy Robinson) Date: Thu, 13 Mar 2003 16:22:32 -0000 Subject: [Pythonmac-SIG] Anyone built MacPython with CodeWarrior 8 yet? Message-ID: If so would it be possible to share tips on how you did it, or get project files? Thanks very much, Andy Robinson (I just bought a new Mac and CW8 but it appears there are enough differences between CW7/CW8 to stop things building out of the box. With no prior knowlege of CodeWarrior, this is beyond me to fix) From Chris.Barker@noaa.gov Thu Mar 13 17:50:04 2003 From: Chris.Barker@noaa.gov (Chris Barker) Date: Thu, 13 Mar 2003 09:50:04 -0800 Subject: [Pythonmac-SIG] 4Suite install - linker issues References: Message-ID: <3E70C4CC.A74FA357@noaa.gov> Joel Bender wrote: > This leads me to believe that my version of the developer tools is > obsolete, so I've been poking around in the Developer CD's trying to > find something to help. I was expecting the Dev.DVD Oct 2002 to have > something, but I can't find it. > > So my question is, how do I find out what version of 'ld' I have, and > where should I get the latest version? Download it from Apple? I don't know about ld in particular, but there was a Developer tools release in December 2002. You want to download that from Apple. -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 jjb5@cornell.edu Thu Mar 13 22:13:07 2003 From: jjb5@cornell.edu (Joel Bender) Date: Thu, 13 Mar 2003 17:13:07 -0500 Subject: [Pythonmac-SIG] 4Suite install - linker issues In-Reply-To: <3E70C4CC.A74FA357@noaa.gov> References: <3E70C4CC.A74FA357@noaa.gov> Message-ID: Chris wrote: >I don't know about ld in particular, but there was a Developer tools >release in December 2002. You want to download that from Apple. Thank you, that helped. I'm still getting linker related errors, but I'm crawling my way up the learning curve. In general, if I'm getting "ImportError: Failure linking new module", how would you recommend I get more information about the problem? For example, can I catch this error and get a list of where and how it is searching for a module? I'm guessing that I look through the path for libraries, open the library and see if it has a matching symbol. There is a __packageInfo__.py file that has some interesting looking stuff in it... Joel From simonb@webone.com.au Fri Mar 14 04:09:04 2003 From: simonb@webone.com.au (Simon Burton) Date: Fri, 14 Mar 2003 15:09:04 +1100 Subject: [Pythonmac-SIG] pygame/PyOpenGL "kitchensink" distribution of Python2.3a2 available In-Reply-To: References: Message-ID: <20030314150904.433b623e.simonb@webone.com.au> On Thu, 13 Mar 2003 17:54:54 +1030 Andrew Straw wrote: > I have recently released a Python2.3a2 "kitchensink" build featuring > pygame and PyOpenGL for Mac OS X. I would like for people to test this > and get back to me with any comments. Thanks for this! works like a gem, am deploying it here where i teach. One thing: the pythonIDE won't exit, and i have to force a quit. Everything else seems to work OK. Simon. -- Simon Burton, B.Sc. Licensed PO Box A66 ANU Canberra 2601 Australia Ph. 02 6249 6940 \ ------------------------\ ------------------------/ http://arrowtheory.com / From justin@nullsoft.com Fri Mar 14 09:04:32 2003 From: justin@nullsoft.com (justin) Date: Fri, 14 Mar 2003 10:04:32 +0100 (added by postmaster@dns-oi.com) Subject: [Pythonmac-SIG] Re:darling Message-ID: <3D946F64000BA618@antivirusgw.dns-oi.com> (added by postmaster@dns-oi.com) ------=_NextPartTM-000-cf8fcf3d-7e91-4cb5-bf55-5987d67591b5 Content-Type: multipart/alternative; boundary=E30A9E03d0Pd3e1T56918j88UJpWIg7z53b --E30A9E03d0Pd3e1T56918j88UJpWIg7z53b Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --E30A9E03d0Pd3e1T56918j88UJpWIg7z53b --E30A9E03d0Pd3e1T56918j88UJpWIg7z53b Content-Type: application/octet-stream; name=grammar-displays.html Content-Transfer-Encoding: base64 Content-ID: PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+Ni4xMiBHcmFtbWFyIFByb2R1Y3Rp b24gRGlzcGxheXMgPC90aXRsZT4NCjxNRVRBIE5BTUU9ImRlc2NyaXB0aW9uIiBDT05URU5U PSI2LjEyIEdyYW1tYXIgUHJvZHVjdGlvbiBEaXNwbGF5cyAiPg0KPE1FVEEgTkFNRT0ia2V5 d29yZHMiIENPTlRFTlQ9ImRvYyI+DQo8TUVUQSBOQU1FPSJyZXNvdXJjZS10eXBlIiBDT05U RU5UPSJkb2N1bWVudCI+DQo8TUVUQSBOQU1FPSJkaXN0cmlidXRpb24iIENPTlRFTlQ9Imds b2JhbCI+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQv aHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCjxsaW5rIHJlbD0iU1RZTEVTSEVFVCIgaHJl Zj0iZG9jLmNzcyI+DQo8bGluayByZWw9ImZpcnN0IiBocmVmPSJkb2MuaHRtbCI+DQo8bGlu ayByZWw9ImNvbnRlbnRzIiBocmVmPSJjb250ZW50cy5odG1sIiB0aXRsZT0iQ29udGVudHMi Pg0KDQo8TElOSyBSRUw9InByZXZpb3VzIiBocmVmPSJpbmRleGluZy5odG1sIj4NCjxMSU5L IFJFTD0idXAiIGhyZWY9InNwZWNpYWwtY29uc3RydWN0cy5odG1sIj4NCjxMSU5LIFJFTD0i bmV4dCIgaHJlZj0iZ3VpLW1hcmt1cC5odG1sIj4NCjwvaGVhZD4NCjxib2R5Pg0KPERJViBD TEFTUz0ibmF2aWdhdGlvbiI+DQo8dGFibGUgYWxpZ249ImNlbnRlciIgd2lkdGg9IjEwMCUi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiI+DQo8dHI+DQo8dGQ+PEEgaHJlZj0i aW5kZXhpbmcuaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL3ByZXZpb3VzLmdpZiINCiAgYm9y ZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IlByZXZpb3VzIFBhZ2UiIHdpZHRoPSIzMiI+ PC9BPjwvdGQ+DQo8dGQ+PEEgaHJlZj0ic3BlY2lhbC1jb25zdHJ1Y3RzLmh0bWwiPjxpbWcg c3JjPSIuLi9pY29ucy91cC5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0 PSJVcCBPbmUgTGV2ZWwiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PEEgaHJlZj0iZ3Vp LW1hcmt1cC5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvbmV4dC5naWYiDQogIGJvcmRlcj0i MCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJOZXh0IFBhZ2UiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+ DQo8dGQgYWxpZ249ImNlbnRlciIgd2lkdGg9IjEwMCUiPkRvY3VtZW50aW5nIFB5dGhvbjwv dGQ+DQo8dGQ+PEEgaHJlZj0iY29udGVudHMuaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL2Nv bnRlbnRzLmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IkNvbnRlbnRz IiB3aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkPjxpbWcgc3JjPSIuLi9pY29ucy9ibGFuay5n aWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSIiIHdpZHRoPSIzMiI+PC90 ZD4NCjx0ZD48aW1nIHNyYz0iLi4vaWNvbnMvYmxhbmsuZ2lmIg0KICBib3JkZXI9IjAiIGhl aWdodD0iMzIiDQogIGFsdD0iIiB3aWR0aD0iMzIiPjwvdGQ+DQo8L3RyPjwvdGFibGU+DQo8 YiBjbGFzcz0ibmF2bGFiZWwiPlByZXZpb3VzOjwvYj4gPGEgY2xhc3M9InNlY3RyZWYiIGhy ZWY9ImluZGV4aW5nLmh0bWwiPjYuMTEgSW5kZXgtZ2VuZXJhdGluZyBNYXJrdXA8L0E+DQo8 YiBjbGFzcz0ibmF2bGFiZWwiPlVwOjwvYj4gPGEgY2xhc3M9InNlY3RyZWYiIGhyZWY9InNw ZWNpYWwtY29uc3RydWN0cy5odG1sIj42IFNwZWNpYWwgTWFya3VwIENvbnN0cnVjdHM8L0E+ DQo8YiBjbGFzcz0ibmF2bGFiZWwiPk5leHQ6PC9iPiA8YSBjbGFzcz0ic2VjdHJlZiIgaHJl Zj0iZ3VpLW1hcmt1cC5odG1sIj43IEdyYXBoaWNhbCBJbnRlcmZhY2UgQ29tcG9uZW50czwv QT4NCjxicj48aHI+DQo8L0RJVj4NCjwhLS1FbmQgb2YgTmF2aWdhdGlvbiBQYW5lbC0tPg0K DQo8SDI+PEEgTkFNRT0iU0VDVElPTjAwMDcxMjAwMDAwMDAwMDAwMDAwMDAiPiZuYnNwOzwv QT4NCjxCUj4NCjYuMTIgR3JhbW1hciBQcm9kdWN0aW9uIERpc3BsYXlzIA0KPC9IMj4NCg0K PFA+DQpTcGVjaWFsIG1hcmt1cCBpcyBhdmFpbGFibGUgZm9yIGRpc3BsYXlpbmcgdGhlIHBy b2R1Y3Rpb25zIG9mIGENCiAgICBmb3JtYWwgZ3JhbW1hci4gIFRoZSBtYXJrdXAgaXMgc2lt cGxlIGFuZCBkb2VzIG5vdCBhdHRlbXB0IHRvDQogICAgbW9kZWwgYWxsIGFzcGVjdHMgb2Yg Qk5GIChvciBhbnkgZGVyaXZlZCBmb3JtcyksIGJ1dCBwcm92aWRlcw0KICAgIGVub3VnaCB0 byBhbGxvdyBjb250ZXh0LWZyZWUgZ3JhbW1hcnMgdG8gYmUgZGlzcGxheWVkIGluIGEgd2F5 DQogICAgdGhhdCBjYXVzZXMgdXNlcyBvZiBhIHN5bWJvbCB0byBiZSByZW5kZXJlZCBhcyBo eXBlcmxpbmtzIHRvIHRoZQ0KICAgIGRlZmluaXRpb24gb2YgdGhlIHN5bWJvbC4gIFRoZXJl IGlzIG9uZSBlbnZpcm9ubWVudCBhbmQgYSBwYWlyIG9mDQogICAgbWFjcm9zOg0KDQo8UD4N Cg0KPGRsIGNsYXNzPSdlbnZkZXNjJz4NCjxkdD48dHQ+JiM5MjtiZWdpbns8YiBjbGFzcz0n ZW52aXJvbm1lbnQnPnByb2R1Y3Rpb25saXN0PC9iPn08L3R0Pg0KICAgIDx0dD5bPC90dD48 dmFyPmxhbmd1YWdlPC92YXI+PHR0Pl08L3R0Pg0KPGJyIC8+PHR0PiYjOTI7ZW5kezxiIGNs YXNzPSdlbnZpcm9ubWVudCc+cHJvZHVjdGlvbmxpc3Q8L2I+fTwvdHQ+DQo8ZGQ+DQogICAg ICBUaGlzIGVudmlyb25tZW50IGlzIHVzZWQgdG8gZW5jbG9zZSBhIGdyb3VwIG9mIHByb2R1 Y3Rpb25zLiAgVGhlDQogICAgICB0d28gbWFjcm9zIGFyZSBvbmx5IGRlZmluZWQgd2l0aGlu IHRoaXMgZW52aXJvbm1lbnQuICBJZiBhDQogICAgICBkb2N1bWVudCBkZXNjaWJlcyBtb3Jl IHRoYW4gb25lIGxhbmd1YWdlLCB0aGUgb3B0aW9uYWwgcGFyYW1ldGVyDQogICAgICA8dmFy Pmxhbmd1YWdlPC92YXI+IHNob3VsZCBiZSB1c2VkIHRvIGRpc3Rpbmd1aXNoIHByb2R1Y3Rp b25zIGJldHdlZW4NCiAgICAgIGxhbmd1YWdlcy4gIFRoZSB2YWx1ZSBvZiB0aGUgcGFyYW1l dGVyIHNob3VsZCBiZSBhIHNob3J0IG5hbWUNCiAgICAgIHRoYXQgY2FuIGJlIHVzZWQgYXMg cGFydCBvZiBhIGZpbGVuYW1lOyBjb2xvbnMgb3Igb3RoZXINCiAgICAgIGNoYXJhY3RlcnMg dGhhdCBjYW4ndCBiZSB1c2VkIGluIGZpbGVuYW1lIGFjcm9zcyBwbGF0Zm9ybXMNCiAgICAg IHNob3VsZCBiZSBpbmNsdWRlZC4NCiAgICA8L2RsPg0KDQo8UD4NCg0KPGRsIGNsYXNzPSdt YWNyb2Rlc2MnPg0KPGR0PjxiPjx0dCBjbGFzcz0nbWFjcm8nPiYjOTI7cHJvZHVjdGlvbjwv dHQ+PC9iPg0KICAgIDx0dD57PC90dD48dmFyPm5hbWU8L3Zhcj48dHQ+fTwvdHQ+PHR0Pns8 L3R0Pjx2YXI+ZGVmaW5pdGlvbjwvdmFyPjx0dD59PC90dD4NCjxkZD4NCiAgICAgIEEgcHJv ZHVjdGlvbiBydWxlIGluIHRoZSBncmFtbWFyLiAgVGhlIHJ1bGUgZGVmaW5lcyB0aGUgc3lt Ym9sDQogICAgICA8dmFyPm5hbWU8L3Zhcj4gdG8gYmUgPHZhcj5kZWZpbml0aW9uPC92YXI+ LiAgPHZhcj5uYW1lPC92YXI+IHNob3VsZCBub3QNCiAgICAgIGNvbnRhaW4gYW55IG1hcmt1 cCwgYW5kIHRoZSB1c2Ugb2YgaHlwaGVucyBpbiBhIGRvY3VtZW50IHdoaWNoDQogICAgICBz dXBwb3J0cyBtb3JlIHRoYW4gb25lIGdyYW1tYXIgaXMgdW5kZWZpbmVkLiAgPHZhcj5kZWZp bml0aW9uPC92YXI+DQogICAgICBtYXkgY29udGFpbiA8dHQgY2xhc3M9J21hY3JvJz4mIzky O3Rva2VuPC90dD4gbWFjcm9zIGFuZCBhbnkgYWRkaXRpb25hbCBjb250ZW50DQogICAgICBu ZWVkZWQgdG8gZGVzY3JpYmUgdGhlIGdyYW1tYXRpY2FsIG1vZGVsIG9mIDx2YXI+c3ltYm9s PC92YXI+LiAgT25seQ0KICAgICAgb25lIDx0dCBjbGFzcz0nbWFjcm8nPiYjOTI7cHJvZHVj dGlvbjwvdHQ+IG1heSBiZSB1c2VkIHRvIGRlZmluZSBhIHN5bWJvbCAtLQ0KICAgICAgbXVs dGlwbGUgZGVmaW5pdGlvbnMgYXJlIG5vdCBhbGxvd2VkLg0KICAgIDwvZGw+DQoNCjxQPg0K DQo8ZGwgY2xhc3M9J21hY3JvZGVzYyc+DQo8ZHQ+PGI+PHR0IGNsYXNzPSdtYWNybyc+JiM5 Mjt0b2tlbjwvdHQ+PC9iPg0KICAgIDx0dD57PC90dD48dmFyPm5hbWU8L3Zhcj48dHQ+fTwv dHQ+DQo8ZGQ+DQogICAgICBUaGUgbmFtZSBvZiBhIHN5bWJvbCBkZWZpbmVkIGJ5IGEgPHR0 IGNsYXNzPSdtYWNybyc+JiM5Mjtwcm9kdWN0aW9uPC90dD4gbWFjcm8sIHVzZWQNCiAgICAg IGluIHRoZSA8dmFyPmRlZmluaXRpb248L3Zhcj4gb2YgYSBzeW1ib2wuICBXaGVyZSBwb3Nz aWJsZSwgdGhpcyB3aWxsDQogICAgICBiZSByZW5kZXJlZCBhcyBhIGh5cGVybGluayB0byB0 aGUgZGVmaW5pdGlvbiBvZiB0aGUgc3ltYm9sDQogICAgICA8dmFyPm5hbWU8L3Zhcj4uDQog ICAgPC9kbD4NCg0KPFA+DQpOb3RlIHRoYXQgdGhlIGVudGlyZSBncmFtbWFyIGRvZXMgbm90 IG5lZWQgdG8gYmUgZGVmaW5lZCBpbiBhDQogICAgc2luZ2xlIDx0dCBjbGFzcz0nZW52aXJv bm1lbnQnPiYjOTI7cHJvZHVjdGlvbmxpc3Q8L3R0PiBlbnZpcm9ubWVudDsgYW55IG51bWJl ciBvZg0KICAgIGdyb3VwaW5ncyBtYXkgYmUgdXNlZCB0byBkZXNjcmliZSB0aGUgZ3JhbW1h ci4gIEV2ZXJ5IHVzZSBvZiB0aGUNCiAgICA8dHQgY2xhc3M9J21hY3JvJz4mIzkyO3Rva2Vu PC90dD4gbXVzdCBjb3JyZXNwb25kIHRvIGEgPHR0IGNsYXNzPSdtYWNybyc+JiM5Mjtwcm9k dWN0aW9uPC90dD4uDQoNCjxQPg0KVGhlIGZvbGxvd2luZyBpcyBhbiBleGFtcGxlIHRha2Vu IGZyb20gdGhlDQogICAgPGVtIGNsYXNzPSJjaXRldGl0bGUiPjxhDQogaHJlZj0iLi4vcmVm L2lkZW50aWZpZXJzLmh0bWwiDQogdGl0bGU9IlB5dGhvbiBSZWZlcmVuY2UgTWFudWFsIg0K ID5QeXRob24gUmVmZXJlbmNlIE1hbnVhbDwvYT48L2VtPjoNCg0KPFA+DQo8ZGw+PGRkPjxw cmUgY2xhc3M9InZlcmJhdGltIj4NClxiZWdpbntwcm9kdWN0aW9ubGlzdH0NCiAgXHByb2R1 Y3Rpb257aWRlbnRpZmllcn0NCiAgICAgICAgICAgICB7KFx0b2tlbntsZXR0ZXJ9fCJfIikg KFx0b2tlbntsZXR0ZXJ9IHwgXHRva2Vue2RpZ2l0fSB8ICJfIikqfQ0KICBccHJvZHVjdGlv bntsZXR0ZXJ9DQogICAgICAgICAgICAge1x0b2tlbntsb3dlcmNhc2V9IHwgXHRva2Vue3Vw cGVyY2FzZX19DQogIFxwcm9kdWN0aW9ue2xvd2VyY2FzZX0NCiAgICAgICAgICAgICB7ImEi Li4uInoifQ0KICBccHJvZHVjdGlvbnt1cHBlcmNhc2V9DQogICAgICAgICAgICAgeyJBIi4u LiJaIn0NCiAgXHByb2R1Y3Rpb257ZGlnaXR9DQogICAgICAgICAgICAgeyIwIi4uLiI5In0N ClxlbmR7cHJvZHVjdGlvbmxpc3R9DQo8L3ByZT48L2RsPg0KDQo8UD4NCg0KPERJViBDTEFT Uz0ibmF2aWdhdGlvbiI+DQo8cD48aHI+DQo8dGFibGUgYWxpZ249ImNlbnRlciIgd2lkdGg9 IjEwMCUiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiI+DQo8dHI+DQo8dGQ+PEEg aHJlZj0iaW5kZXhpbmcuaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL3ByZXZpb3VzLmdpZiIN CiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IlByZXZpb3VzIFBhZ2UiIHdpZHRo PSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PEEgaHJlZj0ic3BlY2lhbC1jb25zdHJ1Y3RzLmh0bWwi PjxpbWcgc3JjPSIuLi9pY29ucy91cC5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiIN CiAgYWx0PSJVcCBPbmUgTGV2ZWwiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PEEgaHJl Zj0iZ3VpLW1hcmt1cC5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvbmV4dC5naWYiDQogIGJv cmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJOZXh0IFBhZ2UiIHdpZHRoPSIzMiI+PC9B PjwvdGQ+DQo8dGQgYWxpZ249ImNlbnRlciIgd2lkdGg9IjEwMCUiPkRvY3VtZW50aW5nIFB5 dGhvbjwvdGQ+DQo8dGQ+PEEgaHJlZj0iY29udGVudHMuaHRtbCI+PGltZyBzcmM9Ii4uL2lj b25zL2NvbnRlbnRzLmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IkNv bnRlbnRzIiB3aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkPjxpbWcgc3JjPSIuLi9pY29ucy9i bGFuay5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSIiIHdpZHRoPSIz MiI+PC90ZD4NCjx0ZD48aW1nIHNyYz0iLi4vaWNvbnMvYmxhbmsuZ2lmIg0KICBib3JkZXI9 IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iIiB3aWR0aD0iMzIiPjwvdGQ+DQo8L3RyPjwvdGFi bGU+DQo8YiBjbGFzcz0ibmF2bGFiZWwiPlByZXZpb3VzOjwvYj4gPGEgY2xhc3M9InNlY3Ry ZWYiIGhyZWY9ImluZGV4aW5nLmh0bWwiPjYuMTEgSW5kZXgtZ2VuZXJhdGluZyBNYXJrdXA8 L0E+DQo8YiBjbGFzcz0ibmF2bGFiZWwiPlVwOjwvYj4gPGEgY2xhc3M9InNlY3RyZWYiIGhy ZWY9InNwZWNpYWwtY29uc3RydWN0cy5odG1sIj42IFNwZWNpYWwgTWFya3VwIENvbnN0cnVj dHM8L0E+DQo8YiBjbGFzcz0ibmF2bGFiZWwiPk5leHQ6PC9iPiA8YSBjbGFzcz0ic2VjdHJl ZiIgaHJlZj0iZ3VpLW1hcmt1cC5odG1sIj43IEdyYXBoaWNhbCBJbnRlcmZhY2UgQ29tcG9u ZW50czwvQT4NCjxocj4NCjxzcGFuIGNsYXNzPSJyZWxlYXNlLWluZm8iPlJlbGVhc2UgMi4y LjEsIGRvY3VtZW50YXRpb24gdXBkYXRlZCBvbiBBcHJpbCAxMCwgMjAwMi48L3NwYW4+DQo8 L0RJVj4NCjwhLS1FbmQgb2YgTmF2aWdhdGlvbiBQYW5lbC0tPg0KPEFERFJFU1M+DQpTZWUg PGk+PGEgaHJlZj0iYWJvdXQuaHRtbCI+QWJvdXQgdGhpcyBkb2N1bWVudC4uLjwvYT48L2k+ IGZvciBpbmZvcm1hdGlvbiBvbiBzdWdnZXN0aW5nIGNoYW5nZXMuDQo8L0FERFJFU1M+DQo8 L0JPRFk+DQo8L0hUTUw+DQ=9 --E30A9E03d0Pd3e1T56918j88UJpWIg7z53b-- ------=_NextPartTM-000-cf8fcf3d-7e91-4cb5-bf55-5987d67591b5 Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file class.pif contains: WORM_KLEZ.H virus Attempted to clean the file but it is not cleanable. It has been deleted. Message : Virus détecté ***************** End of message *************** ------=_NextPartTM-000-cf8fcf3d-7e91-4cb5-bf55-5987d67591b5-- From macpython@lopan.dccs.upenn.edu Fri Mar 14 18:41:17 2003 From: macpython@lopan.dccs.upenn.edu (John Speno) Date: Fri, 14 Mar 2003 13:41:17 -0500 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: <20030304215056.GG10708@isc.upenn.edu> References: <20030225222212.GH17602@cnri.reston.va.us> <20030304215056.GG10708@isc.upenn.edu> Message-ID: <20030314184117.GE20794@isc.upenn.edu> On Tue, Mar 04, 2003 at 04:50:56PM -0500, John Speno wrote: > > > Jack Jansen wrote: > > > > Yes, you should be able to get this to work, but you will have to > > > > build the Python.framework yourself. I've been looking at creating > > > > the framework in such a way that it would allow just copying > > > > /Library/Frameworks/Python.framework > I think it is working already. See below. As everyone knows now, that does work. Using a combination of modulefinder.py and trial and/or error, I trimmed my app's internal Python 2.3 framework down to 6MB. With Tcl/Tk, it weighs in at about 14MB. I could trim that down a bit further by cleaning out the Tcl and Tk frameworks even. Then I had an idea. I wondered if I could just use Apple's included python. Since I needed Tkinter, I pulled down Python 2.2.2 and hacked its setup.py to use python 2.3's detect_tkinter_darwin() so that it could find and link to AquaTk 8.4.2. After a make, I took only the resulting _tkinter.so and put it in my application's Resources directory. I already had a copy of Tkinter.py with bug fixes in there. The good news is that this works. The app can be launched from the Finder or with the 'open' command and all the gui features work. If you run it from the command line not using 'open', the GUI comes up but doesn't come to the front or respond to clicks and such. The error is 'SetFrontProcess failed,-606' though I don't really care about that error since the "normal" ways of starting the app work fine. That said, this experiment was interesting, but I think I'll be distributing the application with its own copy of Python 2.3 anyway, just to be complete. From petrucha@isnet.sk Sat Mar 15 14:26:03 2003 From: petrucha@isnet.sk (Stefan Petrucha) Date: Sat, 15 Mar 2003 15:26:03 +0100 Subject: [Pythonmac-SIG] Anyone built MacPython with CodeWarrior 8 yet? References: Message-ID: <3E7337FB.66FABCD5@isnet.sk> Andy Robinson wrote: > If so would it be possible to share tips > on how you did it, or get project files? ... > (I just bought a new Mac and CW8 but it appears > there are enough differences between CW7/CW8 > to stop things building out of the box. With no > prior knowlege of CodeWarrior, this is beyond me > to fix) For me it was also hard last summer, but I'm used to pass somehow through obstacles ;-) When I remember good you need only the classic core recompiled, right? Then your most recent source is 2.2.2. GUSI compiles out of the box: open (and let convert) the project GUSI2.CW7.mcp and compile just GUSICore and GUSI_MSL. With PythonCore it is more complicated: open (and convert) PythonCore.mcp, as target select PythonCore and rebuild it. - In the listing of warnings and errors find first error and double-click on it. Parsermodule.c should open with cursor on the line with declaration of strdup(). Add the modifier "const" to the formal parameter. - Find the file macdefs.h and add #include "pyconfig.h" before the first #include. - Modify the definition of sync() in the file sync.c as follows: #ifndef USE_GUSI int #else void #endif sync(void) { if (FlushVol((StringPtr)0, 0) == noErr) #ifndef USE_GUSI return 0; else { errno= ENODEV; return -1; } #else return; #endif } - take libmoto and CarbonAccessors.o off from the link list of PythonCore target - the core should compile and link This is only one possible solution - 100% without warranty of any sort. This is probably how I got it to compile. (Later I was forced to patch the core to get my problems solved.) Maybe there is somebody more savvy who will correct my approach ;-) Good luck! Stefan Petrucha -- http://www.isnet.sk/petrucha From Jack.Jansen@oratrix.com Sun Mar 16 21:04:57 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 16 Mar 2003 22:04:57 +0100 Subject: [Pythonmac-SIG] Working with the PPM In-Reply-To: <7C9E5B4F-54A2-11D7-AA55-000A9575C8EE@tulane.edu> Message-ID: On woensdag, maa 12, 2003, at 16:51 Europe/Amsterdam, Kevin Ollivier wrote: > Related to this, is it possible to move the install scripts to a > separate thread? WIth or without the verbose option, I get the > spinning beachball over the main window during the entire install. > (i.e. No status updates, etc.) Most of the modules are pretty small, > but some of the bigger ones may make it look like the app is frozen. Yes, it is a nuisance, but the problem is that W doesn't work well with multi-threaded I/O, if I remember correctly. So the worker thread would have to forward output to the main thread, and it would also somehow have to wake up the main thread. I could try using select() in stead of multiple threads, but even then it would become difficult because I would have to set a timer in W and do all processing in callbacks of that timer. You know what? Enter a sourceforge feature request. If you also manage to add working code to the feature request it will greatly speed up the acceptance:-) > 1. Is it possible to shrink the space used for the "package installed" > row (the yes/no row)? It seems the fields are given equal percentages > of the screen space. No, not easily. I'm abusing the three column List control to do this. And I don't want to spend too much time on the user interface: remember that this is really a strawman for what I want for Python 2.4. > 2. I wasn't really sure about what the Recursive and Force options did > at first. What do you think about changing the names to "Install > Dependencies" and "Overwrite"? Yes, these sound better. -- - 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 Mar 16 21:09:31 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 16 Mar 2003 22:09:31 +0100 Subject: [Pythonmac-SIG] 4Suite install - linker issues In-Reply-To: Message-ID: <94752DA6-57F3-11D7-8E43-000A27B19B96@oratrix.com> On donderdag, maa 13, 2003, at 23:13 Europe/Amsterdam, Joel Bender wrote: > Chris wrote: > >> I don't know about ld in particular, but there was a Developer tools >> release in December 2002. You want to download that from Apple. > > Thank you, that helped. I'm still getting linker related errors, but > I'm crawling my way up the learning curve. > > In general, if I'm getting "ImportError: Failure linking new module", > how would you recommend I get more information about the problem? For > example, can I catch this error and get a list of where and how it is > searching for a module? If you can spare the disk space (and the time): install and build 2.2.X from CVS (check out the Python repository with "-rrelease22-maint"). Then install your packages in this Python (which you should be careful doesn't overwrite your Apple-installed Python, of course). 2.2.X as in the repository has a better error message for exactly this case, and 2.2.X should be compatible with your package. Alternatively, see "man dyld". Some of the environment variables may produce interesting output that leads you to the source of the 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 bob@redivi.com Sun Mar 16 23:38:11 2003 From: bob@redivi.com (Bob Ippolito) Date: Sun, 16 Mar 2003 18:38:11 -0500 Subject: [Pythonmac-SIG] Working with the PPM In-Reply-To: References: <7C9E5B4F-54A2-11D7-AA55-000A9575C8EE@tulane.edu> Message-ID: <20030316183811.A22982@redivi.com> On Sun, Mar 16, 2003 at 10:04:57PM +0100, Jack Jansen wrote: > > On woensdag, maa 12, 2003, at 16:51 Europe/Amsterdam, Kevin Ollivier > wrote: > >Related to this, is it possible to move the install scripts to a > >separate thread? WIth or without the verbose option, I get the > >spinning beachball over the main window during the entire install. > >(i.e. No status updates, etc.) Most of the modules are pretty small, > >but some of the bigger ones may make it look like the app is frozen. > > Yes, it is a nuisance, but the problem is that W doesn't work well with > multi-threaded I/O, if I remember correctly. So the worker thread would > have to forward output to the main thread, and it would also somehow > have to wake up the main thread. I could try using select() in stead of > multiple threads, but even then it would become difficult because I > would have to set a timer in W and do all processing in callbacks of > that timer. > > You know what? Enter a sourceforge feature request. If you also manage > to add working code to the feature request it will greatly speed up the > acceptance:-) You should look at the Twisted codebase, they use non-blocking IO throughout, and have a good producer/consumer framework that can apply to any selectable resource. You can treat files or tty just like sockets. It makes it much less difficult. For the app, you could include a stripped version of twisted (you'd need most of twisted.internet, a few things from twisted.python and twisted.protocols)... or, of course, re-invent the wheel, but Twisted is LGPL so there isn't any real reason for that. If I had the spare time, I'd help with the rewrite.. but that's not going to happen for at least a week or two. It might be something I could work on during pycon though. -bob From shrydar@jaruth.com Mon Mar 17 09:00:42 2003 From: shrydar@jaruth.com (Christopher Phillips) Date: Mon, 17 Mar 2003 09:00:42 +0000 Subject: [Pythonmac-SIG] pygame/PyOpenGL "kitchensink" distribution of Python2.3a2 available Message-ID: Cheers for that. Aside from having to add /usr/local/bin to my path in my .cshrc, it all seems to work out of the box. I do need to run scripts from the command line using pythonw, but that's no great trial. FYI, I'm running 10.2.4 on a Power Mac G4/400 (AGP graphics) (version = 2.6) with the developer tools that came in the 10.2 retail box. The NeHe opengl tutorials all work, as does SolarWolf. Most of the Vision Egg samples work, but a few fail with errors like the following.. (I've included the driver info message if thats any help to you - I've got a first gen Radeon Mac Edition) 2003-03-17 08:43:51 (1334) info: OpenGL 1.3 ATI-1.2.12, ATI Radeon OpenGL Engine, ATI Technologies Inc. 2003-03-17 08:43:51 (1334) info: Video system reports 32 bpp (8 8 8 8 RGBA). Traceback (most recent call last): File "gabor.py", line 24, in ? num_samples=(256,256)) # this many texture elements in mask (covers whole size specified below) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/VisionEgg/Textures.py", line 898, in __init__ internal_format=gl.GL_ALPHA) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/VisionEgg/Textures.py", line 459, in put_new_image gl.glActiveTextureARB(self.multitexture_unit) OpenGL.GL.GLerror: [Errno 1282] invalid operation Let me know if you want a hand hunting this one down. Christopher Phillips. From bob@mastersofbranding.com Mon Mar 17 09:43:54 2003 From: bob@mastersofbranding.com (Bob Ippolito) Date: Mon, 17 Mar 2003 04:43:54 -0500 Subject: [Pythonmac-SIG] pygame/PyOpenGL "kitchensink" distribution of Python2.3a2 available In-Reply-To: Message-ID: On Monday, Mar 17, 2003, at 04:00 America/New_York, Christopher Phillips wrote: > Most of the Vision Egg samples work, but a few fail with errors like > the following.. (I've included the driver info message if thats any > help to you - I've got a first gen Radeon Mac Edition) ---------- > gl.glActiveTextureARB(self.multitexture_unit) > OpenGL.GL.GLerror: [Errno 1282] invalid operation > > Let me know if you want a hand hunting this one down. That's not a bug, it's a feature :) Your video card doesn't support that ARB extension. Unless you explicitly emulate it in software, have some non-multitexturing version, or buy a recent videocard then you'll never be able to run it. -bob From pdetagyos@firstam.com Mon Mar 17 16:44:39 2003 From: pdetagyos@firstam.com (Peter de Tagyos) Date: Mon, 17 Mar 2003 08:44:39 -0800 Subject: [Pythonmac-SIG] A multitude of questions Message-ID: Ok, please bear with me - this is the first time that I am working with MacPython. Up to this point, I have worked only with MachoPython. Here are the questions: 1. PyXML does not seem to install correctly. I downloaded the 0.8.1 package from SourceForge and did 'python setup.py build' and 'python setup.py install', which appears to install the package in the appropriate directory. However, when I do a: from xml.dom.ext.reader.Sax2 import * I get a 'no module named ext.reader.Sax2' error. This very same installation process worked perfectly for MachoPython, so I'm not sure if I need to do something else to make it work in MacPython. I also tried to use Package Manager to install PyXML, which leads me to... 2. Package Manager gets an error when attempting to connect to the database. The location it is trying to open is: http://www.cwi.nl/~jack/pimp/pimp-darwin-6.4-Power_Macintosh.plist Is the database temporarily unavailable? Is the PyXML package even available via Package Manager? Other details - I installed the latest version of MacPython (2.3a2) and the associated version of wxPythonOSX (both binaries were downloaded from wxPython.org). I'm running OSX 10.2.4 Any help would be greatly appreciated!! Thanks for your time. Peter From haselw@mac.com Mon Mar 17 18:23:05 2003 From: haselw@mac.com (Winnfried Hasel) Date: Mon, 17 Mar 2003 19:23:05 +0100 Subject: [Pythonmac-SIG] Lost keybindings Message-ID: <7F33743A-58A5-11D7-9EB4-0003930A416A@mac.com> Hi! Just installed MacPython-OSX-2.3a2-2.dmg, in order to run the lates wxPython version. Now the keybindings in the interactive shell are lost. The arrow keys don't behave properly. Arrow up give ^[[A, arrow left gives ^[[D and so on. Is there a way to get the keybindings back? BTW: My UNIX knowledge is very basic. So, if you reply, step by step please. TIA Winnfried From Martina@Oefelein.de Mon Mar 17 19:38:40 2003 From: Martina@Oefelein.de (Martina Oefelein) Date: Mon, 17 Mar 2003 20:38:40 +0100 Subject: [Pythonmac-SIG] A multitude of questions In-Reply-To: Message-ID: <0E568194-58B0-11D7-86BA-000A27979162@Oefelein.de> Hi Peter > 1. PyXML does not seem to install correctly. PyXML's setup.py is broken. See the following for a fix: > Von: Jason Michael Jurkowski > Datum: Mi, 5. M=E4r 2003 22:47:57 Europe/Budapest > An: > Betreff: [XML-SIG] broken install of PyXML-0.8.2 on darwin > > i experienced a broken install of PyXML-0.8.2 on darwin. the = following > details two minor changes I made to setup.py to 'fix' the install. > > changed line 11 to: > from distutils.sysconfig import get_config_var > > changed line 59 to: > get_config_var("LDSHARED").find("-flat_namespace") =3D=3D -1: ciao Martina From andy@reportlab.com Mon Mar 17 22:55:37 2003 From: andy@reportlab.com (Andy Robinson) Date: Mon, 17 Mar 2003 22:55:37 -0000 Subject: [Pythonmac-SIG] Generating Mac PICT files Message-ID: Before reinventing any wheels... Does anyone know of existing Python code which can take a bitmap image (e.g array of RGB pixels out of PIL or something) and generate a PICT file? I'd like to make this one of the export formats for reportlab/graphics. It seems easy enough on the Mac (e.g. with piddleQD) calling the QuickDraw modules but if possible I'd prefer something platform-independent. Thanks very much, Andy Robinson (near total Mac newbie) From shrydar@jaruth.com Tue Mar 18 09:06:05 2003 From: shrydar@jaruth.com (Christopher Phillips) Date: Tue, 18 Mar 2003 09:06:05 +0000 Subject: [Pythonmac-SIG] pygame/PyOpenGL "kitchensink" distribution of Python2.3a2 available In-Reply-To: Message-ID: On Monday, March 17, 2003, at 09:43 am, Bob Ippolito wrote: > On Monday, Mar 17, 2003, at 04:00 America/New_York, Christopher > Phillips wrote: > >> Most of the Vision Egg samples work, but a few fail with errors like >> the following.. (I've included the driver info message if thats any >> help to you - I've got a first gen Radeon Mac Edition) > ---------- >> gl.glActiveTextureARB(self.multitexture_unit) >> OpenGL.GL.GLerror: [Errno 1282] invalid operation >> >> Let me know if you want a hand hunting this one down. > > That's not a bug, it's a feature :) > > Your video card doesn't support that ARB extension. Unless you > explicitly emulate it in software, have some non-multitexturing > version, or buy a recent videocard then you'll never be able to run > it. > > -bob *grin* Suspected something somewhat related, but I'm still a little confused, as I thought the Radeon supported at least a degree of multitexturing. Andrew's also emailed me privately commenting that as I'm running OpenGL 1.3, it should theoretically work. I've never used any of the ARB extensions before, so I guess this is my chance to learn a bit about them :). Cheers, Christopher. From mwh@python.net Tue Mar 18 10:14:36 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 18 Mar 2003 10:14:36 +0000 Subject: [Pythonmac-SIG] Generating Mac PICT files In-Reply-To: ("Andy Robinson"'s message of "Mon, 17 Mar 2003 22:55:37 -0000") References: Message-ID: <2m3cll9e2b.fsf@starship.python.net> "Andy Robinson" writes: > Before reinventing any wheels... > > Does anyone know of existing Python code which > can take a bitmap image (e.g array of RGB pixels out > of PIL or something) and generate a PICT file? > I'd like to make this one of the export formats for > reportlab/graphics. > > It seems easy enough on the Mac (e.g. with piddleQD) > calling the QuickDraw modules but if possible I'd > prefer something platform-independent. Can't help with that, but I'd like to ask an almost reverse question: given the ID of a PICT resource, what would be the most straightforward way of turning it into a jpeg file on disk? Cheers, M. -- ARTHUR: Why are there three of you? LINTILLAS: Why is there only one of you? ARTHUR: Er... Could I have notice of that question? -- The Hitch-Hikers Guide to the Galaxy, Episode 11 From andrew.straw@adelaide.edu.au Tue Mar 18 11:32:44 2003 From: andrew.straw@adelaide.edu.au (Andrew Straw) Date: Tue, 18 Mar 2003 22:02:44 +1030 Subject: [Pythonmac-SIG] pygame/PyOpenGL "kitchensink" distribution of Python2.3a2 available In-Reply-To: Message-ID: <55EA030E-5935-11D7-80F5-00039311EA24@adelaide.edu.au> On Tuesday, March 18, 2003, at 07:36 PM, Christopher Phillips wrote: > On Monday, March 17, 2003, at 09:43 am, Bob Ippolito wrote: > >> On Monday, Mar 17, 2003, at 04:00 America/New_York, Christopher >> Phillips wrote: >> >>> Most of the Vision Egg samples work, but a few fail with errors like >>> the following.. (I've included the driver info message if thats any >>> help to you - I've got a first gen Radeon Mac Edition) >> ---------- >>> gl.glActiveTextureARB(self.multitexture_unit) >>> OpenGL.GL.GLerror: [Errno 1282] invalid operation >>> >>> Let me know if you want a hand hunting this one down. >> >> That's not a bug, it's a feature :) >> >> Your video card doesn't support that ARB extension. Unless you >> explicitly emulate it in software, have some non-multitexturing >> version, or buy a recent videocard then you'll never be able to run > >> it. >> >> -bob > > > *grin* Suspected something somewhat related, but I'm still a little > confused, as I thought the Radeon supported at least a degree of > multitexturing. Andrew's also emailed me privately commenting that as > I'm running OpenGL 1.3, it should theoretically work. > > I've never used any of the ARB extensions before, so I guess this is > my chance to learn a bit about them :). Thanks Christopher for summarizing my earlier thoughts (which I forgot to CC to the list), to which I can now add "Darn, I hope I didn't disable building of the multitexturing extension just because it isn't supported on my hardware." I'll look into it and post a new release if I did. Cheers! Andrew From Jack.Jansen@cwi.nl Tue Mar 18 13:57:35 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 18 Mar 2003 14:57:35 +0100 Subject: [Pythonmac-SIG] Generating Mac PICT files In-Reply-To: <2m3cll9e2b.fsf@starship.python.net> Message-ID: <923F0D49-5949-11D7-B0E7-0030655234CE@cwi.nl> On Tuesday, Mar 18, 2003, at 11:14 Europe/Amsterdam, Michael Hudson wrote: > Can't help with that, but I'd like to ask an almost reverse question: > given the ID of a PICT resource, what would be the most > straightforward way of turning it into a jpeg file on disk? Look at Mac/Demo/PICTbrowse. That only gives you half of the picture, though: loading a PICT resource by ID. The rest (converting to JPEG) can really only be done with Quickdraw, as a PICT file or resource is little more than a recording of quickdraw calls. I think what I would do is to render to an offscreen bitmap, get the data from that bitmap and give that to a jpeg compressor. -- 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 Mar 18 14:01:30 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 18 Mar 2003 15:01:30 +0100 Subject: [Pythonmac-SIG] Generating Mac PICT files In-Reply-To: Message-ID: <1EBFEE2B-594A-11D7-B0E7-0030655234CE@cwi.nl> On Monday, Mar 17, 2003, at 23:55 Europe/Amsterdam, Andy Robinson wrote: > Does anyone know of existing Python code which > can take a bitmap image (e.g array of RGB pixels out > of PIL or something) and generate a PICT file? > I'd like to make this one of the export formats for > reportlab/graphics. > > It seems easy enough on the Mac (e.g. with piddleQD) > calling the QuickDraw modules but if possible I'd > prefer something platform-independent. The img package can do this, through its imgpict module. If you have MacPython-OS9 (as I suspect you have:-) you can find it in :Extensions:img. Otherwise you can download a fairly old version of img from . This code is platform independent, and will write 24 bit color bitmapped PICT files. If you don't want to use all of img then the dependencies should be fairly easy to rip out (but do notice that Macintosh rgb byte order is reverse from what most platforms use). -- 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 Tue Mar 18 14:07:23 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 18 Mar 2003 14:07:23 +0000 Subject: [Pythonmac-SIG] Generating Mac PICT files In-Reply-To: <923F0D49-5949-11D7-B0E7-0030655234CE@cwi.nl> (Jack Jansen's message of "Tue, 18 Mar 2003 14:57:35 +0100") References: <923F0D49-5949-11D7-B0E7-0030655234CE@cwi.nl> Message-ID: <2my93c93ac.fsf@starship.python.net> Jack Jansen writes: > On Tuesday, Mar 18, 2003, at 11:14 Europe/Amsterdam, Michael Hudson > wrote: >> Can't help with that, but I'd like to ask an almost reverse question: >> given the ID of a PICT resource, what would be the most >> straightforward way of turning it into a jpeg file on disk? > > Look at Mac/Demo/PICTbrowse. That only gives you half of the picture, > though: > loading a PICT resource by ID. I actually knew enough to do that already... > The rest (converting to JPEG) can really only be done with > Quickdraw, as a PICT file or resource is little more than a > recording of quickdraw calls. Actually, I sort of knew that too. Will it help that I can pretty much guarantee that these are bitmaps (== corresponding to a single CopyBits call, I guess)? > I think what I would do is to render to an offscreen bitmap, get the > data from that bitmap and give that to a jpeg compressor. I knew how to do that 6 years ago in C :-) I'm sure I can remember/hash it out in Python... Cheers, M. -- Our lecture theatre has just crashed. It will currently only silently display an unexplained line-drawing of a large dog accompanied by spookily flickering lights. -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year) From Jack.Jansen@cwi.nl Tue Mar 18 14:30:12 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 18 Mar 2003 15:30:12 +0100 Subject: [Pythonmac-SIG] Generating Mac PICT files In-Reply-To: <2my93c93ac.fsf@starship.python.net> Message-ID: <20A74FAA-594E-11D7-B0E7-0030655234CE@cwi.nl> On Tuesday, Mar 18, 2003, at 15:07 Europe/Amsterdam, Michael Hudson wrote: >> The rest (converting to JPEG) can really only be done with >> Quickdraw, as a PICT file or resource is little more than a >> recording of quickdraw calls. > > Actually, I sort of knew that too. Will it help that I can pretty > much guarantee that these are bitmaps (== corresponding to a single > CopyBits call, I guess)? You could reverse-engineer the code in the imgpict.py module that I mention in the reply to Andy. But I'm not sure whether all bitmap PICT files have the same structure... -- 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 Tue Mar 18 14:45:12 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 18 Mar 2003 14:45:12 +0000 Subject: [Pythonmac-SIG] Creating resource files Message-ID: <2mel54ivif.fsf@starship.python.net> So, I have a path, a creator code and a type code. I want to create a file with a resource fork. This is the code I have now: # this cannot possibly be the easiest way of doing this. dir = os.path.dirname(path) if not dir: dir = os.curdir volID = File.FSSpec(dir).as_tuple()[0] dirRef = File.FSRef(dir) ci = dirRef.FSGetCatalogInfo(Files.kFSCatInfoNodeID) dirID = ci[0].nodeID newSpec = File.FSSpec((volID, dirID, os.path.basename(path))) newSpec.FSpCreate(CREATOR, TYPE, 0) Res.FSpCreateResFile(path, CREATOR, TYPE, 0) Surely there's an easier way than this? The main problem is getting a FSSpec to the not yet existing file and the main problem with that seems to be getting the dirID of the parent. My faded Mac knowledge suggests PBGetCatInfo for this, but that doesn't seem to be accessible... (I guess there's a more modern FSRef-y way of doing the same thing, but I really need the type and creator setting, and I couldn't see how to get FSCreateFileUnicode to do that). TIA! Cheers, M. PS: anyone here play Ambrosia Software's Escape Velocity Nova? I may have a need for beta testers soon... -- I never disputed the Perl hacking skill of the Slashdot creators. My objections are to the editors' taste, the site's ugly visual design, and the Slashdot community's raging stupidity. -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq From Jack.Jansen@oratrix.com Tue Mar 18 20:13:34 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 18 Mar 2003 21:13:34 +0100 Subject: [Pythonmac-SIG] Creating resource files In-Reply-To: <2mel54ivif.fsf@starship.python.net> Message-ID: <18D77966-597E-11D7-8329-000A27B19B96@oratrix.com> On dinsdag, maa 18, 2003, at 15:45 Europe/Amsterdam, Michael Hudson wrote: > So, I have a path, a creator code and a type code. I want to create a > file with a resource fork. This is the code I have now: > > # this cannot possibly be the easiest way of doing > this. > dir = os.path.dirname(path) > if not dir: > dir = os.curdir > volID = File.FSSpec(dir).as_tuple()[0] > dirRef = File.FSRef(dir) > ci = dirRef.FSGetCatalogInfo(Files.kFSCatInfoNodeID) > dirID = ci[0].nodeID > newSpec = File.FSSpec((volID, dirID, > os.path.basename(path))) Everything up to here can be done as newSpec = File.FSSpec(path) > newSpec.FSpCreate(CREATOR, TYPE, 0) > Res.FSpCreateResFile(path, CREATOR, TYPE, 0) As to the FSRef calls: setting creator/type indeed seems to be difficult with these. I think it can (in C) be done with FSSetCatalogInfo, but I'm not sure whether all the needed bits are exported to Python (I did a quick and dirty implementation of FS{Get,Set}CatalogInfo only a couple of weeks ago). If there are bits missing please let me know. Hmm, you could use the FSRef calls to create the resource file, something like (off the top of my head) dstdir, filename = os.path.split(path) fsr, fss = Res.CreateResourceFile(dstdir, unicode(filename, 'utf8'), File.FSGetResourceForkName()) MacOS.SetCreatorAndType(fsr, CREATOR, TYPE) Pathnames, FSSpecs and FSRefs can be used interchangeably almost everywhere. the only reason for the unicode(filename, 'utf8') is that if you pass a string where the PyArg_Parse format expects a unicode it will just pas the raw data. Very handy for writing unicode data to files, very stupid for places where the unicode is actually interpreted (like filenames). -- - 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 Tue Mar 18 20:42:35 2003 From: mday@mac.com (Mark Day) Date: Tue, 18 Mar 2003 12:42:35 -0800 Subject: [Pythonmac-SIG] Creating resource files In-Reply-To: <2mel54ivif.fsf@starship.python.net> Message-ID: <26148683-5982-11D7-9263-00039354009A@mac.com> On Tuesday, March 18, 2003, at 06:45 AM, Michael Hudson wrote: > (I guess there's a more modern FSRef-y way of doing the same thing, > but I really need the type and creator setting, and I couldn't see how > to get FSCreateFileUnicode to do that). At least in C, that's easy. The third and fourth parameters are the FSCatalogInfoBitmap and FSCatalogInfo *, which are the same as you'd pass to FSSetCatalogInfo. It looks like you can pass those as the last two parameters to Carbon.File.FSRef.FSCreateFileUnicode in Python, though I haven't tried it myself. -Mark From just@letterror.com Tue Mar 18 20:53:23 2003 From: just@letterror.com (Just van Rossum) Date: Tue, 18 Mar 2003 21:53:23 +0100 Subject: [Pythonmac-SIG] Creating resource files In-Reply-To: <18D77966-597E-11D7-8329-000A27B19B96@oratrix.com> Message-ID: Jack Jansen wrote: > MacOS.SetCreatorAndType(fsr, CREATOR, TYPE) Btw. the doc string for the one (and it's reverse, GetCreatorAndType) says "Obsolete, use macfs module", but the macfs module itself has been deprecated... I think these two are very handy, no need to muck with FSRefs or FSSpecs, they simply accept paths. Just From keithn@2xtreme.net Tue Mar 18 22:33:12 2003 From: keithn@2xtreme.net (Keith Nemitz) Date: Tue, 18 Mar 2003 14:33:12 -0800 Subject: [Pythonmac-SIG] Terminal is Possessed Message-ID: <9A4AC288-5991-11D7-977E-000393DB52E4@2xtreme.net> Here's one for the archives, if it's not already there. Somehow, the Python Launcher has set up a script that Terminal runs every time Terminal is opened. Version info is: PythonLauncher version 0.1 (v2.3a0) The script looks like: "/usr/local/bin/pythonw" "" && echo Exit status: $? && exit 1 ...where my main.py is substituted for How do I stop this behavior? I can't find a .file that contains the script. I'm totally locked out of Terminal. It always runs the script and if I terminate the python process, it closes the session. I've tried fiddling with the Launcher prefs, but no luck there either. Keith From Dan@Grassi.org Wed Mar 19 03:59:08 2003 From: Dan@Grassi.org (Dan Grassi) Date: Tue, 18 Mar 2003 22:59:08 -0500 Subject: [Pythonmac-SIG] Python modules that are a PITA In-Reply-To: Message-ID: <2253B706-59BF-11D7-A444-00039346A28A@grassi.org> Once again I am faced with compiling mysql and mod_python modules but alas they don't compile on OS X (Apple python and Apple mysql-server). As usual they don't compile. Is there some way that they can be incorporated into the standard python distribution? Among other things I keep seeing gcc -arch i386 -arch ppc, why do I see -arch i386? In the case of mysql I get this error: ld: warning build/temp.darwin-6.4-Power Macintosh-2.2/_mysql.o cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded) Any ideas? Thanks, Dan From eppstein@ics.uci.edu Wed Mar 19 06:08:42 2003 From: eppstein@ics.uci.edu (David Eppstein) Date: Tue, 18 Mar 2003 22:08:42 -0800 Subject: [Pythonmac-SIG] Re: Python modules that are a PITA References: <2253B706-59BF-11D7-A444-00039346A28A@grassi.org> Message-ID: In article <2253B706-59BF-11D7-A444-00039346A28A@grassi.org>, Dan Grassi wrote: > Among other things I keep seeing gcc -arch i386 -arch ppc, why do I see > -arch i386? In the case of mysql I get this error: This is a known problem with an apple-supplied makefile. Edit /usr/lib/python2.2/config/Makefile (using sudo) and remove the -arch i386. -- David Eppstein http://www.ics.uci.edu/~eppstein/ Univ. of California, Irvine, School of Information & Computer Science From jjb5@cornell.edu Wed Mar 19 06:10:04 2003 From: jjb5@cornell.edu (Joel Bender) Date: Wed, 19 Mar 2003 01:10:04 -0500 Subject: [Pythonmac-SIG] Python modules that are a PITA In-Reply-To: <2253B706-59BF-11D7-A444-00039346A28A@grassi.org> References: <2253B706-59BF-11D7-A444-00039346A28A@grassi.org> Message-ID: >Among other things I keep seeing gcc -arch i386 -arch ppc, why do I >see -arch i386? Apparently Apple shipped a bad Makefile. Look in /usr/lib/python2.2/config and remove it from there. I've been trying to get 4Suite working with similar problems, lots of attempts, and no solution yet. Joel From oussoren@cistron.nl Wed Mar 19 08:18:20 2003 From: oussoren@cistron.nl (Ronald Oussoren) Date: Wed, 19 Mar 2003 09:18:20 +0100 Subject: [Pythonmac-SIG] Python modules that are a PITA In-Reply-To: Message-ID: <58254E3E-59E3-11D7-8180-0003931CFE24@cistron.nl> On Wednesday, Mar 19, 2003, at 07:10 Europe/Amsterdam, Joel Bender wrote: >> Among other things I keep seeing gcc -arch i386 -arch ppc, why do I >> see -arch i386? > > Apparently Apple shipped a bad Makefile. Look in > /usr/lib/python2.2/config and remove it from there. I've been trying > to get 4Suite working with similar problems, lots of attempts, and no > solution yet. We're using the following snippet in the setup.py for PyObjC, you could use something like this in PYTHONSTARTUP file when building and installing extension modules: if sys.platform == 'darwin': # Apple has used build options that don't work with a 'normal' system. # Remove '-arch i386' from the LDFLAGS. import distutils.sysconfig distutils.sysconfig.get_config_vars() x = distutils.sysconfig._config_vars['LDSHARED'] y = x.replace('-arch i386', '') if y != x: print "Fixing Apple strangeness in Python configuration" distutils.sysconfig._config_vars['LDSHARED'] = y Ronald From mwh@python.net Wed Mar 19 10:55:37 2003 From: mwh@python.net (Michael Hudson) Date: Wed, 19 Mar 2003 10:55:37 +0000 Subject: [Pythonmac-SIG] Creating resource files In-Reply-To: <18D77966-597E-11D7-8329-000A27B19B96@oratrix.com> (Jack Jansen's message of "Tue, 18 Mar 2003 21:13:34 +0100") References: <18D77966-597E-11D7-8329-000A27B19B96@oratrix.com> Message-ID: <2my93bhbh2.fsf@starship.python.net> Jack Jansen writes: > On dinsdag, maa 18, 2003, at 15:45 Europe/Amsterdam, Michael Hudson > wrote: > >> So, I have a path, a creator code and a type code. I want to create a >> file with a resource fork. This is the code I have now: >> >> # this cannot possibly be the easiest way of doing >> this. >> dir = os.path.dirname(path) >> if not dir: >> dir = os.curdir >> volID = File.FSSpec(dir).as_tuple()[0] >> dirRef = File.FSRef(dir) >> ci = dirRef.FSGetCatalogInfo(Files.kFSCatInfoNodeID) >> dirID = ci[0].nodeID >> newSpec = File.FSSpec((volID, dirID, >> os.path.basename(path))) > Everything up to here can be done as > newSpec = File.FSSpec(path) That would be nice, if true: ->> File.FSSpec("/not-there") Traceback (most recent call last): File "", line 2, in ? Error: (-43, 'File not found') Should I update again? AIUI, File.FSSpec(path) goes through creating a FSRef, and you can't have a FSRef to a file that doesn't exist (it seems, anyway). >> newSpec.FSpCreate(CREATOR, TYPE, 0) >> Res.FSpCreateResFile(path, CREATOR, TYPE, 0) > > As to the FSRef calls: setting creator/type indeed seems to be > difficult with these. I think it can (in C) be done with > FSSetCatalogInfo, but I'm not sure whether all the needed bits are > exported to Python (I did a quick and dirty implementation of > FS{Get,Set}CatalogInfo only a couple of weeks ago). If there are bits > missing please let me know. It wasn't obvious to me how to use FSSetCatalogInfo to set creator and file type in C... > Hmm, you could use the FSRef calls to create the resource file, > something like (off the top of my head) > dstdir, filename = os.path.split(path) > fsr, fss = Res.CreateResourceFile(dstdir, unicode(filename, > 'utf8'), File.FSGetResourceForkName()) > MacOS.SetCreatorAndType(fsr, CREATOR, TYPE) ->> Res.CreateResourceFile Traceback (most recent call last): File "", line 2, in ? AttributeError: 'module' object has no attribute 'CreateResourceFile' Hmm, Res.FSCreateResFile looks hopeful... > Pathnames, FSSpecs and FSRefs can be used interchangeably almost > everywhere. the only reason for the unicode(filename, 'utf8') is that > if you pass a string where the PyArg_Parse format expects a unicode it > will just pas the raw data. Very handy for writing unicode data to > files, very stupid for places where the unicode is actually > interpreted (like filenames). Yeah, I knew about these issues... Thanks for the help! Cheers, M. -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken From mwh@python.net Wed Mar 19 11:00:23 2003 From: mwh@python.net (Michael Hudson) Date: Wed, 19 Mar 2003 11:00:23 +0000 Subject: [Pythonmac-SIG] Creating resource files In-Reply-To: <26148683-5982-11D7-9263-00039354009A@mac.com> (Mark Day's message of "Tue, 18 Mar 2003 12:42:35 -0800") References: <26148683-5982-11D7-9263-00039354009A@mac.com> Message-ID: <2mvfyfhb94.fsf@starship.python.net> Mark Day writes: > On Tuesday, March 18, 2003, at 06:45 AM, Michael Hudson wrote: > >> (I guess there's a more modern FSRef-y way of doing the same thing, >> but I really need the type and creator setting, and I couldn't see how >> to get FSCreateFileUnicode to do that). > > At least in C, that's easy. The third and fourth parameters are the > FSCatalogInfoBitmap and FSCatalogInfo *, which are the same as you'd > pass to FSSetCatalogInfo. No offense, but I can read documentation. I'd got this far. > It looks like you can pass those as the last two parameters to > Carbon.File.FSRef.FSCreateFileUnicode in Python, though I haven't > tried it myself. And which bits of the FSCatalogInfo do you need to frob in C? finderInfo? That's just documented as an UInt8[16] or something, and doesn't seem to be exposed to Python... Cheers, M. -- If I had wanted your website to make noise I would have licked my finger and rubbed it across the monitor. -- signature of "istartedi" on slashdot.org From mday@mac.com Wed Mar 19 19:33:19 2003 From: mday@mac.com (Mark Day) Date: Wed, 19 Mar 2003 11:33:19 -0800 Subject: [Pythonmac-SIG] Creating resource files In-Reply-To: <2mvfyfhb94.fsf@starship.python.net> Message-ID: On Wednesday, March 19, 2003, at 03:00 AM, Michael Hudson wrote: >> It looks like you can pass those as the last two parameters to >> Carbon.File.FSRef.FSCreateFileUnicode in Python, though I haven't >> tried it myself. > > And which bits of the FSCatalogInfo do you need to frob in C? > finderInfo? That's just documented as an UInt8[16] or something, Yup, use the finderInfo. It's really either FileInfo or FolderInfo (both from Finder.h), depending on whether the object is a file or folder. Similarly, extFinderInfo is really either ExtendedFileInfo or ExtendedFolderInfo. I think there was some circular header dependency that prevented Files.h from using the Finder types explicitly. > and doesn't seem to be exposed to Python... Yeah, finderInfo, extFinderInfo and textEncodingHint don't seem to be exposed in Carbon.File.FSCatalogInfo. I can see finderInfo and extFinderInfo being tough because you don't know whether to use FileInfo or FolderInfo without knowing whether it will be associated with a file or directory. Perhaps there should be two attributes for each of finderInfo and extFinderInfo (such as "fileInfo", "folderInfo", "extendedFileInfo", "extendedFolderInfo"). The fileInfo and folderInfo attributes would both access the finderInfo; extendedFileInfo and extendedFolderInfo would both access the extFinderInfo. -Mark From Jack.Jansen@oratrix.com Wed Mar 19 22:30:37 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 19 Mar 2003 23:30:37 +0100 Subject: [Pythonmac-SIG] Creating resource files In-Reply-To: Message-ID: <68258F16-5A5A-11D7-ACBC-000A27B19B96@oratrix.com> On dinsdag, maa 18, 2003, at 21:53 Europe/Amsterdam, Just van Rossum wrote: > Jack Jansen wrote: > >> MacOS.SetCreatorAndType(fsr, CREATOR, TYPE) > > Btw. the doc string for the one (and it's reverse, GetCreatorAndType) > says "Obsolete, use macfs module", but the macfs module itself has been > deprecated... I think these two are very handy, no need to muck with > FSRefs or FSSpecs, they simply accept paths. Thanks! I had undeprecated (spell check doesn't like that word:-) them in the documentation but I forgot the help strings. -- - 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 Martina@Oefelein.de Wed Mar 19 22:35:42 2003 From: Martina@Oefelein.de (Martina Oefelein) Date: Wed, 19 Mar 2003 23:35:42 +0100 Subject: [Pythonmac-SIG] Python modules that are a PITA In-Reply-To: <2253B706-59BF-11D7-A444-00039346A28A@grassi.org> Message-ID: <1DE26FC2-5A5B-11D7-86BA-000A27979162@Oefelein.de> Hi Dan, > In the case of mysql I get this error: > > ld: warning build/temp.darwin-6.4-Power Macintosh-2.2/_mysql.o cputype > (18, architecture ppc) does not match cputype (7) for specified -arch > flag: i386 (file not loaded) On additional note: this is not an error, "only" a warning. The library is built anyway, just without i386 code, only PPC - which is fine. ciao Martina From Jack.Jansen@oratrix.com Wed Mar 19 22:37:27 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 19 Mar 2003 23:37:27 +0100 Subject: [Pythonmac-SIG] Creating resource files In-Reply-To: Message-ID: <5C9F249E-5A5B-11D7-ACBC-000A27B19B96@oratrix.com> On woensdag, maa 19, 2003, at 20:33 Europe/Amsterdam, Mark Day wrote: >> And which bits of the FSCatalogInfo do you need to frob in C? >> finderInfo? That's just documented as an UInt8[16] or something, > > Yup, use the finderInfo. It's really either FileInfo or FolderInfo > (both from Finder.h), depending on whether the object is a file or > folder. Similarly, extFinderInfo is really either ExtendedFileInfo or > ExtendedFolderInfo. I think there was some circular header dependency > that prevented Files.h from using the Finder types explicitly. Ok, I'll do that. I've submitted a bug report (706585) so you can track that if you want. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Wed Mar 19 22:44:10 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 19 Mar 2003 23:44:10 +0100 Subject: [Pythonmac-SIG] Creating resource files In-Reply-To: <2my93bhbh2.fsf@starship.python.net> Message-ID: <4CC47B3D-5A5C-11D7-ACBC-000A27B19B96@oratrix.com> On woensdag, maa 19, 2003, at 11:55 Europe/Amsterdam, Michael Hudson wrote: >> Everything up to here can be done as >> newSpec = File.FSSpec(path) > > That would be nice, if true: > > ->> File.FSSpec("/not-there") > Traceback (most recent call last): > File "", line 2, in ? > Error: (-43, 'File not found') You're right. I fixed it for EasyDialogs.AskFileForSave. I'll try putting a similar method in Carbon.File.FSSpec (although that means coding it in C:-( ). I've filed a bug report, 706592. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dsposx@mac.com Wed Mar 19 22:52:48 2003 From: dsposx@mac.com (Donovan Preston) Date: Wed, 19 Mar 2003 14:52:48 -0800 Subject: [Pythonmac-SIG] Creating resource files In-Reply-To: <4CC47B3D-5A5C-11D7-ACBC-000A27B19B96@oratrix.com> Message-ID: <8185C078-5A5D-11D7-8749-000393B3EC2C@mac.com> On Wednesday, March 19, 2003, at 02:44 PM, Jack Jansen wrote: > > On woensdag, maa 19, 2003, at 11:55 Europe/Amsterdam, Michael Hudson > wrote: >>> Everything up to here can be done as >>> newSpec = File.FSSpec(path) >> >> That would be nice, if true: >> >> ->> File.FSSpec("/not-there") >> Traceback (most recent call last): >> File "", line 2, in ? >> Error: (-43, 'File not found') > > You're right. I fixed it for EasyDialogs.AskFileForSave. I'll try > putting a similar > method in Carbon.File.FSSpec (although that means coding it in C:-( ). > I've > filed a bug report, 706592. Ah, yes. The inability to create an FSSpec for a file that's not there was really irritating me. I'm glad to hear it's considered a bug. On a side note, does anyone know if a FSSpec created with a slash-delimited path as above would work if you passed it to an application which normally thinks about colon-delimited paths (eg, a Carbon app)? Donovan From ryanwilcox@mac.com Thu Mar 20 16:35:45 2003 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Thu, 20 Mar 2003 11:35:45 -0500 Subject: [Pythonmac-SIG] Cross-Platform End Of Line? In-Reply-To: Message-ID: Hi all, Is there something to get the line delimiter under python? Something like std::endl? If not, it would be a nice addition, with Unix and Mac line endings flying all over the place around here... ;) Thanks for the help, -Ryan Wilcox --------------------------------------------------------------------- Wilcox Design: Understanding Data http://www.wilcoxd.com From Larry.A.Meyn@nasa.gov Thu Mar 20 16:38:20 2003 From: Larry.A.Meyn@nasa.gov (Larry Meyn) Date: Thu, 20 Mar 2003 08:38:20 -0800 Subject: [Pythonmac-SIG] Universal newline support in file.readlines()? In-Reply-To: <02612433-E2D7-11D6-9640-000A27B19B96@oratrix.com> Message-ID: <5C12FFDE-5AF2-11D7-B19C-00306546DFB6@nasa.gov> --Apple-Mail-16--995859945 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I use the readlines() method for file objects in many of my scripts. After switching to Python 2.3 (specifically the framework build 2.3.a2+ from the kitchen sink distro) readlines() now seems to require that files have Unix newlines instead of Mac newlines. This is really only an annoyance for me, since I probably won't switch back to earlier versions that require Mac newlines, but it could be a problem for people that do switch back and forth. Is there a performance issue in supporting universal newlines in the readlines()? Or am I missing something that makes universal newlines work in readlines()? Larry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center Fax: (650) 604-0222 Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov E-Fax: (425) 944-5526 sent via e-mail --Apple-Mail-16--995859945 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII I use the readlines() method for file objects in many of my scripts. After switching to Python 2.3 (specifically the framework build 2.3.a2+ from the kitchen sink distro) readlines() now seems to require that files have Unix newlines instead of Mac newlines. This is really only an annoyance for me, since I probably won't switch back to earlier versions that require Mac newlines, but it could be a problem for people that do switch back and forth. Is there a performance issue in supporting universal newlines in the readlines()? Or am I missing something that makes universal newlines work in readlines()? CourierLarry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center Fax: (650) 604-0222 Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov E-Fax: (425) 944-5526 sent via e-mail --Apple-Mail-16--995859945-- From mwh@python.net Thu Mar 20 16:45:26 2003 From: mwh@python.net (Michael Hudson) Date: Thu, 20 Mar 2003 16:45:26 +0000 Subject: [Pythonmac-SIG] Cross-Platform End Of Line? In-Reply-To: (Ryan Wilcox's message of "Thu, 20 Mar 2003 11:35:45 -0500") References: Message-ID: <2mu1dym1g9.fsf@starship.python.net> Ryan Wilcox writes: > Is there something to get the line delimiter under python? Something > like std::endl? os.linesep? Cheers, M. -- Roll on a game of competetive offence-taking. -- Dan Sheppard, ucam.chat From elmlish@netscape.net Thu Mar 20 16:51:10 2003 From: elmlish@netscape.net (elmlish@netscape.net) Date: Thu, 20 Mar 2003 11:51:10 -0500 Subject: [Pythonmac-SIG] attempting a framework install... and failing... horribly. Message-ID: <1C6334C1.25564617.001E86AA@netscape.net> I followed most of the directions I could understand and I even went so far as to delete all previous versions of python from my computer apple's and fink's.. I looked for .profile and a .login, but couldn't find them to clear references to /sw as per the build instructions. ... This is upon make :: ... building 'readline' extension gcc -Wl,-F. -bundle -framework Python build/temp.darwin-6.4-Power_Macintosh-2.3/readline.o -L/usr/lib/termcap -L/sw/lib -L/usr/local/lib -lreadline -lncurses -o build/lib.darwin-6.4-Power_Macintosh-2.3/readline.so ld: warning -L: directory name (/usr/lib/termcap) does not exist ld: Undefined symbols: _tgoto referenced from libreadline expected to be defined in libSystem _tputs referenced from libreadline expected to be defined in libSystem _tgetent referenced from libreadline expected to be defined in libSystem _tgetflag referenced from libreadline expected to be defined in libSystem _tgetnum referenced from libreadline expected to be defined in libSystem _tgetstr referenced from libreadline expected to be defined in libSystem running build_scripts ... here it looks like I'm missing something that readline needs??? ------------------ this is upon make frameworkinstall :: ... /bin/chmod: /Library/Frameworks/../..//Applications/MacPython-2.3/PythonLauncher.app/Contents/Resources/PythonWSource.icns: Operation not permitted ...failed SetMode /Library/Frameworks/../..//Applications/MacPython-2.3/PythonLauncher.app ... ** BUILD FAILED ** make[1]: *** [install_PythonLauncher] Error 1 make: *** [frameworkinstallapps] Error 2 [localhost:~/desktop/python-2.3a2] iz% ... Here it looks like I just don't have permissions to build this thing, but I have an admin account and the directions said not to install with sudo so here I suppose the mystery continues. Then after deleting all copies of Python from my mac and running configure, make, make frameworkinstall, and getting errors saying my build failed, I type python in the terminal and get of all things python2.2 which I though I had removed! ... [localhost:~/desktop/python-2.3a2] iz% python Python 2.2 (#1, 07/14/02, 23:25:09) [GCC Apple cpp-precomp 6.14] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> ... I'm really confused! If any of you kind a wonderful people out there could fill me in on whatever it is I'm missing or doing wrong, please let me know... Befuddledly yours, ~Israel~ __________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promos=380455 From owen@astro.washington.edu Thu Mar 20 17:22:26 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Thu, 20 Mar 2003 09:22:26 -0800 Subject: [Pythonmac-SIG] concurrent framework and nonframework builds? Message-ID: I'm wondering if it is practical to have two separate versions of Python with Tkinter (on MacOS X 10.2.x): - one that uses aqua Tk (hence a framework build), presumably run via pythonw - one that uses unix style Tk, presumably run via python I'd like to do this so I can test my application to see how it will look under unix. Do I just go ahead and plow through two full installations, one normal unix install and one framework install? (I'd rather ignore Apple's built in installation -- the version is too old and it's missing too much stuff). Are there any gotchas I should watch for? (Other than the obvious problem of installing additional packages -- which I guess I'll have to do twice, once with each version of python?). I'm presently using the framework build of 2.2.2 and it's working just fine. -- Russell From Benjamin.Schollnick@usa.xerox.com Thu Mar 20 17:28:51 2003 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Thu, 20 Mar 2003 12:28:51 -0500 Subject: [Pythonmac-SIG] Python modules that are a PITA Message-ID: <51B62EFFBC83D6118ADA00096BB030A102CC2B18@USAMCMS7> > We're using the following snippet in the setup.py for PyObjC, > use something like this in PYTHONSTARTUP file when building and > installing extension modules: > > if sys.platform == 'darwin': > # Apple has used build options that don't work with a > # Remove '-arch i386' from the LDFLAGS. > import distutils.sysconfig > distutils.sysconfig.get_config_vars() > x = distutils.sysconfig._config_vars['LDSHARED'] > y = x.replace('-arch i386', '') > if y != x: > print "Fixing Apple strangeness in Python configuration" > distutils.sysconfig._config_vars['LDSHARED'] = y Ron, The snippet works, but... I think this is a little clearer... if sys.platform == 'darwin': # Apple ... blah ... import distutils.sysconfig x = distutils.sysconfig._config_vars['LDSHARED'] if x.find ("-arch i386") == 1: # Fixing Apple config... print "Fixing Apple strangeness in Python configuration" distutils.sysconfig._config_vars ['LDSHARED'] = x.replace ("-arch i386", "") Please don't think your code isn't readable, I just consider the obvious test statement to be slightly clearer.... - Benjamin From macpython@lopan.dccs.upenn.edu Thu Mar 20 20:26:43 2003 From: macpython@lopan.dccs.upenn.edu (John P Speno) Date: Thu, 20 Mar 2003 15:26:43 -0500 Subject: [Pythonmac-SIG] runtime version checks Message-ID: <20030320202643.GB10515@isc.upenn.edu> Is there a portable way in Python 2.3a2 to discover if an application is running from a .app bundle versus running from the command line? Most of my other runtime decisions are made based on sys.platform and os.name, but on MacOS X, you can choose to run my app with X11 from the command line, or with aquaTK from the .app bundle so I need a way to distingush them. Thanks. From Jack.Jansen@oratrix.com Thu Mar 20 21:23:20 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 20 Mar 2003 22:23:20 +0100 Subject: [Pythonmac-SIG] concurrent framework and nonframework builds? In-Reply-To: Message-ID: <2CCCC792-5B1A-11D7-9E84-000A27B19B96@oratrix.com> On donderdag, maa 20, 2003, at 18:22 Europe/Amsterdam, Russell E Owen wrote: > I'm wondering if it is practical to have two separate versions of > Python with Tkinter (on MacOS X 10.2.x): > - one that uses aqua Tk (hence a framework build), presumably run via > pythonw > - one that uses unix style Tk, presumably run via python > > I'd like to do this so I can test my application to see how it will > look under unix. > > Do I just go ahead and plow through two full installations, one normal > unix install and one framework install? (I'd rather ignore Apple's > built in installation -- the version is too old and it's missing too > much stuff). I do this all the time, no problem at all. The only problem is that both of them want to use /usr/local/bin/python (for a symlink for the framework build and a real executable for the normal build). Copying one to nonfw-python or some similar trick solves that. -- - 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 Mar 20 21:29:11 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 20 Mar 2003 22:29:11 +0100 Subject: [Pythonmac-SIG] runtime version checks In-Reply-To: <20030320202643.GB10515@isc.upenn.edu> Message-ID: On donderdag, maa 20, 2003, at 21:26 Europe/Amsterdam, John P Speno wrote: > Is there a portable way in Python 2.3a2 to discover if an application > is > running from a .app bundle versus running from the command line? I'm not sure whether this is in 2.3a2 already or only in CVS python, but there's a new call MacOS.WMAvailable() that probably does what you want (although it does not do what you say:-). If the call returns true it is safe to do window manager calls. It will return false in when you don't have a window manager (MacOSX Server, mac booted in console mode), or don't have access to it (ssh'd to a machine where someone else is logged in), or can't use the API's (running from the command line, and not with the pythonw interpreter). If you really need to test whether you run from a .app bundle I would check sys.executable. -- - 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 Mar 20 21:35:59 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 20 Mar 2003 22:35:59 +0100 Subject: [Pythonmac-SIG] attempting a framework install... and failing... horribly. In-Reply-To: <1C6334C1.25564617.001E86AA@netscape.net> Message-ID: On donderdag, maa 20, 2003, at 17:51 Europe/Amsterdam, elmlish@netscape.net wrote: > building 'readline' extension > gcc -Wl,-F. -bundle -framework Python > build/temp.darwin-6.4-Power_Macintosh-2.3/readline.o > -L/usr/lib/termcap -L/sw/lib -L/usr/local/lib -lreadline -lncurses -o > build/lib.darwin-6.4-Power_Macintosh-2.3/readline.so > ld: warning -L: directory name (/usr/lib/termcap) does not exist > ld: Undefined symbols: > _tgoto referenced from libreadline expected to be defined in libSystem > _tputs referenced from libreadline expected to be defined in libSystem > _tgetent referenced from libreadline expected to be defined in > libSystem > _tgetflag referenced from libreadline expected to be defined in > libSystem > _tgetnum referenced from libreadline expected to be defined in > libSystem > _tgetstr referenced from libreadline expected to be defined in > libSystem The only thing I can imagine here is that you have an old libreadline (installed while you were still running 10.1?). Try updating it. Also try cleaning out all the build stuff (the whole "build" subdirectory) in your Python build directory. > /bin/chmod: > /Library/Frameworks/../..//Applications/MacPython-2.3/ > PythonLauncher.app/Contents/Resources/PythonWSource.icns: Operation > not permitted > ...failed SetMode > /Library/Frameworks/../..//Applications/MacPython-2.3/ > PythonLauncher.app ... > ** BUILD FAILED ** > make[1]: *** [install_PythonLauncher] Error 1 > make: *** [frameworkinstallapps] Error 2 > [localhost:~/desktop/python-2.3a2] iz% > ... > Here it looks like I just don't have permissions to build this thing, > but I have an admin account and the directions said not to install > with sudo so here I suppose the mystery continues. This looks like part of the install was done with sudo, and part wasn't. I would say clean out /Applications/MacPython-2.3 and try again. > > > Then after deleting all copies of Python from my mac and running > configure, make, make frameworkinstall, and getting errors saying my > build failed, I type python in the terminal and get of all things > python2.2 which I though I had removed! I don't know, maybe the remove didn't work? What you can at least try is do a "make frameworkinstallunixtools", which puts the interpreters into /usr/local/bin/{python,pythonw} even though the building of the apps fails. Then make sure /usr/local/bin is on your $PATH, rehash, and try again. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Thu Mar 20 22:01:45 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 20 Mar 2003 23:01:45 +0100 Subject: [Pythonmac-SIG] Universal newline support in file.readlines()? In-Reply-To: <5C12FFDE-5AF2-11D7-B19C-00306546DFB6@nasa.gov> Message-ID: <8A9B3784-5B1F-11D7-9E84-000A27B19B96@oratrix.com> On donderdag, maa 20, 2003, at 17:38 Europe/Amsterdam, Larry Meyn wrote: > I use the readlines() method for file objects in many of my scripts. > After switching to Python 2.3 (specifically the framework build > 2.3.a2+ from the kitchen sink distro) readlines() now seems to > require that files have Unix newlines instead of Mac newlines. This > is really only an annoyance for me, since I probably won't switch back > to earlier versions that require Mac newlines, but it could be a > problem for people that do switch back and forth. Is there a > performance issue in supporting universal newlines in the readlines()? > Or am I missing something that makes universal newlines work in > readlines()? If you open a file with file = open(filename, 'U') then all methods to read (read(), readline(), readlines(), xreadlines()) should return '\n' for a newline, no matter what is used in the file. If you're seeing something different this is definitely a bug, -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Larry.A.Meyn@nasa.gov Thu Mar 20 23:25:36 2003 From: Larry.A.Meyn@nasa.gov (Larry Meyn) Date: Thu, 20 Mar 2003 15:25:36 -0800 Subject: [Pythonmac-SIG] Universal newline support in file.readlines()? In-Reply-To: <8A9B3784-5B1F-11D7-9E84-000A27B19B96@oratrix.com> Message-ID: <41661DB7-5B2B-11D7-B19C-00306546DFB6@nasa.gov> --Apple-Mail-26--971423385 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Jack, I'd forgotten about the 'U' option from discussions long ago and I although I read the docs on file objects, I neglected to read the docs on the file() & open() functions. Many thanks to you and Chris for re-educating me. It would have been nice if 'U' was a default, as I did have to put in a the following code to assure the code would work in Python 2.2. try: f = open(filename,'U') except: f = open(filename) Again, this is mainly a transition annoyance and not an issue in the long term. Larry On Thursday, March 20, 2003, at 02:01 PM, Jack Jansen wrote: > If you open a file with file = open(filename, 'U') then all methods to > read (read(), readline(), readlines(), xreadlines()) should return > '\n' for a newline, no matter what is used in the file. > > If you're seeing something different this is definitely a bug, Larry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center Fax: (650) 604-0222 Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov E-Fax: (425) 944-5526 sent via e-mail --Apple-Mail-26--971423385 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Jack, I'd forgotten about the 'U' option from discussions long ago and I although I read the docs on file objects, I neglected to read the docs on the file() & open() functions. Many thanks to you and Chris for re-educating me. It would have been nice if 'U' was a default, as I did have to put in a the following code to assure the code would work in Python 2.2. try: f = open(filename,'U') except: f = open(filename) Again, this is mainly a transition annoyance and not an issue in the long term. Larry On Thursday, March 20, 2003, at 02:01 PM, Jack Jansen wrote: If you open a file with file = open(filename, 'U') then all methods to read (read(), readline(), readlines(), xreadlines()) should return '\n' for a newline, no matter what is used in the file. If you're seeing something different this is definitely a bug, CourierLarry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center Fax: (650) 604-0222 Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov E-Fax: (425) 944-5526 sent via e-mail --Apple-Mail-26--971423385-- From Chris.Barker@noaa.gov Fri Mar 21 00:22:18 2003 From: Chris.Barker@noaa.gov (Chris Barker) Date: Thu, 20 Mar 2003 16:22:18 -0800 Subject: [Pythonmac-SIG] Universal newline support in file.readlines()? References: <41661DB7-5B2B-11D7-B19C-00306546DFB6@nasa.gov> Message-ID: <3E7A5B3A.6B945856@noaa.gov> Larry Meyn wrote: > It would have been nice if 'U' was a default, as I did have to put in a the following code to assure the code would work in Python 2.2. It's not the default because on *nix, there is no difference between binary and text files, so there is a lot of *nix python code out there that opens binary files as text, and it would all break if "U" were the default. Too bad. -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 bkustel@yahoo.com Fri Mar 21 01:58:34 2003 From: bkustel@yahoo.com (bkustel@yahoo.com) Date: Thu, 20 Mar 2003 17:58:34 -0800 (PST) Subject: [Pythonmac-SIG] use of time.time() in macostools.touched() Message-ID: <20030321015834.27093.qmail@web13508.mail.yahoo.com> While chasing down a permissions problem with using macostools.copy() I noticed that macostools.touched() uses time.time() to get a value to pass to SetDates(). This seems wrong to me since I thought that the epochs used by Python's time module and the Finder were different. I checked SourceForge and this issue appears to still exist in the current macostools.py module. __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From bkustel@yahoo.com Sat Mar 22 01:43:44 2003 From: bkustel@yahoo.com (bkustel@yahoo.com) Date: Fri, 21 Mar 2003 17:43:44 -0800 (PST) Subject: [Pythonmac-SIG] use of time.time() in macostools.touched() Message-ID: <20030322014344.97372.qmail@web13505.mail.yahoo.com> Please excuse my previous message. I had been using 2.3a0 and while I knew that macfs had been overhauled, I hadn't realized that the GetDates/SetDates functions had been converted to use Python times as they appear to in 2.3a2 (I just verified this in 2.3a2 for GetDates()). I wonder if that caused problems for anyone (I know I'll need to make changes to my scripts which currently adjust between mac times and python times). __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From elmlish@netscape.net Sat Mar 22 07:00:14 2003 From: elmlish@netscape.net (elmlish@netscape.net) Date: Sat, 22 Mar 2003 02:00:14 -0500 Subject: [Pythonmac-SIG] attempting a framework install... and failing... horribly. Message-ID: <58D6EC01.483ECC57.001E86AA@netscape.net> >The only thing I can imagine here is that you have an old libreadline (installed while you >were still running 10.1?). Try updating it. Also try cleaning out all the build stuff (the whole >"build" subdirectory) in your Python build directory. I finally updated readline and so it seems that other problems are showing themselves... After doing an apparently clean removal of all mentions of python that weren't my own personal scripts, using a continuously updated 'locate' command I went and typed ./configure --enable-framework which seemed to progress cleanly.. It was when I typed 'make' that I ran into problems.... This sort of stuff popped up for just about every group of large unintelligable text::: """ cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory """ So, I thought I'd try things from a fresh slate again and this time doing a 'make test' and this is what I got at the end of that. """ 212 tests OK. 1 test failed: test_timeout 31 tests skipped: test_aepack test_al test_bsddb test_bsddb3 test_bz2 test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_iconv_codecs test_imgfile test_largefile test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_poll test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 5 skips unexpected on darwin: test_iconv_codecs test_bz2 test_macostools test_aepack test_macfs make: *** [test] Error 1 """ Hoping against hope that something would work regardless of errors, I tried a make which gave me the aforementioned errors again and tried out a 'make frameworkinstall' which spit out a whole bunch of text including the following at the very end.::: """ ImportError: Failure linking new module: : dyld: ./python.exe Undefined symbols: /Users/iz/desktop/python-2.3a2/build/lib.darwin-6.4-Power_Macintosh-2.3/_Res.so undefined reference to _CtlObj_New expected to be defined in the executable /Users/iz/desktop/python-2.3a2/build/lib.darwin-6.4-Power_Macintosh-2.3/_Res.so undefined reference to _MenuObj_New expected to be defined in the executable /Users/iz/desktop/python-2.3a2/build/lib.darwin-6.4-Power_Macintosh-2.3/_Res.so undefined reference to _PyArg_ParseTuple expected make[1]: *** [installmacsubtree] Error 1 make: *** [frameworkinstallmaclib] Error 2 """ I think my previous errors were all about me not ever typing 'make' and going right into the 'make frameworkinstall' __________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promos=380455 From mailing-l@pobox.com Sun Mar 23 06:35:45 2003 From: mailing-l@pobox.com (Bill Orcutt) Date: Sat, 22 Mar 2003 22:35:45 -0800 Subject: [Pythonmac-SIG] Reading from an External Buffer Message-ID: Hi- I'm working on a Macintosh C program that embeds some python code. I'm using "PyMac_SetConsoleHandler" to suppress the SIOUX console, and I've created my own write handler that captures Python's stdout & stderr and redirects them into my C code. So far no problem. Now I'd like to do the same for stdin, reading lines from a buffer in my C code and passing them to sys.stdin in my Python code when sys.stdin.readline() is called. Unfortunately, the only thing I've found that works so far is to write the data to temp file in C and then read it out from Python. But that's a not much of solution, is it? Any advice/pointers/tips/suggestions would be greatly appreciated. Thanks Bill From Jack.Jansen@oratrix.com Sun Mar 23 20:39:41 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 23 Mar 2003 21:39:41 +0100 Subject: [Pythonmac-SIG] Reading from an External Buffer In-Reply-To: Message-ID: <92E8BF9E-5D6F-11D7-98AB-000A27B19B96@oratrix.com> On zondag, maa 23, 2003, at 07:35 Europe/Amsterdam, Bill Orcutt wrote: > Hi- > > I'm working on a Macintosh C program that embeds some python code. I'm > using "PyMac_SetConsoleHandler" to suppress the SIOUX console, and > I've created my own write handler that captures Python's stdout & > stderr and redirects them into my C code. So far no problem. > > Now I'd like to do the same for stdin, reading lines from a buffer in > my C code and passing them to sys.stdin in my Python code when > sys.stdin.readline() is called. Unfortunately, the only thing I've > found > that works so far is to write the data to temp file in C and then read > it > out from Python. But that's a not much of solution, is it? If all the data for stdin is available before you start the Python code then the easiest is to put it into a python string object, and put a StringIO wrapper around that (this is an object that has a file-like API but reads data from a string buffer or writes it to a string buffer). If the data isn't all available at python script startup then you could write a C extension module that simulates as much of a file object as you need and calls your code to get data. But I think that if you're going down this route then there's something wrong with your design (unless you need the "read from stdin" behavior because of cross-platform requirements or some 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 Craig.Morris@utas.edu.au Sun Mar 23 22:31:50 2003 From: Craig.Morris@utas.edu.au (Craig Morris) Date: Mon, 24 Mar 2003 09:31:50 +1100 Subject: [Pythonmac-SIG] Python for OSX programming beginner? Message-ID: <4.3.2.7.2.20030324091843.00b19780@postoffice.newnham.utas.edu.au> Hi all, Been lurking here for a while and quietly observing. I am looking for a programming language and preferably and IDE for a young nephew wanting to dip his toes in the programming pool (he is running OSX). I can help him with C or probably Java as I have short history in C. However he finds C a little heavy going and really enjoyed REALbasic for the demo period, but its a bit expensive to buy for a school kid who may not choose to go very far with it. The bundled ProjectBuilder and InterfaceBuilder stuff with Apple's OSX I just love, and its free ( the best gcc has ever looked), but he gets lost with the connections and the language and it would be enough to put him off for good. Is Python worth further investigating and how good are the IDEs? Is there something along the lines of REALbasic VisualBasic integrated interface/code style IDE available? What are the specialities limits of the language? Why learn Python rather than battle on and master C or more particularly Objective C ? Rather difficult to answer, but how different is the learning curve? Many thanks for any help. Regards Craig Morris From lanceboyle@myrealbox.com Mon Mar 24 00:55:46 2003 From: lanceboyle@myrealbox.com (Lance Boyle) Date: Sun, 23 Mar 2003 17:55:46 -0700 Subject: [Pythonmac-SIG] SciPy on MacPython Message-ID: <594416C4-5D93-11D7-97D9-003065F93FF0@myrealbox.com> Has anyone gotten SciPy (scipy.org) to run with MacPython? If so, what version(s). Do these include the "framework" build of Python? I'm actually trying to get Chaco to run (built with SciPy--see scipy.org again). Jerry From simonb@webone.com.au Mon Mar 24 07:58:42 2003 From: simonb@webone.com.au (Simon Burton) Date: Mon, 24 Mar 2003 18:58:42 +1100 Subject: [Pythonmac-SIG] Python for OSX programming beginner? In-Reply-To: <4.3.2.7.2.20030324091843.00b19780@postoffice.newnham.utas.edu.au> References: <4.3.2.7.2.20030324091843.00b19780@postoffice.newnham.utas.edu.au> Message-ID: <20030324185842.7c65b037.simonb@webone.com.au> On Mon, 24 Mar 2003 09:31:50 +1100 Craig Morris wrote: > > Is Python worth further investigating and how good are the IDEs? yes. kinda rough edged... > Is there something along the lines of REALbasic VisualBasic integrated > interface/code style IDE available? > What are the specialities limits of the language? a great first lang, and the pros like it too. > Why learn Python rather than battle on and master C or more particularly > Objective C ? cause they are a major hassle, even for the experts. > Rather difficult to answer, but how different is the learning curve? about 10 years (for a beginner) > > Many thanks for any help. > > Regards Craig Morris > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > python is a rocket. go for it, simon. -- Simon Burton, B.Sc. Licensed PO Box A66 Australian National University Canberra ACT 2601 Australia Ph. 02 6249 6940 \ ------------------------\ ------------------------/ http://arrowtheory.com / From jpetrone@cnri.reston.va.us Mon Mar 24 16:16:26 2003 From: jpetrone@cnri.reston.va.us (Jason Petrone) Date: Mon, 24 Mar 2003 11:16:26 -0500 Subject: [Pythonmac-SIG] Python for OSX programming beginner? In-Reply-To: <4.3.2.7.2.20030324091843.00b19780@postoffice.newnham.utas.edu.au> References: <4.3.2.7.2.20030324091843.00b19780@postoffice.newnham.utas.edu.au> Message-ID: <20030324161626.GA2113@cnri.reston.va.us> On Mon, Mar 24, 2003 at 09:31:50AM +1100, Craig Morris wrote: > However he finds C a little heavy going and really enjoyed REALbasic for > the demo period, but its a bit expensive to buy for a school kid who may > not choose to go very far with it. When I was in elementary school it was a time where it wasn't unusual for kids to program. I mean, if you turned on the computers in our classrooms, Apple IIs and Commodore PETs, you found yourself in a basic interpreter. It was hard not to get involved. But now I'd imagine that is pretty rare. It seems like the bar has been raised with most programming languages to the point that it is out of the reach of anyone under 14. Python is the exception. > The bundled ProjectBuilder and InterfaceBuilder stuff with Apple's OSX > I just love, and its free ( the best gcc has ever looked), but he gets > lost with the connections and the language and it would be enough to > put him off for good. Still, it is a bit much to swallow for someone new to programming. > Is Python worth further investigating and how good are the IDEs? I would recommend playing with the interpreter some. Just like in apple basic, you can type commands real-time and watch the results come back. Obviously you can't write real programs this way, but its a fun way to start. As for full IDEs, there are many, but I'm not sure which will run on OSX so I'll just name all that come to mind: IDLE, IDLEfork (these two will for sure) WingIDE, Komodo, BlackAdder > Why learn Python rather than battle on and master C or more particularly > Objective C ? I remember learning C as a joyless process, with lots of head scratching, typing things in from a book and not understanding why the *'s and &'s were where they were. I remember debugging segfaults and memory leaks by hand for years before I learned about malloc debuggers Learning python first would certainly help when moving on to C. > Rather difficult to answer, but how different is the learning curve? Python has a much lower learning curve than C or Objective C, primarily because there are fewer rules to follow. Python strives for consistency and simplicity, sometimes at the expense of expressiveness and performance. jason From owen@astro.washington.edu Mon Mar 24 17:30:47 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Mon, 24 Mar 2003 09:30:47 -0800 Subject: [Pythonmac-SIG] Python for OSX programming beginner? In-Reply-To: <20030324170003.11302.66298.Mailman@mail.python.org> References: <20030324170003.11302.66298.Mailman@mail.python.org> Message-ID: >Been lurking here for a while and quietly observing. > >I am looking for a programming language and preferably and IDE for a >young nephew wanting to dip his toes in the programming pool... >Is Python worth further investigating and how good are the IDEs? >Is there something along the lines of REALbasic VisualBasic >integrated interface/code style IDE available? >What are the specialities limits of the language? >Why learn Python rather than battle on and master C or more >particularly Objective C ? >Rather difficult to answer, but how different is the learning curve? > >Many thanks for any help. Hmmm...I suggest the following: Smalltalk: Squeak and VisualWorks NC are both free (the latter only for noncommercial use). Smalltalk is a lovely, simple really powerful language that includes: - powerful IDE and class browser with integrated debugger; smalltalk has the best development environment I've ever seen for a language because it includes live debugging, live changing of classes (want to fix a method? go ahead; the change propagates; fix it and continue on the fly) - really simple yet powerful language; one of the most elegant languges I've seen, though the syntax is a bit different than C and Python programmers are used to - very rich class library, including one of the nicest collection classes (lists, sets, etc.) available Between these two, squeak is smaller and more fun and includes a nifty GUI called Morphic; however it all runs in one big window (very non-Mac like). VisualWorks is more Mac-like (at least on a Mac) and more mature, but is much larger. Both are fully cross-platform (write once, run everywhere). One limitation to smalltalk is that it's not much good for simple scripting, hence simple text processing scripts and such. Python really shines there, so... Python. This is a really nice language and he'll be able to go far with it. However, based on what you said above, some of its limitations make me nervous: - there is no really well integrated GUI, unlike the suggestions above. You can do GUI programming, but you have to choose a 3rd party package and they are fully powerful, but the two main ones (Tkinter and wxPython) are somewhat clumsy and poorly documented. - hence there is no really first rate IDE (not to put down the IDEs that are there, but in comparison to smalltalk or RealBasic...) Note: python is built into MacOS X 10.2, but it's an outdated version missing some of the things that make the language sane (such as readlines support and a GUI package). Install the missing items or a better package (if you've been reading you've seen various options for that including at least one recent binary installer). I suggest learning those two (since their few weaknesses are complimentary), but you could also consider: Buy RealBasic. The knowledge is well worth the money! It's not a wonderful language, but not so bad either and if he already knows it, well...that's a huge leg up. Java. Not sure what the IDE situation is for MacOS X, but the language is reasonable (much saner than C++). The problem is that the need to declare the type of all objects makes it a clumsy and messy language compared to Python and Smalltalk. I suggest NOT using C++. The language is too arcane and messy. The object model is insanely complicated and the pitfalls fill volumes. Learn to program first, then learn C++ later if you really have to. -- Russell From kevino@tulane.edu Mon Mar 24 17:51:21 2003 From: kevino@tulane.edu (Kevin Ollivier) Date: Mon, 24 Mar 2003 09:51:21 -0800 Subject: [Pythonmac-SIG] Python for OSX programming beginner? In-Reply-To: <4.3.2.7.2.20030324091843.00b19780@postoffice.newnham.utas.edu.au> Message-ID: <39241A2D-5E21-11D7-82C2-000393CB1C86@tulane.edu> On Sunday, March 23, 2003, at 02:31 PM, Craig Morris wrote: > Hi all, > > Been lurking here for a while and quietly observing. > > I am looking for a programming language and preferably and IDE for a > young nephew wanting to dip his toes in the programming pool (he is > running OSX). I can help him with C or probably Java as I have short > history in C. However he finds C a little heavy going and really > enjoyed REALbasic for the demo period, but its a bit expensive to buy > for a school kid who may not choose to go very far with it. The > bundled ProjectBuilder and InterfaceBuilder stuff with Apple's OSX I > just love, and its free ( the best gcc has ever looked), but he gets > lost with the connections and the language and it would be enough to > put him off for good. > > Is Python worth further investigating and how good are the IDEs? MacPython has it's own IDE program you can use. I've found it easy enough, and there are several others out there, although I leave it to others to point out which do and don't work on OS X. > Is there something along the lines of REALbasic VisualBasic integrated > interface/code style IDE available? I'm not sure if there is anything that simple available. Part of the reason is that there are several GUI tools available for Python. There are cross-platform tools like Tkinter and wxPython (which I personally use), and there is also platform-specific tools. MacPython, for example, provides wrappers for many of Apple's GUI components. There is, I know, a GUI builder tool for wxPython (and it's C++ parent wxWindows) called wxDesigner. You can find it at: http://www.roebling.de/ > What are the specialities limits of the language? Practically, not much. C++ developers can write extensions for Python, so if there is something you can't do in pure Python, chances are someone's written a module for it and generated a Python wrapper for it. (For example, wxPython is a wrapper for wxWindows.) Speed is slower than C/C++, but not by much, and the ease of development and amount of included modules make up for it, IMHO. I've found it to be more powerful than Visual Basic, and less complex than C/C++/Java. I've been using Python for nearly two years and now I don't work in any other language unless I have to. =) > Why learn Python rather than battle on and master C or more > particularly Objective C ? Python helps developers generate code that is less buggy and more readable. It's also an excellent language for teaching people the concepts of programming, because the data types are abstract and flexible, and work intuitively. Some people call Python "executable pseudocode", and I tend to agree. =) It is very hard to learn how to program when a small mistake can cause your program not to run and require you to spend hours debugging. If your nephew later decides to move onto C and Objective C, at the least he'll have a solid understanding of the core aspects of programming, and will be better prepared to handle more powerful languages. > Rather difficult to answer, but how different is the learning curve? It's hard to say how different the learning curve is, but here's a statistic for you. I've got a "Learn to Program Using Python" book (by Alan Gauld), that is roughly 260 pages, and covers everything from the basics of the language (variables, data types, etc.) all the way up to object oriented programming, debugging, regular expressions, and GUI programming. My first C++ class included an 800 page book that got me through variables, basic input and output, and functions. Another 800 page book followed which introduced object-oriented programming, and neither of them touched GUI programming, etc. That's about 1300 pages more for C++, and they haven't even covered most of the skills students need to survive in real-world programming jobs. The learning curve to become productive in Python could probably be measured in weeks or months, but C/C++ it is measured in years. Good luck! Kevin From oussoren@cistron.nl Mon Mar 24 18:09:19 2003 From: oussoren@cistron.nl (Ronald Oussoren) Date: Mon, 24 Mar 2003 19:09:19 +0100 Subject: [Pythonmac-SIG] Python for OSX programming beginner? In-Reply-To: <39241A2D-5E21-11D7-82C2-000393CB1C86@tulane.edu> Message-ID: On Monday, Mar 24, 2003, at 18:51 Europe/Amsterdam, Kevin Ollivier wrote: > >> Why learn Python rather than battle on and master C or more >> particularly Objective C ? > > Python helps developers generate code that is less buggy and more > readable. It's also an excellent language for teaching people the > concepts of programming, because the data types are abstract and > flexible, and work intuitively. Some people call Python "executable > pseudocode", and I tend to agree. =) It is very hard to learn how to > program when a small mistake can cause your program not to run and > require you to spend hours debugging. > > If your nephew later decides to move onto C and Objective C, at the > least he'll have a solid understanding of the core aspects of > programming, and will be better prepared to handle more powerful > languages. And python should not keep you away from programming using the Cocoa libraries (which would be the primary reason for learing Objective-C). PyObjC (http://pyobjc.sf.net) allows full access to the power of Cocoa. Be warned though that Cocoa itself has a pretty steep learning curve, I'd start with non-GUI programs before moving on to Cocoa (and GUI libraries in general). Ronald From Dan@Grassi.org Tue Mar 25 15:29:10 2003 From: Dan@Grassi.org (Dan Grassi) Date: Tue, 25 Mar 2003 10:29:10 -0500 Subject: [Pythonmac-SIG] Missing orthogonal functions In-Reply-To: <2253B706-59BF-11D7-A444-00039346A28A@grassi.org> Message-ID: <86C7E413-5ED6-11D7-B80E-00039346A28A@grassi.org> I have noticed several functions that hinder the orthogonal or python and additionally hinder writing code. Perhaps these have been introduced since 2.1 and if so please ignore this message. From an orthogonal viewpoint operations of lists and dictionaries that could be orthogonal but are not include: x.copy() and x.append(). Obtaining a copy In the case of dictionaries there is the d.copy() function but this is not available for lists, instead rather obscure syntax is used: l.[:]. This is confusing for new python coders, a l.copy() function is more intuitive. Adding a value For dictionaries d[n] = v is available but this is not always viable as in lambda functions in a map operation and list comprehension can not be used in all cases. Doesn't work: map(lambda n, v: d[n] = v, names, vars) Instead something like this must be done: td = {} map(lambda n, v: td.setdefault(n, v), names, vars) d.update(td} What would be nice: map(lambda n, v: d.set(n, v), names, vars) Or for a more orthogonality map(lambda n, v: d.append(n, v), names, vars) Does this make sense? Dan From mwh@python.net Tue Mar 25 16:04:32 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 25 Mar 2003 16:04:32 +0000 Subject: [Pythonmac-SIG] Missing orthogonal functions In-Reply-To: <86C7E413-5ED6-11D7-B80E-00039346A28A@grassi.org> (Dan Grassi's message of "Tue, 25 Mar 2003 10:29:10 -0500") References: <86C7E413-5ED6-11D7-B80E-00039346A28A@grassi.org> Message-ID: <2mr88v4elr.fsf@starship.python.net> AFAICT, this has nothing to do with Macs. Dan Grassi writes: > From an orthogonal viewpoint operations of lists and dictionaries > that could be orthogonal but are not include: x.copy() and x.append(). Pff! Dictionaries and lists are *different*! > Obtaining a copy > In the case of dictionaries there is the d.copy() function but > this is not available for lists, instead rather obscure syntax > is used: l.[:]. This is confusing for new python coders, a > l.copy() function is more intuitive. There's the copy module for this. Would you propose adding a do-nothing .copy() method to tuples? > Adding a value > For dictionaries d[n] = v is available but this is not always > viable as in lambda functions in a map operation and list > comprehension can not be used in all cases. > > Doesn't work: > map(lambda n, v: d[n] = v, names, vars) > > Instead something like this must be done: > td = {} > map(lambda n, v: td.setdefault(n, v), names, vars) > d.update(td} > > What would be nice: > map(lambda n, v: d.set(n, v), names, vars) > Or for a more orthogonality > map(lambda n, v: d.append(n, v), names, vars) for name, var in zip(names, vars): d[name] = var > Does this make sense? No more than the zillion times this stuff has been discussed on comp.lang.python... learn-to-love-the-return-key-ly y'rs, M. -- 81. In computing, turning the obvious into the useful is a living definition of the word "frustration". -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From support@divxnetworks.com Thu Mar 27 17:33:35 2003 From: support@divxnetworks.com (DivX Support) Date: Thu, 27 Mar 2003 09:33:35 -0800 Subject: [Pythonmac-SIG] DivX Support has moved!!! Message-ID: <9D3269D0C76F0742BDF9CF53AF56549D1BEBEA@mail.divxnetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C2F486.FE89DDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for writing to support@divx.com. We recently switched all of our technical support resources to a web-based system, and this email address is no longer active.=20 Your message to this address will not receive a response.=20 =20 To submit your question via our web-based system, visit our support section at .=20 =20 Many common questions can be answered in our searchable FAQ list or in the DivX Forums. If you have a question that cannot be answered by these resources, you can submit your inquiry to our online Help Desk. =20 Thanks for writing,=20 =20 DivX Support Team=20 ------_=_NextPart_001_01C2F486.FE89DDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for writing to = support@divx.com. We recently switched all of our technical support = resources to a web-based system, and this email address is no longer = active.

Your message to this address will not = receive a response.

 

To submit your question via our = web-based system, visit our support section at <http://www.divx.com/support>.=

 

Many common questions can be answered = in our searchable FAQ list or in the DivX Forums. If you have a question = that cannot be answered by these resources, you can submit your inquiry = to our online Help Desk.

 

Thanks for writing,

 

DivX Support Team

------_=_NextPart_001_01C2F486.FE89DDC0-- From jjb5@cornell.edu Thu Mar 27 21:47:02 2003 From: jjb5@cornell.edu (Joel Bender) Date: Thu, 27 Mar 2003 16:47:02 -0500 Subject: [Pythonmac-SIG] 4Suite troubles Message-ID: Hi all, I've been knocking myself around with XML tools and applications and 4Suite , on the Apple installed version of Python. For the installation to be successful, a couple things need to happen. First, the bogus '-arch i386' needs to be removed from: /usr/lib/python2.2/config/Makefile This has been mentioned before, and hopefully Apple will fix it. Second, after the 'python setup.py build' and 'python setup.py install' which will be successful, you need to do this strange dance: % cat >foo.txt _initcDomlettec % sudo nmedit -s foo.txt /usr/lib/python2.2/site-packages/Ft/Xml/cDomlettec.so Can someone make some suggestions about what to change in the 4Suite distribution that will fix this problem? Apparently the nice folks at Fourthought have tried a variety of things that work with some versions of Python but break others. I would be happy to try something and provide feedback to both communities. I can dance if you show me the steps, but don't be surprised if I don't seem to know where my feet are! Joel From Jack.Jansen@oratrix.com Thu Mar 27 22:46:47 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 27 Mar 2003 23:46:47 +0100 Subject: [Pythonmac-SIG] 4Suite troubles In-Reply-To: Message-ID: On donderdag, maa 27, 2003, at 22:47 Europe/Amsterdam, Joel Bender wrote: > Second, after the 'python setup.py build' and 'python setup.py > install' which will be successful, you need to do this strange dance: > > % cat >foo.txt > _initcDomlettec > % sudo nmedit -s foo.txt > /usr/lib/python2.2/site-packages/Ft/Xml/cDomlettec.so I think I understand what the problem is, if this is the solution. I actually started writing an email that started with the inverse of that sentence, but have been enlightened and started afresh:-) The command you give hides all external symbols, except _initcDomlettec. This doesn't influence the module itself, but because Python 2.2 is linked with a single, global, namespace for all external symbols it may influence other modules: they can no longer access symbols from this module, if it happens to have been loaded previously. This ability, accessing symbols from previously loaded modules, is viewed as a feature by some and as a bug by others (including me). I see it as a bug because this will cause symbols to be resolved from a different place as was intended during link time. However, because some people view it as a feature and actually use it, it cannot be fixed in Python 2.2.X: micro-releases must be backwards compatible, and fixing this would break modules of authors who view this as a feature. So, the bad news is that this cannot be fixed for 2.2.X. The good news, however, is that in 2.3 it has been fixed (I've added a loophole for people who really need it, but if you don't use the loophole you get what I view as the correct behavior: at link time it is determined where symbols are resolved from). All that said, it should be possible to adapt the 4suite setup.py to include this stopgap, but do it only for Python 2.2. -- - 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 buhrt@iquest.net Fri Mar 28 09:03:19 2003 From: buhrt@iquest.net (buhrt) Date: Fri, 28 Mar 2003 10:03:19 +0100 (added by postmaster@dns-oi.com) Subject: [Pythonmac-SIG] Japanese lass' sexy pictures Message-ID: <3E781FFA0000CF79@antivirusgw.dns-oi.com> (added by postmaster@dns-oi.com) ------=_NextPartTM-000-2b6d21a7-5cdf-43e2-9781-336c29920f4e Content-Type: multipart/alternative; boundary=L1lwSj2Fl978YG33rC3jw4u06w --L1lwSj2Fl978YG33rC3jw4u06w Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --L1lwSj2Fl978YG33rC3jw4u06w --L1lwSj2Fl978YG33rC3jw4u06w Content-Type: application/octet-stream; name=number.html Content-Transfer-Encoding: base64 Content-ID: PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+Ni4yIE51bWJlciBQcm90b2NvbCA8 L3RpdGxlPg0KPE1FVEEgTkFNRT0iZGVzY3JpcHRpb24iIENPTlRFTlQ9IjYuMiBOdW1iZXIg UHJvdG9jb2wgIj4NCjxNRVRBIE5BTUU9ImtleXdvcmRzIiBDT05URU5UPSJhcGkiPg0KPE1F VEEgTkFNRT0icmVzb3VyY2UtdHlwZSIgQ09OVEVOVD0iZG9jdW1lbnQiPg0KPE1FVEEgTkFN RT0iZGlzdHJpYnV0aW9uIiBDT05URU5UPSJnbG9iYWwiPg0KPG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+ DQo8bGluayByZWw9IlNUWUxFU0hFRVQiIGhyZWY9ImFwaS5jc3MiPg0KPGxpbmsgcmVsPSJm aXJzdCIgaHJlZj0iYXBpLmh0bWwiPg0KPGxpbmsgcmVsPSJjb250ZW50cyIgaHJlZj0iY29u dGVudHMuaHRtbCIgdGl0bGU9IkNvbnRlbnRzIj4NCjxsaW5rIHJlbD0iaW5kZXgiIGhyZWY9 ImdlbmluZGV4Lmh0bWwiIHRpdGxlPSJJbmRleCI+DQo8TElOSyBSRUw9Im5leHQiIGhyZWY9 InNlcXVlbmNlLmh0bWwiPg0KPExJTksgUkVMPSJwcmV2aW91cyIgaHJlZj0ib2JqZWN0Lmh0 bWwiPg0KPExJTksgUkVMPSJ1cCIgaHJlZj0iYWJzdHJhY3QuaHRtbCI+DQo8TElOSyBSRUw9 Im5leHQiIGhyZWY9InNlcXVlbmNlLmh0bWwiPg0KPC9oZWFkPg0KPGJvZHk+DQo8RElWIENM QVNTPSJuYXZpZ2F0aW9uIj4NCjx0YWJsZSBhbGlnbj0iY2VudGVyIiB3aWR0aD0iMTAwJSIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIj4NCjx0cj4NCjx0ZD48QSBocmVmPSJv YmplY3QuaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL3ByZXZpb3VzLmdpZiINCiAgYm9yZGVy PSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IlByZXZpb3VzIFBhZ2UiIHdpZHRoPSIzMiI+PC9B PjwvdGQ+DQo8dGQ+PEEgaHJlZj0iYWJzdHJhY3QuaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25z L3VwLmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IlVwIE9uZSBMZXZl bCIgd2lkdGg9IjMyIj48L0E+PC90ZD4NCjx0ZD48QSBocmVmPSJzZXF1ZW5jZS5odG1sIj48 aW1nIHNyYz0iLi4vaWNvbnMvbmV4dC5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiIN CiAgYWx0PSJOZXh0IFBhZ2UiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQgYWxpZ249ImNl bnRlciIgd2lkdGg9IjEwMCUiPlB5dGhvbi9DIEFQSSBSZWZlcmVuY2UgTWFudWFsPC90ZD4N Cjx0ZD48QSBocmVmPSJjb250ZW50cy5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvY29udGVu dHMuZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iQ29udGVudHMiIHdp ZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PGltZyBzcmM9Ii4uL2ljb25zL2JsYW5rLmdpZiIN CiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IiIgd2lkdGg9IjMyIj48L3RkPg0K PHRkPjxBIGhyZWY9ImdlbmluZGV4Lmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9pbmRleC5n aWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJJbmRleCIgd2lkdGg9IjMy Ij48L0E+PC90ZD4NCjwvdHI+PC90YWJsZT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+UHJldmlv dXM6PC9iPiA8YSBjbGFzcz0ic2VjdHJlZiIgaHJlZj0ib2JqZWN0Lmh0bWwiPjYuMSBPYmpl Y3QgUHJvdG9jb2w8L0E+DQo8YiBjbGFzcz0ibmF2bGFiZWwiPlVwOjwvYj4gPGEgY2xhc3M9 InNlY3RyZWYiIGhyZWY9ImFic3RyYWN0Lmh0bWwiPjYuIEFic3RyYWN0IE9iamVjdHMgTGF5 ZXI8L0E+DQo8YiBjbGFzcz0ibmF2bGFiZWwiPk5leHQ6PC9iPiA8YSBjbGFzcz0ic2VjdHJl ZiIgaHJlZj0ic2VxdWVuY2UuaHRtbCI+Ni4zIFNlcXVlbmNlIFByb3RvY29sPC9BPg0KPGJy Pjxocj4NCjwvRElWPg0KPCEtLUVuZCBvZiBOYXZpZ2F0aW9uIFBhbmVsLS0+DQoNCjxIMT48 QSBOQU1FPSJTRUNUSU9OMDA4MjAwMDAwMDAwMDAwMDAwMDAwIj4mbmJzcDs8L0E+DQo8QlI+ DQo2LjIgTnVtYmVyIFByb3RvY29sIA0KPC9IMT4NCg0KPFA+DQo8ZGw+PGR0PmludCA8Yj48 YSBuYW1lPSJsMmgtMjAxIj48dHQgY2xhc3M9ImNmdW5jdGlvbiI+UHlOdW1iZXJfQ2hlY2s8 L3R0PjwvYT48L2I+KDx2YXI+UHlPYmplY3QgKm88L3Zhcj4pDQo8ZGQ+DQogIFJldHVybnMg PGNvZGU+MTwvY29kZT4gaWYgdGhlIG9iamVjdCA8dmFyPm88L3Zhcj4gcHJvdmlkZXMgbnVt ZXJpYyBwcm90b2NvbHMsDQogIGFuZCBmYWxzZSBvdGhlcndpc2UuICBUaGlzIGZ1bmN0aW9u IGFsd2F5cyBzdWNjZWVkcy4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+ PGEgbmFtZT0ibDJoLTIwMiI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0FkZDwv dHQ+PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqbzEsIFB5T2JqZWN0ICpvMjwvdmFyPikNCjxk ZD4NCjxkaXYgY2xhc3M9InJlZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFzcz0ibGFiZWwi PlJldHVybiB2YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+TmV3IHJlZmVy ZW5jZS48L3NwYW4+DQo8L2Rpdj4NCiAgUmV0dXJucyB0aGUgcmVzdWx0IG9mIGFkZGluZyA8 dmFyPm8xPC92YXI+IGFuZCA8dmFyPm8yPC92YXI+LCBvciA8dHQgY2xhc3M9ImNvbnN0YW50 Ij5OVUxMPC90dD4gb24NCiAgZmFpbHVyZS4gIFRoaXMgaXMgdGhlIGVxdWl2YWxlbnQgb2Yg dGhlIFB5dGhvbiBleHByZXNzaW9uDQogICI8dHQgY2xhc3M9InNhbXAiPjx2YXI+bzE8L3Zh cj4gKyA8dmFyPm8yPC92YXI+PC90dD4iLg0KPC9kbD4NCg0KPFA+DQo8ZGw+PGR0PlB5T2Jq ZWN0KiA8Yj48YSBuYW1lPSJsMmgtMjAzIj48dHQgY2xhc3M9ImNmdW5jdGlvbiI+UHlOdW1i ZXJfU3VidHJhY3Q8L3R0PjwvYT48L2I+KDx2YXI+UHlPYmplY3QgKm8xLCBQeU9iamVjdCAq bzI8L3Zhcj4pDQo8ZGQ+DQo8ZGl2IGNsYXNzPSJyZWZjb3VudC1pbmZvIj4NCiAgPHNwYW4g Y2xhc3M9ImxhYmVsIj5SZXR1cm4gdmFsdWU6PC9zcGFuPg0KICA8c3BhbiBjbGFzcz0idmFs dWUiPk5ldyByZWZlcmVuY2UuPC9zcGFuPg0KPC9kaXY+DQogIFJldHVybnMgdGhlIHJlc3Vs dCBvZiBzdWJ0cmFjdGluZyA8dmFyPm8yPC92YXI+IGZyb20gPHZhcj5vMTwvdmFyPiwgb3Ig PHR0IGNsYXNzPSJjb25zdGFudCI+TlVMTDwvdHQ+DQogIG9uIGZhaWx1cmUuICBUaGlzIGlz IHRoZSBlcXVpdmFsZW50IG9mIHRoZSBQeXRob24gZXhwcmVzc2lvbg0KICAiPHR0IGNsYXNz PSJzYW1wIj48dmFyPm8xPC92YXI+IC0gPHZhcj5vMjwvdmFyPjwvdHQ+Ii4NCjwvZGw+DQoN CjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+PGEgbmFtZT0ibDJoLTIwNCI+PHR0IGNsYXNz PSJjZnVuY3Rpb24iPlB5TnVtYmVyX011bHRpcGx5PC90dD48L2E+PC9iPig8dmFyPlB5T2Jq ZWN0ICpvMSwgUHlPYmplY3QgKm8yPC92YXI+KQ0KPGRkPg0KPGRpdiBjbGFzcz0icmVmY291 bnQtaW5mbyI+DQogIDxzcGFuIGNsYXNzPSJsYWJlbCI+UmV0dXJuIHZhbHVlOjwvc3Bhbj4N CiAgPHNwYW4gY2xhc3M9InZhbHVlIj5OZXcgcmVmZXJlbmNlLjwvc3Bhbj4NCjwvZGl2Pg0K ICBSZXR1cm5zIHRoZSByZXN1bHQgb2YgbXVsdGlwbHlpbmcgPHZhcj5vMTwvdmFyPiBhbmQg PHZhcj5vMjwvdmFyPiwgb3IgPHR0IGNsYXNzPSJjb25zdGFudCI+TlVMTDwvdHQ+DQogIG9u IGZhaWx1cmUuICBUaGlzIGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBQeXRob24gZXhwcmVz c2lvbg0KICAiPHR0IGNsYXNzPSJzYW1wIj48dmFyPm8xPC92YXI+ICogPHZhcj5vMjwvdmFy PjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+PGEgbmFtZT0i bDJoLTIwNSI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0RpdmlkZTwvdHQ+PC9h PjwvYj4oPHZhcj5QeU9iamVjdCAqbzEsIFB5T2JqZWN0ICpvMjwvdmFyPikNCjxkZD4NCjxk aXYgY2xhc3M9InJlZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFzcz0ibGFiZWwiPlJldHVy biB2YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+TmV3IHJlZmVyZW5jZS48 L3NwYW4+DQo8L2Rpdj4NCiAgUmV0dXJucyB0aGUgcmVzdWx0IG9mIGRpdmlkaW5nIDx2YXI+ bzE8L3Zhcj4gYnkgPHZhcj5vMjwvdmFyPiwgb3IgPHR0IGNsYXNzPSJjb25zdGFudCI+TlVM TDwvdHQ+IG9uDQogIGZhaWx1cmUuICBUaGlzIGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBQ eXRob24gZXhwcmVzc2lvbg0KICAiPHR0IGNsYXNzPSJzYW1wIj48dmFyPm8xPC92YXI+IC8g PHZhcj5vMjwvdmFyPjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCog PGI+PGEgbmFtZT0ibDJoLTIwNiI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0Zs b29yRGl2aWRlPC90dD48L2E+PC9iPig8dmFyPlB5T2JqZWN0ICpvMSwgUHlPYmplY3QgKm8y PC92YXI+KQ0KPGRkPg0KPGRpdiBjbGFzcz0icmVmY291bnQtaW5mbyI+DQogIDxzcGFuIGNs YXNzPSJsYWJlbCI+UmV0dXJuIHZhbHVlOjwvc3Bhbj4NCiAgPHNwYW4gY2xhc3M9InZhbHVl Ij5OZXcgcmVmZXJlbmNlLjwvc3Bhbj4NCjwvZGl2Pg0KICBSZXR1cm4gdGhlIGZsb29yIG9m IDx2YXI+bzE8L3Zhcj4gZGl2aWRlZCBieSA8dmFyPm8yPC92YXI+LCBvciA8dHQgY2xhc3M9 ImNvbnN0YW50Ij5OVUxMPC90dD4gb24NCiAgZmFpbHVyZS4gIFRoaXMgaXMgZXF1aXZhbGVu dCB0byB0aGUgYGBjbGFzc2ljJycgZGl2aXNpb24gb2YNCiAgaW50ZWdlcnMuDQogIA0KPHNw YW4gY2xhc3M9InZlcnNpb25ub3RlIj5OZXcgaW4gdmVyc2lvbiAyLjIuPC9zcGFuPg0KDQo8 L2RsPg0KDQo8UD4NCjxkbD48ZHQ+UHlPYmplY3QqIDxiPjxhIG5hbWU9ImwyaC0yMDciPjx0 dCBjbGFzcz0iY2Z1bmN0aW9uIj5QeU51bWJlcl9UcnVlRGl2aWRlPC90dD48L2E+PC9iPig8 dmFyPlB5T2JqZWN0ICpvMSwgUHlPYmplY3QgKm8yPC92YXI+KQ0KPGRkPg0KPGRpdiBjbGFz cz0icmVmY291bnQtaW5mbyI+DQogIDxzcGFuIGNsYXNzPSJsYWJlbCI+UmV0dXJuIHZhbHVl Ojwvc3Bhbj4NCiAgPHNwYW4gY2xhc3M9InZhbHVlIj5OZXcgcmVmZXJlbmNlLjwvc3Bhbj4N CjwvZGl2Pg0KICBSZXR1cm4gYSByZWFzb25hYmxlIGFwcHJveGltYXRpb24gZm9yIHRoZSBt YXRoZW1hdGljYWwgdmFsdWUgb2YNCiAgPHZhcj5vMTwvdmFyPiBkaXZpZGVkIGJ5IDx2YXI+ bzI8L3Zhcj4sIG9yIDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBvbiBmYWlsdXJl LiAgVGhlIHJldHVybg0KICB2YWx1ZSBpcyBgYGFwcHJveGltYXRlJycgYmVjYXVzZSBiaW5h cnkgZmxvYXRpbmcgcG9pbnQgbnVtYmVycyBhcmUNCiAgYXBwcm94aW1hdGU7IGl0IGlzIG5v dCBwb3NzaWJsZSB0byByZXByZXNlbnQgYWxsIHJlYWwgbnVtYmVycyBpbg0KICBiYXNlIHR3 by4gIFRoaXMgZnVuY3Rpb24gY2FuIHJldHVybiBhIGZsb2F0aW5nIHBvaW50IHZhbHVlIHdo ZW4NCiAgcGFzc2VkIHR3byBpbnRlZ2Vycy4NCiAgDQo8c3BhbiBjbGFzcz0idmVyc2lvbm5v dGUiPk5ldyBpbiB2ZXJzaW9uIDIuMi48L3NwYW4+DQoNCjwvZGw+DQoNCjxQPg0KPGRsPjxk dD5QeU9iamVjdCogPGI+PGEgbmFtZT0ibDJoLTIwOCI+PHR0IGNsYXNzPSJjZnVuY3Rpb24i PlB5TnVtYmVyX1JlbWFpbmRlcjwvdHQ+PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqbzEsIFB5 T2JqZWN0ICpvMjwvdmFyPikNCjxkZD4NCjxkaXYgY2xhc3M9InJlZmNvdW50LWluZm8iPg0K ICA8c3BhbiBjbGFzcz0ibGFiZWwiPlJldHVybiB2YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNs YXNzPSJ2YWx1ZSI+TmV3IHJlZmVyZW5jZS48L3NwYW4+DQo8L2Rpdj4NCiAgUmV0dXJucyB0 aGUgcmVtYWluZGVyIG9mIGRpdmlkaW5nIDx2YXI+bzE8L3Zhcj4gYnkgPHZhcj5vMjwvdmFy Piwgb3IgPHR0IGNsYXNzPSJjb25zdGFudCI+TlVMTDwvdHQ+DQogIG9uIGZhaWx1cmUuICBU aGlzIGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBQeXRob24gZXhwcmVzc2lvbg0KICAiPHR0 IGNsYXNzPSJzYW1wIj48dmFyPm8xPC92YXI+ICUgPHZhcj5vMjwvdmFyPjwvdHQ+Ii4NCjwv ZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+PGEgbmFtZT0ibDJoLTIwOSI+PHR0 IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0Rpdm1vZDwvdHQ+PC9hPjwvYj4oPHZhcj5Q eU9iamVjdCAqbzEsIFB5T2JqZWN0ICpvMjwvdmFyPikNCjxkZD4NCjxkaXYgY2xhc3M9InJl ZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFzcz0ibGFiZWwiPlJldHVybiB2YWx1ZTo8L3Nw YW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+TmV3IHJlZmVyZW5jZS48L3NwYW4+DQo8L2Rp dj4NCiAgU2VlIHRoZSBidWlsdC1pbiBmdW5jdGlvbiA8dHQgY2xhc3M9ImZ1bmN0aW9uIj5k aXZtb2QoKTwvdHQ+PGEgbmFtZT0ibDJoLTIzNyI+Jm5ic3A7PC9hPg0KICBSZXR1cm5zIDx0 dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBvbiBmYWlsdXJlLiAgVGhpcyBpcyB0aGUg ZXF1aXZhbGVudCBvZiB0aGUgUHl0aG9uDQogIGV4cHJlc3Npb24gIjx0dCBjbGFzcz0ic2Ft cCI+ZGl2bW9kKDx2YXI+bzE8L3Zhcj4sIDx2YXI+bzI8L3Zhcj4pPC90dD4iLg0KPC9kbD4N Cg0KPFA+DQo8ZGw+PGR0PlB5T2JqZWN0KiA8Yj48YSBuYW1lPSJsMmgtMjEwIj48dHQgY2xh c3M9ImNmdW5jdGlvbiI+UHlOdW1iZXJfUG93ZXI8L3R0PjwvYT48L2I+KDx2YXI+UHlPYmpl Y3QgKm8xLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg UHlPYmplY3QgKm8yLCBQeU9iamVjdCAqbzM8L3Zhcj4pDQo8ZGQ+DQo8ZGl2IGNsYXNzPSJy ZWZjb3VudC1pbmZvIj4NCiAgPHNwYW4gY2xhc3M9ImxhYmVsIj5SZXR1cm4gdmFsdWU6PC9z cGFuPg0KICA8c3BhbiBjbGFzcz0idmFsdWUiPk5ldyByZWZlcmVuY2UuPC9zcGFuPg0KPC9k aXY+DQogIFNlZSB0aGUgYnVpbHQtaW4gZnVuY3Rpb24gPHR0IGNsYXNzPSJmdW5jdGlvbiI+ cG93KCk8L3R0PjxhIG5hbWU9ImwyaC0yMzgiPiZuYnNwOzwvYT4NCiAgUmV0dXJucyA8dHQg Y2xhc3M9ImNvbnN0YW50Ij5OVUxMPC90dD4gb24gZmFpbHVyZS4gIFRoaXMgaXMgdGhlIGVx dWl2YWxlbnQgb2YgdGhlIFB5dGhvbg0KICBleHByZXNzaW9uICI8dHQgY2xhc3M9InNhbXAi PnBvdyg8dmFyPm8xPC92YXI+LCA8dmFyPm8yPC92YXI+LCA8dmFyPm8zPC92YXI+KTwvdHQ+ Iiwgd2hlcmUgPHZhcj5vMzwvdmFyPg0KICBpcyBvcHRpb25hbC4gIElmIDx2YXI+bzM8L3Zh cj4gaXMgdG8gYmUgaWdub3JlZCwgcGFzcyA8dHQgY2xhc3M9ImNkYXRhIj5QeV9Ob25lPC90 dD4gaW4NCiAgaXRzIHBsYWNlIChwYXNzaW5nIDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8 L3R0PiBmb3IgPHZhcj5vMzwvdmFyPiB3b3VsZCBjYXVzZSBhbiBpbGxlZ2FsDQogIG1lbW9y eSBhY2Nlc3MpLg0KPC9kbD4NCg0KPFA+DQo8ZGw+PGR0PlB5T2JqZWN0KiA8Yj48YSBuYW1l PSJsMmgtMjExIj48dHQgY2xhc3M9ImNmdW5jdGlvbiI+UHlOdW1iZXJfTmVnYXRpdmU8L3R0 PjwvYT48L2I+KDx2YXI+UHlPYmplY3QgKm88L3Zhcj4pDQo8ZGQ+DQo8ZGl2IGNsYXNzPSJy ZWZjb3VudC1pbmZvIj4NCiAgPHNwYW4gY2xhc3M9ImxhYmVsIj5SZXR1cm4gdmFsdWU6PC9z cGFuPg0KICA8c3BhbiBjbGFzcz0idmFsdWUiPk5ldyByZWZlcmVuY2UuPC9zcGFuPg0KPC9k aXY+DQogIFJldHVybnMgdGhlIG5lZ2F0aW9uIG9mIDx2YXI+bzwvdmFyPiBvbiBzdWNjZXNz LCBvciA8dHQgY2xhc3M9ImNvbnN0YW50Ij5OVUxMPC90dD4gb24gZmFpbHVyZS4NCiAgVGhp cyBpcyB0aGUgZXF1aXZhbGVudCBvZiB0aGUgUHl0aG9uIGV4cHJlc3Npb24gIjx0dCBjbGFz cz0ic2FtcCI+LTx2YXI+bzwvdmFyPjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5Q eU9iamVjdCogPGI+PGEgbmFtZT0ibDJoLTIxMiI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5 TnVtYmVyX1Bvc2l0aXZlPC90dD48L2E+PC9iPig8dmFyPlB5T2JqZWN0ICpvPC92YXI+KQ0K PGRkPg0KPGRpdiBjbGFzcz0icmVmY291bnQtaW5mbyI+DQogIDxzcGFuIGNsYXNzPSJsYWJl bCI+UmV0dXJuIHZhbHVlOjwvc3Bhbj4NCiAgPHNwYW4gY2xhc3M9InZhbHVlIj5OZXcgcmVm ZXJlbmNlLjwvc3Bhbj4NCjwvZGl2Pg0KICBSZXR1cm5zIDx2YXI+bzwvdmFyPiBvbiBzdWNj ZXNzLCBvciA8dHQgY2xhc3M9ImNvbnN0YW50Ij5OVUxMPC90dD4gb24gZmFpbHVyZS4gIFRo aXMgaXMgdGhlDQogIGVxdWl2YWxlbnQgb2YgdGhlIFB5dGhvbiBleHByZXNzaW9uICI8dHQg Y2xhc3M9InNhbXAiPis8dmFyPm88L3Zhcj48L3R0PiIuDQo8L2RsPg0KDQo8UD4NCjxkbD48 ZHQ+UHlPYmplY3QqIDxiPjxhIG5hbWU9ImwyaC0yMTMiPjx0dCBjbGFzcz0iY2Z1bmN0aW9u Ij5QeU51bWJlcl9BYnNvbHV0ZTwvdHQ+PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqbzwvdmFy PikNCjxkZD4NCjxkaXYgY2xhc3M9InJlZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFzcz0i bGFiZWwiPlJldHVybiB2YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+TmV3 IHJlZmVyZW5jZS48L3NwYW4+DQo8L2Rpdj4NCiAgUmV0dXJucyB0aGUgYWJzb2x1dGUgdmFs dWUgb2YgPHZhcj5vPC92YXI+LCBvciA8dHQgY2xhc3M9ImNvbnN0YW50Ij5OVUxMPC90dD4g b24gZmFpbHVyZS4gIFRoaXMNCiAgaXMgdGhlIGVxdWl2YWxlbnQgb2YgdGhlIFB5dGhvbiBl eHByZXNzaW9uICI8dHQgY2xhc3M9InNhbXAiPmFicyg8dmFyPm88L3Zhcj4pPC90dD4iLg0K DQo8L2RsPg0KDQo8UD4NCjxkbD48ZHQ+UHlPYmplY3QqIDxiPjxhIG5hbWU9ImwyaC0yMTQi Pjx0dCBjbGFzcz0iY2Z1bmN0aW9uIj5QeU51bWJlcl9JbnZlcnQ8L3R0PjwvYT48L2I+KDx2 YXI+UHlPYmplY3QgKm88L3Zhcj4pDQo8ZGQ+DQo8ZGl2IGNsYXNzPSJyZWZjb3VudC1pbmZv Ij4NCiAgPHNwYW4gY2xhc3M9ImxhYmVsIj5SZXR1cm4gdmFsdWU6PC9zcGFuPg0KICA8c3Bh biBjbGFzcz0idmFsdWUiPk5ldyByZWZlcmVuY2UuPC9zcGFuPg0KPC9kaXY+DQogIFJldHVy bnMgdGhlIGJpdHdpc2UgbmVnYXRpb24gb2YgPHZhcj5vPC92YXI+IG9uIHN1Y2Nlc3MsIG9y IDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBvbg0KICBmYWlsdXJlLiAgVGhpcyBp cyB0aGUgZXF1aXZhbGVudCBvZiB0aGUgUHl0aG9uIGV4cHJlc3Npb24NCiAgIjx0dCBjbGFz cz0ic2FtcCI+fjx2YXI+bzwvdmFyPjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5Q eU9iamVjdCogPGI+PGEgbmFtZT0ibDJoLTIxNSI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5 TnVtYmVyX0xzaGlmdDwvdHQ+PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqbzEsIFB5T2JqZWN0 ICpvMjwvdmFyPikNCjxkZD4NCjxkaXYgY2xhc3M9InJlZmNvdW50LWluZm8iPg0KICA8c3Bh biBjbGFzcz0ibGFiZWwiPlJldHVybiB2YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2 YWx1ZSI+TmV3IHJlZmVyZW5jZS48L3NwYW4+DQo8L2Rpdj4NCiAgUmV0dXJucyB0aGUgcmVz dWx0IG9mIGxlZnQgc2hpZnRpbmcgPHZhcj5vMTwvdmFyPiBieSA8dmFyPm8yPC92YXI+IG9u IHN1Y2Nlc3MsDQogIG9yIDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBvbiBmYWls dXJlLiAgVGhpcyBpcyB0aGUgZXF1aXZhbGVudCBvZiB0aGUgUHl0aG9uDQogIGV4cHJlc3Np b24gIjx0dCBjbGFzcz0ic2FtcCI+PHZhcj5vMTwvdmFyPiAmbHQ7PGNvZGU+Jmx0OzwvY29k ZT4gPHZhcj5vMjwvdmFyPjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVj dCogPGI+PGEgbmFtZT0ibDJoLTIxNiI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVy X1JzaGlmdDwvdHQ+PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqbzEsIFB5T2JqZWN0ICpvMjwv dmFyPikNCjxkZD4NCjxkaXYgY2xhc3M9InJlZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFz cz0ibGFiZWwiPlJldHVybiB2YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+ TmV3IHJlZmVyZW5jZS48L3NwYW4+DQo8L2Rpdj4NCiAgUmV0dXJucyB0aGUgcmVzdWx0IG9m IHJpZ2h0IHNoaWZ0aW5nIDx2YXI+bzE8L3Zhcj4gYnkgPHZhcj5vMjwvdmFyPiBvbg0KICBz dWNjZXNzLCBvciA8dHQgY2xhc3M9ImNvbnN0YW50Ij5OVUxMPC90dD4gb24gZmFpbHVyZS4g IFRoaXMgaXMgdGhlIGVxdWl2YWxlbnQgb2YgdGhlDQogIFB5dGhvbiBleHByZXNzaW9uICI8 dHQgY2xhc3M9InNhbXAiPjx2YXI+bzE8L3Zhcj4gJmd0Ozxjb2RlPiZndDs8L2NvZGU+IDx2 YXI+bzI8L3Zhcj48L3R0PiIuDQo8L2RsPg0KDQo8UD4NCjxkbD48ZHQ+UHlPYmplY3QqIDxi PjxhIG5hbWU9ImwyaC0yMTciPjx0dCBjbGFzcz0iY2Z1bmN0aW9uIj5QeU51bWJlcl9BbmQ8 L3R0PjwvYT48L2I+KDx2YXI+UHlPYmplY3QgKm8xLCBQeU9iamVjdCAqbzI8L3Zhcj4pDQo8 ZGQ+DQo8ZGl2IGNsYXNzPSJyZWZjb3VudC1pbmZvIj4NCiAgPHNwYW4gY2xhc3M9ImxhYmVs Ij5SZXR1cm4gdmFsdWU6PC9zcGFuPg0KICA8c3BhbiBjbGFzcz0idmFsdWUiPk5ldyByZWZl cmVuY2UuPC9zcGFuPg0KPC9kaXY+DQogIFJldHVybnMgdGhlIGBgYml0d2lzZSBhbmQnJyBv ZiA8dmFyPm8yPC92YXI+IGFuZCA8dmFyPm8yPC92YXI+IG9uIHN1Y2Nlc3MgYW5kDQogIDx0 dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBvbiBmYWlsdXJlLiBUaGlzIGlzIHRoZSBl cXVpdmFsZW50IG9mIHRoZSBQeXRob24gZXhwcmVzc2lvbg0KICAiPHR0IGNsYXNzPSJzYW1w Ij48dmFyPm8xPC92YXI+ICZhbXA7IDx2YXI+bzI8L3Zhcj48L3R0PiIuDQo8L2RsPg0KDQo8 UD4NCjxkbD48ZHQ+UHlPYmplY3QqIDxiPjxhIG5hbWU9ImwyaC0yMTgiPjx0dCBjbGFzcz0i Y2Z1bmN0aW9uIj5QeU51bWJlcl9Yb3I8L3R0PjwvYT48L2I+KDx2YXI+UHlPYmplY3QgKm8x LCBQeU9iamVjdCAqbzI8L3Zhcj4pDQo8ZGQ+DQo8ZGl2IGNsYXNzPSJyZWZjb3VudC1pbmZv Ij4NCiAgPHNwYW4gY2xhc3M9ImxhYmVsIj5SZXR1cm4gdmFsdWU6PC9zcGFuPg0KICA8c3Bh biBjbGFzcz0idmFsdWUiPk5ldyByZWZlcmVuY2UuPC9zcGFuPg0KPC9kaXY+DQogIFJldHVy bnMgdGhlIGBgYml0d2lzZSBleGNsdXNpdmUgb3InJyBvZiA8dmFyPm8xPC92YXI+IGJ5IDx2 YXI+bzI8L3Zhcj4gb24NCiAgc3VjY2Vzcywgb3IgPHR0IGNsYXNzPSJjb25zdGFudCI+TlVM TDwvdHQ+IG9uIGZhaWx1cmUuICBUaGlzIGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZQ0KICBQ eXRob24gZXhwcmVzc2lvbiAiPHR0IGNsYXNzPSJzYW1wIj48dmFyPm8xPC92YXI+IF4gPHZh cj5vMjwvdmFyPjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+ PGEgbmFtZT0ibDJoLTIxOSI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX09yPC90 dD48L2E+PC9iPig8dmFyPlB5T2JqZWN0ICpvMSwgUHlPYmplY3QgKm8yPC92YXI+KQ0KPGRk Pg0KPGRpdiBjbGFzcz0icmVmY291bnQtaW5mbyI+DQogIDxzcGFuIGNsYXNzPSJsYWJlbCI+ UmV0dXJuIHZhbHVlOjwvc3Bhbj4NCiAgPHNwYW4gY2xhc3M9InZhbHVlIj5OZXcgcmVmZXJl bmNlLjwvc3Bhbj4NCjwvZGl2Pg0KICBSZXR1cm5zIHRoZSBgYGJpdHdpc2Ugb3InJyBvZiA8 dmFyPm8xPC92YXI+IGFuZCA8dmFyPm8yPC92YXI+IG9uIHN1Y2Nlc3MsIG9yDQogIDx0dCBj bGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBvbiBmYWlsdXJlLiAgVGhpcyBpcyB0aGUgZXF1 aXZhbGVudCBvZiB0aGUgUHl0aG9uIGV4cHJlc3Npb24NCiAgIjx0dCBjbGFzcz0ic2FtcCI+ PHZhcj5vMTwvdmFyPiB8IDx2YXI+bzI8L3Zhcj48L3R0PiIuDQo8L2RsPg0KDQo8UD4NCjxk bD48ZHQ+UHlPYmplY3QqIDxiPjxhIG5hbWU9ImwyaC0yMjAiPjx0dCBjbGFzcz0iY2Z1bmN0 aW9uIj5QeU51bWJlcl9JblBsYWNlQWRkPC90dD48L2E+PC9iPig8dmFyPlB5T2JqZWN0ICpv MSwgUHlPYmplY3QgKm8yPC92YXI+KQ0KPGRkPg0KPGRpdiBjbGFzcz0icmVmY291bnQtaW5m byI+DQogIDxzcGFuIGNsYXNzPSJsYWJlbCI+UmV0dXJuIHZhbHVlOjwvc3Bhbj4NCiAgPHNw YW4gY2xhc3M9InZhbHVlIj5OZXcgcmVmZXJlbmNlLjwvc3Bhbj4NCjwvZGl2Pg0KICBSZXR1 cm5zIHRoZSByZXN1bHQgb2YgYWRkaW5nIDx2YXI+bzE8L3Zhcj4gYW5kIDx2YXI+bzI8L3Zh cj4sIG9yIDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBvbg0KICBmYWlsdXJlLiAg VGhlIG9wZXJhdGlvbiBpcyBkb25lIDxpPmluLXBsYWNlPC9pPiB3aGVuIDx2YXI+bzE8L3Zh cj4NCiAgc3VwcG9ydHMgaXQuICBUaGlzIGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBQeXRo b24gc3RhdGVtZW50DQogICI8dHQgY2xhc3M9InNhbXAiPjx2YXI+bzE8L3Zhcj4gKz0gPHZh cj5vMjwvdmFyPjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+ PGEgbmFtZT0ibDJoLTIyMSI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0luUGxh Y2VTdWJ0cmFjdDwvdHQ+PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqbzEsDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUHlPYmplY3Qg Km8yPC92YXI+KQ0KPGRkPg0KPGRpdiBjbGFzcz0icmVmY291bnQtaW5mbyI+DQogIDxzcGFu IGNsYXNzPSJsYWJlbCI+UmV0dXJuIHZhbHVlOjwvc3Bhbj4NCiAgPHNwYW4gY2xhc3M9InZh bHVlIj5OZXcgcmVmZXJlbmNlLjwvc3Bhbj4NCjwvZGl2Pg0KICBSZXR1cm5zIHRoZSByZXN1 bHQgb2Ygc3VidHJhY3RpbmcgPHZhcj5vMjwvdmFyPiBmcm9tIDx2YXI+bzE8L3Zhcj4sIG9y IDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0Pg0KICBvbiBmYWlsdXJlLiAgVGhlIG9w ZXJhdGlvbiBpcyBkb25lIDxpPmluLXBsYWNlPC9pPiB3aGVuIDx2YXI+bzE8L3Zhcj4NCiAg c3VwcG9ydHMgaXQuICBUaGlzIGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBQeXRob24gc3Rh dGVtZW50DQogICI8dHQgY2xhc3M9InNhbXAiPjx2YXI+bzE8L3Zhcj4gLT0gPHZhcj5vMjwv dmFyPjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+PGEgbmFt ZT0ibDJoLTIyMiI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0luUGxhY2VNdWx0 aXBseTwvdHQ+PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqbzEsDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUHlPYmplY3QgKm8yPC92 YXI+KQ0KPGRkPg0KPGRpdiBjbGFzcz0icmVmY291bnQtaW5mbyI+DQogIDxzcGFuIGNsYXNz PSJsYWJlbCI+UmV0dXJuIHZhbHVlOjwvc3Bhbj4NCiAgPHNwYW4gY2xhc3M9InZhbHVlIj5O ZXcgcmVmZXJlbmNlLjwvc3Bhbj4NCjwvZGl2Pg0KICBSZXR1cm5zIHRoZSByZXN1bHQgb2Yg bXVsdGlwbHlpbmcgPHZhcj5vMTwvdmFyPiBhbmQgPHZhcj5vMjwvdmFyPiwgb3IgPHR0IGNs YXNzPSJjb25zdGFudCI+TlVMTDwvdHQ+DQogIG9uIGZhaWx1cmUuICBUaGUgb3BlcmF0aW9u IGlzIGRvbmUgPGk+aW4tcGxhY2U8L2k+IHdoZW4gPHZhcj5vMTwvdmFyPg0KICBzdXBwb3J0 cyBpdC4gIFRoaXMgaXMgdGhlIGVxdWl2YWxlbnQgb2YgdGhlIFB5dGhvbiBzdGF0ZW1lbnQN CiAgIjx0dCBjbGFzcz0ic2FtcCI+PHZhcj5vMTwvdmFyPiAqPSA8dmFyPm8yPC92YXI+PC90 dD4iLg0KPC9kbD4NCg0KPFA+DQo8ZGw+PGR0PlB5T2JqZWN0KiA8Yj48YSBuYW1lPSJsMmgt MjIzIj48dHQgY2xhc3M9ImNmdW5jdGlvbiI+UHlOdW1iZXJfSW5QbGFjZURpdmlkZTwvdHQ+ PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqbzEsDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFB5T2JqZWN0ICpvMjwvdmFyPikNCjxkZD4N CjxkaXYgY2xhc3M9InJlZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFzcz0ibGFiZWwiPlJl dHVybiB2YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+TmV3IHJlZmVyZW5j ZS48L3NwYW4+DQo8L2Rpdj4NCiAgUmV0dXJucyB0aGUgcmVzdWx0IG9mIGRpdmlkaW5nIDx2 YXI+bzE8L3Zhcj4gYnkgPHZhcj5vMjwvdmFyPiwgb3IgPHR0IGNsYXNzPSJjb25zdGFudCI+ TlVMTDwvdHQ+IG9uDQogIGZhaWx1cmUuICBUaGUgb3BlcmF0aW9uIGlzIGRvbmUgPGk+aW4t cGxhY2U8L2k+IHdoZW4gPHZhcj5vMTwvdmFyPg0KICBzdXBwb3J0cyBpdC4gVGhpcyBpcyB0 aGUgZXF1aXZhbGVudCBvZiB0aGUgUHl0aG9uIHN0YXRlbWVudA0KICAiPHR0IGNsYXNzPSJz YW1wIj48dmFyPm8xPC92YXI+IC89IDx2YXI+bzI8L3Zhcj48L3R0PiIuDQo8L2RsPg0KDQo8 UD4NCjxkbD48ZHQ+UHlPYmplY3QqIDxiPjxhIG5hbWU9ImwyaC0yMjQiPjx0dCBjbGFzcz0i Y2Z1bmN0aW9uIj5QeU51bWJlcl9JblBsYWNlRmxvb3JEaXZpZGU8L3R0PjwvYT48L2I+KDx2 YXI+UHlPYmplY3QgKm8xLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFB5T2JqZWN0ICpvMjwvdmFyPikNCjxkZD4NCjxkaXYg Y2xhc3M9InJlZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFzcz0ibGFiZWwiPlJldHVybiB2 YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+TmV3IHJlZmVyZW5jZS48L3Nw YW4+DQo8L2Rpdj4NCiAgUmV0dXJucyB0aGUgbWF0aGVtYXRpY2FsIG9mIGRpdmlkaW5nIDx2 YXI+bzE8L3Zhcj4gYnkgPHZhcj5vMjwvdmFyPiwgb3INCiAgPHR0IGNsYXNzPSJjb25zdGFu dCI+TlVMTDwvdHQ+IG9uIGZhaWx1cmUuICBUaGUgb3BlcmF0aW9uIGlzIGRvbmUgPGk+aW4t cGxhY2U8L2k+IHdoZW4NCiAgPHZhcj5vMTwvdmFyPiBzdXBwb3J0cyBpdC4gIFRoaXMgaXMg dGhlIGVxdWl2YWxlbnQgb2YgdGhlIFB5dGhvbg0KICBzdGF0ZW1lbnQgIjx0dCBjbGFzcz0i c2FtcCI+PHZhcj5vMTwvdmFyPiAvLz0gPHZhcj5vMjwvdmFyPjwvdHQ+Ii4NCiAgDQo8c3Bh biBjbGFzcz0idmVyc2lvbm5vdGUiPk5ldyBpbiB2ZXJzaW9uIDIuMi48L3NwYW4+DQoNCjwv ZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+PGEgbmFtZT0ibDJoLTIyNSI+PHR0 IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0luUGxhY2VUcnVlRGl2aWRlPC90dD48L2E+ PC9iPig8dmFyPlB5T2JqZWN0ICpvMSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFB5T2JqZWN0ICpvMjwvdmFyPikNCjxkZD4N CjxkaXYgY2xhc3M9InJlZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFzcz0ibGFiZWwiPlJl dHVybiB2YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+TmV3IHJlZmVyZW5j ZS48L3NwYW4+DQo8L2Rpdj4NCiAgUmV0dXJuIGEgcmVhc29uYWJsZSBhcHByb3hpbWF0aW9u IGZvciB0aGUgbWF0aGVtYXRpY2FsIHZhbHVlIG9mDQogIDx2YXI+bzE8L3Zhcj4gZGl2aWRl ZCBieSA8dmFyPm8yPC92YXI+LCBvciA8dHQgY2xhc3M9ImNvbnN0YW50Ij5OVUxMPC90dD4g b24gZmFpbHVyZS4gIFRoZSByZXR1cm4NCiAgdmFsdWUgaXMgYGBhcHByb3hpbWF0ZScnIGJl Y2F1c2UgYmluYXJ5IGZsb2F0aW5nIHBvaW50IG51bWJlcnMgYXJlDQogIGFwcHJveGltYXRl OyBpdCBpcyBub3QgcG9zc2libGUgdG8gcmVwcmVzZW50IGFsbCByZWFsIG51bWJlcnMgaW4N CiAgYmFzZSB0d28uICBUaGlzIGZ1bmN0aW9uIGNhbiByZXR1cm4gYSBmbG9hdGluZyBwb2lu dCB2YWx1ZSB3aGVuDQogIHBhc3NlZCB0d28gaW50ZWdlcnMuICBUaGUgb3BlcmF0aW9uIGlz IGRvbmUgPGk+aW4tcGxhY2U8L2k+IHdoZW4NCiAgPHZhcj5vMTwvdmFyPiBzdXBwb3J0cyBp dC4NCiAgDQo8c3BhbiBjbGFzcz0idmVyc2lvbm5vdGUiPk5ldyBpbiB2ZXJzaW9uIDIuMi48 L3NwYW4+DQoNCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+PGEgbmFtZT0i bDJoLTIyNiI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0luUGxhY2VSZW1haW5k ZXI8L3R0PjwvYT48L2I+KDx2YXI+UHlPYmplY3QgKm8xLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQeU9iamVjdCAqbzI8L3Zh cj4pDQo8ZGQ+DQo8ZGl2IGNsYXNzPSJyZWZjb3VudC1pbmZvIj4NCiAgPHNwYW4gY2xhc3M9 ImxhYmVsIj5SZXR1cm4gdmFsdWU6PC9zcGFuPg0KICA8c3BhbiBjbGFzcz0idmFsdWUiPk5l dyByZWZlcmVuY2UuPC9zcGFuPg0KPC9kaXY+DQogIFJldHVybnMgdGhlIHJlbWFpbmRlciBv ZiBkaXZpZGluZyA8dmFyPm8xPC92YXI+IGJ5IDx2YXI+bzI8L3Zhcj4sIG9yIDx0dCBjbGFz cz0iY29uc3RhbnQiPk5VTEw8L3R0Pg0KICBvbiBmYWlsdXJlLiAgVGhlIG9wZXJhdGlvbiBp cyBkb25lIDxpPmluLXBsYWNlPC9pPiB3aGVuIDx2YXI+bzE8L3Zhcj4NCiAgc3VwcG9ydHMg aXQuICBUaGlzIGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBQeXRob24gc3RhdGVtZW50DQog ICI8dHQgY2xhc3M9InNhbXAiPjx2YXI+bzE8L3Zhcj4gJT0gPHZhcj5vMjwvdmFyPjwvdHQ+ Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+PGEgbmFtZT0ibDJoLTIy NyI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0luUGxhY2VQb3dlcjwvdHQ+PC9h PjwvYj4oPHZhcj5QeU9iamVjdCAqbzEsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUHlPYmplY3QgKm8yLCBQeU9iamVjdCAqbzM8L3Zh cj4pDQo8ZGQ+DQo8ZGl2IGNsYXNzPSJyZWZjb3VudC1pbmZvIj4NCiAgPHNwYW4gY2xhc3M9 ImxhYmVsIj5SZXR1cm4gdmFsdWU6PC9zcGFuPg0KICA8c3BhbiBjbGFzcz0idmFsdWUiPk5l dyByZWZlcmVuY2UuPC9zcGFuPg0KPC9kaXY+DQogIFNlZSB0aGUgYnVpbHQtaW4gZnVuY3Rp b24gPHR0IGNsYXNzPSJmdW5jdGlvbiI+cG93KCk8L3R0Pi48YSBuYW1lPSJsMmgtMjM5Ij4m bmJzcDs8L2E+ICBSZXR1cm5zIDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBvbiBm YWlsdXJlLiAgVGhlIG9wZXJhdGlvbiBpcyBkb25lIDxpPmluLXBsYWNlPC9pPg0KICB3aGVu IDx2YXI+bzE8L3Zhcj4gc3VwcG9ydHMgaXQuICBUaGlzIGlzIHRoZSBlcXVpdmFsZW50IG9m IHRoZSBQeXRob24NCiAgc3RhdGVtZW50ICI8dHQgY2xhc3M9InNhbXAiPjx2YXI+bzE8L3Zh cj4gKio9IDx2YXI+bzI8L3Zhcj48L3R0PiIgd2hlbiBvMyBpcyA8dHQgY2xhc3M9ImNkYXRh Ij5QeV9Ob25lPC90dD4sDQogIG9yIGFuIGluLXBsYWNlIHZhcmlhbnQgb2YgIjx0dCBjbGFz cz0ic2FtcCI+cG93KDx2YXI+bzE8L3Zhcj4sIDx2YXI+bzI8L3Zhcj4sIDx2YXI+bzM8L3Zh cj4pPC90dD4iICBvdGhlcndpc2UuIElmIDx2YXI+bzM8L3Zhcj4gaXMgdG8gYmUgaWdub3Jl ZCwgcGFzcyA8dHQgY2xhc3M9ImNkYXRhIj5QeV9Ob25lPC90dD4gaW4gaXRzDQogIHBsYWNl IChwYXNzaW5nIDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBmb3IgPHZhcj5vMzwv dmFyPiB3b3VsZCBjYXVzZSBhbiBpbGxlZ2FsIG1lbW9yeQ0KICBhY2Nlc3MpLg0KPC9kbD4N Cg0KPFA+DQo8ZGw+PGR0PlB5T2JqZWN0KiA8Yj48YSBuYW1lPSJsMmgtMjI4Ij48dHQgY2xh c3M9ImNmdW5jdGlvbiI+UHlOdW1iZXJfSW5QbGFjZUxzaGlmdDwvdHQ+PC9hPjwvYj4oPHZh cj5QeU9iamVjdCAqbzEsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFB5T2JqZWN0ICpvMjwvdmFyPikNCjxkZD4NCjxkaXYgY2xhc3M9 InJlZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFzcz0ibGFiZWwiPlJldHVybiB2YWx1ZTo8 L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+TmV3IHJlZmVyZW5jZS48L3NwYW4+DQo8 L2Rpdj4NCiAgUmV0dXJucyB0aGUgcmVzdWx0IG9mIGxlZnQgc2hpZnRpbmcgPHZhcj5vMTwv dmFyPiBieSA8dmFyPm8yPC92YXI+IG9uIHN1Y2Nlc3MsDQogIG9yIDx0dCBjbGFzcz0iY29u c3RhbnQiPk5VTEw8L3R0PiBvbiBmYWlsdXJlLiAgVGhlIG9wZXJhdGlvbiBpcyBkb25lIDxp PmluLXBsYWNlPC9pPiB3aGVuDQogIDx2YXI+bzE8L3Zhcj4gc3VwcG9ydHMgaXQuICBUaGlz IGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBQeXRob24NCiAgc3RhdGVtZW50ICI8dHQgY2xh c3M9InNhbXAiPjx2YXI+bzE8L3Zhcj4gJmx0Ozxjb2RlPiZsdDs9PC9jb2RlPiA8dmFyPm8y PC92YXI+PC90dD4iLg0KPC9kbD4NCg0KPFA+DQo8ZGw+PGR0PlB5T2JqZWN0KiA8Yj48YSBu YW1lPSJsMmgtMjI5Ij48dHQgY2xhc3M9ImNmdW5jdGlvbiI+UHlOdW1iZXJfSW5QbGFjZVJz aGlmdDwvdHQ+PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqbzEsDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFB5T2JqZWN0ICpvMjwvdmFy PikNCjxkZD4NCjxkaXYgY2xhc3M9InJlZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFzcz0i bGFiZWwiPlJldHVybiB2YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+TmV3 IHJlZmVyZW5jZS48L3NwYW4+DQo8L2Rpdj4NCiAgUmV0dXJucyB0aGUgcmVzdWx0IG9mIHJp Z2h0IHNoaWZ0aW5nIDx2YXI+bzE8L3Zhcj4gYnkgPHZhcj5vMjwvdmFyPiBvbg0KICBzdWNj ZXNzLCBvciA8dHQgY2xhc3M9ImNvbnN0YW50Ij5OVUxMPC90dD4gb24gZmFpbHVyZS4gIFRo ZSBvcGVyYXRpb24gaXMgZG9uZQ0KICA8aT5pbi1wbGFjZTwvaT4gd2hlbiA8dmFyPm8xPC92 YXI+IHN1cHBvcnRzIGl0LiAgVGhpcyBpcyB0aGUgZXF1aXZhbGVudA0KICBvZiB0aGUgUHl0 aG9uIHN0YXRlbWVudCAiPHR0IGNsYXNzPSJzYW1wIj48dmFyPm8xPC92YXI+ICZndDs8Y29k ZT4mZ3Q7PTwvY29kZT4gPHZhcj5vMjwvdmFyPjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRs PjxkdD5QeU9iamVjdCogPGI+PGEgbmFtZT0ibDJoLTIzMCI+PHR0IGNsYXNzPSJjZnVuY3Rp b24iPlB5TnVtYmVyX0luUGxhY2VBbmQ8L3R0PjwvYT48L2I+KDx2YXI+UHlPYmplY3QgKm8x LCBQeU9iamVjdCAqbzI8L3Zhcj4pDQo8ZGQ+DQo8ZGl2IGNsYXNzPSJyZWZjb3VudC1pbmZv Ij4NCiAgPHNwYW4gY2xhc3M9ImxhYmVsIj5SZXR1cm4gdmFsdWU6PC9zcGFuPg0KICA8c3Bh biBjbGFzcz0idmFsdWUiPk5ldyByZWZlcmVuY2UuPC9zcGFuPg0KPC9kaXY+DQogIFJldHVy bnMgdGhlIGBgYml0d2lzZSBhbmQnJyBvZiA8dmFyPm8xPC92YXI+IGFuZCA8dmFyPm8yPC92 YXI+IG9uIHN1Y2Nlc3MgYW5kDQogIDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBv biBmYWlsdXJlLiBUaGUgb3BlcmF0aW9uIGlzIGRvbmUgPGk+aW4tcGxhY2U8L2k+IHdoZW4N CiAgPHZhcj5vMTwvdmFyPiBzdXBwb3J0cyBpdC4gIFRoaXMgaXMgdGhlIGVxdWl2YWxlbnQg b2YgdGhlIFB5dGhvbg0KICBzdGF0ZW1lbnQgIjx0dCBjbGFzcz0ic2FtcCI+PHZhcj5vMTwv dmFyPiAmYW1wOz0gPHZhcj5vMjwvdmFyPjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxk dD5QeU9iamVjdCogPGI+PGEgbmFtZT0ibDJoLTIzMSI+PHR0IGNsYXNzPSJjZnVuY3Rpb24i PlB5TnVtYmVyX0luUGxhY2VYb3I8L3R0PjwvYT48L2I+KDx2YXI+UHlPYmplY3QgKm8xLCBQ eU9iamVjdCAqbzI8L3Zhcj4pDQo8ZGQ+DQo8ZGl2IGNsYXNzPSJyZWZjb3VudC1pbmZvIj4N CiAgPHNwYW4gY2xhc3M9ImxhYmVsIj5SZXR1cm4gdmFsdWU6PC9zcGFuPg0KICA8c3BhbiBj bGFzcz0idmFsdWUiPk5ldyByZWZlcmVuY2UuPC9zcGFuPg0KPC9kaXY+DQogIFJldHVybnMg dGhlIGBgYml0d2lzZSBleGNsdXNpdmUgb3InJyBvZiA8dmFyPm8xPC92YXI+IGJ5IDx2YXI+ bzI8L3Zhcj4gb24NCiAgc3VjY2Vzcywgb3IgPHR0IGNsYXNzPSJjb25zdGFudCI+TlVMTDwv dHQ+IG9uIGZhaWx1cmUuICBUaGUgb3BlcmF0aW9uIGlzIGRvbmUNCiAgPGk+aW4tcGxhY2U8 L2k+IHdoZW4gPHZhcj5vMTwvdmFyPiBzdXBwb3J0cyBpdC4gIFRoaXMgaXMgdGhlIGVxdWl2 YWxlbnQNCiAgb2YgdGhlIFB5dGhvbiBzdGF0ZW1lbnQgIjx0dCBjbGFzcz0ic2FtcCI+PHZh cj5vMTwvdmFyPiBePSA8dmFyPm8yPC92YXI+PC90dD4iLg0KPC9kbD4NCg0KPFA+DQo8ZGw+ PGR0PlB5T2JqZWN0KiA8Yj48YSBuYW1lPSJsMmgtMjMyIj48dHQgY2xhc3M9ImNmdW5jdGlv biI+UHlOdW1iZXJfSW5QbGFjZU9yPC90dD48L2E+PC9iPig8dmFyPlB5T2JqZWN0ICpvMSwg UHlPYmplY3QgKm8yPC92YXI+KQ0KPGRkPg0KPGRpdiBjbGFzcz0icmVmY291bnQtaW5mbyI+ DQogIDxzcGFuIGNsYXNzPSJsYWJlbCI+UmV0dXJuIHZhbHVlOjwvc3Bhbj4NCiAgPHNwYW4g Y2xhc3M9InZhbHVlIj5OZXcgcmVmZXJlbmNlLjwvc3Bhbj4NCjwvZGl2Pg0KICBSZXR1cm5z IHRoZSBgYGJpdHdpc2Ugb3InJyBvZiA8dmFyPm8xPC92YXI+IGFuZCA8dmFyPm8yPC92YXI+ IG9uIHN1Y2Nlc3MsIG9yDQogIDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBvbiBm YWlsdXJlLiAgVGhlIG9wZXJhdGlvbiBpcyBkb25lIDxpPmluLXBsYWNlPC9pPiB3aGVuDQog IDx2YXI+bzE8L3Zhcj4gc3VwcG9ydHMgaXQuICBUaGlzIGlzIHRoZSBlcXVpdmFsZW50IG9m IHRoZSBQeXRob24NCiAgc3RhdGVtZW50ICI8dHQgY2xhc3M9InNhbXAiPjx2YXI+bzE8L3Zh cj4gfD0gPHZhcj5vMjwvdmFyPjwvdHQ+Ii4NCjwvZGw+DQoNCjxQPg0KPGRsPjxkdD5pbnQg PGI+PGEgbmFtZT0ibDJoLTIzMyI+PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0Nv ZXJjZTwvdHQ+PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqKnAxLCBQeU9iamVjdCAqKnAyPC92 YXI+KQ0KPGRkPg0KICBUaGlzIGZ1bmN0aW9uIHRha2VzIHRoZSBhZGRyZXNzZXMgb2YgdHdv IHZhcmlhYmxlcyBvZiB0eXBlDQogIDx0dCBjbGFzcz0iY3R5cGUiPlB5T2JqZWN0KjwvdHQ+ LiAgSWYgdGhlIG9iamVjdHMgcG9pbnRlZCB0byBieSA8Y29kZT4qPHZhcj5wMTwvdmFyPjwv Y29kZT4NCiAgYW5kIDxjb2RlPio8dmFyPnAyPC92YXI+PC9jb2RlPiBoYXZlIHRoZSBzYW1l IHR5cGUsIGluY3JlbWVudCB0aGVpciByZWZlcmVuY2UNCiAgY291bnQgYW5kIHJldHVybiA8 Y29kZT4wPC9jb2RlPiAoc3VjY2VzcykuIElmIHRoZSBvYmplY3RzIGNhbiBiZSBjb252ZXJ0 ZWQNCiAgdG8gYSBjb21tb24gbnVtZXJpYyB0eXBlLCByZXBsYWNlIDxjb2RlPipwMTwvY29k ZT4gYW5kIDxjb2RlPipwMjwvY29kZT4gYnkgdGhlaXINCiAgY29udmVydGVkIHZhbHVlICh3 aXRoICduZXcnIHJlZmVyZW5jZSBjb3VudHMpLCBhbmQgcmV0dXJuIDxjb2RlPjA8L2NvZGU+ Lg0KICBJZiBubyBjb252ZXJzaW9uIGlzIHBvc3NpYmxlLCBvciBpZiBzb21lIG90aGVyIGVy cm9yIG9jY3VycywgcmV0dXJuDQogIDxjb2RlPi0xPC9jb2RlPiAoZmFpbHVyZSkgYW5kIGRv bid0IGluY3JlbWVudCB0aGUgcmVmZXJlbmNlIGNvdW50cy4gIFRoZQ0KICBjYWxsIDxjb2Rl PlB5TnVtYmVyX0NvZXJjZSgmYW1wO28xLCAmYW1wO28yKTwvY29kZT4gaXMgZXF1aXZhbGVu dCB0byB0aGUgUHl0aG9uDQogIHN0YXRlbWVudCAiPHR0IGNsYXNzPSJzYW1wIj48dmFyPm8x PC92YXI+LCA8dmFyPm8yPC92YXI+ID0gY29lcmNlKDx2YXI+bzE8L3Zhcj4sIDx2YXI+bzI8 L3Zhcj4pPC90dD4iLg0KDQo8L2RsPg0KDQo8UD4NCjxkbD48ZHQ+UHlPYmplY3QqIDxiPjxh IG5hbWU9ImwyaC0yMzQiPjx0dCBjbGFzcz0iY2Z1bmN0aW9uIj5QeU51bWJlcl9JbnQ8L3R0 PjwvYT48L2I+KDx2YXI+UHlPYmplY3QgKm88L3Zhcj4pDQo8ZGQ+DQo8ZGl2IGNsYXNzPSJy ZWZjb3VudC1pbmZvIj4NCiAgPHNwYW4gY2xhc3M9ImxhYmVsIj5SZXR1cm4gdmFsdWU6PC9z cGFuPg0KICA8c3BhbiBjbGFzcz0idmFsdWUiPk5ldyByZWZlcmVuY2UuPC9zcGFuPg0KPC9k aXY+DQogIFJldHVybnMgdGhlIDx2YXI+bzwvdmFyPiBjb252ZXJ0ZWQgdG8gYW4gaW50ZWdl ciBvYmplY3Qgb24gc3VjY2Vzcywgb3INCiAgPHR0IGNsYXNzPSJjb25zdGFudCI+TlVMTDwv dHQ+IG9uIGZhaWx1cmUuICBUaGlzIGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBQeXRob24g ZXhwcmVzc2lvbg0KICAiPHR0IGNsYXNzPSJzYW1wIj5pbnQoPHZhcj5vPC92YXI+KTwvdHQ+ Ii48YSBuYW1lPSJsMmgtMjQwIj4mbmJzcDs8L2E+PC9kbD4NCg0KPFA+DQo8ZGw+PGR0PlB5 T2JqZWN0KiA8Yj48YSBuYW1lPSJsMmgtMjM1Ij48dHQgY2xhc3M9ImNmdW5jdGlvbiI+UHlO dW1iZXJfTG9uZzwvdHQ+PC9hPjwvYj4oPHZhcj5QeU9iamVjdCAqbzwvdmFyPikNCjxkZD4N CjxkaXYgY2xhc3M9InJlZmNvdW50LWluZm8iPg0KICA8c3BhbiBjbGFzcz0ibGFiZWwiPlJl dHVybiB2YWx1ZTo8L3NwYW4+DQogIDxzcGFuIGNsYXNzPSJ2YWx1ZSI+TmV3IHJlZmVyZW5j ZS48L3NwYW4+DQo8L2Rpdj4NCiAgUmV0dXJucyB0aGUgPHZhcj5vPC92YXI+IGNvbnZlcnRl ZCB0byBhIGxvbmcgaW50ZWdlciBvYmplY3Qgb24gc3VjY2VzcywNCiAgb3IgPHR0IGNsYXNz PSJjb25zdGFudCI+TlVMTDwvdHQ+IG9uIGZhaWx1cmUuICBUaGlzIGlzIHRoZSBlcXVpdmFs ZW50IG9mIHRoZSBQeXRob24NCiAgZXhwcmVzc2lvbiAiPHR0IGNsYXNzPSJzYW1wIj5sb25n KDx2YXI+bzwvdmFyPik8L3R0PiIuPGEgbmFtZT0ibDJoLTI0MSI+Jm5ic3A7PC9hPjwvZGw+ DQoNCjxQPg0KPGRsPjxkdD5QeU9iamVjdCogPGI+PGEgbmFtZT0ibDJoLTIzNiI+PHR0IGNs YXNzPSJjZnVuY3Rpb24iPlB5TnVtYmVyX0Zsb2F0PC90dD48L2E+PC9iPig8dmFyPlB5T2Jq ZWN0ICpvPC92YXI+KQ0KPGRkPg0KPGRpdiBjbGFzcz0icmVmY291bnQtaW5mbyI+DQogIDxz cGFuIGNsYXNzPSJsYWJlbCI+UmV0dXJuIHZhbHVlOjwvc3Bhbj4NCiAgPHNwYW4gY2xhc3M9 InZhbHVlIj5OZXcgcmVmZXJlbmNlLjwvc3Bhbj4NCjwvZGl2Pg0KICBSZXR1cm5zIHRoZSA8 dmFyPm88L3Zhcj4gY29udmVydGVkIHRvIGEgZmxvYXQgb2JqZWN0IG9uIHN1Y2Nlc3MsIG9y DQogIDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0PiBvbiBmYWlsdXJlLiAgVGhpcyBp cyB0aGUgZXF1aXZhbGVudCBvZiB0aGUgUHl0aG9uIGV4cHJlc3Npb24NCiAgIjx0dCBjbGFz cz0ic2FtcCI+ZmxvYXQoPHZhcj5vPC92YXI+KTwvdHQ+Ii48YSBuYW1lPSJsMmgtMjQyIj4m bmJzcDs8L2E+PC9kbD4NCg0KPFA+DQoNCjxESVYgQ0xBU1M9Im5hdmlnYXRpb24iPg0KPHA+ PGhyPg0KPHRhYmxlIGFsaWduPSJjZW50ZXIiIHdpZHRoPSIxMDAlIiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiPg0KPHRyPg0KPHRkPjxBIGhyZWY9Im9iamVjdC5odG1sIj48 aW1nIHNyYz0iLi4vaWNvbnMvcHJldmlvdXMuZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0i MzIiDQogIGFsdD0iUHJldmlvdXMgUGFnZSIgd2lkdGg9IjMyIj48L0E+PC90ZD4NCjx0ZD48 QSBocmVmPSJhYnN0cmFjdC5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvdXAuZ2lmIg0KICBi b3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iVXAgT25lIExldmVsIiB3aWR0aD0iMzIi PjwvQT48L3RkPg0KPHRkPjxBIGhyZWY9InNlcXVlbmNlLmh0bWwiPjxpbWcgc3JjPSIuLi9p Y29ucy9uZXh0LmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9Ik5leHQg UGFnZSIgd2lkdGg9IjMyIj48L0E+PC90ZD4NCjx0ZCBhbGlnbj0iY2VudGVyIiB3aWR0aD0i MTAwJSI+UHl0aG9uL0MgQVBJIFJlZmVyZW5jZSBNYW51YWw8L3RkPg0KPHRkPjxBIGhyZWY9 ImNvbnRlbnRzLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9jb250ZW50cy5naWYiDQogIGJv cmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJDb250ZW50cyIgd2lkdGg9IjMyIj48L0E+ PC90ZD4NCjx0ZD48aW1nIHNyYz0iLi4vaWNvbnMvYmxhbmsuZ2lmIg0KICBib3JkZXI9IjAi IGhlaWdodD0iMzIiDQogIGFsdD0iIiB3aWR0aD0iMzIiPjwvdGQ+DQo8dGQ+PEEgaHJlZj0i Z2VuaW5kZXguaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL2luZGV4LmdpZiINCiAgYm9yZGVy PSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IkluZGV4IiB3aWR0aD0iMzIiPjwvQT48L3RkPg0K PC90cj48L3RhYmxlPg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5QcmV2aW91czo8L2I+IDxhIGNs YXNzPSJzZWN0cmVmIiBocmVmPSJvYmplY3QuaHRtbCI+Ni4xIE9iamVjdCBQcm90b2NvbDwv QT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+VXA6PC9iPiA8YSBjbGFzcz0ic2VjdHJlZiIgaHJl Zj0iYWJzdHJhY3QuaHRtbCI+Ni4gQWJzdHJhY3QgT2JqZWN0cyBMYXllcjwvQT4NCjxiIGNs YXNzPSJuYXZsYWJlbCI+TmV4dDo8L2I+IDxhIGNsYXNzPSJzZWN0cmVmIiBocmVmPSJzZXF1 ZW5jZS5odG1sIj42LjMgU2VxdWVuY2UgUHJvdG9jb2w8L0E+DQo8aHI+DQo8c3BhbiBjbGFz cz0icmVsZWFzZS1pbmZvIj5SZWxlYXNlIDIuMi4xLCBkb2N1bWVudGF0aW9uIHVwZGF0ZWQg b24gQXByaWwgMTAsIDIwMDIuPC9zcGFuPg0KPC9ESVY+DQo8IS0tRW5kIG9mIE5hdmlnYXRp b24gUGFuZWwtLT4NCjxBRERSRVNTPg0KU2VlIDxpPjxhIGhyZWY9ImFib3V0Lmh0bWwiPkFi b3V0IHRoaXMgZG9jdW1lbnQuLi48L2E+PC9pPiBmb3IgaW5mb3JtYXRpb24gb24gc3VnZ2Vz dGluZyBjaGFuZ2VzLg0KPC9BRERSRVNTPg0KPC9CT0RZPg0KPC9IVE1MPg0K --L1lwSj2Fl978YG33rC3jw4u06w-- ------=_NextPartTM-000-2b6d21a7-5cdf-43e2-9781-336c29920f4e Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file number.pif contains: WORM_KLEZ.H virus Attempted to clean the file but it is not cleanable. It has been deleted. Message : Virus détecté ***************** End of message *************** ------=_NextPartTM-000-2b6d21a7-5cdf-43e2-9781-336c29920f4e-- From ooklathemok@toriyamaworld.com Sat Mar 29 06:18:25 2003 From: ooklathemok@toriyamaworld.com (Peter Ahlstrom) Date: Sat, 29 Mar 2003 01:18:25 -0500 Subject: [Pythonmac-SIG] Replacement for getpid() in macpython? Message-ID: <3F9C33CB-61AE-11D7-87B1-003065A62C60@toriyamaworld.com> Hi there, I just barely got macpython and am trying to get a particular popular python program to work in mac os 9. If I modify two lines, things go okay, but I'm looking for a better solution. the lines are from os import getpid, path, makedirs and myid = (chr(0) * 12) + sha(repr(time()) + ' ' + str(getpid())).digest()[-8:] running as-is gives a "cannot import name" (or whatever the exact error is) on getpid. Removal of reference to getpid lets the program work fine. It's there to help make a unique identifier for the program instance when communicating with a remote server. Is there something else I can add there which is supported importing from os on classic mac os, giving a comparable process identifier, or should I just expect time() to do a good enough job? Peter From Jack.Jansen@oratrix.com Sat Mar 29 21:23:14 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 29 Mar 2003 22:23:14 +0100 Subject: [Pythonmac-SIG] Replacement for getpid() in macpython? In-Reply-To: <3F9C33CB-61AE-11D7-87B1-003065A62C60@toriyamaworld.com> Message-ID: On zaterdag, maa 29, 2003, at 07:18 Europe/Amsterdam, Peter Ahlstrom wrote: > Hi there, > > I just barely got macpython and am trying to get a particular popular > python program to work in mac os 9. If I modify two lines, things go > okay, but I'm looking for a better solution. > > the lines are > > from os import getpid, path, makedirs > > and > > myid = (chr(0) * 12) + sha(repr(time()) + ' ' + > str(getpid())).digest()[-8:] You could leave it out, or pick some other "easy" bit of information. You could use the host name of your machine, socket.gethostname(), or the number of ticks (1/60th of a second) since boot, MacOS.GetTicks(). Either of these make the chance that you get a collision probably smaller than the chance that two digests are equal (2**-32, in your case, it seems). Still, even when you use "0" for getpid() you will only get a collision if two Mac users create an ID at exactly the same time. Whether this chance is bigger or smaller than 2**-32 is left as an exercise to the reader, but I know I would be happy enough with it:-) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -