From bobsavage@mac.com Tue Jan 1 03:42:11 2002 From: bobsavage@mac.com (Bob Savage) Date: Mon, 31 Dec 2001 21:42:11 -0600 Subject: [Pythonmac-SIG] Thanks for a great year :) Message-ID: My best wishes to everyone in the MacPython community, for the coming new year. When I started using Python several years ago, I couldn't have done it without the community leaders who participated in the development of MacPython, and in the discussion on this list. Over the years Python has given me a way to try out my ideas, and create things that pleased me and/or my boss. As time passed, my success in implementing my ideas in Python encouraged me to tackle bigger problems, and to test the water in other languages. I have *always* thought, while using some other language, that things would be going a lot quicker if I were working in Python, and now that I have recently been learning another language which starts with 'P', I also think that, executed in Python, my code would not be so Pig-Ugly. I'm raising this glass to honor those of you who have cared enough to participate in the past. This next year holds great promise for the Python / MacOSX combo. I'm raising this glass to wish all of us an exciting tomorrow. Bob Savage From fgranger@altern.org Tue Jan 1 03:54:07 2002 From: fgranger@altern.org (Francois Granger) Date: Tue, 1 Jan 2002 04:54:07 +0100 Subject: [Pythonmac-SIG] Thanks for a great year :) In-Reply-To: References: Message-ID: At 21:42 -0600 31/12/01, in message [Pythonmac-SIG] Thanks for a great year :), Bob Savage wrote: >My best wishes to everyone in the MacPython community, for the coming new >year. I'd like to join you in these wishes. From cjl@physics.otago.ac.nz Wed Jan 2 19:19:14 2002 From: cjl@physics.otago.ac.nz (Chris Lee) Date: Thu, 03 Jan 2002 08:19:14 +1300 Subject: [Pythonmac-SIG] Installing numpy on mach-o python Message-ID: <7D213.813E.1BE49C.Nisus.ID@physics.otago.ac.nz> Hi All, I am having a wee problem with macpython running scripts with large arrays. = The same scripts have been run on a linux machine without problems. I = have installed the command line version of python and I am trying to = install Numeric module without success. Can someone help me with this? Cheers Chris= From prastawa@cs.unc.edu Wed Jan 2 20:19:47 2002 From: prastawa@cs.unc.edu (Marcelinus Prastawa) Date: Wed, 2 Jan 2002 15:19:47 -0500 Subject: [Pythonmac-SIG] Installing numpy on mach-o python In-Reply-To: <7D213.813E.1BE49C.Nisus.ID@physics.otago.ac.nz> Message-ID: <11214816-FFBE-11D5-9974-000A27942780@cs.unc.edu> You will need to give more information... What Python and Numeric versions are you using? What are the error messages? Marcel On Wednesday, January 2, 2002, at 02:19 , Chris Lee wrote: > > > Hi All, > > I am having a wee problem with macpython running scripts with large > arrays. The same scripts have been run on a linux machine without > problems. I have installed the command line version of python and I am > trying to install Numeric module without success. Can someone help me > with this? > > Cheers > Chris > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From cjl@physics.otago.ac.nz Wed Jan 2 20:48:59 2002 From: cjl@physics.otago.ac.nz (Chris Lee) Date: Thu, 03 Jan 2002 09:48:59 +1300 Subject: [Pythonmac-SIG] Installing numpy on mach-o python Message-ID: <7D213.9303B.1DB1C8.Nisus.ID@physics.otago.ac.nz> Numeric version 20.0 Python version 2.1 running setup_all.py install results in error messages like... cc -bundle -undefined suppress build/temp.darwin-1.4-Power = Macintosh-2.1/_numpymodule.o build/temp.darwin-1.4-Power = Macintosh-2.1/arrayobject.o build/temp.darwin-1.4-Power = Macintosh-2.1/ufuncobject.o -o build/lib.darwin-1.4-Power = Macintosh-2.1/_numpy.so /usr/bin/ld: -undefined error must be used when -twolevel_namespace is in = effect error: command 'cc' failed with exit status 1 and numerous skip messages like... skipping Src/arrayobject.c (build/temp.darwin-1.4-Power = Macintosh-2.1/arrayobject.o up-to-date) I think the main problem is that I know enough about unix to be dangerous = and not to usefull cheers chris On January 02 2002, Marcelinus Prastawa wrote: >You will need to give more information... > >What Python and Numeric versions are you using? What are the error >messages? > >Marcel > >On Wednesday, January 2, 2002, at 02:19 , Chris Lee wrote: > >> >> >> Hi All, >> >> I am having a wee problem with macpython running scripts with large >> arrays. The same scripts have been run on a linux machine without >> problems. I have installed the command line version of python and I am >> trying to install Numeric module without success. Can someone help me >> with this? >> >> Cheers >> Chris >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > From prastawa@cs.unc.edu Wed Jan 2 21:21:23 2002 From: prastawa@cs.unc.edu (Marcelinus Prastawa) Date: Wed, 2 Jan 2002 16:21:23 -0500 Subject: [Pythonmac-SIG] Installing numpy on mach-o python In-Reply-To: <7D213.9303B.1DB1C8.Nisus.ID@physics.otago.ac.nz> Message-ID: You could shift some of the blame to Apple on this one. :) This happened to someone else before... Starting from 10.1 Mac OS X has two different namespace settings: flat and two-level. Unfortunately, I think that Python 2.1 is not set to handle this properly by default... Possible solutions: Get Python 2.2 -- and if you ever need to deal with small matrices, I recommend Numeric 20.3 (there are bug fixes too). Modify /usr/local/lib/python2.1/config/Makefile so that the variables LDSHARED and BLDSHARED are set to: $(CC) $(LDFLAGS) -bundle -undefined error -bundle_loader /usr/local/bin/python2.1 (this will give you two-level namespace extensions) or $(CC) $(LDFLAGS) -flat_namespace -bundle -undefined suppress (this will give you flat namespace extensions) You may need to change /usr/local to the location of your Python installation. If you are going to write your own extensions to Numeric, you probably want to build it as a two-level namespace extension. Otherwise you could get name clashes... Marcel On Wednesday, January 2, 2002, at 03:48 , Chris Lee wrote: > > Numeric version 20.0 > Python version 2.1 > > running setup_all.py install results in error messages like... > > cc -bundle -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.1/ > _numpymodule.o build/temp.darwin-1.4-Power Macintosh-2.1/arrayobject.o > build/temp.darwin-1.4-Power Macintosh-2.1/ufuncobject.o -o > build/lib.darwin-1.4-Power Macintosh-2.1/_numpy.so > /usr/bin/ld: -undefined error must be used when -twolevel_namespace is in > effect > error: command 'cc' failed with exit status 1 > > and numerous skip messages like... > > skipping Src/arrayobject.c (build/temp.darwin-1.4-Power > Macintosh-2.1/arrayobject.o up-to-date) > > > I think the main problem is that I know enough about unix to be dangerous > and not to usefull > > cheers > chris From Jack.Jansen@cwi.nl Wed Jan 2 21:51:55 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 2 Jan 2002 22:51:55 +0100 (CET) Subject: [Pythonmac-SIG] Installing numpy on mach-o python In-Reply-To: <7D213.9303B.1DB1C8.Nisus.ID@physics.otago.ac.nz> Message-ID: On Thu, 3 Jan 2002, Chris Lee wrote: > > Numeric version 20.0 > Python version 2.1 Ah, you can't use 2.1 on OSX 10.1 or later without some surgery. I think 2.1.1 will also not work out of the box. 2.1.2 will work, and is forthcoming soon, but if you have no serious reason to stick with the 2.1 family I suggest you move to 2.2, which handles this correctly and is out since Christmas. In OSX 10.1 Apple changed the way external symbols were resolved in dynamically loaded libraries and such, and this influences the building of Python dynamic modules. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From cjl@physics.otago.ac.nz Thu Jan 3 08:20:54 2002 From: cjl@physics.otago.ac.nz (Chris Lee) Date: Thu, 03 Jan 2002 21:20:54 +1300 Subject: [Pythonmac-SIG] Installing numpy on mach-o python Message-ID: <7D213.151436.2FE5B8.Nisus.ID@physics.otago.ac.nz> On January 02 2002, Jack Jansen wrote: >On Thu, 3 Jan 2002, Chris Lee wrote: > >> >> Numeric version 20.0 >> Python version 2.1 > >Ah, you can't use 2.1 on OSX 10.1 or later without some surgery. I think >2.1.1 will also not work out of the box. 2.1.2 will work, and is >forthcoming soon, but if you have no serious reason to stick with the 2.1 >family I suggest you move to 2.2, which handles this correctly and is out >since Christmas. > >In OSX 10.1 Apple changed the way external symbols were resolved in >dynamically loaded libraries and such, and this influences the building of = >Python dynamic modules. Okay so I have downloaded 2.2 and the latest and greatest Numerics and I = have installed them. However when I run autotest I get a segementation = fault at test_re Anymore advice? Cheers Chris > -- >Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ >Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig = ++++ >http://www.cwi.nl/~jack | see = http://www.xs4all.nl/~tank/spg-l/sigaction.htm > From Jack.Jansen@cwi.nl Thu Jan 3 14:59:49 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 3 Jan 2002 15:59:49 +0100 (CET) Subject: [Pythonmac-SIG] Installing numpy on mach-o python In-Reply-To: <7D213.151436.2FE5B8.Nisus.ID@physics.otago.ac.nz> Message-ID: On Thu, 3 Jan 2002, Chris Lee wrote: > Okay so I have downloaded 2.2 and the latest and greatest Numerics and I have installed them. However when I run autotest I get a segementation fault at test_re > > Anymore advice? Yes: read the release notes:-) This is a known problem wit OSX: you need to set the stack bigger to make the selftests pass. "limit stack 2048" should do the trick. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul@fxtech.com Thu Jan 3 16:39:38 2002 From: paul@fxtech.com (Paul Miller) Date: Thu, 03 Jan 2002 10:39:38 -0600 Subject: [Pythonmac-SIG] That darned SIOUX console and OS/X (embedded Carbon Python) In-Reply-To: <5E06582A-F808-11D5-BD18-003065A7CFBA@mac.com> Message-ID: <5.1.0.14.2.20020103103722.02a98410@cedar.he.net> This SIOUX console is giving me much grief on OS/X - I can't disable it (because PythonPrefs doesn't work), and it is preventing my host app from quitting (the SIOUX menu takes over the app Quit, and using it doesn't actually Quit the app). Does anyone have a work-around for this? To prevent the console from appearing in OS9 I have disabled it in PythonPrefs, but that doesn't work in OS/X. Note - this is NOT the native OS/X Python - this is MacPython 2.2. Thanks much! -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From cjl@physics.otago.ac.nz Thu Jan 3 20:14:58 2002 From: cjl@physics.otago.ac.nz (Chris Lee) Date: Fri, 04 Jan 2002 09:14:58 +1300 Subject: [Pythonmac-SIG] Installing numpy on mach-o python Message-ID: <7D214.9E3A.38124E.Nisus.ID@physics.otago.ac.nz> On January 03 2002, Jack Jansen wrote: >On Thu, 3 Jan 2002, Chris Lee wrote: >> Okay so I have downloaded 2.2 and the latest and greatest Numerics and I = have installed them. However when I run autotest I get a segementation = fault at test_re >> >> Anymore advice? > >Yes: read the release notes:-) I had but it was only after I sent the email that I figured out that SEGV =3D = semengtation fault (This is why I prefer installers to building my own). = Anyway even then it took me a while to realise that the limit statement was = a command and not a modification to a configuration file. So this is not the end of my woes. 3 test failed unexpectedly test_sax, = test_pyexpat and test_locale however as far as I can tell these test = functions I never use still, it would be nice to know that it wasn't = fatal.... Far worse I cannot run any scripts. I can start the interpreter and run = commands from the command line but when I execute python myfile.py it = starts and terminates without executing any code. So whats have I done = now? Thanks for all your help everyone. Cheers Chris > >This is a known problem wit OSX: you need to set the stack bigger to make >the selftests pass. "limit stack 2048" should do the trick. >-- >Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ >Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig = ++++ >http://www.cwi.nl/~jack | see = http://www.xs4all.nl/~tank/spg-l/sigaction.htm > From jack@oratrix.nl Thu Jan 3 22:46:58 2002 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 03 Jan 2002 23:46:58 +0100 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? Message-ID: <20020103224658.A336DE8451@oratrix.oratrix.nl> Folks, I'm toying with the idea of making MacPython 2.3 Carbon-only, as this would save a lot of development effort. And there are a lot of things I'd like to do, for one thing I would like all our MacPython goodies to run natively in MachoPython by the time 2.3 is released. There are two drawbacks to this plan: 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the last release anyway), and on 8.6 you would need to manually install CarbonLib. 2. Tkinter is going to be a problem, but I think it is a solvable problem (it is possible to load InterfaceLib-based code into a CarbonLib-based main program). What do people think? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From nathan@vividworks.com Thu Jan 3 22:53:32 2002 From: nathan@vividworks.com (Nathan Heagy) Date: Thu, 3 Jan 2002 16:53:32 -0600 (CST) Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <20020103224658.A336DE8451@oratrix.oratrix.nl> Message-ID: Personally I only use Macho python (I call it unix python myself). However bias aside I think this is the Right Thing To Do. Nathan On Thu, 3 Jan 2002, Jack Jansen wrote: > Folks, > I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > would save a lot of development effort. And there are a lot of things > I'd like to do, for one thing I would like all our MacPython goodies > to run natively in MachoPython by the time 2.3 is released. > > There are two drawbacks to this plan: > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the > last release anyway), and on 8.6 you would need to manually install > CarbonLib. > 2. Tkinter is going to be a problem, but I think it is a solvable > problem (it is possible to load InterfaceLib-based code into a > CarbonLib-based main program). > > What do people think? > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From sdm7g@Virginia.EDU Thu Jan 3 23:06:32 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Thu, 3 Jan 2002 18:06:32 -0500 (EST) Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <20020103224658.A336DE8451@oratrix.oratrix.nl> Message-ID: That plan is OK by me. ( 9.1 was so much more stable (IMHE) than anything that came before, that laziness is the only reason I still might have machines with 8.x. ) -- Steve From bobsavage@mac.com Thu Jan 3 23:06:11 2002 From: bobsavage@mac.com (Bob Savage) Date: Thu, 03 Jan 2002 17:06:11 -0600 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <20020103224658.A336DE8451@oratrix.oratrix.nl> Message-ID: on 1/3/02 4:46 PM, Jack Jansen wrote: > I'm toying with the idea of making MacPython 2.3 Carbon-only, <...> > What do people think? I always feel selfish when I put my two cents in on these matters, because I know someone has real needs that require the old stuff (my brother runs a gene chip producing machine from a IIsi, so I can understand that people have legacy equipment and applications), but I am in favor of pushing ahead. I live out of OSX for most of the day (I do have a second machine dedicated as a software router, a scanning station, and to use Propellerhead Reason :) , but even that Mac is running OS 9. If it means Jack can accomplish more of what he wants to do, I'm in favor of untying his hands. Bob From sdm7g@Virginia.EDU Thu Jan 3 23:33:39 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Thu, 3 Jan 2002 18:33:39 -0500 (EST) Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: Message-ID: Besides, there may be some advantages to moving the implementation over to the new Carbon-events model. On Thu, 3 Jan 2002, I wrote: > > That plan is OK by nme. > ( 9.1 was so much more stable (IMHE) than anything that came before, > that laziness is the only reason I still might have machines with > 8.x. ) > From smithsm@samuelsmith.org Thu Jan 3 23:52:19 2002 From: smithsm@samuelsmith.org (Samuel Smith) Date: Thu, 3 Jan 2002 16:52:19 -0700 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <20020103224658.A336DE8451@oratrix.oratrix.nl> References: <20020103224658.A336DE8451@oratrix.oratrix.nl> Message-ID: >Folks, >I'm toying with the idea of making MacPython 2.3 Carbon-only, as this >would save a lot of development effort. And there are a lot of things >I'd like to do, for one thing I would like all our MacPython goodies >to run natively in MachoPython by the time 2.3 is released. I have no plans to ever use System 8 in the future. > >There are two drawbacks to this plan: >1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the >last release anyway), and on 8.6 you would need to manually install >CarbonLib. >2. Tkinter is going to be a problem, but I think it is a solvable >problem (it is possible to load InterfaceLib-based code into a >CarbonLib-based main program). I am hoping by then that wxPython-mac will be running > >What do people think? >-- >Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ >Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ >www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ********************************************** Samuel M. Smith Ph.D. 360 W. 920 N. Orem, Utah 84057 801-226-7607 x112 (voice) 801-226-7608 (fax) http://www.samuelsmith.org (web) ********************************************* From mday@mac.com Thu Jan 3 23:57:41 2002 From: mday@mac.com (Mark Day) Date: Thu, 3 Jan 2002 15:57:41 -0800 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <20020103224658.A336DE8451@oratrix.oratrix.nl> Message-ID: On Thursday, January 3, 2002, at 02:46 PM, Jack Jansen wrote: > Folks, > I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > would save a lot of development effort. And there are a lot of things > I'd like to do, for one thing I would like all our MacPython goodies > to run natively in MachoPython by the time 2.3 is released. If making MacPython Carbon-only increases the chances of integrating MacPython and MachoPython, then I'm all for it. I'd really like to see Python be able to take advantage of both traditional Mac (Carbon) and Unix (simultaneously) on a Mac OS X system. > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the > last release anyway), and on 8.6 you would need to manually install > CarbonLib. In legacy installations, I think 8.6 is good enough these days. If the minimum requirement was 9.x, that might be a bit more of a problem (given the increased hardware demands of 9.x). There isn't a lot of difference in the requirements between 8.5 and 8.6. But I don't know how much the requirements change because of CarbonLib (eg., additional RAM usage). In my wife's store, the machines all run 8.6. That's mostly because 8.6 has a smaller RAM footprint, and those old machines are a pain to upgrade. I think a Carbon-only MacPython would be fine. They *could* be upgraded to 9.x if I really needed to. But it sounds like can put off that kind of decision until sometime after MacPython 2.3 (at which point I may have upgraded to newer machines anyway). For my own personal tinkering and general productivity enhancement, I already run the latest Mac OS 9 and X anyway. -Mark From prastawa@cs.unc.edu Fri Jan 4 00:54:54 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Thu, 03 Jan 2002 19:54:54 -0500 Subject: [Pythonmac-SIG] Installing numpy on mach-o python References: <7D214.9E3A.38124E.Nisus.ID@physics.otago.ac.nz> Message-ID: <3C34FD5E.3080209@cs.unc.edu> I don't know about the other two tests, but I think that it is normal/expected that test_locale fails. IIRC, Mac OS X has weak locale support. You probably don't need to worry too much about the failures, unless you really need to use those modules. > Far worse I cannot run any scripts. I can start the interpreter and > run commands from the command line but when I execute python myfile.py > it starts and terminates without executing any code. So whats have I > done now? Now this is odd... Do you not get any error messages or a stack trace? Did you check your code for bugs? One thing you could do is sprinkle some print statements in your code so you can tell what it is doing (or not doing). Also keep in mind that Python does not automatically echo/display the results of expressions when it executes a script file (it does so in an interactive session). BTW, if you don't want to get hassled with building your own Python, you should look into Fink: http://fink.sourceforge.net I do not use it for (Mach-O) Python, but I have happily used it for many other things. There's also GNU-Darwin at http://gnu-darwin.sourceforge.net Marcel From chrisl@fone.net Fri Jan 4 04:29:43 2002 From: chrisl@fone.net (Chris Lumsargis) Date: Thu, 3 Jan 2002 21:29:43 -0700 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <20020103224658.A336DE8451@oratrix.oratrix.nl> Message-ID: This is my first time to post on pythonmac-sig. I think your idea of going Carbon-only is a good one. It would make developing for me a whole lot simpler since most of my development tools either Cocoa or Carbon. Additionally, anything to speed the development process up and make things simpler for you is a boon of folks like me. Thanks, Chris Lumsargis On Thursday, January 3, 2002, at 03:46 PM, Jack Jansen wrote: > Folks, > I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > would save a lot of development effort. And there are a lot of things > I'd like to do, for one thing I would like all our MacPython goodies > to run natively in MachoPython by the time 2.3 is released. > > There are two drawbacks to this plan: > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the > last release anyway), and on 8.6 you would need to manually install > CarbonLib. > 2. Tkinter is going to be a problem, but I think it is a solvable > problem (it is possible to load InterfaceLib-based code into a > CarbonLib-based main program). > > What do people think? > -- > Jack Jansen | ++++ stop the execution of Mumia > Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your > sig ++++ > www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From patrick@swdev.com Fri Jan 4 07:08:01 2002 From: patrick@swdev.com (Patrick Curtain) Date: Thu, 3 Jan 2002 23:08:01 -0800 Subject: [Pythonmac-SIG] Project Build and native Cocoa Message-ID: Hey All! Please forgive what may very well be a silly question. Seems worth asking, though. Is there any hope of making Python another language for developing Cocoa applications? I just read about Apple's AppleScript Studio and I view the Interface Builder / Project Builder as a nearly -killer- environment for client-side development. If they can have pluggable development languages supporting ObjC, Java and now AppleScript, with Perl on the way (i understand), it seems possible to plug Python into that world. Can anyone with more knowledge about Cocoa development give an opinion? Thank You All! --p Patrick Curtain, Husband & Father ( i also write software ) - - "Your site looks great, but does it DO anything?" - Call SWDev to give your site the ACTIVE Edge. - 503.781.6199 - http://www.swdev.com/info/corporate/ From Benjamin.Schollnick@usa.xerox.com Fri Jan 4 12:53:00 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 04 Jan 2002 07:53:00 -0500 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? Message-ID: Jack, Carbon Only is probably (??) a good thing. The only reason I can think of not being carbonized, is to allow older hardware / OSes run the software... But as you mentioned Python 2.2 is the last release allowed for Mac OS 8.1. Since your placing that restriction, then it's probably a good time to "sneak" this one in as well... Honestly, the Tkinter question is my only hesitation... Tkinter has to be available, since that's the "native" GUI platform for Python. (Native meaning it comes with the software, and it's demoed with it.) - Benjamin -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Thursday, January 03, 2002 5:47 PM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? Folks, I'm toying with the idea of making MacPython 2.3 Carbon-only, as this would save a lot of development effort. And there are a lot of things I'd like to do, for one thing I would like all our MacPython goodies to run natively in MachoPython by the time 2.3 is released. There are two drawbacks to this plan: 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the last release anyway), and on 8.6 you would need to manually install CarbonLib. 2. Tkinter is going to be a problem, but I think it is a solvable problem (it is possible to load InterfaceLib-based code into a CarbonLib-based main program). What do people think? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From jhrsn@pitt.edu Fri Jan 4 13:22:29 2002 From: jhrsn@pitt.edu (Jim Harrison) Date: Fri, 04 Jan 2002 08:22:29 -0500 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <20020103224658.A336DE8451@oratrix.oratrix.nl> Message-ID: on 1/3/02 5:46 PM, Jack Jansen at jack@oratrix.nl wrote: > I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > would save a lot of development effort. And there are a lot of things > I'd like to do, for one thing I would like all our MacPython goodies > to run natively in MachoPython by the time 2.3 is released. This would be fine with me and now is probably a good time to make the leap. Jim Harrison Univ. of Pittsburgh From fgranger@altern.org Fri Jan 4 14:58:31 2002 From: fgranger@altern.org (Francois Granger) Date: Fri, 4 Jan 2002 15:58:31 +0100 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: References: Message-ID: At 7:53 -0500 4/01/02, in message RE: [Pythonmac-SIG] MacPython 2.3 - Carbon only?, Schollnick, Benjamin wrote: > > Honestly, the Tkinter question is my only hesitation... > Tkinter has to be available, since that's the "native" > GUI platform for Python. And the only still available. And I don't see wx available soon for Mac. From bobsavage@mac.com Fri Jan 4 17:08:16 2002 From: bobsavage@mac.com (Bob Savage) Date: Fri, 04 Jan 2002 11:08:16 -0600 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: Message-ID: on 1/4/02 8:58 AM, Francois Granger wrote: >> >> Honestly, the Tkinter question is my only hesitation... >> Tkinter has to be available, since that's the "native" >> GUI platform for Python. > > And the only still available. > > And I don't see wx available soon for Mac. The Mac has had long-standing problems with TKinter. Personally I don't see that being resolved without MacOSX. That means hoping that integration with TKinter will get better under OS 8.x is futile. Bob From stephenm@humongous.com Fri Jan 4 17:59:07 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Fri, 4 Jan 2002 09:59:07 -0800 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE611@sea-horse.humongous.com> I guess I'll be a voice of dissention. I work for a game company writing kids software. We try to keep our min specs as broad as possible. As a point of reference, our current min specs is 7.5.5. In our up coming games we plan to use Python. A requirement of 8.6 cuts into our potential market. Also, 8.6 is only about 2 and a half years old. True we can just stay with 2.2, but there may be some feature in 2.3 that we may really want to use. At that time, we would be stuck between a rock (wanting the new feature) and a hard place (Having our min spec jump up). -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Thursday, January 03, 2002 2:47 PM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? Folks, I'm toying with the idea of making MacPython 2.3 Carbon-only, as this would save a lot of development effort. And there are a lot of things I'd like to do, for one thing I would like all our MacPython goodies to run natively in MachoPython by the time 2.3 is released. There are two drawbacks to this plan: 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the last release anyway), and on 8.6 you would need to manually install CarbonLib. 2. Tkinter is going to be a problem, but I think it is a solvable problem (it is possible to load InterfaceLib-based code into a CarbonLib-based main program). What do people think? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From marcus.h.mendenhall@vanderbilt.edu Fri Jan 4 11:14:52 2002 From: marcus.h.mendenhall@vanderbilt.edu (Marcus H. Mendenhall) Date: Fri, 4 Jan 2002 12:14:52 +0100 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? (Jack Jansen) In-Reply-To: References: Message-ID: I am perfectly happy with migrating Python 2.3 to Carbon only. Although I am a heavy user of Python 2.1 on OS8.1-8.6, I can easily live without the updates to the versions running on those older systems. Most of the work is numerical (Numpy) stuff anyway, and so I really don't use many Python features beyond what was in 1.5/1.6. I only used a list comprehension for the first time a few days ago. Marcus Mendenhall From Benjamin.Schollnick@usa.xerox.com Fri Jan 4 18:32:33 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 04 Jan 2002 13:32:33 -0500 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? Message-ID: Bob, I agree.... There are several limitations in the Mac OS (classic) version of Tkinter that bothers me. Especially, since those limits are not in the PC version of Tkinter... (Since I write cross platform code, if I have to code it slightly differently on the each platform, it causes headaches later...) But, that being said, we need a GUI. If going carbonized would Hinder, or prevent us from using a Tkinter Gui, then what do we develope our GUI's with? I don't expect Carbonization to help or hinder our use of Tkinter, but if it does (hinder), then we need to have a plan in place to solve it... Not just ignore it... - Benjamin -----Original Message----- From: Bob Savage [mailto:bobsavage@mac.com] Sent: Friday, January 04, 2002 12:08 PM To: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] MacPython 2.3 - Carbon only? on 1/4/02 8:58 AM, Francois Granger wrote: >> >> Honestly, the Tkinter question is my only hesitation... >> Tkinter has to be available, since that's the "native" >> GUI platform for Python. > > And the only still available. > > And I don't see wx available soon for Mac. The Mac has had long-standing problems with TKinter. Personally I don't see that being resolved without MacOSX. That means hoping that integration with TKinter will get better under OS 8.x is futile. Bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From nathan@vividworks.com Fri Jan 4 19:02:54 2002 From: nathan@vividworks.com (Nathan Heagy) Date: Fri, 4 Jan 2002 13:02:54 -0600 (CST) Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE611@sea-horse.humongous.com> Message-ID: I think that this only limits what platform can be used for development. I expect to be corrected if I'm wrong however. Nathan On Fri, 4 Jan 2002, Magladry, Stephen wrote: > I guess I'll be a voice of dissention. I work for a game company writing > kids software. We try to keep our min specs as broad as possible. As a point > of reference, our current min specs is 7.5.5. In our up coming games we plan > to use Python. A requirement of 8.6 cuts into our potential market. Also, > 8.6 is only about 2 and a half years old. > > True we can just stay with 2.2, but there may be some feature in 2.3 that we > may really want to use. At that time, we would be stuck between a rock > (wanting the new feature) and a hard place (Having our min spec jump up). > > -----Original Message----- > From: Jack Jansen [mailto:jack@oratrix.nl] > Sent: Thursday, January 03, 2002 2:47 PM > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > > Folks, > I'm toying with the idea of making MacPython 2.3 > Carbon-only, as this > would save a lot of development effort. And there are a lot > of things > I'd like to do, for one thing I would like all our MacPython > goodies > to run natively in MachoPython by the time 2.3 is released. > > There are two drawbacks to this plan: > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython > 2.2 is the > last release anyway), and on 8.6 you would need to manually > install > CarbonLib. > 2. Tkinter is going to be a problem, but I think it is a > solvable > problem (it is possible to load InterfaceLib-based code into > a > CarbonLib-based main program). > > What do people think? > -- > Jack Jansen | ++++ stop the execution of Mumia > Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines > to your sig ++++ > www.cwi.nl/~jack | ++++ see > http://www.xs4all.nl/~tank/ ++++ > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From stephenm@humongous.com Fri Jan 4 19:06:16 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Fri, 4 Jan 2002 11:06:16 -0800 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE612@sea-horse.humongous.com> No take a look at point 1 from Jack initial e-mail. 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the last release anyway), and on 8.6 you would need to manually install CarbonLib. -----Original Message----- From: Nathan Heagy [mailto:nathan@vividworks.com] Sent: Friday, January 04, 2002 11:03 AM To: Magladry, Stephen Cc: 'Jack Jansen'; pythonmac-sig@python.org Subject: RE: [Pythonmac-SIG] MacPython 2.3 - Carbon only? I think that this only limits what platform can be used for development. I expect to be corrected if I'm wrong however. Nathan On Fri, 4 Jan 2002, Magladry, Stephen wrote: > I guess I'll be a voice of dissention. I work for a game company writing > kids software. We try to keep our min specs as broad as possible. As a point > of reference, our current min specs is 7.5.5. In our up coming games we plan > to use Python. A requirement of 8.6 cuts into our potential market. Also, > 8.6 is only about 2 and a half years old. > > True we can just stay with 2.2, but there may be some feature in 2.3 that we > may really want to use. At that time, we would be stuck between a rock > (wanting the new feature) and a hard place (Having our min spec jump up). > > -----Original Message----- > From: Jack Jansen [mailto:jack@oratrix.nl] > Sent: Thursday, January 03, 2002 2:47 PM > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > > Folks, > I'm toying with the idea of making MacPython 2.3 > Carbon-only, as this > would save a lot of development effort. And there are a lot > of things > I'd like to do, for one thing I would like all our MacPython > goodies > to run natively in MachoPython by the time 2.3 is released. > > There are two drawbacks to this plan: > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython > 2.2 is the > last release anyway), and on 8.6 you would need to manually > install > CarbonLib. > 2. Tkinter is going to be a problem, but I think it is a > solvable > problem (it is possible to load InterfaceLib-based code into > a > CarbonLib-based main program). > > What do people think? > -- > Jack Jansen | ++++ stop the execution of Mumia > Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines > to your sig ++++ > www.cwi.nl/~jack | ++++ see > http://www.xs4all.nl/~tank/ ++++ > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From nathan@vividworks.com Fri Jan 4 19:16:43 2002 From: nathan@vividworks.com (Nathan Heagy) Date: Fri, 4 Jan 2002 13:16:43 -0600 (CST) Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE612@sea-horse.humongous.com> Message-ID: > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython > 2.2 is the last release anyway), and on 8.6 you would need to manually > install CarbonLib. I stand corrected. Since I do think that Carbon is the right way to go let me then say this: while, "8.6 is only about 2 and a half years old," that is only right now. Python 2.3 will probably not be released for nine months judging from 2.1's release. Add to that the development time for a kids' game - perhaps a year - and at that point 8.6 will be nearly five years old. Nathan > -----Original Message----- > From: Nathan Heagy [mailto:nathan@vividworks.com] > Sent: Friday, January 04, 2002 11:03 AM > To: Magladry, Stephen > Cc: 'Jack Jansen'; pythonmac-sig@python.org > Subject: RE: [Pythonmac-SIG] MacPython 2.3 - Carbon > only? > > I think that this only limits what platform can be used for > development. I > expect to be corrected if I'm wrong however. > > Nathan > > > > On Fri, 4 Jan 2002, Magladry, Stephen wrote: > > > I guess I'll be a voice of dissention. I work for a game > company writing > > kids software. We try to keep our min specs as broad as > possible. As a point > > of reference, our current min specs is 7.5.5. In our up > coming games we plan > > to use Python. A requirement of 8.6 cuts into our > potential market. Also, > > 8.6 is only about 2 and a half years old. > > > > True we can just stay with 2.2, but there may be some > feature in 2.3 that we > > may really want to use. At that time, we would be stuck > between a rock > > (wanting the new feature) and a hard place (Having our min > spec jump up). > > > > -----Original Message----- > > From: Jack Jansen [mailto:jack@oratrix.nl] > > Sent: Thursday, January 03, 2002 2:47 PM > > To: pythonmac-sig@python.org > > Subject: [Pythonmac-SIG] MacPython > 2.3 - Carbon only? > > > > Folks, > > I'm toying with the idea of making MacPython > 2.3 > > Carbon-only, as this > > would save a lot of development effort. And > there are a lot > > of things > > I'd like to do, for one thing I would like > all our MacPython > > goodies > > to run natively in MachoPython by the time > 2.3 is released. > > > > There are two drawbacks to this plan: > > 1. MacPython wouldn't run on 8.5 anymore > (for 8.1 MacPython > > 2.2 is the > > last release anyway), and on 8.6 you would > need to manually > > install > > CarbonLib. > > 2. Tkinter is going to be a problem, but I > think it is a > > solvable > > problem (it is possible to load > InterfaceLib-based code into > > a > > CarbonLib-based main program). > > > > What do people think? > > -- > > Jack Jansen | ++++ stop the > execution of Mumia > > Abu-Jamal ++++ > > Jack.Jansen@oratrix.com | ++++ if you agree > copy these lines > > to your sig ++++ > > www.cwi.nl/~jack | ++++ see > > http://www.xs4all.nl/~tank/ ++++ > > > > > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > From stephenm@humongous.com Fri Jan 4 19:33:57 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Fri, 4 Jan 2002 11:33:57 -0800 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE615@sea-horse.humongous.com> Our cross platform code is already under development. Our first title is to be released in about nine months. True 2.3 wouldn't be usable for us at that time, but this engine will be reused many times, maybe even concurrently with this first project. So a release three months after the release of 2.3 wouldn't be totally out of the question. That would make 8.6 not even 3 and a half years old. Our current support of System 7.5.5, released in August 1996, makes our support go back almost 6 years. 3 and a half years, even 4 years, is considerably shorter that 6 years. -----Original Message----- From: Nathan Heagy [mailto:nathan@vividworks.com] Sent: Friday, January 04, 2002 11:17 AM To: Magladry, Stephen Cc: 'Jack Jansen'; pythonmac-sig@python.org Subject: RE: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython > 2.2 is the last release anyway), and on 8.6 you would need to manually > install CarbonLib. I stand corrected. Since I do think that Carbon is the right way to go let me then say this: while, "8.6 is only about 2 and a half years old," that is only right now. Python 2.3 will probably not be released for nine months judging from 2.1's release. Add to that the development time for a kids' game - perhaps a year - and at that point 8.6 will be nearly five years old. Nathan > -----Original Message----- > From: Nathan Heagy [mailto:nathan@vividworks.com] > Sent: Friday, January 04, 2002 11:03 AM > To: Magladry, Stephen > Cc: 'Jack Jansen'; pythonmac-sig@python.org > Subject: RE: [Pythonmac-SIG] MacPython 2.3 - Carbon > only? > > I think that this only limits what platform can be used for > development. I > expect to be corrected if I'm wrong however. > > Nathan > > > > On Fri, 4 Jan 2002, Magladry, Stephen wrote: > > > I guess I'll be a voice of dissention. I work for a game > company writing > > kids software. We try to keep our min specs as broad as > possible. As a point > > of reference, our current min specs is 7.5.5. In our up > coming games we plan > > to use Python. A requirement of 8.6 cuts into our > potential market. Also, > > 8.6 is only about 2 and a half years old. > > > > True we can just stay with 2.2, but there may be some > feature in 2.3 that we > > may really want to use. At that time, we would be stuck > between a rock > > (wanting the new feature) and a hard place (Having our min > spec jump up). > > > > -----Original Message----- > > From: Jack Jansen [mailto:jack@oratrix.nl] > > Sent: Thursday, January 03, 2002 2:47 PM > > To: pythonmac-sig@python.org > > Subject: [Pythonmac-SIG] MacPython > 2.3 - Carbon only? > > > > Folks, > > I'm toying with the idea of making MacPython > 2.3 > > Carbon-only, as this > > would save a lot of development effort. And > there are a lot > > of things > > I'd like to do, for one thing I would like > all our MacPython > > goodies > > to run natively in MachoPython by the time > 2.3 is released. > > > > There are two drawbacks to this plan: > > 1. MacPython wouldn't run on 8.5 anymore > (for 8.1 MacPython > > 2.2 is the > > last release anyway), and on 8.6 you would > need to manually > > install > > CarbonLib. > > 2. Tkinter is going to be a problem, but I > think it is a > > solvable > > problem (it is possible to load > InterfaceLib-based code into > > a > > CarbonLib-based main program). > > > > What do people think? > > -- > > Jack Jansen | ++++ stop the > execution of Mumia > > Abu-Jamal ++++ > > Jack.Jansen@oratrix.com | ++++ if you agree > copy these lines > > to your sig ++++ > > www.cwi.nl/~jack | ++++ see > > http://www.xs4all.nl/~tank/ ++++ > > > > > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > From seanh@real.com Fri Jan 4 19:31:48 2002 From: seanh@real.com (Sean Hummel) Date: Fri, 4 Jan 2002 11:31:48 -0800 (PST) Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: Message-ID: What's the huge deal with supporting just 8.6 or later? Yeah I know some people on earlier OS versions will be cut off. This is the way things have progressed for years in the Macintosh software community, after a while you can't support everything. As for Mr. Magladry's problem with not supporting anything less than 8.6, I can't see the issue. Does your company need to use the latest release at all? I mean, that I assumed that in the making of a game engine including Python that you would have tailored some version of Python to your need. Anyway this seems like a positive step to me. (Especially since all I use any longer is OSX.) From nathan@vividworks.com Fri Jan 4 19:53:48 2002 From: nathan@vividworks.com (Nathan Heagy) Date: Fri, 4 Jan 2002 13:53:48 -0600 (CST) Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE615@sea-horse.humongous.com> Message-ID: Fair enough. Also very interesting. Sounds like you are using Python's RAD properties well. While there is a big difference in time between 3 years and 6 years in terms of technology both are very old. For certain halving the minimum age of supported OSes would not cut you off from half your potential customers. Please don't get angry with me for pressing the issue, I am mearly curious. Do you know how many of your customers use these older versions of your OSes? Also the issue is complicated by the trends of Macintosh users. PC users tend to accept that a 3 year old OS is obsolete. To compound that PC developers already have a larger audience so they do not feel as much pressure to reach all of their potential customers. Mac users tend to expect their machines to be supported longer. Just as when Apple started using PowerPC CPUs something similar is occuring now with the transition to OS X. For the next few years Mac OSes will be obsolete earlier than the generations before them. Nathan On Fri, 4 Jan 2002, Magladry, Stephen wrote: > Our cross platform code is already under development. Our first title is to > be released in about nine months. True 2.3 wouldn't be usable for us at that > time, but this engine will be reused many times, maybe even concurrently > with this first project. So a release three months after the release of 2.3 > wouldn't be totally out of the question. That would make 8.6 not even 3 and > a half years old. Our current support of System 7.5.5, released in August > 1996, makes our support go back almost 6 years. 3 and a half years, even 4 > years, is considerably shorter that 6 years. > > -----Original Message----- > From: Nathan Heagy [mailto:nathan@vividworks.com] > Sent: Friday, January 04, 2002 11:17 AM > To: Magladry, Stephen > Cc: 'Jack Jansen'; pythonmac-sig@python.org > Subject: RE: [Pythonmac-SIG] MacPython 2.3 - Carbon > only? > > > 1. MacPython wouldn't run on 8.5 anymore > (for 8.1 MacPython > > 2.2 is the last release anyway), and on 8.6 you would need > to manually > > install CarbonLib. > > I stand corrected. Since I do think that Carbon is the right > way to go let > me then say this: while, "8.6 is only about 2 and a half > years old," that > is only right now. Python 2.3 will probably not be released > for nine > months judging from 2.1's release. Add to that the > development time for a > kids' game - perhaps a year - and at that point 8.6 will be > nearly five > years old. > > Nathan > > > > -----Original Message----- > > From: Nathan Heagy > [mailto:nathan@vividworks.com] > > Sent: Friday, January 04, 2002 11:03 AM > > To: Magladry, Stephen > > Cc: 'Jack Jansen'; > pythonmac-sig@python.org > > Subject: RE: [Pythonmac-SIG] > MacPython 2.3 - Carbon > > only? > > > > I think that this only limits what platform > can be used for > > development. I > > expect to be corrected if I'm wrong however. > > > > Nathan > > > > > > > > On Fri, 4 Jan 2002, Magladry, Stephen wrote: > > > > > I guess I'll be a voice of dissention. I > work for a game > > company writing > > > kids software. We try to keep our min > specs as broad as > > possible. As a point > > > of reference, our current min specs is > 7.5.5. In our up > > coming games we plan > > > to use Python. A requirement of 8.6 cuts > into our > > potential market. Also, > > > 8.6 is only about 2 and a half years old. > > > > > > True we can just stay with 2.2, but there > may be some > > feature in 2.3 that we > > > may really want to use. At that time, we > would be stuck > > between a rock > > > (wanting the new feature) and a hard place > (Having our min > > spec jump up). > > > > > > -----Original Message----- > > > From: Jack Jansen > [mailto:jack@oratrix.nl] > > > Sent: Thursday, January > 03, 2002 2:47 PM > > > To: > pythonmac-sig@python.org > > > Subject: > [Pythonmac-SIG] MacPython > > 2.3 - Carbon only? > > > > > > Folks, > > > I'm toying with the idea of > making MacPython > > 2.3 > > > Carbon-only, as this > > > would save a lot of > development effort. And > > there are a lot > > > of things > > > I'd like to do, for one > thing I would like > > all our MacPython > > > goodies > > > to run natively in > MachoPython by the time > > 2.3 is released. > > > > > > There are two drawbacks to > this plan: > > > 1. MacPython wouldn't run on > 8.5 anymore > > (for 8.1 MacPython > > > 2.2 is the > > > last release anyway), and on > 8.6 you would > > need to manually > > > install > > > CarbonLib. > > > 2. Tkinter is going to be a > problem, but I > > think it is a > > > solvable > > > problem (it is possible to > load > > InterfaceLib-based code into > > > a > > > CarbonLib-based main > program). > > > > > > What do people think? > > > -- > > > Jack Jansen | > ++++ stop the > > execution of Mumia > > > Abu-Jamal ++++ > > > Jack.Jansen@oratrix.com | > ++++ if you agree > > copy these lines > > > to your sig ++++ > > > www.cwi.nl/~jack | > ++++ see > > > http://www.xs4all.nl/~tank/ ++++ > > > > > > > > > > _______________________________________________ > > > Pythonmac-SIG maillist - > Pythonmac-SIG@python.org > > > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > > > From cjl@physics.otago.ac.nz Fri Jan 4 19:54:33 2002 From: cjl@physics.otago.ac.nz (Chris Lee) Date: Sat, 05 Jan 2002 08:54:33 +1300 Subject: [Pythonmac-SIG] Installing numpy on mach-o python Message-ID: <7D215.83621.453832.Nisus.ID@physics.otago.ac.nz> On January 03 2002, Marcel Prastawa wrote: >I don't know about the other two tests, but I think that it is >normal/expected that test_locale fails. IIRC, Mac OS X has weak locale >support. You probably don't need to worry too much about the failures, >unless you really need to use those modules. > > > Far worse I cannot run any scripts. I can start the interpreter and > > run commands from the command line but when I execute python myfile.py > > it starts and terminates without executing any code. So whats have I > > done now? > >Now this is odd... Do you not get any error messages or a stack trace? >Did you check your code for bugs? One thing you could do is sprinkle >some print statements in your code so you can tell what it is doing (or >not doing). Also keep in mind that Python does not automatically >echo/display the results of expressions when it executes a script file >(it does so in an interactive session). I finally figured it out.... All my python scripts were written using = MacPython and have mac line endings when I changed the line ending = everything went again. :) > >BTW, if you don't want to get hassled with building your own Python, you >should look into Fink: http://fink.sourceforge.net >I do not use it for (Mach-O) Python, but I have happily used it for many >other things. >There's also GNU-Darwin at http://gnu-darwin.sourceforge.net I'll know better next time :) Thanks for all your help everyone. Cheers Chris From stephenm@humongous.com Fri Jan 4 21:24:30 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Fri, 4 Jan 2002 13:24:30 -0800 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE616@sea-horse.humongous.com> I do not know our break down of OS customers. One thing we keep in mind is we want to run on hand-me-down systems. Dad/Mom got the latest and greatest, John/Susie gets this box. So the trend is towards Mac OS x...with new boxes. But because of our lag with hand-me-down machines, we also lag behind the trends. -----Original Message----- From: Nathan Heagy [mailto:nathan@vividworks.com] Sent: Friday, January 04, 2002 11:54 AM To: Magladry, Stephen Cc: 'Jack Jansen'; pythonmac-sig@python.org Subject: RE: [Pythonmac-SIG] MacPython 2.3 - Carbon only? Fair enough. Also very interesting. Sounds like you are using Python's RAD properties well. While there is a big difference in time between 3 years and 6 years in terms of technology both are very old. For certain halving the minimum age of supported OSes would not cut you off from half your potential customers. Please don't get angry with me for pressing the issue, I am mearly curious. Do you know how many of your customers use these older versions of your OSes? Also the issue is complicated by the trends of Macintosh users. PC users tend to accept that a 3 year old OS is obsolete. To compound that PC developers already have a larger audience so they do not feel as much pressure to reach all of their potential customers. Mac users tend to expect their machines to be supported longer. Just as when Apple started using PowerPC CPUs something similar is occuring now with the transition to OS X. For the next few years Mac OSes will be obsolete earlier than the generations before them. Nathan On Fri, 4 Jan 2002, Magladry, Stephen wrote: > Our cross platform code is already under development. Our first title is to > be released in about nine months. True 2.3 wouldn't be usable for us at that > time, but this engine will be reused many times, maybe even concurrently > with this first project. So a release three months after the release of 2.3 > wouldn't be totally out of the question. That would make 8.6 not even 3 and > a half years old. Our current support of System 7.5.5, released in August > 1996, makes our support go back almost 6 years. 3 and a half years, even 4 > years, is considerably shorter that 6 years. > > -----Original Message----- > From: Nathan Heagy [mailto:nathan@vividworks.com] > Sent: Friday, January 04, 2002 11:17 AM > To: Magladry, Stephen > Cc: 'Jack Jansen'; pythonmac-sig@python.org > Subject: RE: [Pythonmac-SIG] MacPython 2.3 - Carbon > only? > > > 1. MacPython wouldn't run on 8.5 anymore > (for 8.1 MacPython > > 2.2 is the last release anyway), and on 8.6 you would need > to manually > > install CarbonLib. > > I stand corrected. Since I do think that Carbon is the right > way to go let > me then say this: while, "8.6 is only about 2 and a half > years old," that > is only right now. Python 2.3 will probably not be released > for nine > months judging from 2.1's release. Add to that the > development time for a > kids' game - perhaps a year - and at that point 8.6 will be > nearly five > years old. > > Nathan > > > > -----Original Message----- > > From: Nathan Heagy > [mailto:nathan@vividworks.com] > > Sent: Friday, January 04, 2002 11:03 AM > > To: Magladry, Stephen > > Cc: 'Jack Jansen'; > pythonmac-sig@python.org > > Subject: RE: [Pythonmac-SIG] > MacPython 2.3 - Carbon > > only? > > > > I think that this only limits what platform > can be used for > > development. I > > expect to be corrected if I'm wrong however. > > > > Nathan > > > > > > > > On Fri, 4 Jan 2002, Magladry, Stephen wrote: > > > > > I guess I'll be a voice of dissention. I > work for a game > > company writing > > > kids software. We try to keep our min > specs as broad as > > possible. As a point > > > of reference, our current min specs is > 7.5.5. In our up > > coming games we plan > > > to use Python. A requirement of 8.6 cuts > into our > > potential market. Also, > > > 8.6 is only about 2 and a half years old. > > > > > > True we can just stay with 2.2, but there > may be some > > feature in 2.3 that we > > > may really want to use. At that time, we > would be stuck > > between a rock > > > (wanting the new feature) and a hard place > (Having our min > > spec jump up). > > > > > > -----Original Message----- > > > From: Jack Jansen > [mailto:jack@oratrix.nl] > > > Sent: Thursday, January > 03, 2002 2:47 PM > > > To: > pythonmac-sig@python.org > > > Subject: > [Pythonmac-SIG] MacPython > > 2.3 - Carbon only? > > > > > > Folks, > > > I'm toying with the idea of > making MacPython > > 2.3 > > > Carbon-only, as this > > > would save a lot of > development effort. And > > there are a lot > > > of things > > > I'd like to do, for one > thing I would like > > all our MacPython > > > goodies > > > to run natively in > MachoPython by the time > > 2.3 is released. > > > > > > There are two drawbacks to > this plan: > > > 1. MacPython wouldn't run on > 8.5 anymore > > (for 8.1 MacPython > > > 2.2 is the > > > last release anyway), and on > 8.6 you would > > need to manually > > > install > > > CarbonLib. > > > 2. Tkinter is going to be a > problem, but I > > think it is a > > > solvable > > > problem (it is possible to > load > > InterfaceLib-based code into > > > a > > > CarbonLib-based main > program). > > > > > > What do people think? > > > -- > > > Jack Jansen | > ++++ stop the > > execution of Mumia > > > Abu-Jamal ++++ > > > Jack.Jansen@oratrix.com | > ++++ if you agree > > copy these lines > > > to your sig ++++ > > > www.cwi.nl/~jack | > ++++ see > > > http://www.xs4all.nl/~tank/ ++++ > > > > > > > > > > _______________________________________________ > > > Pythonmac-SIG maillist - > Pythonmac-SIG@python.org > > > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > > > From nathan@vividworks.com Fri Jan 4 21:31:14 2002 From: nathan@vividworks.com (Nathan Heagy) Date: Fri, 4 Jan 2002 15:31:14 -0600 (CST) Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE616@sea-horse.humongous.com> Message-ID: > I do not know our break down of OS customers. One thing we keep in mind is > we want to run on hand-me-down systems. Dad/Mom got the latest and greatest, > John/Susie gets this box. So the trend is towards Mac OS x...with new > boxes. But because of our lag with hand-me-down machines, we also lag behind > the trends. That's an interesting point. Kids *do* tend to get hand me downs. iMacs work particularly good because they're do durable (unlike some of the more damaged PCs I've seen). Nathan > -----Original Message----- > From: Nathan Heagy [mailto:nathan@vividworks.com] > Sent: Friday, January 04, 2002 11:54 AM > To: Magladry, Stephen > Cc: 'Jack Jansen'; pythonmac-sig@python.org > Subject: RE: [Pythonmac-SIG] MacPython 2.3 - Carbon > only? > > Fair enough. Also very interesting. Sounds like you are > using Python's RAD > properties well. > > While there is a big difference in time between 3 years and > 6 years in > terms of technology both are very old. For certain halving > the minimum age > of supported OSes would not cut you off from half your > potential > customers. Please don't get angry with me for pressing the > issue, I am > mearly curious. Do you know how many of your customers use > these older > versions of your OSes? > > Also the issue is complicated by the trends of Macintosh > users. PC users > tend to accept that a 3 year old OS is obsolete. To compound > that PC > developers already have a larger audience so they do not > feel as much > pressure to reach all of their potential customers. Mac > users tend to > expect their machines to be supported longer. > > Just as when Apple started using PowerPC CPUs something > similar is > occuring now with the transition to OS X. For the next few > years Mac OSes > will be obsolete earlier than the generations before them. > > Nathan > > > > On Fri, 4 Jan 2002, Magladry, Stephen wrote: > > > Our cross platform code is already under development. Our > first title is to > > be released in about nine months. True 2.3 wouldn't be > usable for us at that > > time, but this engine will be reused many times, maybe > even concurrently > > with this first project. So a release three months after > the release of 2.3 > > wouldn't be totally out of the question. That would make > 8.6 not even 3 and > > a half years old. Our current support of System 7.5.5, > released in August > > 1996, makes our support go back almost 6 years. 3 and a > half years, even 4 > > years, is considerably shorter that 6 years. > > > > -----Original Message----- > > From: Nathan Heagy > [mailto:nathan@vividworks.com] > > Sent: Friday, January 04, 2002 11:17 AM > > To: Magladry, Stephen > > Cc: 'Jack Jansen'; > pythonmac-sig@python.org > > Subject: RE: [Pythonmac-SIG] > MacPython 2.3 - Carbon > > only? > > > > > 1. MacPython wouldn't run on > 8.5 anymore > > (for 8.1 MacPython > > > 2.2 is the last release anyway), and on > 8.6 you would need > > to manually > > > install CarbonLib. > > > > I stand corrected. Since I do think that > Carbon is the right > > way to go let > > me then say this: while, "8.6 is only about > 2 and a half > > years old," that > > is only right now. Python 2.3 will probably > not be released > > for nine > > months judging from 2.1's release. Add to > that the > > development time for a > > kids' game - perhaps a year - and at that > point 8.6 will be > > nearly five > > years old. > > > > Nathan > > > > > > > -----Original Message----- > > > From: Nathan Heagy > > [mailto:nathan@vividworks.com] > > > Sent: Friday, January 04, > 2002 11:03 AM > > > To: Magladry, Stephen > > > Cc: 'Jack Jansen'; > > pythonmac-sig@python.org > > > Subject: RE: > [Pythonmac-SIG] > > MacPython 2.3 - Carbon > > > only? > > > > > > I think that this only > limits what platform > > can be used for > > > development. I > > > expect to be corrected if > I'm wrong however. > > > > > > Nathan > > > > > > > > > > > > On Fri, 4 Jan 2002, > Magladry, Stephen wrote: > > > > > > > I guess I'll be a voice of > dissention. I > > work for a game > > > company writing > > > > kids software. We try to > keep our min > > specs as broad as > > > possible. As a point > > > > of reference, our current > min specs is > > 7.5.5. In our up > > > coming games we plan > > > > to use Python. A > requirement of 8.6 cuts > > into our > > > potential market. Also, > > > > 8.6 is only about 2 and a > half years old. > > > > > > > > True we can just stay with > 2.2, but there > > may be some > > > feature in 2.3 that we > > > > may really want to use. At > that time, we > > would be stuck > > > between a rock > > > > (wanting the new feature) > and a hard place > > (Having our min > > > spec jump up). > > > > > > > > > -----Original Message----- > > > > From: Jack > Jansen > > [mailto:jack@oratrix.nl] > > > > Sent: > Thursday, January > > 03, 2002 2:47 PM > > > > To: > > pythonmac-sig@python.org > > > > Subject: > > [Pythonmac-SIG] MacPython > > > 2.3 - Carbon only? > > > > > > > > Folks, > > > > I'm toying > with the idea of > > making MacPython > > > 2.3 > > > > Carbon-only, as this > > > > would save a > lot of > > development effort. And > > > there are a lot > > > > of things > > > > I'd like to > do, for one > > thing I would like > > > all our MacPython > > > > goodies > > > > to run > natively in > > MachoPython by the time > > > 2.3 is released. > > > > > > > > There are > two drawbacks to > > this plan: > > > > 1. MacPython > wouldn't run on > > 8.5 anymore > > > (for 8.1 MacPython > > > > 2.2 is the > > > > last release > anyway), and on > > 8.6 you would > > > need to manually > > > > install > > > > CarbonLib. > > > > 2. Tkinter > is going to be a > > problem, but I > > > think it is a > > > > solvable > > > > problem (it > is possible to > > load > > > InterfaceLib-based code into > > > > a > > > > > CarbonLib-based main > > program). > > > > > > > > What do > people think? > > > > -- > > > > Jack Jansen > | > > ++++ stop the > > > execution of Mumia > > > > Abu-Jamal ++++ > > > > > Jack.Jansen@oratrix.com | > > ++++ if you agree > > > copy these lines > > > > to your sig ++++ > > > > > www.cwi.nl/~jack | > > ++++ see > > > > > http://www.xs4all.nl/~tank/ ++++ > > > > > > > > > > > > > > _______________________________________________ > > > > Pythonmac-SIG maillist - > > Pythonmac-SIG@python.org > > > > > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > > > > > > > > From tastytreats@aol.com Sat Jan 26 13:51:13 2002 From: tastytreats@aol.com (tastytreats@aol.com) Date: Sat, 26 Jan 2002 13:51:13 Subject: [Pythonmac-SIG] You love cookies Don't you ? A special holiday treat! Message-ID: Untitled Document I noticed your email address on a physician list serve related to growing your practice. With your permission, we would like to send you information regarding new approaches to improving and/or growing your patient base, business tips for private practice physicians, and workshops and events for healthcare practitioners. To opt-in to our monthly e-newsletter and events calendar click here.

Sincerely,

Victor Black
Practice Growth Consultant

From prastawa@cs.unc.edu Fri Jan 4 22:25:38 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Fri, 04 Jan 2002 17:25:38 -0500 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? References: Message-ID: <3C362BE2.5090209@cs.unc.edu> I played with wxWindows (the C++ library running on Carbon) recently and it appears to be generally usable, even though some things are missing. wxMac is getting better, and wxPython-Mac should follow (I hope, I haven't managed to build it yet, may need some hacks). Marcel Bob Savage wrote: > on 1/4/02 8:58 AM, Francois Granger wrote: > >>>Honestly, the Tkinter question is my only hesitation... >>>Tkinter has to be available, since that's the "native" >>>GUI platform for Python. >>> >>And the only still available. >> >>And I don't see wx available soon for Mac. >> > > > The Mac has had long-standing problems with TKinter. Personally I don't see > that being resolved without MacOSX. That means hoping that integration with > TKinter will get better under OS 8.x is futile. > > > Bob > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From richard@richardgordon.net Sat Jan 5 00:51:45 2002 From: richard@richardgordon.net (Richard Gordon) Date: Fri, 4 Jan 2002 19:51:45 -0500 Subject: [Pythonmac-SIG] You love cookies Don't you ? A special holiday treat! In-Reply-To: References: Message-ID: --============_-1201930585==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 1:51 PM -0500 1/26/02, tastytreats@aol.com wrote: >I noticed your email address > on a physician list serve related to growing your practice. >With your permission, we would like to send you information >regarding new approaches to improving and/or growing your patient >base, business tips for private practice physicians, and workshops >and events for healthcare practitioners. To opt-in to our monthly >e-newsletter and events calendar >click here. > >Sincerely, > >Victor Black >Practice Growth Consultant Dear Victor I am so pleased that you noticed my email address on a physician list and am very impressed that you are offering your very useful services via a website in Spain, yet used an open relay at a little community college in Oklahoma to spread your message to the world. Your website asks "Are you interested in learning about how to professionally and ethically market your practice to grow and/or improve your practice, and/or attract better patient cases?" You bet I am, but I'm afraid that I just dabble in abnormal gynecology as a hobby and don't really have a practice as such since that presents some licensing problems. In any case, I can see that you have adapted your Practice Growth consultancy to the subtle nuances of the internet quite well and expect that you will achieve positive feedback from many licensed practitioners of abnormal gynecology. However, I remain a little confused about the reference to holiday cookies in the subject header of your message- did you mean "nookies?" Thanks & I wish you a prosperous New Year. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net --============_-1201930585==_ma============ Content-Type: text/enriched; charset="us-ascii" At 1:51 PM -0500 1/26/02, tastytreats@aol.com wrote: ArialI noticed your email address on a physician list serve related to growing your practice. With your permission, we would like to send you information regarding new approaches to improving and/or growing your patient base, business tips for private practice physicians, and workshops and events for healthcare practitioners. To opt-in to our monthly e-newsletter and events calendar <click here. Sincerely, Victor Black Practice Growth Consultant Arial Dear Victor I am so pleased that you noticed my email address on a physician list and am very impressed that you are offering your very useful services via a website in Spain, yet used an open relay at a little community college in Oklahoma to spread your message to the world. Your website asks "Are you Verdanainterested in learning about how to professionally and ethically market your practice to grow and/or improve your practice, and/or attract better patient cases?" You bet I am, but I'm afraid that I just dabble in abnormal gynecology as a hobby and don't really have a practice as such since that presents some licensing problems. In any case, I can see that you have adapted your Practice Growth consultancy to the subtle nuances of the internet quite well and expect that you will achieve positive feedback from many licensed practitioners of abnormal gynecology. However, I remain a little confused about the reference to holiday cookies in the subject header of your message- did you mean "nookies?" Thanks & I wish you a prosperous New Year. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net --============_-1201930585==_ma============-- From kevino@tulane.edu Sat Jan 5 01:20:43 2002 From: kevino@tulane.edu (Kevin Ollivier) Date: Fri, 4 Jan 2002 20:20:43 -0500 Subject: [Pythonmac-SIG] Carbon MacPython 2.3 - An idea Message-ID: <70966788-017A-11D6-88E8-003065BE204C@tulane.edu> Hi everyone, Regarding the Carbonization of MacPython 2.3, I personally think it is a good idea. After all, the number of people using Mac 9.x and OS X is growing and will continue to grow, and for that reason I feel those audiences should be the primary focus for future development. Does anyone know if it would be realistic to consider using IDLE as the console shell for OS X now that Apple has ported TCL/TK? However, I think it is also important to discuss and see if we can find a compromise for those wanting to support older versions of the Mac OS. I was wondering if it would be possible to "fork" the GUI code. That is, leave an non-carbonated classic version of the GUI in the project so that anyone that needed to support this environment could do so. It would no longer be "supported", but neither would it be removed and could still be improved and updated if some kind soul was inclined to do so. =) How feasible is this idea? What does everyone think? Sorry if I'm actually repeating someone's previous comments - I'm new to this group and have just been following the discussion over the past couple days. (I'm a rather new convert to the Mac universe, but I've been converted to Python for awhile now!) Kevin From healthynow@msn.com Sat Jan 26 17:16:55 2002 From: healthynow@msn.com (healthynow@msn.com) Date: Sat, 26 Jan 2002 17:16:55 Subject: [Pythonmac-SIG] Create the practice of your dreams ! Message-ID: Untitled Document I noticed your email address on a physician list serve related to growing your practice. With your permission, we would like to send you information regarding new approaches to improving and/or growing your patient base, business tips for private practice physicians, and workshops and events for healthcare practitioners. To opt-in to our monthly e-newsletter and events calendar click here.

Sincerely,

Victor Black
Practice Growth Consultant

From richard@richardgordon.net Sat Jan 5 01:56:20 2002 From: richard@richardgordon.net (Richard Gordon) Date: Fri, 4 Jan 2002 20:56:20 -0500 Subject: [Pythonmac-SIG] Create the practice of your dreams ! In-Reply-To: References: Message-ID: --============_-1201926704==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 5:16 PM -0500 1/26/02, healthynow@msn.com wrote: >I noticed your email address > > on a physician list Thanks again, Victor, but like I said I just enjoy gynecology as a hobby. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net --============_-1201926704==_ma============ Content-Type: text/enriched; charset="us-ascii" At 5:16 PM -0500 1/26/02, healthynow@msn.com wrote: ArialI noticed your email address on a physician list Arial Thanks again, Victor, but like I said I just enjoy gynecology as a hobby. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net --============_-1201926704==_ma============-- From sburr@home.com Sat Jan 5 07:45:43 2002 From: sburr@home.com (Steven Burr) Date: Sat, 5 Jan 2002 00:45:43 -0700 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE615@sea-horse.humongous.com> Message-ID: <38ADBBB6-01B0-11D6-AFA3-00039362D50A@home.com> On Friday, January 4, 2002, at 12:33 PM, Magladry, Stephen wrote: > Our cross platform code is already under development. Our first title > is to > be released in about nine months. True 2.3 wouldn't be usable for us at > that > time, but this engine will be reused many times, maybe even concurrently > with this first project. So a release three months after the release of > 2.3 > wouldn't be totally out of the question. That would make 8.6 not even 3 > and > a half years old. Our current support of System 7.5.5, released in > August > 1996, makes our support go back almost 6 years. 3 and a half years, > even 4 > years, is considerably shorter that 6 years. If I understand Jack correctly, Python 2.2 will be the last release that runs on 8.1 or earlier, no matter what. Running 2.3 on 7.5.5 or any other system version preceding 8.5 will NOT be an option. System 8.5 was released in 10/98, and 8.6 came out in 4/99. I can see that there might be a significant difference between supporting system versions that are 2 and a half years apart. But would there be a significant difference between supporting systems that are only 5 months apart? For that matter, would you really even consider cutting off support at 8.5? Because that's what you'll have to do, if you want to use 2.3 in your products, regardless of whether 2.3 is Carbon-only. From billb@mousa.demon.co.uk Sat Jan 5 15:25:07 2002 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Sat, 5 Jan 2002 15:25:07 +0000 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: <38ADBBB6-01B0-11D6-AFA3-00039362D50A@home.com> References: <38ADBBB6-01B0-11D6-AFA3-00039362D50A@home.com> Message-ID: At 12:45 am -0700 05/01/02, Steven Burr wrote: >On Friday, January 4, 2002, at 12:33 PM, Magladry, Stephen wrote: > >> Our cross platform code is already under development. Our first title is to >> be released in about nine months. True 2.3 wouldn't be usable for us at that >> time, but this engine will be reused many times, maybe even concurrently >> with this first project. So a release three months after the release of 2.3 >> wouldn't be totally out of the question. That would make 8.6 not even 3 and >> a half years old. Our current support of System 7.5.5, released in August >> 1996, makes our support go back almost 6 years. 3 and a half years, even 4 >> years, is considerably shorter that 6 years. > >If I understand Jack correctly, Python 2.2 will be the last release >that runs on 8.1 or earlier, no matter what. Running 2.3 on 7.5.5 >or any other system version preceding 8.5 will NOT be an option. > >System 8.5 was released in 10/98, and 8.6 came out in 4/99. I can >see that there might be a significant difference between supporting >system versions that are 2 and a half years apart. But would there >be a significant difference between supporting systems that are only >5 months apart? For that matter, would you really even consider >cutting off support at 8.5? Because that's what you'll have to do, >if you want to use 2.3 in your products, regardless of whether 2.3 >is Carbon-only. But which was the last hardware not to be able to run OS 8.5? I have a 6100 from c1995 which runs 8.6 and I believe all power PC will run any OS up to and including 9.2. -- Bill Bedford You can win or you can have peace, but not at the same time. From kp87@lycos.com Sat Jan 5 17:29:12 2002 From: kp87@lycos.com (kevin parks) Date: Sun, 06 Jan 2002 02:29:12 +0900 Subject: [Pythonmac-SIG] Carbon only for 2.3 Message-ID: >>But which was the last hardware not to be able to run OS 8.5? >> >>I have a 6100 from c1995 which runs 8.6 and I believe all power PC >>will run any OS up to and including 9.2. Unfortunatly some of us who bought clones are stuck with machines that only go as high as 8.6. I have a PowerComputing PowerCenterPro 210, which is a 604e and I am still running 8.6 on it. I hear that 9.x is a problem on it so I am afraid to go up to 9.x on it. And of course OS X is a no-no on it as well. It is a shame cause the machine was manufactured in 1997, which is not all that long ago. I was running my NeXT machine until a year ago. Don't you all feel bad for me? I send my whole life getting screwed over by Steve Jobs. I Buy a NeXT, they go out of business a few months later. By a PowerComputing clone, Steve Jobs kills their license a few weeks later. Despite this, i think going carbon only is ok. The transition has to be made sometime and the integration of unix(mach-o) python and the current MacPython is really important for the mac python community. From jack@oratrix.nl Sat Jan 5 21:46:57 2002 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 05 Jan 2002 22:46:57 +0100 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: Message by "Magladry, Stephen" , Fri, 4 Jan 2002 09:59:07 -0800 , <151590CD351823429A7EBA135BEEAD5801ADE611@sea-horse.humongous.com> Message-ID: <20020105214703.1B52BE8451@oratrix.oratrix.nl> I'll just answer Stephens mail, since he started it all, and try and address the comments by others as I go along. Recently, "Magladry, Stephen" said: > I guess I'll be a voice of dissention. I work for a game company writing > kids software. We try to keep our min specs as broad as possible. As a point > of reference, our current min specs is 7.5.5. In our up coming games we plan > to use Python. A requirement of 8.6 cuts into our potential market. Also, > 8.6 is only about 2 and a half years old. My reason for picking 8.6 is twofold: - Apple makes a version of CarbonLib available for 8.6, but not earlier. - For some powerPC machines 8.6 is the end of the line. This is true for some clones, but I think also for the 6100 (though I'm not 100% sure). But all that said, the Mac software market has a history of keeping old machines and OS versions alive very long. You could still surf the internet with a Mac Plus in 1995, and I know people who are still happily using their LC-II's for surfing, MS Word and lots of other things. MacPython 1.5.2, the last version to support 68K, came out in september 1999, at least 4 years after the last 68K mac was sold. And I'd like to continue this trend, but for that I need help. The alternative is that I spend my time maintaining od hardware in stead of new hardware, and that's not a good idea. Already Python is lagging behind RealBasic and AppleScript (and probably even Tcl) on OSX, while I think the two fit hand-in-glove. What I can do is that I try not to put fullblown carbon-depencencies in the C source code, and leave the classic targets in the CodeWarrior project files. Maybe I can even try to compile them once in a while to keep them working, if this doesn't cost me too much time. What I cannot do is test them, so someone else will have to do that. What I also don't want to do is hinder the progress of Carbon MacPython because of Classic, so that means that the .py library files and tools (such as the IDE) will probably move towards Carbon. But this is fairly easy to solve: we add a folder :Mac:Lib:lib-classic that's in sys.path before :Mac:Lib if you're on classic and that contains older, classic-compatible versions of modules. This shouldn't be too much of a problem for Stephen (I assume that he can live with a slightly older version of the Python IDE if it's embedded in his game:-), and others will have to work on porting features themselves. With this in place compatibility back to 8.1 should be doable. But, as said above: for this I need help. Volunteers: please step forward! -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From bobsavage@mac.com Sat Jan 5 23:37:51 2002 From: bobsavage@mac.com (Bob Savage) Date: Sat, 05 Jan 2002 17:37:51 -0600 Subject: [Pythonmac-SIG] Carbon only for 2.3 In-Reply-To: Message-ID: on 1/5/02 11:29 AM, kevin parks wrote: > Unfortunatly some of us who bought clones are stuck with machines that > only go as high as 8.6. I have a PowerComputing PowerCenterPro 210, which > is a 604e and I am still running 8.6 on it. I hear that 9.x is a problem > on it so I am afraid to go up to 9.x on it. And of course OS X is a no-no > on it as well. It is a shame cause the machine was manufactured in 1997, > which is not all that long ago. I was running my NeXT machine until a year > ago. I had a PowerBase 180 (603e) which also would not run OS 9. I eventually replaced it with a G4 (450mhz). I can assure you, if you replace your computer with a new one, you will know why OSX is not supported on the old equipment; they are dog slow in comparison. And that's without considering the improvement in the case design -- installing a hard drive, or RAM, or even a PCI card in my PowerBase was a massive project, with 8 screws needing to be removed before I could even pull the "outer" lid off! Now, I just lift the latch :) Well, my point was that, from my experience, you shouldn't bother going past 8.6 on the PowerCenter. Bob From jack@oratrix.nl Sat Jan 5 23:40:08 2002 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 06 Jan 2002 00:40:08 +0100 Subject: [Pythonmac-SIG] MacPython icons on OSX Message-ID: <20020105234008.29AAFE8451@oratrix.oratrix.nl> Folks, on OSX I'm seeing (but not always) that PythonInterpreter picks up the icon of the IDE in stead of using its own. This seems to be a problem with the interpreter having multiple BNDL resources (128 for itself, and 129 and 130 to ease the process of building applets and the IDE), but I'm not sure I really understand what's going on. If this happens .py files for creator 'Pyth' type 'TEXT' also pick up the IDE sourcefile icon in stead of the interpreter sourcefile icon. But files for which the IDE doesn't have an icon (pyc files, dyamic modules) keep the interpreter icon. Does anyone else see this? Anyone has any insights to offer as to why there seems to be a problem on OSX but on on OS9? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dan@grassi.org Sun Jan 6 01:30:42 2002 From: dan@grassi.org (Dan Grassi) Date: Sat, 5 Jan 2002 20:30:42 -0500 Subject: [Pythonmac-SIG] Carbon only for 2.3 In-Reply-To: Message-ID: Hi Jack, IMHO you should not even consider non-carbon nor worry about putting fullblown carbon-depencencies in the C source code -- it that makes your job easier. If someone steps forward to work on a non-carbon version let them worry about that and fork the non-carbon version. If no one steps forward then there is no champion and insufficient interest. Even in the latter case every current Python program will continue to run. I see no reason to hinder Python development and add complexity just because someone _may_ want to use a feature in a Python upgrade without upgrading the OS/computer to the minimum requirements of the upgrade version. After all, what we are mainly talking about are features that can be accomplished more easily and more straight forwardly in a upgrade release but can still be accomplished in the current version. Python meets the Turing Test so upgrades are not _necessary_ to produce any program. :-) The ability to use niceties and better syntactic sugar is, IMHO, insufficient reason to hold back Python. My main concern is getting a version that is stable and supports TK. Second would be the merger of the two OS X versions. Dan On Saturday, January 5, 2002, at 04:46 PM, Jack Jansen wrote: What I can do is that I try not to put fullblown carbon-depencencies in the C source code From bob@redivi.com Sun Jan 6 04:15:08 2002 From: bob@redivi.com (Bob Ippolito) Date: Sat, 5 Jan 2002 23:15:08 -0500 Subject: [Pythonmac-SIG] dynamic loader in 2.2 Message-ID: I've done a lot of work recently with Python 2.2 on Mac OS X in my effort to port pygame and its dependencies to Mac OS X The largest issue so far (other than a few distutils quirks) is the dynamic loader for next style dylibs is broken, it doesn't differentiate between blah/module.so and anotherpath/module.so, it only loads the first. My solution to this is to download libcompat from darwin cvs, and to use the standard libdl implementation for loading .so files, this works beautifully but it requires patching the configure script for python to get it to work. In a few days, after I release my binaries as a nice easy to install package, I'll try and get my changes to python, distutils, SDL, pygame, and PyOpenGL into their respective source trees. I think that dependency on libdl might not be the best thing, since it doesn't come with OS X (as of 10.1.2), but if someone else who has more time can look through it and patch the dylib loader already in python to work properly that'd be awesome. Another issue I've noticed is that when starting python from the command prompt, it's just about impossible to get menus and the dock working, I've yet to find a way around this. However, one can still create windows like this with one caveat. If the python interpreter is initiated from the path (i.e. "python somefile.py") the WindowServer will be unable to find it. The solution to this is to re-write argv[0] with a full-path location. Unfortunately the setproctitle in darwin cvs is totally worthless, and the source for top and ps don't use the same way for reading the process title as the WindowServer and Cocoa does. I'm currently working on my own setproctitle, and it has yielded good results so far but causes a segfault when the arguments message is passed to a NSProcessInfo instance (only under certain conditions). Unfortunately this part of Mac OS X (like many others) isn't documented at all so I'm trying to resolve this issue by "guess and check" and some playing around in GDB. PyOpenGL on Mac OS X works well so far but I had to disable GL_VERTEX_ARRAY_EXT and the GL.ARB.TEXTURECOMPRESS to get it to compile. GL_VERTEX_ARRAY doesn't seem to be a supported enumerator in Mac OS X's implementation of OpenGL (at least on my g4-400), none of the GLUT demos use it either so I really don't know if we're stuck without it or if something is screwing up otherwise. I'm also trying to hack Tkinter into working properly. Wish/Tk works great on it's own, but the python module as is so far doesn't seem to be working quite right. I don't really have much experience with any of these libraries, but hopefully I'll be able to track down what's going on. Screenshots of what I've got working so far (regarding pygame mostly) are available at http://redivi.com/~bob - I hope to be releasing my package by Monday. -bob From tmk@mac.com Sun Jan 6 11:17:32 2002 From: tmk@mac.com (tmk) Date: Sun, 6 Jan 2002 12:17:32 +0100 Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? In-Reply-To: Message-ID: Yo, I'm all for making MacPython 2.3 Carbon only. On Saturday, January 5, 2002, at 04:25 PM, Bill Bedford wrote: > At 12:45 am -0700 05/01/02, Steven Burr wrote: > > [snip] > > But which was the last hardware not to be able to run OS 8.5? > > I have a 6100 from c1995 which runs 8.6 and I believe all power PC > will run any OS up to and including 9.2. I'm not sure about this. I have this umax box (PPC 604e 225MHz I think) and I don't seem to be able to install anything beyond 9.1 same goes for a PowerMac 7500 (1995 machine). = tmk = > > > -- > Bill Bedford > > You can win or you can have peace, but not at the same time. > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob@redivi.com Sun Jan 6 19:25:35 2002 From: bob@redivi.com (Bob Ippolito) Date: Sun, 6 Jan 2002 14:25:35 -0500 Subject: [Pythonmac-SIG] pygame osx binaries released Message-ID: <28503326-02DB-11D6-A5E6-003065A10F5A@redivi.com> Well, a bit earlier than I've expected, but up at http://redivi.com/~bob I've got a package up for download that covers all the bases. All development headers are also included. This should simplify a lot of things until these packages are made to compile properly and a distutils package system for OS X is established (which shouldn't be very hard at all if/when the pax archive format is figured out). Including (but not limited to) Compiled as dynamic bundle unless otherwise stated, most of them with flat_namespace, but a couple I got to compile with two level Python 2.2 (compiled as framework) with slightly patched distutils, and fixed module loader w/ tkinter and pyexpat TCL (from cvs, framework) Tk (from cvs, framework) expat (static lib) pygame 1.3.4 SDL (framework) SDL_image (framework) SDL_mixer (framework) SDL_ttf (framework) freetype2 smpeg libogg libvorbis libjpeg libpng libtiff SWIG PyOpenGL PyXML dlcompat (from darwin cvs) PIL Numeric enjoy -bob From guess-who@kevin-masako.com Sun Jan 6 21:22:10 2002 From: guess-who@kevin-masako.com (Kevin & Masako Ollivier) Date: Sun, 6 Jan 2002 16:22:10 -0500 Subject: [Pythonmac-SIG] Menus for wxPythonMac Message-ID: <054801c196f8$348f8000$6401a8c0@cj622768a> Sorry for the cross-posting, but I thought I'd cover all my bases! =) I'll briefly explain where I'm at. I'm using the Carbon version of Python 2.2, along with wxWindows and wxPython on OS X 10.1.2. I've pulled all the sources from CVS. Everything compiles, and so far I've been able to run wxPython scripts with a limited degree of success. However, the major problem is that I'm still having troubles with the menus. When I load a wxPython script in Python, Python's menubars stay active and the menus created by the script are nowhere to be found. Has anyone else experienced this? Also, when I run the script it does not open as a separate application in OS X. All windows are listed as child windows of the Python application. I'm wondering if these two issues are related. wxPython may not be able to modify Python's menus, and since it does not have its own application, it has no way of showing its own menus. Does this make sense? I admit I'm pretty new to Mac programming, and as such I'm a bit stuck as to what can be done about this problem. Any help would be appreciated! Thanks, Kevin From bob@redivi.com Sun Jan 6 23:56:41 2002 From: bob@redivi.com (Bob Ippolito) Date: Sun, 6 Jan 2002 18:56:41 -0500 Subject: [Pythonmac-SIG] Menus for wxPythonMac In-Reply-To: <054801c196f8$348f8000$6401a8c0@cj622768a> Message-ID: <07CD21F6-0301-11D6-A5E6-003065A10F5A@redivi.com> That's quite a hairy issue. You see, the way WindowServer and the Dock work, to my knowledge, is that they just *will not* register two separate dock instances or two menus for the same pid. It is possible to change the menu bars dynamically, so, with appropriate fixes to wxWindows and/or wxPython's source code it could work by using submenus or something under PythonInterpreter. But until apple (which they will almost certainly never do...) properly documents WindowServer and the behind-the-scenes stuff that goes on it's going to be pretty difficult to see flawless operation of any scripting language with the GUI. The only solution I can think of is to make dummy application bundles and launch them in separate processes, and have some sort of socket communication between wxPython and the dummy bundles. Each bundle would have to have a unique name because WindowServer seems to use argv[0] as it's key to redirect events back to the application, so it could get confused. This is a terrible hack, but it would almost certainly work. The problem is that all communication to windows probably has to be done over sockets, unless you can get an NSApplication pointer to the dummy app or something, which would be awfully cool. It'd be a lot of work though, obviously. -bob On Sunday, January 6, 2002, at 04:22 PM, Kevin & Masako Ollivier wrote: > Sorry for the cross-posting, but I thought I'd cover all my bases! =) > > I'll briefly explain where I'm at. I'm using the Carbon version of > Python > 2.2, along with wxWindows and wxPython on OS X 10.1.2. I've pulled all > the > sources from CVS. Everything compiles, and so far I've been able to run > wxPython scripts with a limited degree of success. However, the major > problem is that I'm still having troubles with the menus. When I load a > wxPython script in Python, Python's menubars stay active and the menus > created by the script are nowhere to be found. Has anyone else > experienced > this? > > Also, when I run the script it does not open as a separate application > in OS > X. All windows are listed as child windows of the Python application. > I'm > wondering if these two issues are related. wxPython may not be able to > modify Python's menus, and since it does not have its own application, > it > has no way of showing its own menus. Does this make sense? I admit I'm > pretty new to Mac programming, and as such I'm a bit stuck as to what > can be > done about this problem. Any help would be appreciated! > > Thanks, > > Kevin > > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From robin@alldunn.com Mon Jan 7 00:43:05 2002 From: robin@alldunn.com (Robin Dunn) Date: Sun, 6 Jan 2002 16:43:05 -0800 Subject: [Pythonmac-SIG] Re: [wxPython-mac] Menus for wxPythonMac References: <054801c196f8$348f8000$6401a8c0@cj622768a> Message-ID: <021001c19714$50414740$0214a8c0@Rogue> > Sorry for the cross-posting, but I thought I'd cover all my bases! =) > > I'll briefly explain where I'm at. I'm using the Carbon version of Python > 2.2, along with wxWindows and wxPython on OS X 10.1.2. I've pulled all the > sources from CVS. Everything compiles, and so far I've been able to run > wxPython scripts with a limited degree of success. However, the major > problem is that I'm still having troubles with the menus. When I load a > wxPython script in Python, Python's menubars stay active and the menus > created by the script are nowhere to be found. Has anyone else experienced > this? Yes. I've been experimenting with Python built as a Framework and have the similar problem of there being no menus at all. > > Also, when I run the script it does not open as a separate application in OS > X. All windows are listed as child windows of the Python application. I'm > wondering if these two issues are related. wxPython may not be able to > modify Python's menus, and since it does not have its own application, it > has no way of showing its own menus. Does this make sense? I admit I'm > pretty new to Mac programming, and as such I'm a bit stuck as to what can be > done about this problem. Any help would be appreciated! An approach that I've been thinking of trying is to build a wxMac C++ application that embeds Python, rather than a standard Python extension module. This app can then do the housework necessary to be a well behaved Mac app, and then hand off to the embedded Python to run the main wxPython script. I havn't had much time lately to do more than think about this, perhaps if you've got the time you could try it? Any more knowledgable people have comments about this approach? -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From adam@switchedonsoftware.com Mon Jan 7 06:05:58 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Mon, 7 Jan 2002 17:05:58 +1100 Subject: [Pythonmac-SIG] Slimmed down framework Message-ID: <9E5C5914-0334-11D6-96E0-0030656E8732@switchedonsoftware.com> I'm working on an app that embeds Python 2.2 using the framework, built from the Unix sources. I was about to copy the whole lot over to another machine when I realised that my app was 125 KB, and the framework 62 MB!!! At first I thought this may be due to a proliferation of headers and other documentation, but inspection revealed that 58.3 MB is contained within the lib folder, and then 38.3 MB of that is from the lib-dynload folder. Basically all I want the user to have access to is the raw language and built-in types (strings, arrays, dictionaries etc.). Other libraries are not vital at this stage. Can anyone give me a pointer on what files are safe to delete, and what implications these have. ie, delete x, then change line in file y etc. I'm not that familiar with how all the bits and pieces of Python slot together. Once I get that under control I'll post a slimmed down framework if there's interest. Thanks in advance. Kind regards, Adam Eijdenberg Switched on Software adam@switchedonsoftware.com http://www.switchedonsoftware.com/ Phone: +61 3 6231 3467 Fax: +61 3 6231 3476 Mobile: +61 4 0704 6857 47 Molle Street Hobart TAS 7000 Australia From Y.Benita@pharm.uu.nl Mon Jan 7 08:13:03 2002 From: Y.Benita@pharm.uu.nl (Yair Benita) Date: Mon, 07 Jan 2002 09:13:03 +0100 Subject: [Pythonmac-SIG] Compiling extensions. Where is MSL_ShLibRuntime_PPC.Lib Message-ID: Hi All, I am trying to compile some extensions for python. I am still using CodeWarrior 5.3, Python 2.2 source and Gusi2 for Python 2.2. The project build in CW has a library called MSL_ShLibRuntime_PPC.Lib. I can't find it anywhere, is it part of later versions of CW? Can I use another library instead? Thanks, Yair -- Yair Benita Pharmaceutical Proteomics Utrecht University From jack@oratrix.nl Mon Jan 7 09:43:29 2002 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 07 Jan 2002 10:43:29 +0100 Subject: [Pythonmac-SIG] Slimmed down framework In-Reply-To: Message by Adam Eijdenberg , Mon, 7 Jan 2002 17:05:58 +1100 , <9E5C5914-0334-11D6-96E0-0030656E8732@switchedonsoftware.com> Message-ID: <20020107094334.3B383E8451@oratrix.oratrix.nl> Recently, Adam Eijdenberg said: > I'm working on an app that embeds Python 2.2 using the framework, built > from the Unix sources. I was about to copy the whole lot over to > another machine when I realised that my app was 125 KB, and the > framework 62 MB!!! > > At first I thought this may be due to a proliferation of headers and > other documentation, but inspection revealed that 58.3 MB is contained > within the lib folder, and then 38.3 MB of that is from the lib-dynload > folder. By default everything is built with "-g", which gives debugging symbolic information in all the output files (like plugin modules). Turning this off should make quite a difference. You can also check to see whether "strip" has an option to strip all non-global symbols, and if so you can use that on all .so files to make 'm smaller. -- - 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 adam@switchedonsoftware.com Mon Jan 7 09:50:50 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Mon, 7 Jan 2002 20:50:50 +1100 Subject: [Pythonmac-SIG] Slimmed down framework In-Reply-To: <20020107094334.3B383E8451@oratrix.oratrix.nl> Message-ID: <08511EBC-0354-11D6-A69E-0030656E8732@switchedonsoftware.com> On Monday, January 7, 2002, at 08:43 PM, Jack Jansen wrote: > By default everything is built with "-g", which gives debugging > symbolic information in all the output files (like plugin > modules). Turning this off should make quite a difference. You can > also check to see whether "strip" has an option to strip all > non-global symbols, and if so you can use that on all .so files to > make 'm smaller. On Monday, January 7, 2002, at 07:34 PM, bill fancher wrote: > Most of the bloat is from debugging symbols. Stripping them brings the > framework size down to around 26 MB without losing functionality. To > get smaller still, you can dump the lib folder, which brings the entire > framework down to about 1.5 MB. You could get away with less. All you > really need is the Python library (about 1 MB). Thanks for both responses. As I get further along the project and this becomes necessary I'll post the results to the list if anyone's interested. Might save someone else in a similar situation a bit of head scratching. Kind regards, Adam Eijdenberg Switched on Software adam@switchedonsoftware.com http://www.switchedonsoftware.com/ Phone: +61 3 6231 3467 Fax: +61 3 6231 3476 Mobile: +61 4 0704 6857 47 Molle Street Hobart TAS 7000 Australia From just@letterror.com Mon Jan 7 10:14:43 2002 From: just@letterror.com (Just van Rossum) Date: Mon, 7 Jan 2002 11:14:43 +0100 Subject: [Pythonmac-SIG] Slimmed down framework In-Reply-To: <08511EBC-0354-11D6-A69E-0030656E8732@switchedonsoftware.com> Message-ID: <20020107111446-r01010800-6aca95fc-0920-010c@10.0.0.23> Adam Eijdenberg wrote: > Thanks for both responses. As I get further along the project and this > becomes necessary I'll post the results to the list if anyone's > interested. Might save someone else in a similar situation a bit of head > scratching. Please do! It would be nice if at some point we had BuildApplication-like functionality, and it would be nice if resulting apps were under, say, 10 megs ;-) (Simple apps generated by BuildApplication are typically around 3 megs or so.) Just From mjb@uma.pt Mon Jan 7 11:46:05 2002 From: mjb@uma.pt (Michael J. Barber) Date: Mon, 7 Jan 2002 11:46:05 +0000 Subject: [Pythonmac-SIG] MacPython icons on OSX In-Reply-To: <20020105234008.29AAFE8451@oratrix.oratrix.nl> Message-ID: <222C79EC-0364-11D6-8E27-0050E4794D0F@uma.pt> On Saturday, January 5, 2002, at 11:40 PM, Jack Jansen wrote: > [incorrect icon for the interpreter] > > Does anyone else see this? Anyone has any insights to offer as to why > there seems to be a problem on OSX but on on OS9? I see this as well. To be more precise, this showed up when I installed 2.2; version 2.1.1 (which was installed originally under OS 8.6) was fine. I still have the 2.1.1 folder, and the icons there are now mangled, too. The interpreter looks like the IDE in the dock. In the finder, it's a little stranger: you can see part of the hand and pencil within the outline of the 16 ton weight, but the rest of the hand and the wrist are cut off outside the border of the weight. Unfortunately, I have no understanding as to the causes. From altis@semi-retired.com Mon Jan 7 20:55:10 2002 From: altis@semi-retired.com (Kevin Altis) Date: Mon, 7 Jan 2002 12:55:10 -0800 Subject: [Pythonmac-SIG] running python/wxpython on the Mac with emulation? Message-ID: Note, if you send me a reply directly, I can post a summary to the lists. I don't currently use a Mac (the old Performa I have with System 7.5 isn't really that usable), but there are quite a few people interested in the PythonCard project that only use Macs, so they are waiting for wxPython Mac to be finished. What I'm wondering is whether any of the free or commercial emulation solutions would be good substitutes until wxPython Mac is available for use with MacPython? Basically, they would just run a version of Python and wxPython (win32 or GTK) for either Windows or Linux depending on the emulation solution. Is anyone already doing this on their Macs? Either OS classic or OS X? If so, could you provide details of the configuration and installation or any tricky parts of getting it to work? Some possibilities: VirtualPC http://www.connectix.com/products/vpc5m.html Bochs http://bochs.sourceforge.net/ VMWare http://www.vmware.com/ plex86 http://www.plex86.org/ XFree86 http://www.xfree86.org/ I had one person suggest "Just use wxGTK under Xfree86 in rootless mode..." on OS X. Thanks, ka --- Kevin Altis altis@semi-retired.com From mcclenon@cstone.net Tue Jan 8 17:13:45 2002 From: mcclenon@cstone.net (mcclenon) Date: Tue, 08 Jan 2002 12:13:45 -0500 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #945 - 14 msgs References: Message-ID: <3C3B28D3.E39BEE00@cstone.net> Please remove me from your mailing list. Thanks. pythonmac-sig-request@python.org wrote: > Send Pythonmac-SIG mailing list submissions to > pythonmac-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/pythonmac-sig > or, via email, send a message with subject or body 'help' to > pythonmac-sig-request@python.org > > You can reach the person managing the list at > pythonmac-sig-admin@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pythonmac-SIG digest..." > > ------------------------------------------------------------------------ > Today's Topics: > > 1. Re: Installing numpy on mach-o python (Chris Lee) > 2. MacPython 2.3 - Carbon only? (Jack Jansen) > 3. Re: MacPython 2.3 - Carbon only? (Nathan Heagy) > 4. Re: MacPython 2.3 - Carbon only? (Steven Majewski) > 5. Re: MacPython 2.3 - Carbon only? (Bob Savage) > 6. Re: MacPython 2.3 - Carbon only? (Steven Majewski) > 7. Re: MacPython 2.3 - Carbon only? (Samuel Smith) > 8. Re: MacPython 2.3 - Carbon only? (Mark Day) > 9. Re: Installing numpy on mach-o python (Marcel Prastawa) > 10. Re: MacPython 2.3 - Carbon only? (Chris Lumsargis) > 11. Project Build and native Cocoa (Patrick Curtain) > 12. RE: MacPython 2.3 - Carbon only? (Schollnick, Benjamin) > 13. Re: MacPython 2.3 - Carbon only? (Jim Harrison) > 14. RE: MacPython 2.3 - Carbon only? (Francois Granger) > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] Installing numpy on mach-o python > Date: Fri, 04 Jan 2002 09:14:58 +1300 > From: "Chris Lee" > To: "Python" > > On January 03 2002, Jack Jansen wrote: > > >On Thu, 3 Jan 2002, Chris Lee wrote: > >> Okay so I have downloaded 2.2 and the latest and greatest Numerics and I have installed them. However when I run autotest I get a segementation fault at test_re > >> > >> Anymore advice? > > > >Yes: read the release notes:-) > > I had but it was only after I sent the email that I figured out that SEGV = semengtation fault (This is why I prefer installers to building my own). Anyway even then it took me a while to realise that the limit statement was a command and not a modification to a configuration file. > > So this is not the end of my woes. 3 test failed unexpectedly test_sax, test_pyexpat and test_locale however as far as I can tell these test functions I never use still, it would be nice to know that it wasn't fatal.... > > Far worse I cannot run any scripts. I can start the interpreter and run commands from the command line but when I execute python myfile.py it starts and terminates without executing any code. So whats have I done now? > > Thanks for all your help everyone. > > Cheers > Chris > > > >This is a known problem wit OSX: you need to set the stack bigger to make > >the selftests pass. "limit stack 2048" should do the trick. > >-- > >Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > >Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ > >http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > > > > ------------------------------------------------------------------------ > > Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Thu, 03 Jan 2002 23:46:58 +0100 > From: Jack Jansen > To: pythonmac-sig@python.org > > Folks, > I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > would save a lot of development effort. And there are a lot of things > I'd like to do, for one thing I would like all our MacPython goodies > to run natively in MachoPython by the time 2.3 is released. > > There are two drawbacks to this plan: > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the > last release anyway), and on 8.6 you would need to manually install > CarbonLib. > 2. Tkinter is going to be a problem, but I think it is a solvable > problem (it is possible to load InterfaceLib-based code into a > CarbonLib-based main program). > > What do people think? > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Thu, 3 Jan 2002 16:53:32 -0600 (CST) > From: Nathan Heagy > To: Jack Jansen > CC: pythonmac-sig@python.org > > Personally I only use Macho python (I call it unix python myself). However > bias aside I think this is the Right Thing To Do. > > Nathan > > On Thu, 3 Jan 2002, Jack Jansen wrote: > > > Folks, > > I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > > would save a lot of development effort. And there are a lot of things > > I'd like to do, for one thing I would like all our MacPython goodies > > to run natively in MachoPython by the time 2.3 is released. > > > > There are two drawbacks to this plan: > > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the > > last release anyway), and on 8.6 you would need to manually install > > CarbonLib. > > 2. Tkinter is going to be a problem, but I think it is a solvable > > problem (it is possible to load InterfaceLib-based code into a > > CarbonLib-based main program). > > > > What do people think? > > -- > > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > > www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ > > > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Thu, 3 Jan 2002 18:06:32 -0500 (EST) > From: Steven Majewski > To: Jack Jansen > CC: pythonmac-sig@python.org > > That plan is OK by me. > ( 9.1 was so much more stable (IMHE) than anything that came before, > that laziness is the only reason I still might have machines with > 8.x. ) > > -- Steve > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Thu, 03 Jan 2002 17:06:11 -0600 > From: Bob Savage > To: PythonMac > > on 1/3/02 4:46 PM, Jack Jansen wrote: > > I'm toying with the idea of making MacPython 2.3 Carbon-only, > <...> > > What do people think? > > I always feel selfish when I put my two cents in on these matters, because I > know someone has real needs that require the old stuff (my brother runs a > gene chip producing machine from a IIsi, so I can understand that people > have legacy equipment and applications), but I am in favor of pushing ahead. > > I live out of OSX for most of the day (I do have a second machine dedicated > as a software router, a scanning station, and to use Propellerhead Reason :) > , but even that Mac is running OS 9. > > If it means Jack can accomplish more of what he wants to do, I'm in favor of > untying his hands. > > Bob > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Thu, 3 Jan 2002 18:33:39 -0500 (EST) > From: Steven Majewski > To: Jack Jansen > CC: pythonmac-sig@python.org > > Besides, there may be some advantages to moving the implementation > over to the new Carbon-events model. > > On Thu, 3 Jan 2002, I wrote: > > > > > That plan is OK by nme. > > ( 9.1 was so much more stable (IMHE) than anything that came before, > > that laziness is the only reason I still might have machines with > > 8.x. ) > > > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Thu, 3 Jan 2002 16:52:19 -0700 > From: Samuel Smith > To: pythonmac-sig@python.org > References: <20020103224658.A336DE8451@oratrix.oratrix.nl> > > >Folks, > >I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > >would save a lot of development effort. And there are a lot of things > >I'd like to do, for one thing I would like all our MacPython goodies > >to run natively in MachoPython by the time 2.3 is released. > > I have no plans to ever use System 8 in the future. > > > > >There are two drawbacks to this plan: > >1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the > >last release anyway), and on 8.6 you would need to manually install > >CarbonLib. > >2. Tkinter is going to be a problem, but I think it is a solvable > >problem (it is possible to load InterfaceLib-based code into a > >CarbonLib-based main program). > > I am hoping by then that wxPython-mac will be running > > > > >What do people think? > >-- > >Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > >Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > >www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ > > > >_______________________________________________ > >Pythonmac-SIG maillist - Pythonmac-SIG@python.org > >http://mail.python.org/mailman/listinfo/pythonmac-sig > > -- > ********************************************** > > Samuel M. Smith Ph.D. > > 360 W. 920 N. > Orem, Utah 84057 > > 801-226-7607 x112 (voice) > 801-226-7608 (fax) > http://www.samuelsmith.org (web) > > ********************************************* > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Thu, 3 Jan 2002 15:57:41 -0800 > From: Mark Day > To: Jack Jansen > CC: pythonmac-sig@python.org > > On Thursday, January 3, 2002, at 02:46 PM, Jack Jansen wrote: > > > Folks, > > I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > > would save a lot of development effort. And there are a lot of things > > I'd like to do, for one thing I would like all our MacPython goodies > > to run natively in MachoPython by the time 2.3 is released. > > If making MacPython Carbon-only increases the chances of integrating > MacPython and MachoPython, then I'm all for it. I'd really like to see > Python be able to take advantage of both traditional Mac (Carbon) and > Unix (simultaneously) on a Mac OS X system. > > > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the > > last release anyway), and on 8.6 you would need to manually install > > CarbonLib. > > In legacy installations, I think 8.6 is good enough these days. If the > minimum requirement was 9.x, that might be a bit more of a problem > (given the increased hardware demands of 9.x). There isn't a lot of > difference in the requirements between 8.5 and 8.6. But I don't know > how much the requirements change because of CarbonLib (eg., additional > RAM usage). > > In my wife's store, the machines all run 8.6. That's mostly because 8.6 > has a smaller RAM footprint, and those old machines are a pain to > upgrade. I think a Carbon-only MacPython would be fine. They *could* > be upgraded to 9.x if I really needed to. But it sounds like can put > off that kind of decision until sometime after MacPython 2.3 (at which > point I may have upgraded to newer machines anyway). > > For my own personal tinkering and general productivity enhancement, I > already run the latest Mac OS 9 and X anyway. > > -Mark > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] Installing numpy on mach-o python > Date: Thu, 03 Jan 2002 19:54:54 -0500 > From: Marcel Prastawa > To: Chris Lee > CC: Python > References: <7D214.9E3A.38124E.Nisus.ID@physics.otago.ac.nz> > > I don't know about the other two tests, but I think that it is > normal/expected that test_locale fails. IIRC, Mac OS X has weak locale > support. You probably don't need to worry too much about the failures, > unless you really need to use those modules. > > > Far worse I cannot run any scripts. I can start the interpreter and > > run commands from the command line but when I execute python myfile.py > > it starts and terminates without executing any code. So whats have I > > done now? > > Now this is odd... Do you not get any error messages or a stack trace? > Did you check your code for bugs? One thing you could do is sprinkle > some print statements in your code so you can tell what it is doing (or > not doing). Also keep in mind that Python does not automatically > echo/display the results of expressions when it executes a script file > (it does so in an interactive session). > > BTW, if you don't want to get hassled with building your own Python, you > should look into Fink: http://fink.sourceforge.net > I do not use it for (Mach-O) Python, but I have happily used it for many > other things. > There's also GNU-Darwin at http://gnu-darwin.sourceforge.net > > Marcel > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Thu, 3 Jan 2002 21:29:43 -0700 > From: Chris Lumsargis > To: Jack Jansen > CC: pythonmac-sig@python.org > > This is my first time to post on pythonmac-sig. I think your idea of > going Carbon-only is a good one. It would make developing for me a whole > lot simpler since most of my development tools either Cocoa or Carbon. > Additionally, anything to speed the development process up and make > things simpler for you is a boon of folks like me. > > Thanks, > > Chris Lumsargis > > On Thursday, January 3, 2002, at 03:46 PM, Jack Jansen wrote: > > > Folks, > > I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > > would save a lot of development effort. And there are a lot of things > > I'd like to do, for one thing I would like all our MacPython goodies > > to run natively in MachoPython by the time 2.3 is released. > > > > There are two drawbacks to this plan: > > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the > > last release anyway), and on 8.6 you would need to manually install > > CarbonLib. > > 2. Tkinter is going to be a problem, but I think it is a solvable > > problem (it is possible to load InterfaceLib-based code into a > > CarbonLib-based main program). > > > > What do people think? > > -- > > Jack Jansen | ++++ stop the execution of Mumia > > Abu-Jamal ++++ > > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your > > sig ++++ > > www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ > > > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > ------------------------------------------------------------------------ > > Subject: [Pythonmac-SIG] Project Build and native Cocoa > Date: Thu, 3 Jan 2002 23:08:01 -0800 > From: Patrick Curtain > To: pythonmac-sig@python.org > > Hey All! > > Please forgive what may very well be a silly question. Seems worth > asking, though. > > Is there any hope of making Python another language for developing Cocoa > applications? > > I just read about Apple's AppleScript Studio and I view the Interface > Builder / Project Builder as a nearly -killer- environment for > client-side development. If they can have pluggable development > languages supporting ObjC, Java and now AppleScript, with Perl on the > way (i understand), it seems possible to plug Python into that world. > > Can anyone with more knowledge about Cocoa development give an opinion? > > Thank You All! > --p > > Patrick Curtain, Husband & Father ( i also write software ) > - > - "Your site looks great, but does it DO anything?" > - Call SWDev to give your site the ACTIVE Edge. > - 503.781.6199 - http://www.swdev.com/info/corporate/ > > ------------------------------------------------------------------------ > > Subject: RE: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Fri, 04 Jan 2002 07:53:00 -0500 > From: "Schollnick, Benjamin" > To: "'Jack Jansen'" , pythonmac-sig@python.org > > Jack, > > Carbon Only is probably (??) a good thing. > > The only reason I can think of not being carbonized, is > to allow older hardware / OSes run the software... > But as you mentioned Python 2.2 is the last release > allowed for Mac OS 8.1. > > Since your placing that restriction, then it's probably > a good time to "sneak" this one in as well... > > Honestly, the Tkinter question is my only hesitation... > Tkinter has to be available, since that's the "native" > GUI platform for Python. > > (Native meaning it comes with the software, and it's > demoed with it.) > > > - Benjamin > > -----Original Message----- > From: Jack Jansen [mailto:jack@oratrix.nl] > Sent: Thursday, January 03, 2002 5:47 PM > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > > Folks, > I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > would save a lot of development effort. And there are a lot of things > I'd like to do, for one thing I would like all our MacPython goodies > to run natively in MachoPython by the time 2.3 is released. > > There are two drawbacks to this plan: > 1. MacPython wouldn't run on 8.5 anymore (for 8.1 MacPython 2.2 is the > last release anyway), and on 8.6 you would need to manually install > CarbonLib. > 2. Tkinter is going to be a problem, but I think it is a solvable > problem (it is possible to load InterfaceLib-based code into a > CarbonLib-based main program). > > What do people think? > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig > ++++ > www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Fri, 04 Jan 2002 08:22:29 -0500 > From: Jim Harrison > To: Jack Jansen > CC: pythonmac-sig@python.org > > on 1/3/02 5:46 PM, Jack Jansen at jack@oratrix.nl wrote: > > > I'm toying with the idea of making MacPython 2.3 Carbon-only, as this > > would save a lot of development effort. And there are a lot of things > > I'd like to do, for one thing I would like all our MacPython goodies > > to run natively in MachoPython by the time 2.3 is released. > > This would be fine with me and now is probably a good time to make the leap. > > Jim Harrison > Univ. of Pittsburgh > > ------------------------------------------------------------------------ > > Subject: RE: [Pythonmac-SIG] MacPython 2.3 - Carbon only? > Date: Fri, 4 Jan 2002 15:58:31 +0100 > From: Francois Granger > To: "Schollnick, Benjamin" , > "'Jack Jansen'" , pythonmac-sig@python.org > References: > > At 7:53 -0500 4/01/02, in message RE: [Pythonmac-SIG] MacPython 2.3 - > Carbon only?, Schollnick, Benjamin wrote: > > > > Honestly, the Tkinter question is my only hesitation... > > Tkinter has to be available, since that's the "native" > > GUI platform for Python. > > And the only still available. > > And I don't see wx available soon for Mac. From jack@oratrix.nl Tue Jan 8 22:42:35 2002 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 08 Jan 2002 23:42:35 +0100 Subject: [Pythonmac-SIG] Tkinter 8.3.4 for classic *and Carbon* MacPython Message-ID: <20020108224235.96D23E8451@oratrix.oratrix.nl> Ok lazy bones, as nobody jumped in I've finally taken the plunge and updated _tkinter to Tcl/Tk version 8.3.4. Moreover, I did one better and created an _tkinter.carbon.slb too, so MacPython in its Carbon version should now also be able to run Tkinter scripts. Everyone interested in Tk is expected to download this and try it with MacPython 2.2. I've built it with 2.2+ but I'm 99% sure it should work with 2.2 (but be sure to make a backup of your old _tkinter.ppc.slb in case it doesn't work). Download the new plugin modules from http://www.cwi.nl/~jack/python/mac/newer, and drop them in :Lib:lib-dynload. One known problem: I don't see a mouse cursor when running under Carbon MacPython (ppc MacPython is ok). cmd-tab back and forth to another program to know where your mouse is:-) Suggestions as to what could be going on are welcome. Another known problem: file event handlers still don't work, and will never work. If the situation has gotten worse here than with the previous _tkinter I would like to know about it (I took out the workaround code, which I think was non-functional anyway since Tk 8). Yet another known problem: this doesn't work under OSX, and it never will. The Carbon version isn't really Carbon, it's classic but it is linked in such a way that it can function in a Carbon MacPython on OS9. And a question: I didn't include the Tk-specific MDEF. This also wasn't included in the previous _tkinter. Are people seeing strange behaviour with menus? Should I see what happens if I include 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 lmeyn@mail.arc.nasa.gov Tue Jan 8 23:36:27 2002 From: lmeyn@mail.arc.nasa.gov (Larry Meyn) Date: Tue, 8 Jan 2002 15:36:27 -0800 Subject: [Pythonmac-SIG] Tkinter 8.3.4 for classic *and Carbon* MacPython In-Reply-To: <20020108224235.96D23E8451@oratrix.oratrix.nl> References: <20020108224235.96D23E8451@oratrix.oratrix.nl> Message-ID: --============_-1201589505==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Jack, I tried running a demo that works fine with the previous libraries, but got the following traceback with the new libraries. TCL 8.3.4 is installed. Larry Traceback (most recent call last): File "Macintosh HD:Programming:Python:Python 2.2:Demo:tkinter:guido:hanoi.py", line 154, in ? main() File "Macintosh HD:Programming:Python:Python 2.2:Demo:tkinter:guido:hanoi.py", line 146, in main h = Tkhanoi(n, bitmap) File "Macintosh HD:Programming:Python:Python 2.2:Demo:tkinter:guido:hanoi.py", line 31, in __init__ self.tk = tk = Tk() File "Macintosh HD:Programming:Python:Python 2.2:Lib:lib-tk:Tkinter.py", line 1487, in __init__ self.tk = _tkinter.create(screenName, baseName, className) TclError: can't find Init resource or a usable Init.tcl file in the following directories: {Macintosh HD:System Folder:Extensions:Tool Command Language:tcl8.3} perhaps you need to install Tcl or set your TCL_LIBRARY environment variable? -- ---------------------------------------------------------------------- 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 email: lmeyn@mail.arc.nasa.gov E-FAX: (425) 944-5526 sent via e-mail ---------------------------------------------------------------------- --============_-1201589505==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Pythonmac-SIG] Tkinter 8.3.4 for classic *and Car
Jack,

I tried running a demo that works fine with the previous libraries, but got the following traceback with the new libraries.  TCL 8.3.4 is installed.

Larry


Traceback (most recent call last):
  File "Macintosh HD:Programming:Python:Python 2.2:Demo:tkinter:guido:hanoi.py", line 154, in ?
    main()
  File "Macintosh HD:Programming:Python:Python 2.2:Demo:tkinter:guido:hanoi.py", line 146, in main
    h = Tkhanoi(n, bitmap)
  File "Macintosh HD:Programming:Python:Python 2.2:Demo:tkinter:guido:hanoi.py", line 31, in __init__
    self.tk = tk = Tk()
  File "Macintosh HD:Programming:Python:Python 2.2:Lib:lib-tk:Tkinter.py", line 1487, in __init__
    self.tk = _tkinter.create(screenName, baseName, className)
TclError: can't find Init resource or a usable Init.tcl file
in the following directories:
    {Macintosh HD:System Folder:Extensions:Tool Command Language:tcl8.3}
 perhaps you need to install Tcl or set your
TCL_LIBRARY environment variable?
--
----------------------------------------------------------------------
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    email:  lmeyn@mail.arc.nasa.gov
                                E-FAX:  (425) 944-5526 sent via e-mail
----------------------------------------------------------------------
--============_-1201589505==_ma============-- From altis@semi-retired.com Tue Jan 8 23:49:30 2002 From: altis@semi-retired.com (Kevin Altis) Date: Tue, 8 Jan 2002 15:49:30 -0800 Subject: [Pythonmac-SIG] RE: [Pythoncard-users] running python/wxpython on the Mac with emulation? In-Reply-To: Message-ID: I only got two replies to my post, but if I get any more I'll email another follow-up. Dan Shafer confirmed that VirtualPC works fine (as one would expect), he even used an old version, 3.0 on his Mac. This is a Windows Python/wxPython emulation solution. Pim Buurman responded with this GTK solution under OS X: My "solution" for using wx on Mac OS X: - I installed the XFree X-server and X-prog packages - Then I compiled gtk - Then I compiled wxGTK 2.3.2 - Then I compiled python (terminal version, i.e. plain UNIX version) - Then I compiled wxPython with this python I now have a command-line python, with which I can run any wxPython app This is actually very interesting to me for testing purposes because it looks like I could have an OS X box and test both wxPython Mac and wxPython GTK on that machine once wxPython Mac is available. I'm looking forward to hearing from other people using wxPython via emulation on the Mac. ka > -----Original Message----- > From: pythoncard-users-admin@lists.sourceforge.net > [mailto:pythoncard-users-admin@lists.sourceforge.net]On Behalf Of Kevin > Altis > Sent: Monday, January 07, 2002 12:55 PM > To: Wxpython-Users; pythonmac-sig@python.org; pythoncard-Users > Subject: [Pythoncard-users] running python/wxpython on the Mac with > emulation? > > > Note, if you send me a reply directly, I can post a summary to the lists. > > I don't currently use a Mac (the old Performa I have with System 7.5 isn't > really that usable), but there are quite a few people interested in the > PythonCard project that only use Macs, so they are waiting for > wxPython Mac > to be finished. > > What I'm wondering is whether any of the free or commercial emulation > solutions would be good substitutes until wxPython Mac is > available for use > with MacPython? Basically, they would just run a version of Python and > wxPython (win32 or GTK) for either Windows or Linux depending on the > emulation solution. > > Is anyone already doing this on their Macs? Either OS classic or OS X? If > so, could you provide details of the configuration and installation or any > tricky parts of getting it to work? > > Some possibilities: > > VirtualPC > http://www.connectix.com/products/vpc5m.html > > Bochs > http://bochs.sourceforge.net/ > > VMWare > http://www.vmware.com/ > > plex86 > http://www.plex86.org/ > > XFree86 > http://www.xfree86.org/ > I had one person suggest "Just use wxGTK under Xfree86 in > rootless mode..." > on OS X. > > Thanks, > > ka > --- > Kevin Altis > altis@semi-retired.com > > > _______________________________________________ > Pythoncard-users mailing list > Pythoncard-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > From jack@oratrix.nl Wed Jan 9 09:51:53 2002 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 09 Jan 2002 10:51:53 +0100 Subject: [Pythonmac-SIG] Tkinter 8.3.4 for classic *and Carbon* MacPython In-Reply-To: Message by Larry Meyn , Tue, 8 Jan 2002 15:36:27 -0800 , Message-ID: <20020109095153.49211E8451@oratrix.oratrix.nl> > 2.2:Lib:lib-tk:Tkinter.py", line 1487, in __init__ > self.tk = _tkinter.create(screenName, baseName, className) > TclError: can't find Init resource or a usable Init.tcl file > in the following directories: > {Macintosh HD:System Folder:Extensions:Tool Command Language:tcl8.3} > perhaps you need to install Tcl or set your > TCL_LIBRARY environment variable? Strange: init.tcl should be incorporated as a resource in the .slb (just as for previous versions of _tkinter). Is anyone else seeing this? Everyone else but me? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From fgranger@altern.org Wed Jan 9 13:16:44 2002 From: fgranger@altern.org (Francois Granger) Date: Wed, 09 Jan 2002 14:16:44 +0100 Subject: [Pythonmac-SIG] Tkinter 8.3.4 for classic *and Carbon* MacPython In-Reply-To: <20020108224235.96D23E8451@oratrix.oratrix.nl> Message-ID: on 8/01/02 23:42, Jack Jansen at jack@oratrix.nl wrote: > Download the new plugin modules from > http://www.cwi.nl/~jack/python/mac/newer, I got an errror message at this URL, and found it at: http://www.cwi.nl/ftp/jack/python/mac/newer/ Or ftp://ftp.cwi.nl/pub/jack/python/mac/newer/ From fgranger@altern.org Wed Jan 9 14:36:35 2002 From: fgranger@altern.org (Francois Granger) Date: Wed, 09 Jan 2002 15:36:35 +0100 Subject: [Pythonmac-SIG] Tkinter 8.3.4 for classic *and Carbon* MacPython In-Reply-To: Message-ID: on 9/01/02 0:36, Larry Meyn at lmeyn@mail.arc.nasa.gov wrote: Same here, see below >=20 > Traceback (most recent call last): > File "Macintosh HD:Programming:Python:Python > 2.2:Demo:tkinter:guido:hanoi.py", line 154, in ? > main() > File "Macintosh HD:Programming:Python:Python > 2.2:Demo:tkinter:guido:hanoi.py", line 146, in main > h =3D Tkhanoi(n, bitmap) > File "Macintosh HD:Programming:Python:Python > 2.2:Demo:tkinter:guido:hanoi.py", line 31, in __init__ > self.tk =3D tk =3D Tk() > File "Macintosh HD:Programming:Python:Python > 2.2:Lib:lib-tk:Tkinter.py", line 1487, in __init__ > self.tk =3D _tkinter.create(screenName, baseName, className) > TclError: can't find Init resource or a usable Init.tcl file > in the following directories: > {Macintosh HD:System Folder:Extensions:Tool Command Language:tcl8.3} > perhaps you need to install Tcl or set your > TCL_LIBRARY environment variable? MacOS FU1 9.0.4 on G4 Cube Python 2.2 fresh install Your patch installed. I get the same: Traceback (most recent call last): File "Macintosh HD:Desktop Folder:anygui-0.1b1:test:test_button.py", line 4, in ? app =3D Application() File "Macintosh HD:Python 2.2:Lib:anygui:backends:tkgui.py", line 574, in __init__ self._root =3D Tk() File "Macintosh HD:Python 2.2:Lib:lib-tk:Tkinter.py", line 1487, in __init__ self.tk =3D _tkinter.create(screenName, baseName, className) TclError: can't find Init resource or a usable Init.tcl file in the following directories: {Macintosh HD:Dossier Syst=E8me:Extensions:Tool Command Language:tcl8.3} perhaps you need to install Tcl or set your TCL_LIBRARY environment variable? From jack@oratrix.nl Wed Jan 9 14:44:25 2002 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 09 Jan 2002 15:44:25 +0100 Subject: [Pythonmac-SIG] Tkinter 8.3.4 for classic *and Carbon* MacPython In-Reply-To: Message by Francois Granger , Wed, 09 Jan 2002 14:16:44 +0100 , Message-ID: <20020109144425.A4E2EE8451@oratrix.oratrix.nl> Absolutely right! Sorry for the confusion... > I got an errror message at this URL, and found it at: > > http://www.cwi.nl/ftp/jack/python/mac/newer/ > > Or > > ftp://ftp.cwi.nl/pub/jack/python/mac/newer/ > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From blacktrash@gmx.net Wed Jan 9 17:09:54 2002 From: blacktrash@gmx.net (Christian Ebert) Date: Wed, 9 Jan 2002 18:09:54 +0100 Subject: [Pythonmac-SIG] Tkinter 8.3.4 for classic *and Carbon* MacPython In-Reply-To: <20020109095153.49211E8451@oratrix.oratrix.nl> Message-ID: <20020109181013-r01010800-0f67d9b6-0922-0108@217.0.172.169> Jack Jansen at 10:51 on Wednesday, January 9, 2002: > Is anyone else seeing this? Traceback (most recent call last): File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Scripts:test_tk.py", line 4, in ? tk = Tkinter.Tk() File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Lib:lib-tk:Tkinter.py", line 1487, in __init__ self.tk = _tkinter.create(screenName, baseName, className) TclError: can't find Init resource or a usable Init.tcl file in the following directories: {Christians PB HD:Systemordner:Systemerweiterungen:Tool Command Language:tcl8.3} perhaps you need to install Tcl or set your TCL_LIBRARY environment variable? > Everyone else but me? -- Marlon Brando, Pocahontas and me (Neil Young, Rust Never Sleeps) From owen@astro.washington.edu Wed Jan 9 19:23:14 2002 From: owen@astro.washington.edu (Russell E Owen) Date: Wed, 9 Jan 2002 11:23:14 -0800 Subject: [Pythonmac-SIG] Installing unix Python on OS X...a few details wanted Message-ID: christopher ariza wrote (in regards to getting Tkinter fully working on Macs): >get MacOSX >install Fink: http://sourceforge.net/projects/fink/ > >with Fink, you can easily (did i say easily? i meant very very easily) install Xfree86, XDarwin, Python, and Tk. this is done all in a different directory (/sw), so your system is not changed at all. once this is up, you can run Tkinter in Python from Xwindows just as if it were any unix, without a single problem. you can have multiple instances of Tk, Pmw works, the Grayson examples work, all without any hassle. did i say it was easy? Sounds great. So I bought Mac OS X and installed it (ugh; did you know FileMaker Pro 4 doesn't run in Classic?). Anyway, I installed Fink and used it to install: - Xfree86-base - Xfree86-root (the rootless server; there was no option in "sudo dselect" for the Xfree86-server, the allegedly-more-stable rooted server). This shows up as XDarwin in applications, so I think I'm on the right track. But now I have a few questions before I mess things up: - Which python should I use? Fink offers one that explicitly excludes X, which sounds suspicious. So I should use the standard unix distribution? Or perhaps a command-line version of fink to get source? - I already have tcl and tk on my Mac in System:Library:Tcl. So should I also install the fink version or should I skip that and hope Python can find it (or configure it to do so)? I don't see obvious signs of shared libraries, which suggests using fink. -- Russell From jack@oratrix.nl Wed Jan 9 22:26:35 2002 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 09 Jan 2002 23:26:35 +0100 Subject: [Pythonmac-SIG] Installing unix Python on OS X...a few details wanted In-Reply-To: Message by Russell E Owen , Wed, 9 Jan 2002 11:23:14 -0800 , Message-ID: <20020109222640.E096AE8451@oratrix.oratrix.nl> Educated guesses: > - Which python should I use? Fink offers one that explicitly excludes X, whic > h sounds suspicious. So I should use the standard unix distribution? Or perha > ps a command-line version of fink to get source? The X-based Tcl/Tk doesn't need X support in Python. So the version fink offers is probably fine. > - I already have tcl and tk on my Mac in System:Library:Tcl. So should I also > install the fink version or should I skip that and hope Python can find it ( > or configure it to do so)? I think the latter. -- - 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 Wed Jan 9 22:49:30 2002 From: bob@redivi.com (Bob Ippolito) Date: Wed, 9 Jan 2002 17:49:30 -0500 Subject: [Pythonmac-SIG] Installing unix Python on OS X...a few details wanted In-Reply-To: <20020109222640.E096AE8451@oratrix.oratrix.nl> Message-ID: <2474EEF2-0553-11D6-A353-003065A10F5A@redivi.com> FYI, I was successful in building Tkinter for OS X without using X11 at all. It seems to work pretty well, but only if you start python as an application bundle (i.e. by the finder or with "open"). The only caveat really is that you can only have one python interpreter running at a time.. Eventually I'm sure this problem will be solved, but would certainly require some clever hacking in macmain.c I have a binary version of the package (python + tcl + tk + tkinter and some other goodies) at http://redivi.com/~bob/ If you want to do it yourself, build Tcl and Tk (get both from CVS, as they have aqua support) as frameworks and install to /Library/Frameworks/ (may need to sudo for this or edit a configure script). ~/Library/Frameworks/ may work as well, but I didn't try any of that as there is more than one user of this computer. Python should also be built as a framework and I very highly recommend getting libcompat from darwin CVS and hacking python's configure script to use libdl instead of dynload_next as dynload_next has serious issues and will get in your way at some point. You should also mkdir /usr/local/include/X11 and copy the .h files that are included in Xlib/X11 in the Tk source tree, Tk's headers depend on X11 headers and the X11 headers don't get put into the Tk framework. I didn't really have time to mess with Python's Modules/Setup file but here are some manual compile commands that should work for you as well, may have to change paths, and you'll probably have to sudo to do the last line if you haven't done any chmodding to the python framework as I did to make it easier on myself. I'm not quite sure why Tcl and Tk use PrivateHeaders when applications depend on them to compile? cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -fno-common -dynamic -Ddarwin -DTK_FRAMEWORK -DTK_AQUA -DMAC_OSX_TK -F/Library/Frameworks/Python.framework -I/Library/Frameworks/Python.framework/Headers -F/Library/Frameworks/Tcl.framework -I/Library/Frameworks/Tcl.framework/Headers -F/Library/Frameworks/Tk.framework -I/Library/Frameworks/Tk.framework/Headers -I/usr/local/include -I/Library/Frameworks/Tk.framework/PrivateHeaders -I/Library/Frameworks/Tcl.framework/PrivateHeaders -c _tkinter.c -o _tkinter.o cc -Wl,-F. -Wl,-flat_namespace,-U,_environ -bundle -framework Python -framework Tk -framework Tcl _tkinter.o -o _tkinter.so -undefined suppress cp _tkinter.so /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/lib-tk/ -bob On Wednesday, January 9, 2002, at 05:26 PM, Jack Jansen wrote: > Educated guesses: > >> - Which python should I use? Fink offers one that explicitly excludes >> X, whic >> h sounds suspicious. So I should use the standard unix distribution? >> Or perha >> ps a command-line version of fink to get source? > > The X-based Tcl/Tk doesn't need X support in Python. So the version > fink offers is probably fine. > >> - I already have tcl and tk on my Mac in System:Library:Tcl. So should >> I also >> install the fink version or should I skip that and hope Python can >> find it ( >> or configure it to do so)? > > I think the latter. > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From owen@astro.washington.edu Thu Jan 10 01:35:27 2002 From: owen@astro.washington.edu (Russell E Owen) Date: Wed, 9 Jan 2002 17:35:27 -0800 Subject: [Pythonmac-SIG] Progress report: unix python on Mac OS X Message-ID: I used fink to install the source version of python, to give it maximum odds of building all optional packages. This was version 2.1.1. It ran just fine and Tkinter, etc. clearly work. Unfortunately, I have not yet figured out how to get a working X server. The fink versions crash for me (the rootless crashes twm at startup. sometimes leaving usable-but-unmovable windows, sometimes leaving nothing). I'm less sure what's wrong with the "more stable but older" rooted version. I have not yet tried rebooting the Mac. I also am trying the eXodus 8 demo, but have run into different problems there (figuring out how to get my Mac to see it; setting DISPLAY to localhost:0.0 didn't do it). Also, amusingly enough, fink now has python 2.2 binary available, supposedly with all optional packages built. Unfortunately, it requires "gmp", which fink doesn't have available (nor do I know what it is; I suppose it might even be a misspelling of some other package, such as "gimp"). Anyway, it's not perfect, but overall I'm pretty impressed with fink. Also Mac OS X is rough in places (keyboard navigation in the open dialogs is disgusting and some modern apps crash and some older ones will not run in Classic at all), but overall it seems OK, and the enhanced multitasking is very nice. -- Russell From cameron.lewis@mail.com Thu Jan 10 10:32:34 2002 From: cameron.lewis@mail.com (Cameron Lewis) Date: Thu, 10 Jan 2002 21:32:34 +1100 Subject: [Pythonmac-SIG] Tkinter 8.3.4 for classic *and Carbon* Message-ID: Works for my simple tkinter app with exception of the pointer cursor as described. Note that when the cursor is moved over a text entry widget the text entry cursor DOES appear. Python 2.2 Mac OS 9.1 From Benjamin.Schollnick@usa.xerox.com Thu Jan 10 18:05:25 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Thu, 10 Jan 2002 13:05:25 -0500 Subject: [Pythonmac-SIG] Webbrowser module? Message-ID: I just sat down and attempted to use the webbrowser module on my Mac... And failed... I've got the internet control panel configured right... (Pointing to the right browser)... But webbrowser.open ("http://www.yahoo.com") returns a trace & english text of "cannot locate runnable browser". On the PC side, it works, so I'm assuming it's a configuration issue with my mac, or one of the control panels? Anyone have any hints? - Benjamin From jack@oratrix.nl Thu Jan 10 21:57:28 2002 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 10 Jan 2002 22:57:28 +0100 Subject: [Pythonmac-SIG] Webbrowser module? In-Reply-To: Message by "Schollnick, Benjamin" , Thu, 10 Jan 2002 13:05:25 -0500 , Message-ID: <20020110215733.F1F27E8451@oratrix.oratrix.nl> Recently, "Schollnick, Benjamin" said: > I just sat down and attempted to use the webbrowser module > on my Mac... And failed... > > I've got the internet control panel configured right... > (Pointing to the right browser)... > > But > > webbrowser.open ("http://www.yahoo.com") > > returns a trace & english text of "cannot locate runnable browser". MacPython or MachoPython? Which version? Which OS? Could you send the stacktrace? -- - 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@oratrix.nl Thu Jan 10 21:58:37 2002 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 10 Jan 2002 22:58:37 +0100 Subject: [Pythonmac-SIG] Progress report: unix python on Mac OS X In-Reply-To: Message by Russell E Owen , Wed, 9 Jan 2002 17:35:27 -0800 , Message-ID: <20020110215842.ADCD4E8452@oratrix.oratrix.nl> I can answer only one: > Also, amusingly enough, fink now has python 2.2 binary available, supposedly > with all optional packages built. Unfortunately, it requires "gmp", which fin > k doesn't have available (nor do I know what it is; I suppose it might even b > e a misspelling of some other package, such as "gimp"). I think this is the GNU Multiple Precision library or some such. It's probably used for encryption modules 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 jack@oratrix.nl Thu Jan 10 22:02:57 2002 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 10 Jan 2002 23:02:57 +0100 Subject: [Pythonmac-SIG] Tkinter - the saga continues Message-ID: <20020110220257.70612E8451@oratrix.oratrix.nl> Folks, some people out on the MacTcl list provided some help, and I can get the resource-based scheme to work for Tkinter with some effort, apparently. But another problem is that the Tcl/Tk in this Tkinter will then not have access to the various character encodings, only utf8 and latin-1 will be available (MacRoman is most notably absent). My question now is, what would people prefer: - A Tkinter that is fully functional, but requires you to download a separate Tcl/Tk distribution, or - A Tkinter that works out of the box, but may not be fully functional. Please let me know soon, as the two development paths diverge quickly. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From smithsm@samuelsmith.org Thu Jan 10 22:17:44 2002 From: smithsm@samuelsmith.org (Samuel Smith) Date: Thu, 10 Jan 2002 15:17:44 -0700 Subject: [Pythonmac-SIG] Tkinter - the saga continues In-Reply-To: <20020110220257.70612E8451@oratrix.oratrix.nl> References: <20020110220257.70612E8451@oratrix.oratrix.nl> Message-ID: > >My question now is, what would people prefer: >- A Tkinter that is fully functional, but requires you to download a >separate Tcl/Tk distribution, or >- A Tkinter that works out of the box, but may not be fully >functional. Fully functional with explicit direction for downloading separate distribution. >Please let me know soon, as the two development paths diverge >quickly. >-- >- Jack Jansen >http://www.cwi.nl/~jack - >- If I can't dance I don't want to be part of your revolution -- >Emma Goldman - > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ********************************************** Samuel M. Smith Ph.D. 360 W. 920 N. Orem, Utah 84057 801-226-7607 x112 (voice) 801-226-7608 (fax) http://www.samuelsmith.org (web) ********************************************* From owen@astro.washington.edu Thu Jan 10 22:52:26 2002 From: owen@astro.washington.edu (Russell E Owen) Date: Thu, 10 Jan 2002 14:52:26 -0800 Subject: [Pythonmac-SIG] Progress report: unix python on Mac OS X In-Reply-To: <20020110215842.ADCD4E8452@oratrix.oratrix.nl> References: <20020110215842.ADCD4E8452@oratrix.oratrix.nl> Message-ID: At 10:58 PM +0100 1/10/02, Jack Jansen wrote: >I can answer only one: > >> Also, amusingly enough, fink now has python 2.2 binary available, supposedly >> with all optional packages built. Unfortunately, it requires "gmp", which fin >> k doesn't have available (nor do I know what it is; I suppose it might even b >> e a misspelling of some other package, such as "gimp"). > >I think this is the GNU Multiple Precision library or some such. It's >probably used for encryption modules or some such. You were right, thanks! It turns out fink can find it using "fink install gmp". I'm not sure why it didn't show up in the list of known source or binary packages. Anyway, installing it allowed the full python 2.2 installation to proceed and it works fine. One quirk is that "inf' and "nan" do not work. On MacPython and Solaris (Python versions 2.1.1) you can do things like: >>>a = float("NaN") >>>a nan and use that value in comparisons and such. On the unix installation of Python 2.2 on Mac OS X float("NaN") raises an exception. Oh well...IEEE handling has never been claimed to work in Python, though I hope that will change someday. So far everything seems to work great (except my x server, and I'm working on that). Much thanks to Jack Jansen and all others who made the unix version of Python compatible with Mac OS X! If you go this route, consider upgrading to BBEdit 6.5, since it allows one to run Python scripts from the editor. (I'm hoping Pepper eventually gets there, as well.) Regards, -- Russell P.S. fink selfupdate fails (in version 0.3.1) due to a minor bug in a perl script; if you run into this, I'll be happy to send you the fix. From prastawa@cs.unc.edu Fri Jan 11 02:56:51 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Thu, 10 Jan 2002 21:56:51 -0500 Subject: [Pythonmac-SIG] Progress report: unix python on Mac OS X References: <20020110215842.ADCD4E8452@oratrix.oratrix.nl> Message-ID: <3C3E5473.5010204@cs.unc.edu> Russell E Owen wrote: > You were right, thanks! It turns out fink can find it using "fink > install gmp". I'm not sure why it didn't show up in the list of known > source or binary packages. Anyway, installing it allowed the full > python 2.2 installation to proceed and it works fine. A quick note on Fink: Fink has two package classifications: stable and unstable. You need to build the unstable packages from the source. See http://fink.sourceforge.net/faq/usage-fink.php#bindist Could you send me the fix for Fink? I want to minimize my exposure to Perl... :) Marcel From prastawa@cs.unc.edu Fri Jan 11 03:00:29 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Thu, 10 Jan 2002 22:00:29 -0500 Subject: [Pythonmac-SIG] Tkinter - the saga continues References: <20020110220257.70612E8451@oratrix.oratrix.nl> Message-ID: <3C3E554D.2000303@cs.unc.edu> Jack Jansen wrote: > My question now is, what would people prefer: > - A Tkinter that is fully functional, but requires you to download a > separate Tcl/Tk distribution, or > - A Tkinter that works out of the box, but may not be fully > functional. I wouldn't mind downloading Tkinter separately. Marcel From chrisl@fone.net Fri Jan 11 03:58:20 2002 From: chrisl@fone.net (Chris Lumsargis) Date: Thu, 10 Jan 2002 20:58:20 -0700 Subject: [Pythonmac-SIG] Tkinter - the saga continues In-Reply-To: <20020110220257.70612E8451@oratrix.oratrix.nl> References: <20020110220257.70612E8451@oratrix.oratrix.nl> Message-ID: I think a fully functional Tkinter would be best. The complete download is a minor inconvenience. Thanks, Chris Lumsargis >Folks, >some people out on the MacTcl list provided some help, and I can get >the resource-based scheme to work for Tkinter with some effort, >apparently. But another problem is that the Tcl/Tk in this Tkinter >will then not have access to the various character encodings, only >utf8 and latin-1 will be available (MacRoman is most notably absent). > >My question now is, what would people prefer: >- A Tkinter that is fully functional, but requires you to download a >separate Tcl/Tk distribution, or >- A Tkinter that works out of the box, but may not be fully >functional. > >Please let me know soon, as the two development paths diverge >quickly. >-- >- Jack Jansen >http://www.cwi.nl/~jack - >- If I can't dance I don't want to be part of your revolution -- >Emma Goldman - > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- From sburr@home.com Fri Jan 11 04:52:04 2002 From: sburr@home.com (Steven Burr) Date: Thu, 10 Jan 2002 21:52:04 -0700 Subject: [Pythonmac-SIG] Progress report: unix python on Mac OS X In-Reply-To: <3C3E5473.5010204@cs.unc.edu> Message-ID: On Thursday, January 10, 2002, at 07:56 PM, Marcel Prastawa wrote: > Russell E Owen wrote: > > You were right, thanks! It turns out fink can find it using "fink > > install gmp". I'm not sure why it didn't show up in the list of known > > source or binary packages. Anyway, installing it allowed the full > > python 2.2 installation to proceed and it works fine. > > A quick note on Fink: Fink has two package classifications: stable and > unstable. You need to build the unstable packages from the source. > See http://fink.sourceforge.net/faq/usage-fink.php#bindist > > Could you send me the fix for Fink? I want to minimize my exposure to > Perl... :) If you mean a fix for python 2.2, it really shouldn't be necessary. The gmp package is in stable: 21:42:21 $ ls /sw/fink/dists/stable/main/finkinfo/libs/gmp* /sw/fink/dists/stable/main/finkinfo/libs/gmp-3.1.1-2.info It's listed as a dependency in the python 2.2 info file, so when you do "fink install python," fink will ask if you want gmp (and any other dependencies you don't already have) installed as well. It worked for me. From sburr@home.com Fri Jan 11 06:37:59 2002 From: sburr@home.com (Steven Burr) Date: Thu, 10 Jan 2002 23:37:59 -0700 Subject: [Pythonmac-SIG] Webbrowser module? In-Reply-To: <20020110215733.F1F27E8451@oratrix.oratrix.nl> Message-ID: On Thursday, January 10, 2002, at 02:57 PM, Jack Jansen wrote: > > Recently, "Schollnick, Benjamin" > said: >> I just sat down and attempted to use the webbrowser module >> on my Mac... And failed... >> >> I've got the internet control panel configured right... >> (Pointing to the right browser)... >> >> But >> >> webbrowser.open ("http://www.yahoo.com") >> >> returns a trace & english text of "cannot locate runnable browser". > > MacPython or MachoPython? Which version? Which OS? Could you send the > stacktrace? I suspect Benjamin is referring to webbrowser on MachoPython. The InternetConfig class doesn't work for MachoPython. When I tried using webbrowser from python running in a Terminal, it opened the url in lynx. If I hadn't had lynx installed, I'm certain I would have gotten the "cannot locate runnable browser" message as well. I have actually been trying to come up with a patch to webbrowser that would allow it to open a url in an Aqua browser while running in MachoPython and finally found something that works. It's a very simple patch that uses the osascript command (i.e. AppleScript from the command line) to open the url in Internet Explorer. I patched my lib/python2.2/ copy of webbrowser, and it worked fine. The patch could be extended to accept other browsers that are scriptable in Apple Script. A default priority list of browsers could be established as it has for other Unices. If you think this would be worthwhile, I'd be happy to work on adding that functionality. I noticed that you had an assignment to add IC support for MachoPython. If that's not working out, perhaps you could use my patch as an alternative. I've submitted the patch to SourceForge. This time I used OmniWeb instead of IE to submit, and I think that solved the file format problem you and Guido encountered with my other patch. From ack@nethere.com Fri Jan 11 06:45:58 2002 From: ack@nethere.com (Michael Ackerman) Date: Thu, 10 Jan 2002 22:45:58 -0800 Subject: [Pythonmac-SIG] Installing unix Python on OS X...a few details wanted References: <2474EEF2-0553-11D6-A353-003065A10F5A@redivi.com> Message-ID: <3C3E8A26.AED18221@nethere.com> I've installed your binaries; they seem to work perfectly. Thanks very much for making available such a comprehensive package! Michael Ackerman Bob Ippolito wrote: > > FYI, I was successful in building Tkinter for OS X without using X11 at > all. It seems to work pretty well, but only if you start python as an > application bundle (i.e. by the finder or with "open"). The only caveat > really is that you can only have one python interpreter running at a > time.. Eventually I'm sure this problem will be solved, but would > certainly require some clever hacking in macmain.c > > I have a binary version of the package (python + tcl + tk + tkinter and > some other goodies) at http://redivi.com/~bob/ ... From alexp@strata.com Fri Jan 11 05:00:39 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Thu, 10 Jan 2002 21:00:39 -0800 Subject: [Pythonmac-SIG] [Ann] MacCvs 3.2b9 is out, using MacPython 2.2 Message-ID: <001c01c19a5c$f7896550$0400a8c0@veropc> - Ton of OSX work - Better ssh (thanks Jean-Pierre) - Python macros using MacPython 2.2 : be careful, MacPython 2.2 doesn't work well on OSX yet especially on SMP machines, but using MacPython is optional with MacCvs. However a fix has been submitted and next version of 2.2 should fix the problem. - Added a ISO-8559 support for MacCvsPro http://sourceforge.net/project/showfiles.php?group_id=10072&release_id=69387 Special thanks to Jack for this release. From jack@oratrix.nl Fri Jan 11 09:27:14 2002 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 11 Jan 2002 10:27:14 +0100 Subject: [Pythonmac-SIG] Webbrowser module? In-Reply-To: Message by Steven Burr , Thu, 10 Jan 2002 23:37:59 -0700 , Message-ID: <20020111092719.EB3E7E8451@oratrix.oratrix.nl> Recently, Steven Burr said: > On Thursday, January 10, 2002, at 02:57 PM, Jack Jansen wrote: > > > > > Recently, "Schollnick, Benjamin" > > said: > >> I just sat down and attempted to use the webbrowser module > >> on my Mac... And failed... > >> > >> I've got the internet control panel configured right... > >> (Pointing to the right browser)... > >> > >> But > >> > >> webbrowser.open ("http://www.yahoo.com") > >> > >> returns a trace & english text of "cannot locate runnable browser". > > > > MacPython or MachoPython? Which version? Which OS? Could you send the > > stacktrace? > > I suspect Benjamin is referring to webbrowser on MachoPython. The > InternetConfig class doesn't work for MachoPython. When I tried using > webbrowser from python running in a Terminal, it opened the url in > lynx. If I hadn't had lynx installed, I'm certain I would have gotten > the "cannot locate runnable browser" message as well. I have a bugfix request for myself in sourceforge to enable the use of Internet Config in MachoPython, but I haven't started on implementing it yet. The IC module is available under MachoPython, but I think it would also require LaunchServices, which isn't available yet. > I have actually been trying to come up with a patch to webbrowser that > would allow it to open a url in an Aqua browser while running in > MachoPython and finally found something that works. It's a very simple > patch that uses the osascript command (i.e. AppleScript from the command > line) to open the url in Internet Explorer. This sounds like a nice stopgap. Could you try adding the IC stuff so that it really opens the users' default browser? This shouldn't be too difficult, mainly combining stuff from the classic MacPython webbrowser code with your osascript code. One thing, though: what will happen if you run this when you don't have access to the window server? I.e. when you're on Mac OS X Server, or when you're in an ssh session to an OSX machine where you ar enot logged in on the console? Doing a Carbon call in such circumstances will crash Python, and that probably isn't acceptable... -- - 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 Fri Jan 11 12:25:20 2002 From: bob@redivi.com (Bob Ippolito) Date: Fri, 11 Jan 2002 07:25:20 -0500 Subject: [Pythonmac-SIG] Webbrowser module? In-Reply-To: <20020111092719.EB3E7E8451@oratrix.oratrix.nl> Message-ID: <477A1C8C-068E-11D6-BE94-0003938210D6@redivi.com> On Friday, January 11, 2002, at 04:27 AM, Jack Jansen wrote: > > Recently, Steven Burr said: >> On Thursday, January 10, 2002, at 02:57 PM, Jack Jansen wrote: >> >>> >>> Recently, "Schollnick, Benjamin" >>> said: >>>> I just sat down and attempted to use the webbrowser module >>>> on my Mac... And failed... >>>> >>>> I've got the internet control panel configured right... >>>> (Pointing to the right browser)... >>>> >>>> But >>>> >>>> webbrowser.open ("http://www.yahoo.com") >>>> >>>> returns a trace & english text of "cannot locate runnable browser". >>> >>> MacPython or MachoPython? Which version? Which OS? Could you send the >>> stacktrace? >> >> I suspect Benjamin is referring to webbrowser on MachoPython. The >> InternetConfig class doesn't work for MachoPython. When I tried using >> webbrowser from python running in a Terminal, it opened the url in >> lynx. If I hadn't had lynx installed, I'm certain I would have gotten >> the "cannot locate runnable browser" message as well. > > I have a bugfix request for myself in sourceforge to enable the use of > Internet Config in MachoPython, but I haven't started on implementing > it yet. The IC module is available under MachoPython, but I think it > would also require LaunchServices, which isn't available yet. > >> I have actually been trying to come up with a patch to webbrowser that >> would allow it to open a url in an Aqua browser while running in >> MachoPython and finally found something that works. It's a very simple >> patch that uses the osascript command (i.e. AppleScript from the >> command >> line) to open the url in Internet Explorer. > > This sounds like a nice stopgap. Could you try adding the IC stuff so > that it really opens the users' default browser? This shouldn't be too > difficult, mainly combining stuff from the classic MacPython > webbrowser code with your osascript code. > > One thing, though: what will happen if you run this when you don't > have access to the window server? I.e. when you're on Mac OS X Server, > or when you're in an ssh session to an OSX machine where you ar enot > logged in on the console? Doing a Carbon call in such circumstances > will crash Python, and that probably isn't acceptable... > Cocoa has a message you can send to an instance of NSWorkspace called openURL: that accepts objects of type NSURL. The code would look like this: void openURL(char *theURL) { NSString *urlstring; NSURL *url; NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; urlstring = [NSString stringWithCString: theURL]; url = [NSURL URLWithString:urlstring]; [[NSWorkspace sharedWorkspace] openURL: url]; [pool release]; } Even if +[NSWorkspace sharedWorkspace] fails, sending a message to a nil object doesn't crash anything. Worst case it'll complain in the console log. 'course this means having some extra #includes and perhaps linking to more frameworks but you're doing this anyways if you're using carbon. From Benjamin.Schollnick@usa.xerox.com Fri Jan 11 12:53:59 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 11 Jan 2002 07:53:59 -0500 Subject: [Pythonmac-SIG] Webbrowser module? Message-ID: Sorry Jack... It's been a long two days... >g< It's Python 2.1.1 - MacPython.... On Mac OS 9.2.2, with 128M Ram. Python 2.1.1 (#97, Aug 2 2001, 21:53:31) [CW PPC GUSI2 THREADS] on mac Type "copyright", "credits" or "license" for more information. b>>> >>> import webbrowser >>> webbrowser.open ("http://www.yahoo.com") Traceback (most recent call last): File "", line 1, in ? File "OS v9.1:Applications (Mac OS 9):Python 2.1.1:Lib:webbrowser.py", line 43, in open get().open(url, new, autoraise) File "OS v9.1:Applications (Mac OS 9):Python 2.1.1:Lib:webbrowser.py", line 38, in get raise Error("could not locate runnable browser") webbrowser.Error: could not locate runnable browser >>> The code that I'm attempting, is literally (from the Python Console): import webbrowser webbrowser.open ("www.yahoo.com") I've also tried "http://www.yahoo.com"... in case it's parsing the http. - Benjamin -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Thursday, January 10, 2002 4:57 PM To: Schollnick, Benjamin Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Webbrowser module? Recently, "Schollnick, Benjamin" said: > I just sat down and attempted to use the webbrowser module > on my Mac... And failed... > > I've got the internet control panel configured right... > (Pointing to the right browser)... > > But > > webbrowser.open ("http://www.yahoo.com") > > returns a trace & english text of "cannot locate runnable browser". MacPython or MachoPython? Which version? Which OS? Could you send the stacktrace? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From kevino@tulane.edu Fri Jan 11 04:44:38 2002 From: kevino@tulane.edu (Kevin Ollivier) Date: Thu, 10 Jan 2002 23:44:38 -0500 Subject: [Pythonmac-SIG] Menus for wxPythonMac References: <07CD21F6-0301-11D6-A5E6-003065A10F5A@redivi.com> Message-ID: <06e501c19a5a$b32b5460$6401a8c0@cj622768a> > That's quite a hairy issue. You see, the way WindowServer and the Dock > work, to my knowledge, is that they just *will not* register two > separate dock instances or two menus for the same pid. > > It is possible to change the menu bars dynamically, so, with appropriate > fixes to wxWindows and/or wxPython's source code it could work by using > submenus or something under PythonInterpreter. But until apple (which > they will almost certainly never do...) properly documents WindowServer > and the behind-the-scenes stuff that goes on it's going to be pretty > difficult to see flawless operation of any scripting language with the > GUI. I don't think this will be too much work using wxWindows, in fact, what confuses me is that (as I understand it) wxWindows is actually built to dynamically create and change menus on Mac. This is because wxWindows apps generally define menu items right inside the code. To me this indicates that there is some problem with wxWindows getting 'access' to the hosting application's menubar. My (Mac-inexperienced) eyes see two possible problems: 1. A resource file conflict? This seems rather unlikely to me, but I noticed that most Mac apps use an 'MBAR' resource to define their menus. Could it cause a problem if a shared library and the 'host' application both define a MBAR resource, especially if they have the same resource ID? Also, would anyone know if a shared library needs its resource file bundled with the hosting application or is it compiled into the library? If this is the case, creating a wxWindows version of the Python app could solve this problem. 2. GetNewMBar() fails because a menubar already exists for the application. This seems more likely to me, the question then becomes: is there a way to check to see if a menubar exists before calling GetNewMBar(), and if so, getting the Handle to that menubar? Does my thinking make sense here? Of course, I'm new to Mac programming so I may be missing something obvious here. ^_^; Thanks for your help! Kevin > The only solution I can think of is to make dummy application bundles > and launch them in separate processes, and have some sort of socket > communication between wxPython and the dummy bundles. Each bundle would > have to have a unique name because WindowServer seems to use argv[0] as > it's key to redirect events back to the application, so it could get > confused. This is a terrible hack, but it would almost certainly work. > The problem is that all communication to windows probably has to be done > over sockets, unless you can get an NSApplication pointer to the dummy > app or something, which would be awfully cool. It'd be a lot of work > though, obviously. > > -bob > > On Sunday, January 6, 2002, at 04:22 PM, Kevin & Masako Ollivier wrote: > > > Sorry for the cross-posting, but I thought I'd cover all my bases! =) > > > > I'll briefly explain where I'm at. I'm using the Carbon version of > > Python > > 2.2, along with wxWindows and wxPython on OS X 10.1.2. I've pulled all > > the > > sources from CVS. Everything compiles, and so far I've been able to run > > wxPython scripts with a limited degree of success. However, the major > > problem is that I'm still having troubles with the menus. When I load a > > wxPython script in Python, Python's menubars stay active and the menus > > created by the script are nowhere to be found. Has anyone else > > experienced > > this? > > > > Also, when I run the script it does not open as a separate application > > in OS > > X. All windows are listed as child windows of the Python application. > > I'm > > wondering if these two issues are related. wxPython may not be able to > > modify Python's menus, and since it does not have its own application, > > it > > has no way of showing its own menus. Does this make sense? I admit I'm > > pretty new to Mac programming, and as such I'm a bit stuck as to what > > can be > > done about this problem. Any help would be appreciated! > > > > Thanks, > > > > Kevin > > > > > > > > > > _______________________________________________ > > 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 moehl@akaflieg.extern.tu-berlin.de Fri Jan 11 15:26:57 2002 From: moehl@akaflieg.extern.tu-berlin.de (Torsten Sadowski) Date: Fri, 11 Jan 2002 16:26:57 +0100 (CET) Subject: [Pythonmac-SIG] Tkinter - the saga continues In-Reply-To: <20020110220257.70612E8451@oratrix.oratrix.nl> Message-ID: Hi Jack, I would definitely prefer a fully functional tkinter, even if it requires an additional download. Cheers, Torsten From owen@astro.washington.edu Fri Jan 11 16:06:22 2002 From: owen@astro.washington.edu (Russell E Owen) Date: Fri, 11 Jan 2002 08:06:22 -0800 Subject: [Pythonmac-SIG] Progress report: unix python on Mac OS X In-Reply-To: References: Message-ID: At 9:52 PM -0700 1/10/02, Steven Burr wrote: >On Thursday, January 10, 2002, at 07:56 PM, Marcel Prastawa wrote: > >>Russell E Owen wrote: >>> You were right, thanks! It turns out fink can find it using "fink >>> install gmp". I'm not sure why it didn't show up in the list of known >>> source or binary packages. Anyway, installing it allowed the full >>> python 2.2 installation to proceed and it works fine. >> >>A quick note on Fink: Fink has two package classifications: stable and unstable. You need to build the unstable packages from the source. >>See http://fink.sourceforge.net/faq/usage-fink.php#bindist >> >>Could you send me the fix for Fink? I want to minimize my exposure to Perl... :) > >If you mean a fix for python 2.2, it really shouldn't be necessary. > >The gmp package is in stable: > >21:42:21 >$ ls /sw/fink/dists/stable/main/finkinfo/libs/gmp* >/sw/fink/dists/stable/main/finkinfo/libs/gmp-3.1.1-2.info > >It's listed as a dependency in the python 2.2 info file, so when you do "fink install python," fink will ask if you want gmp (and any other dependencies you don't already have) installed as well. It worked for me. I was installing Python from binary, not from source, and gmp is not available as source. Hence I did a "fink install gmp" from the command line first (and got version 3.1.1-2, as you note), then installed Python from binary (using sudo dselect) and all was well. The fix for "fink selfupdate" is as follows (thanks to Max Horn): edit "sw/lib/perl5/Fink/SelfUpdate.pm": in line 379, change: $unpack_cmd = "tar -xz${verbosity}f -"; to $unpack_cmd = "tar -xz${verbosity}f $pkgtarball"; Other options are to wait for a newer fink or install fink from cvs (in both cases I assume using the normal software update mechanism rather than "selfupdate"). twm seems to be broken for some Mac OS X users. I'm hunting for another window manager now (any recommendations gratefully received -- if it matters, I'm mostly interested in it being easy to install and working reliably). -- Russell From fgranger@altern.org Fri Jan 11 15:51:11 2002 From: fgranger@altern.org (Francois Granger) Date: Fri, 11 Jan 2002 16:51:11 +0100 Subject: [Pythonmac-SIG] Webbrowser module? Message-ID: (sorry, this answer was sent to the author, not to the list) At 13:05 -0500 on 10/01/02, in message [Pythonmac-SIG] Webbrowser module?, you wrote: >I just sat down and attempted to use the webbrowser module >on my Mac... And failed... > >I've got the internet control panel configured right... >(Pointing to the right browser)... > >But > >webbrowser.open ("http://www.yahoo.com") This works on my Mac and launch iCab: import webbrowser br = webbrowser.InternetConfig() br.open ("http://www.yahoo.com") From jack@oratrix.nl Fri Jan 11 23:50:43 2002 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 12 Jan 2002 00:50:43 +0100 Subject: [Pythonmac-SIG] Tkinter strikes again Message-ID: <20020111235043.3AEF7E8451@oratrix.oratrix.nl> Folks, new versions of _tkinter for Carbon and classic PPC are available in http://www.cwi.nl/ftp/jack/python/mac/newer . These versions require an installed Tcl/Tk 8.3.4, which you can get via http://prdownloads.sourceforge.net/tcl/TclTk_8.3.4_WebInstall.bin . Alternative installers are available through http://tcl.sourceforge.net . Unfortunately if you *don't* install Tcl/Tk, you get the error message at a rather late stage: not when you're importing Tkinter but when you first try to use it. And the message is rather cryptic, something like "Cannot load init.tcl, maybe you need to install Tcl or set TCL_PATH". Suggestions as to how to fix this are welcome. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From sburr@home.com Sat Jan 12 04:08:55 2002 From: sburr@home.com (Steven Burr) Date: Fri, 11 Jan 2002 21:08:55 -0700 Subject: [Pythonmac-SIG] Webbrowser module? In-Reply-To: <20020111092719.EB3E7E8451@oratrix.oratrix.nl> Message-ID: <183E5A81-0712-11D6-BEBF-00039362D50A@home.com> On Friday, January 11, 2002, at 02:27 AM, Jack Jansen wrote: > This sounds like a nice stopgap. Could you try adding the IC stuff so > that it really opens the users' default browser? I'm not sure how to do this. The open method in the InternetConfig class calls "ic.launch(url)." If I try to import ic while running MachoPython in the Terminal, I get an ImportError. BUT, I've run across something just as good, or at least close. I was using the openURL command from the AppleScript dictionary for Internet Explorer. Tonight I took a look at the Standard Additions dictionary and found an "open location" command that opens a url with the user's default browser! I ran the command The openURL command seems to be standard for scriptable browsers. I found it in the AppleScript dictionaries for IE, OmniWeb and Netscape. By using both that and the open location command, I believe I can give MachoPython users of webbrowser the same options that other Unix users have: choose a browser or rely on the default. I'll work on it and send in another patch. > This shouldn't be too > difficult, . . . . Probably not, for you. : ) But I'm just hobbyist. > One thing, though: what will happen if you run this when you don't > have access to the window server? I.e. when you're on Mac OS X Server, > or when you're in an ssh session to an OSX machine where you ar enot > logged in on the console? I can test a couple of scenarios where no window manager is available. I can start my Mac in console-only mode, and I can access my other Mac with ssh. I don't have access to OS X Server, though. > Doing a Carbon call in such circumstances > will crash Python, and that probably isn't acceptable... I guess that means a try/except won't work. : ) From adam@switchedonsoftware.com Sat Jan 12 04:42:06 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Sat, 12 Jan 2002 15:42:06 +1100 Subject: [Pythonmac-SIG] Slim Python Framework (under 340 KB compressed) Message-ID: As promised I had a go at sliming down Python. The objective was to create a framework for Python that is suitable for distributing with applications that embed Python. Here's the summary of what I did. First I'll mention that I have only just started using all this unix stuff last year after switching to OS X, so all you unix guru's will probably have a good chuckle and maybe an occasional cringe when you see what I have done. 1) Start off with the standard unix source distribution of Python 2.2. 2) Hack the configure file so that debug information is not built when compiling. 3) Configure Python to build as a framework without toolbox glue code. 4) Make and install it in /Library/Frameworks 5) Remove all headers files and related symbolic links. 6) Remove all files in the library folder. 7) Create empty directory (lib-dynload) and empty files (os.py and site.py) to keep the python happy. Results in a folder with size 995126 bytes (according to the Finder). This zips down to 337 KB, a most acceptable size. The only real gotcha that's hit me so far is that I removed all Headers from the framework, so one might like to keep a version hanging around with header files so that you can still compile. Oh yeah, and no warranties at all. It seems to work for me :). You can either use the script below to slim your own framework, or if you find compiling programs as exciting as I do, then it can downloaded from: http://www.switchedonsoftware.com/python/SlimPython.tar.gz My extremely amateur shell script (apologies if any lines wrap): #!/bin/sh tar zxf Python-2.2.tgz && \ cd Python-2.2 && \ sed -e 's/OPT="-g -O3 -Wall -Wstrict-prototypes"/OPT="-O3 -Wall -Wstrict-prototypes"/g' configure > TEMP && \ mv TEMP configure && \ chmod u+x configure && \ ./configure --enable-framework --disable-toolbox-glue && \ make && \ make frameworkinstall && \ FRAMEWORK="/Library/Frameworks/Python.framework" && \ VERSION="2.2" && \ rm -r "$FRAMEWORK/Versions/$VERSION/lib/python$VERSION" && \ mkdir "$FRAMEWORK/Versions/$VERSION/lib/python$VERSION" && \ touch "$FRAMEWORK/Versions/$VERSION/lib/python$VERSION/site.py" && \ touch "$FRAMEWORK/Versions/$VERSION/lib/python$VERSION/os.py" && \ mkdir "$FRAMEWORK/Versions/$VERSION/lib/python$VERSION/lib-dynload" && \ rm "$FRAMEWORK/Headers" && \ rm "$FRAMEWORK/Versions/$VERSION/Headers" && \ rm -r "$FRAMEWORK/Versions/$VERSION/include" && \ rm -r "$FRAMEWORK/Versions/$VERSION/man" && \ echo "Done." Kind regards, Adam Eijdenberg Switched on Software From blacktrash@gmx.net Sat Jan 12 10:33:27 2002 From: blacktrash@gmx.net (Christian Ebert) Date: Sat, 12 Jan 2002 11:33:27 +0100 Subject: [Pythonmac-SIG] Tkinter strikes again In-Reply-To: <20020111235043.3AEF7E8451@oratrix.oratrix.nl> Message-ID: <20020112113442-r01010800-f183180b-0922-0108@217.0.162.55> Hi, Jack Jansen at 0:50 on Saturday, January 12, 2002: > Unfortunately if you *don't* install Tcl/Tk, you get the error message > at a rather late stage: not when you're importing Tkinter but when you > first try to use it. And the message is rather cryptic, something like > "Cannot load init.tcl, maybe you need to install Tcl or set TCL_PATH". Traceback (most recent call last): File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Scripts:tk_test.py", line 4, in ? tk = Tkinter.Tk() File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Lib:lib-tk:Tkinter.py", line 1487, in __init__ self.tk = _tkinter.create(screenName, baseName, className) TclError: can't find Init resource or a usable Init.tcl file in the following directories: {Christians PB HD:Systemordner:Systemerweiterungen:Tool Command Language:tcl8.3} perhaps you need to install Tcl or set your TCL_LIBRARY environment variable? Folder listing for Systemerweiterungen:Tool Command Language: tcl8.3 Tcl8.3.shlb Tclapplescript.shlb tk8.3 Tk8.3.shlb all alias. Should I replace some of these with copies of the originals? Same as I did with PythonCore to make my applets run after restart? Or how do I set my TCL_LIBRARY environment variable? Have a nice weekend. Christian -- I would prefer not to. (Herman Melville, Bartleby) From jack@oratrix.nl Sat Jan 12 12:45:35 2002 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 12 Jan 2002 13:45:35 +0100 Subject: [Pythonmac-SIG] Tkinter strikes again In-Reply-To: Message by Christian Ebert , Sat, 12 Jan 2002 11:33:27 +0100 , <20020112113442-r01010800-f183180b-0922-0108@217.0.162.55> Message-ID: <20020112124540.274DAE8451@oratrix.oratrix.nl> Recently, Christian Ebert said: > File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Lib:lib > -tk:Tkinter.py", line 1487, in __init__ > self.tk = _tkinter.create(screenName, baseName, className) > TclError: can't find Init resource or a usable Init.tcl file > in the following directories: > {Christians PB HD:Systemordner:Systemerweiterungen:Tool Command Language: > tcl8.3} > perhaps you need to install Tcl or set your > TCL_LIBRARY environment variable? > > Folder listing for > > Systemerweiterungen:Tool Command Language: > tcl8.3 > Tcl8.3.shlb > Tclapplescript.shlb > tk8.3 > Tk8.3.shlb > > all alias. Should I replace some of these with copies of the > originals? Same as I did with PythonCore to make my applets > run after restart? Ah, if you had to do this for Python there's a good reason you also have to do this for Tcl. Although I still have absolutely no idea why your aliases would start failing after restart:-) What you could try is check to see whether the problem is Python-only. I.e. if you make a copy of wish outside of the Tcl/Tk folder, will it still run? -- - 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 blacktrash@gmx.net Sat Jan 12 13:53:04 2002 From: blacktrash@gmx.net (Christian Ebert) Date: Sat, 12 Jan 2002 14:53:04 +0100 Subject: [Pythonmac-SIG] Tkinter strikes again In-Reply-To: <20020112124540.274DAE8451@oratrix.oratrix.nl> Message-ID: <20020112145325-r01010800-57d7c1e5-0922-0108@217.0.162.16> Hi Jack, Jack Jansen at 13:45 on Saturday, January 12, 2002: > What you could try is check to see whether the problem is > Python-only. I.e. if you make a copy of wish outside of the Tcl/Tk > folder, will it still run? No. Could not be launched because "tcl8.3" wasn't found. ... Made a _copy_ of Tcl's folder "library" in System Extensions:Tool Commands:, called it "tcl8.3", and now the _copy_ of wish runs. But Tkinter still misses tcl8.3, both in carbon and classic :-( Christian -- Capitalism and schizophrenia go together like salsa and tortilla chips. (bukvich in alt.angst) From blacktrash@gmx.net Sat Jan 12 19:53:46 2002 From: blacktrash@gmx.net (Christian Ebert) Date: Sat, 12 Jan 2002 20:53:46 +0100 Subject: [Pythonmac-SIG] Tkinter strikes again In-Reply-To: <20020112145325-r01010800-57d7c1e5-0922-0108@217.0.162.16> Message-ID: <20020112205400-r01010800-69f95d62-0922-0108@217.0.165.66> Christian Ebert at 14:53 on Saturday, January 12, 2002: > Jack Jansen at 13:45 on Saturday, January 12, 2002: > > > What you could try is check to see whether the problem is > > Python-only. I.e. if you make a copy of wish outside of the Tcl/Tk > > folder, will it still run? > > Made a _copy_ of Tcl's folder "library" in System > Extensions:Tool Commands:, called it "tcl8.3", and now the > _copy_ of wish runs. No. After a restart, the wish copy cannot find tcl8.3 anymore. So the issue seems to be more on part of tcl. Hm. Christian -- The whores hustle and the hustlers whore. (PJ Harvey) From adam@switchedonsoftware.com Sun Jan 13 13:27:32 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Mon, 14 Jan 2002 00:27:32 +1100 Subject: [Pythonmac-SIG] Python RAD tools Message-ID: <4C6602AB-0829-11D6-A3F6-0030656E8732@switchedonsoftware.com> Hello all, I'm toying around with the idea of developing a Python rapid application development tool, initially just for the Mac. This tool is written in C for Carbon, so it is native in all regards and uses the Unix mach-o version of Python. Basically what I'm working on is a tool that allows the graphic design of user interfaces, similar in nature to "Interface Builder" that then allows Python scripts to be executed as a result of user actions, for example, when a button is clicked, a user action occurs. The native file format for a program description is XML. I always think examples are the best way to explain these things, so below is the description of a program that displays a window with a text field and a button. Upon clicking the button what is in the text field is evaluated and replaces the current content. It is a fairly trivial example but may make a nice little calculator. :) I'm not going to explain exactly how it is interpreted (it's too late at night :), but it should be fairly obvious. Basically upon runtime the param named "init" is run, which references a global variable "app" that is passed to it. Then it just goes from there. win = app.getWindow ("Main").instantiate () win.show () self.hide () app.quit () 235 139 Calculator 28 * 28 57 16 * (if you read that carefully and are wondering about the *'s in the bounds, that is to do with handling of window resizing) At the moment I have written an interface builder that produced the XML above, and a runtime that will "run" this. Both are still _way_ too buggy for any form of public release. But give them a week or so. :) But my question is, would a tool like this be welcomed? Is it a duplication of existing effort or could it find a niche? What do you all think? Oh, and BTW I've called the project Viper. Sort of a mix of "Visual Python", "rapid development" and "snakes". Kind regards, Adam Eijdenberg Switched on Software adam@switchedonsoftware.com http://www.switchedonsoftware.com/ Phone: +61 3 6231 3467 Fax: +61 3 6231 3476 Mobile: +61 4 0704 6857 47 Molle Street Hobart TAS 7000 Australia From ntiffin@earthlink.net Sun Jan 13 13:37:15 2002 From: ntiffin@earthlink.net (Neil Tiffin) Date: Sun, 13 Jan 2002 08:37:15 -0500 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <4C6602AB-0829-11D6-A3F6-0030656E8732@switchedonsoftware.com> References: <4C6602AB-0829-11D6-A3F6-0030656E8732@switchedonsoftware.com> Message-ID: At 12:27 AM +1100 1/14/02, Adam Eijdenberg wrote: >Hello all, > >I'm toying around with the idea of developing a Python rapid >application development tool, initially just for the Mac. This tool >is written in C for Carbon, so it is native in all regards and uses >the Unix mach-o version of Python. Exactly what I am looking for also. You might be able to build on the Form Designer from GNU Enterprise. It is based on unix python. It currently is targeted towards wxWindows but it is XML and object based. And I have the CORBA middleware server working on OS X. If you could work with the GNU Enterprise team it would help us provide enterprise software tools for the MAC community. I would love to talk more with you about how this might be done. -- Neil neilt@gnue.org GNU Enterprise http://www.gnuenterprise.org/ http://www.gnuenterprise.org/~neilt/sc.html From fgranger@mac.com Sun Jan 13 14:32:24 2002 From: fgranger@mac.com (=?iso-8859-1?Q?Fran=E7ois?= Granger) Date: Sun, 13 Jan 2002 15:32:24 +0100 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <4C6602AB-0829-11D6-A3F6-0030656E8732@switchedonsoftware.com> References: <4C6602AB-0829-11D6-A3F6-0030656E8732@switchedonsoftware.com> Message-ID: At 0:27 +1100 14/01/02, in message [Pythonmac-SIG] Python RAD tools, Adam Eijdenberg wrote: >But my question is, would a tool like this be welcomed? Is it a >duplication of existing effort or could it find a niche? What do you >all think? Have a look to the following projects and a chat with their developpers, this could be a welcome addition.... anygui: http://anygui.org PythonCard: on sourceforge... -- François Granger fgranger@mac.com From altis@semi-retired.com Sun Jan 13 18:22:52 2002 From: altis@semi-retired.com (Kevin Altis) Date: Sun, 13 Jan 2002 10:22:52 -0800 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <4C6602AB-0829-11D6-A3F6-0030656E8732@switchedonsoftware.com> Message-ID: I think you might want to get involved in the PythonCard project. PythonCard main page: http://pythoncard.sourceforge.net/ Look at the sample screenshots at: http://pythoncard.sourceforge.net/samples.html There are over 20 samples to look at. It runs wherever wxPython does: Windows, Linux, Solaris, and Real Soon Now the Mac. There have been some threads recently running wxPython on Mac OS X and Mac classic via emulation or a GTK install under OS X. See the archives. We will most likely end up using XML for the layout (resource) format, but only after the design settles down. We will also be working to maintain some form of compatibility with the wxWindows XML resource format to leverage tools like wxDesigner. The resourceEditor sample is a basic layout and menu editor. ka ps. Dan Shafer just sent me a PythonCard tutorial this morning. Hopefully, this is the start of a documentation fest :) > -----Original Message----- > From: pythonmac-sig-admin@python.org > [mailto:pythonmac-sig-admin@python.org]On Behalf Of Adam Eijdenberg > Sent: Sunday, January 13, 2002 5:28 AM > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] Python RAD tools > > > Hello all, > > I'm toying around with the idea of developing a Python rapid application > development tool, initially just for the Mac. This tool is written in C > for Carbon, so it is native in all regards and uses the Unix mach-o > version of Python. > > Basically what I'm working on is a tool that allows the graphic design > of user interfaces, similar in nature to "Interface Builder" that then > allows Python scripts to be executed as a result of user actions, for > example, when a button is clicked, a user action occurs. The native file > format for a program description is XML. > > I always think examples are the best way to explain these things, so > below is the description of a program that displays a window with a text > field and a button. Upon clicking the button what is in the text field > is evaluated and replaces the current content. It is a fairly trivial > example but may make a nice little calculator. :) > > I'm not going to explain exactly how it is interpreted (it's too late at > night :), but it should be fairly obvious. Basically upon runtime the > param named "init" is run, which references a global variable "app" that > is passed to it. Then it just goes from there. > > > > win = app.getWindow ("Main").instantiate () > win.show () > > > > self.hide () > app.quit () > > 235 139 > Calculator > > > 28 * 28 57 16 * > > > > > > > (if you read that carefully and are wondering about the *'s in the > bounds, that is to do with handling of window resizing) > > At the moment I have written an interface builder that produced the XML > above, and a runtime that will "run" this. > Both are still _way_ too buggy for any form of public release. But give > them a week or so. :) > > But my question is, would a tool like this be welcomed? Is it a > duplication of existing effort or could it find a niche? What do you all > think? > > Oh, and BTW I've called the project Viper. Sort of a mix of "Visual > Python", "rapid development" and "snakes". > > Kind regards, > Adam Eijdenberg > Switched on Software > > adam@switchedonsoftware.com > http://www.switchedonsoftware.com/ > > Phone: +61 3 6231 3467 > Fax: +61 3 6231 3476 > Mobile: +61 4 0704 6857 > > 47 Molle Street > Hobart TAS 7000 > Australia > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From kevino@tulane.edu Sun Jan 13 18:51:07 2002 From: kevino@tulane.edu (Kevin Ollivier) Date: Sun, 13 Jan 2002 13:51:07 -0500 Subject: [Pythonmac-SIG] Python RAD tools References: <4C6602AB-0829-11D6-A3F6-0030656E8732@switchedonsoftware.com> Message-ID: <005c01c19c63$47508840$6401a8c0@cj622768a> > Hello all, > > I'm toying around with the idea of developing a Python rapid application > development tool, initially just for the Mac. This tool is written in C > for Carbon, so it is native in all regards and uses the Unix mach-o > version of Python. > > Basically what I'm working on is a tool that allows the graphic design > of user interfaces, similar in nature to "Interface Builder" that then > allows Python scripts to be executed as a result of user actions, for > example, when a button is clicked, a user action occurs. The native file > format for a program description is XML. If you're initially targeting Mac and want to use an XML-based format, why not just use Interface Builder? IB uses XML as its data format, so it should do exactly what you want in terms of graphically designing the interface. That way, you could focus on getting the XML into Python and parsing it. I think, like another poster commented, that interfacing this with a tool like anygui would make it a really powerful tool for cross-platform RAD. And once demand grows for a cross-platform interface builder, it will probably be easier to build it with anygui. In fact, you could probably use IB to design the interface for the cross-platform interface builder! =) BTW, Viper sounds like a cool name for this project! Kevin From jack@oratrix.nl Sun Jan 13 21:45:13 2002 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 13 Jan 2002 22:45:13 +0100 Subject: [Pythonmac-SIG] Tkinter strikes again In-Reply-To: Message by Christian Ebert , Sat, 12 Jan 2002 14:53:04 +0100 , <20020112145325-r01010800-57d7c1e5-0922-0108@217.0.162.16> Message-ID: <20020113214519.12F1FE8451@oratrix.oratrix.nl> Folks, so far Christian is the only person who sent feedback on the new (second version) Tkinter, and for him things were bumpy. I would be especially interested in hearing success stories at this point... -- - 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 adam@switchedonsoftware.com Sun Jan 13 22:26:37 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Mon, 14 Jan 2002 09:26:37 +1100 Subject: [Pythonmac-SIG] Python RAD tools Message-ID: <9B9A2D5C-0874-11D6-A3F6-0030656E8732@switchedonsoftware.com> Thanks for all replies. There sure are some interesting projects going on that I didn't know about. I received a couple of pointers to different projects so now I'll try to summarize each of them and how they related to what I'm trying to achieve. Anygui (http://anygui.sourceforge.net/) ============================== "The purpose of the Anygui project is to create an easy-to-use, simple, and generic module for making graphical user interfaces in Python. Its main feature is that it works transparently with many different GUI packages on most platforms" (web page) This project certainly seems like an excellent idea, but it is not what I am trying to implement. I want to design the GUI first, and chuck code in afterwards, rather than code to create the GUI. That is one the things I would like to prevent. Python Card (http://pythoncard.sourceforge.net/) ====================================== Aim: To reimplement HyperCard in Python This looks like a very interesting project and appears to be close to what I am trying to achieve. This project is however written entirely in Python (a good thing), but this is not what I want to do. My project aims to basically create a native project, that can be scripted by Python. Mainly for the reasons that so far any attempts that I have seen as a cross-platform GUI (e.g. Java, Tkinter) never look "quite" right. But I hasten to note that I haven't had a good look at the download just yet. Interface Builder ============= I don't want to use this for the following reasons: - I want my project to be standalone (only requires a 337 KB Python runtime download) - Having to use two different tools, ie IB for designing GUIS, another app for assigning actions to GUI elements is too messy for my liking. GNU Enterprise ============ Words like CORBA scare me. :) Sounds a beyond the scope of what I want to do right now. Conclusion ========= I'm going to keep working on Viper on my own for a while. I've already written (and rewritten once over from scratch) both the editor and the runtime (both on the based on the same code base). Hopefully I will have something ready for public release in a week or so, pending fixing a few GUI elements that make the GUI editor a pain to use (and I need to write a little documentation). Would the group like to be kept up-to-date on any public releases I make? Kind regards, Adam Eijdenberg Switched on Software adam@switchedonsoftware.com http://www.switchedonsoftware.com/ Phone: +61 3 6231 3467 Fax: +61 3 6231 3476 Mobile: +61 4 0704 6857 47 Molle Street Hobart TAS 7000 Australia From altis@semi-retired.com Sun Jan 13 22:56:35 2002 From: altis@semi-retired.com (Kevin Altis) Date: Sun, 13 Jan 2002 14:56:35 -0800 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <9B9A2D5C-0874-11D6-A3F6-0030656E8732@switchedonsoftware.com> Message-ID: > From: Adam Eijdenberg > > Python Card (http://pythoncard.sourceforge.net/) > ====================================== > Aim: To reimplement HyperCard in Python > > This looks like a very interesting project and appears to be close to > what I am trying to achieve. This project is however written entirely in > Python (a good thing), but this is not what I want to do. My project > aims to basically create a native project, that can be scripted by > Python. Mainly for the reasons that so far any attempts that I have seen > as a cross-platform GUI (e.g. Java, Tkinter) never look "quite" right. > But I hasten to note that I haven't had a good look at the download just > yet. Just some comments on PythonCard, since that is where I'm an expert. I started a thread earlier this week on what PythonCard is. We have that discussion every few months just to keep everyone in sync. The short answer is that we aren't re-implementing HyperCard in Python, HyperCard is just inspiration due to its simplicity of use. Yes we probably need to change the project name. http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/976090 By native project I assume you want standalone binaries for your applications that don't require Python or any other libraries to be installed? We can't do this yet on the Mac due to the missing wxPython Mac port, but it will happen. You can create standalones with py2exe for Windows (both the minimal and textRouter samples have instructions). Last night I got standalone builds on Windows working with Gordon McMillan's Installer. I have not done a Linux or Solaris build yet, but based on what I've seen so far that should work too. I'm hoping that Gordon's installer will be a usable Mac solution once wxPython Mac exists, perhaps people on this list can comment on the current solutions for building standalones. If you just want something to run on the Mac and not worry about cross-platform issues, no problem. As far as scripting the app is concerned, PythonCard already uses the PyCrust runtime shell. If you want AppleEvent bindings, somebody on this list will have to discuss those issues and how it would relate to wxPython Mac. I don't see any reason why it can't be done. If you want to write a PythonCard app that uses COM on Windows and won't work on Linux or the Mac in the future that's doable too; we try to not have any arbitrary straightjackets. wxPython uses native widgets and PythonCard sits on wxPython so you get native widget look and behavior. A potentially big benefit of the PythonCard design currently in use is that different layouts can be used with the same source code or you could mix the code and layouts used when the app starts by doing a simple check of the platform. What this means is that you could write an app and layout designed and tested on a Mac and someone else could provide an adjusted Windows layout and then add a simple if/then to the code to do the right thing depending on platform. If you want to use sizers or anchors that is often a better solution, but more difficult for people new to sizers (and sometimes even experts) for all but the simplest of layouts. Hope that helps, ka From bfancher@mac.com Sun Jan 13 23:30:06 2002 From: bfancher@mac.com (bill fancher) Date: Sun, 13 Jan 2002 15:30:06 -0800 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <4C6602AB-0829-11D6-A3F6-0030656E8732@switchedonsoftware.com> Message-ID: <7A0AF3E3-087D-11D6-B189-0005029E8B13@mac.com> On Sunday, January 13, 2002, at 05:27 AM, Adam Eijdenberg wrote: > But my question is, would a tool like this be welcomed? Is it a > duplication of existing effort or could it find a niche? What do you > all think? I believe such a tool would be welcomed. Whether it's a duplication of effort is debatable... I have an OSA component for Python that enables Python scripting in Script Editor and other OSA compliant applications. After a few tweaks, it can now be used to create Python applications in AppleScript Studio. Here's the complete script for a very simple calendar application with a text entry field, a button, and a text display field: from calendar import calendar def will_finish_launching(): showYear() def action(theObject): showYear() def clicked(theObject): showYear() def showYear(): w = app().window['main'] year = w.text_field['dateEntry'].contents w.scroll_view['display'].text_view['calendar'].contents = calendar(year) The application comes up displaying a calendar for 2002 (in blue text). Entering a different year in the text entry field and hitting return or pressing the button puts the appropriate calendar in the calendar display field. The application has all the features you'd expect with a Cocoa app: field validation, copy/paste, a scrolling resizable window, working "Hide" and "Minimize" menu items, an "About Calendar" dialog, services, etc. The interface is constructed and linked to the Python handlers in Interface Builder. All AppleScriptKit interface objects are supported. Script editing and application building are done with Project Builder. During compilation, syntax errors are reported by Project Builder and clicking the error report selects the correct line in the script. Debugging (single step, breakpoints, variable display, etc.) is not yet working, but runtime errors are reported in a dialog giving the error message and line number. One advantage of this approach is that you can write part or all of your application in C, OjbC, C++, or Java, making it easy to progress from a scripted prototype to a fully optimized application with only minor changes in IB. I reimplemented the ASS Outline example in Python with NO changes in IB. It's far from a finished solution, and, as it stands, it's not ready for production use: it requires hacking a ProjectBuilderJambase rule that's hard coded for AppleScript, PB will muck with your script files in various annoying ways, and you can't mix Python and AppleScript in the same application. But it's a start. I'll be sending this latest version of OSA Python (1.0a5) to testers shortly. (Anyone else interested in helping out should contact me off list.) Apple has hinted that future versions of PB/IB will fully support OSA languages other than AppleScript. I'm hoping they deliver and looking at alternatives in the meanwhile. Let a thousand flowers bloom... -- bill From neilt@gnue.org Mon Jan 14 00:33:14 2002 From: neilt@gnue.org (Neil Tiffin) Date: Sun, 13 Jan 2002 19:33:14 -0500 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <9B9A2D5C-0874-11D6-A3F6-0030656E8732@switchedonsoftware.com> References: <9B9A2D5C-0874-11D6-A3F6-0030656E8732@switchedonsoftware.com> Message-ID: At 9:26 AM +1100 1/14/02, Adam Eijdenberg wrote: >GNU Enterprise >============ >Words like CORBA scare me. :) >Sounds a beyond the scope of what I want to do right now. Sorry, did not mean to scare you. Our 2 tier solution works with a dozen or so databases without the use of CORBA. -- Neil neilt@gnue.org GNU Enterprise http://www.gnuenterprise.org/ http://www.gnuenterprise.org/~neilt/sc.html From hiss999@dircon.co.uk Mon Jan 14 01:02:45 2002 From: hiss999@dircon.co.uk (sandro s.) Date: Mon, 14 Jan 2002 01:02:45 +0000 Subject: [Pythonmac-SIG] Tkinter strikes again In-Reply-To: <20020113214519.12F1FE8451@oratrix.oratrix.nl> Message-ID: on 13/1/02 9:45 pm GMT, Jack Jansen at jack@oratrix.nl apparently typed: > Folks, > so far Christian is the only person who sent feedback on the new > (second version) Tkinter, and for him things were bumpy. > > I would be especially interested in hearing success stories at this > point... Runs smooth here. OS 9.04. -- LUThER [active soon] From landauer@got.net Mon Jan 14 03:44:38 2002 From: landauer@got.net (Doug Landauer) Date: Sun, 13 Jan 2002 19:44:38 -0800 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <9B9A2D5C-0874-11D6-A3F6-0030656E8732@switchedonsoftware.com> References: <9B9A2D5C-0874-11D6-A3F6-0030656E8732@switchedonsoftware.com> Message-ID: >I'm going to keep working on Viper on my own for a while. Please do come up with a different name. Vyper is the name of John Skaller's python implementation (written in OCaml). Currently stalled, unfortunately... http://vyper.sourceforge.net/ As I understand it, your project includes a GUI element where the GUI description is in a language embedded within XML. Other projects that you might wish to become familiar with (if only to see and avoid the problems that they may have run into) would be GLADE and XUL ... GLADE http://glade.gnome.org/index.html Glade is a free user interface builder for GTK+ and GNOME. [...] Glade can produce C source code itself. C++, Ada95, Python & Perl support is also available, via external tools which process the XML interface description files output by Glade... XUL (just do a Google search for XUL) was, I believe, the first XML-based GUI language... XUL Tutorial http://www.xulplanet.com/tutorials/xultu/ This tutorial guides you to learning XUL (XML-based User-interface Language) which is a cross-platform language for describing user interfaces of applications. Good luck! -- Doug From gherman@darwin.in-berlin.de Mon Jan 14 08:33:20 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Mon, 14 Jan 2002 09:33:20 +0100 (CET) Subject: [Pythonmac-SIG] Python-"Services" on OS X? Message-ID: <1010997200.3c4297d0c8b8b@webmail.in-berlin.de> Hi all, I'd really like to write a few "services" for OS X with Python as the primary implementation language, but I'm not sure this is already possible? Maybe someone could drop a few lines only, saying if it is or when to expect it? For those unfamiliar with these "services": it's a concept in- troduced in NeXTSTEP, that lets you write (usually little) apps that are available in the Finder->Services menu of any applica- tion you use, depending on the selected item. An example: you could write a rot-13 function in Python and use it on any piece of text you select in any editor you like to re- place it with its rotated version. The same holds in principle for other data types as well, like, say, files... Regards, Dinu -- Dinu C. Gherman ................................................................ "In a world without fences and walls we don't need windows and gates." (Anonymous) From adam@switchedonsoftware.com Mon Jan 14 09:07:51 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Mon, 14 Jan 2002 20:07:51 +1100 Subject: [Pythonmac-SIG] Python-"Services" on OS X? In-Reply-To: <1010997200.3c4297d0c8b8b@webmail.in-berlin.de> Message-ID: <2FDFA485-08CE-11D6-A55B-0030656E8732@switchedonsoftware.com> > I'd really like to write a few "services" for OS X with Python > as the primary implementation language, but I'm not sure this > is already possible? Maybe someone could drop a few lines only, > saying if it is or when to expect it? If this hasn't yet been done, then something that would be kind of cool would be a service that takes the current selection, evaluates it as Python code and replaces it with the output. This shouldn't be too hard to implement, but I know nothing about services. Might have a look though if no one has already done this. Once this were done, such as architecture could be extended to instead take the selection, apply an arbitrary python function to it (ie, one that you wrote) and replace the selection with the result. Has any work on such a service been started? Kind regards, Adam Eijdenberg Switched on Software adam@switchedonsoftware.com http://www.switchedonsoftware.com/ Phone: +61 3 6231 3467 Fax: +61 3 6231 3476 Mobile: +61 4 0704 6857 47 Molle Street Hobart TAS 7000 Australia From bob@redivi.com Mon Jan 14 10:22:03 2002 From: bob@redivi.com (Bob Ippolito) Date: Mon, 14 Jan 2002 05:22:03 -0500 Subject: [Pythonmac-SIG] Python-"Services" on OS X? In-Reply-To: <2FDFA485-08CE-11D6-A55B-0030656E8732@switchedonsoftware.com> Message-ID: <8DA07C40-08D8-11D6-8EA0-0003938210D6@redivi.com> I've played with services myself.. and I see no reason whatsoever why doing this should give you any problem. Writing a service is quite easy really You can check out a simple set of services that I wrote at http://redivi.com/~bob/URLServices.tgz -- It doesn't use python, but it wouldn't be too hard for it to do so. One thing about services is that they're not just restricted to text, it can be files or images or anything else, which leaves plenty of possibilities The only problem with the Mac OS X implemenation of services.. well, there are two. 1) services and carbon applications that haven't been modified to explicitly support services don't play well. 2) You must logout (maybe just relaunch finder?) to reliably remove or add new services. -bob On Monday, January 14, 2002, at 04:07 AM, Adam Eijdenberg wrote: >> I'd really like to write a few "services" for OS X with Python >> as the primary implementation language, but I'm not sure this >> is already possible? Maybe someone could drop a few lines only, >> saying if it is or when to expect it? > > If this hasn't yet been done, then something that would be kind of cool > would be a service that takes the current selection, evaluates it as > Python code and replaces it with the output. > > This shouldn't be too hard to implement, but I know nothing about > services. Might have a look though if no one has already done this. > > Once this were done, such as architecture could be extended to instead > take the selection, apply an arbitrary python function to it (ie, one > that you wrote) and replace the selection with the result. > > Has any work on such a service been started? > > Kind regards, > Adam Eijdenberg > Switched on Software > > adam@switchedonsoftware.com > http://www.switchedonsoftware.com/ > > Phone: +61 3 6231 3467 > Fax: +61 3 6231 3476 > Mobile: +61 4 0704 6857 > > 47 Molle Street > Hobart TAS 7000 > Australia > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From gherman@darwin.in-berlin.de Mon Jan 14 11:16:25 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Mon, 14 Jan 2002 12:16:25 +0100 Subject: [Pythonmac-SIG] Python-"Services" on OS X? References: <8DA07C40-08D8-11D6-8EA0-0003938210D6@redivi.com> Message-ID: <3C42BE09.BA606F15@darwin.in-berlin.de> Bob Ippolito wrote: > > I've played with services myself.. and I see no reason whatsoever why > doing this should give you any problem. Writing a service is quite easy > really > > You can check out a simple set of services that I wrote at > http://redivi.com/~bob/URLServices.tgz -- It doesn't use python, but it > wouldn't be too hard for it to do so. That works fine - thanks! What I'm after is something more of a little service template project with some stubs left for plugging in your Python scripts (so you can forget about the rest). But I know there are issues with getting your hand at objects like selected images, say, which is where I hope the next-ge- neration (?) Python.framework on OS X might make things much easier (??). Regards, Dinu From Benjamin.Schollnick@usa.xerox.com Mon Jan 14 12:53:01 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Mon, 14 Jan 2002 07:53:01 -0500 Subject: [Pythonmac-SIG] Python RAD tools Message-ID: A GUI RAD tool? Excellent... I miss that from my OPRO (Object Professional) days programming on the PC... - Benjamin -----Original Message----- From: Adam Eijdenberg [mailto:adam@switchedonsoftware.com] Sent: Sunday, January 13, 2002 8:28 AM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] Python RAD tools Hello all, I'm toying around with the idea of developing a Python rapid application development tool, initially just for the Mac. This tool is written in C for Carbon, so it is native in all regards and uses the Unix mach-o version of Python. Basically what I'm working on is a tool that allows the graphic design of user interfaces, similar in nature to "Interface Builder" that then allows Python scripts to be executed as a result of user actions, for example, when a button is clicked, a user action occurs. The native file format for a program description is XML. I always think examples are the best way to explain these things, so below is the description of a program that displays a window with a text field and a button. Upon clicking the button what is in the text field is evaluated and replaces the current content. It is a fairly trivial example but may make a nice little calculator. :) I'm not going to explain exactly how it is interpreted (it's too late at night :), but it should be fairly obvious. Basically upon runtime the param named "init" is run, which references a global variable "app" that is passed to it. Then it just goes from there. win = app.getWindow ("Main").instantiate () win.show () self.hide () app.quit () 235 139 Calculator 28 * 28 57 16 * (if you read that carefully and are wondering about the *'s in the bounds, that is to do with handling of window resizing) At the moment I have written an interface builder that produced the XML above, and a runtime that will "run" this. Both are still _way_ too buggy for any form of public release. But give them a week or so. :) But my question is, would a tool like this be welcomed? Is it a duplication of existing effort or could it find a niche? What do you all think? Oh, and BTW I've called the project Viper. Sort of a mix of "Visual Python", "rapid development" and "snakes". Kind regards, Adam Eijdenberg Switched on Software adam@switchedonsoftware.com http://www.switchedonsoftware.com/ Phone: +61 3 6231 3467 Fax: +61 3 6231 3476 Mobile: +61 4 0704 6857 47 Molle Street Hobart TAS 7000 Australia _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From adam@switchedonsoftware.com Mon Jan 14 12:53:44 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Mon, 14 Jan 2002 23:53:44 +1100 Subject: [Pythonmac-SIG] RAD tool (with screenshot...) Message-ID: OK what I didn't make clear from the start was my original aim for this project: I want to create an easy way of creating GUI front ends for databases. Like MS Access or FileMaker, but instead interfacing with other backends such as MySQL etc. This is probably a fairly ambitions aim but let's face it, IMHO Access is downright awful to create GUIs in (even though you can always do what you want), and FileMaker is wonderful to create GUIs in, but it's hard to ever get it to do exactly what you want with them. Python is to be to my project what Visual Basic is to Microsoft Access. I think that is the best summary. Anyway, I haven't done any work on connecting to a DB yet, instead concentrating on the GUI builder. That's when I began to think this my have some use outside of just databases. I think now I may be wrong as there are plenty of other projects that cater to that audience. Nevertheless, I've chucked together some pretty awful documentation and a couple of binaries so if you are interested you can see what I've come up with so far. The distribution is Mac OS X only at this stage. Sorry about that OS 9 users. Read me can be found here (and is included with the download): http://www.switchedonsoftware.com/python/READ_ME.txt Main applications and examples: http://www.switchedonsoftware.com/python/Adder.tar.gz (67 KB) You will need Python compiled as a framework. A minimal version (with no modules at all) can be found here: http://www.switchedonsoftware.com/python/SlimPython.tar.gz (338 KB) AND the obligatory screenshot (sorry about the size (227 KB), in OS X I don't have any image converters!): http://www.switchedonsoftware.com/python/screenshot.tiff If you have any comments, I'd love to hear them. Kind regards, Adam Eijdenberg Switched on Software adam@switchedonsoftware.com http://www.switchedonsoftware.com/ Phone: +61 3 6231 3467 Fax: +61 3 6231 3476 Mobile: +61 4 0704 6857 47 Molle Street Hobart TAS 7000 Australia From Benjamin.Schollnick@usa.xerox.com Mon Jan 14 12:57:35 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Mon, 14 Jan 2002 07:57:35 -0500 Subject: [Pythonmac-SIG] Python RAD tools Message-ID: Kevin, Gordon's package shouldn't be needed on the Macintosh... At least, I've never run into a situation where I've needed a 3rd party "freeze" package on the Macintosh. The MacPython package includes a "freeze" like utility that handles all of that by itself, and produces Macintosh executables... I'm not even sure that Gordon's package should work in Classic MacOS, possibly in Darwin or MOSX.... But I haven't installed v5 of Installer, so I'm not sure... - Benjamin -----Original Message----- From: Kevin Altis [mailto:altis@semi-retired.com] Sent: Sunday, January 13, 2002 5:57 PM To: Adam Eijdenberg; pythonmac-sig@python.org Subject: RE: [Pythonmac-SIG] Python RAD tools > From: Adam Eijdenberg > > Python Card (http://pythoncard.sourceforge.net/) > ====================================== > Aim: To reimplement HyperCard in Python > > This looks like a very interesting project and appears to be close to > what I am trying to achieve. This project is however written entirely in > Python (a good thing), but this is not what I want to do. My project > aims to basically create a native project, that can be scripted by > Python. Mainly for the reasons that so far any attempts that I have seen > as a cross-platform GUI (e.g. Java, Tkinter) never look "quite" right. > But I hasten to note that I haven't had a good look at the download just > yet. Just some comments on PythonCard, since that is where I'm an expert. I started a thread earlier this week on what PythonCard is. We have that discussion every few months just to keep everyone in sync. The short answer is that we aren't re-implementing HyperCard in Python, HyperCard is just inspiration due to its simplicity of use. Yes we probably need to change the project name. http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/976090 By native project I assume you want standalone binaries for your applications that don't require Python or any other libraries to be installed? We can't do this yet on the Mac due to the missing wxPython Mac port, but it will happen. You can create standalones with py2exe for Windows (both the minimal and textRouter samples have instructions). Last night I got standalone builds on Windows working with Gordon McMillan's Installer. I have not done a Linux or Solaris build yet, but based on what I've seen so far that should work too. I'm hoping that Gordon's installer will be a usable Mac solution once wxPython Mac exists, perhaps people on this list can comment on the current solutions for building standalones. If you just want something to run on the Mac and not worry about cross-platform issues, no problem. As far as scripting the app is concerned, PythonCard already uses the PyCrust runtime shell. If you want AppleEvent bindings, somebody on this list will have to discuss those issues and how it would relate to wxPython Mac. I don't see any reason why it can't be done. If you want to write a PythonCard app that uses COM on Windows and won't work on Linux or the Mac in the future that's doable too; we try to not have any arbitrary straightjackets. wxPython uses native widgets and PythonCard sits on wxPython so you get native widget look and behavior. A potentially big benefit of the PythonCard design currently in use is that different layouts can be used with the same source code or you could mix the code and layouts used when the app starts by doing a simple check of the platform. What this means is that you could write an app and layout designed and tested on a Mac and someone else could provide an adjusted Windows layout and then add a simple if/then to the code to do the right thing depending on platform. If you want to use sizers or anchors that is often a better solution, but more difficult for people new to sizers (and sometimes even experts) for all but the simplest of layouts. Hope that helps, ka _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From bobsavage@mac.com Mon Jan 14 14:47:18 2002 From: bobsavage@mac.com (Bob Savage) Date: Mon, 14 Jan 2002 08:47:18 -0600 Subject: [Pythonmac-SIG] Python-"Services" on OS X? In-Reply-To: <1010997200.3c4297d0c8b8b@webmail.in-berlin.de> Message-ID: You might well not want to do it this way, but: There is also an optional "services-like" feature on MacOSX. There is a little script menu (? I'm sure Apple has a special name for these things -- one of those things that are black icons on the right of the screen, and are available in all apps). You can put arbitrary scripts in there (originally designed for AppleScripts, but shell scripts, Perl scipts, and Python scripts work fine as well). For what you want, Services might be the best way to go, because the concept of communicating with the current app (e.g. getting the selected object) is built right in, wereas with the script menu thing, you would have to be able to communicate with the app via AppleEvents. See . best, Bob on 1/14/02 2:33 AM, Dinu Gherman wrote: > > I'd really like to write a few "services" for OS X with Python > as the primary implementation language, but I'm not sure this > is already possible? Maybe someone could drop a few lines only, > saying if it is or when to expect it? From bob@redivi.com Mon Jan 14 16:01:40 2002 From: bob@redivi.com (Bob Ippolito) Date: Mon, 14 Jan 2002 11:01:40 -0500 Subject: [Pythonmac-SIG] Python-"Services" on OS X? In-Reply-To: Message-ID: The problem with this is that it only works with the finder.. You don't need to use AppleEvents (directly) if you write the services and the shell for the embedded python interpreter in Cocoa, it's a lot quicker this way. -bob On Monday, January 14, 2002, at 09:47 AM, Bob Savage wrote: > You might well not want to do it this way, but: There is also an > optional > "services-like" feature on MacOSX. There is a little script menu (? I'm > sure > Apple has a special name for these things -- one of those things that > are > black icons on the right of the screen, and are available in all apps). > You > can put arbitrary scripts in there (originally designed for > AppleScripts, > but shell scripts, Perl scipts, and Python scripts work fine as well). > > For what you want, Services might be the best way to go, because the > concept > of communicating with the current app (e.g. getting the selected > object) is > built right in, wereas with the script menu thing, you would have to be > able > to communicate with the app via AppleEvents. > > See . > > best, > > Bob > > on 1/14/02 2:33 AM, Dinu Gherman wrote: >> >> I'd really like to write a few "services" for OS X with Python >> as the primary implementation language, but I'm not sure this >> is already possible? Maybe someone could drop a few lines only, >> saying if it is or when to expect it? > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From jack@oratrix.nl Mon Jan 14 16:15:15 2002 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 14 Jan 2002 17:15:15 +0100 Subject: [Pythonmac-SIG] Python-"Services" on OS X? In-Reply-To: Message by Dinu Gherman , Mon, 14 Jan 2002 12:16:25 +0100 , <3C42BE09.BA606F15@darwin.in-berlin.de> Message-ID: <20020114161520.D0D81E8452@oratrix.oratrix.nl> Recently, Dinu Gherman said: > > You can check out a simple set of services that I wrote at > > http://redivi.com/~bob/URLServices.tgz -- It doesn't use python, but it > > wouldn't be too hard for it to do so. > > That works fine - thanks! What I'm after is something more > of a little service template project with some stubs left for > plugging in your Python scripts (so you can forget about the > rest). Could you create an example for this? Shoething like a Rot13 service sounds like a perfect example that isn't complicated and shows all the details. For now we could create a repository of such example uses of Python, and later we can then try and get these examples included in the standard Python distribution. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From nathan@vividworks.com Mon Jan 14 16:38:08 2002 From: nathan@vividworks.com (Nathan Heagy) Date: Mon, 14 Jan 2002 10:38:08 -0600 (CST) Subject: [Pythonmac-SIG] Python-"Services" on OS X? In-Reply-To: <20020114161520.D0D81E8452@oratrix.oratrix.nl> Message-ID: > Could you create an example for this? Shoething like a Rot13 service > sounds like a perfect example that isn't complicated and shows all the > details. Ya that sounds cool. I'm gonna go read the docs on Services now. Nathan From dp@ulaluma.com Mon Jan 14 19:36:42 2002 From: dp@ulaluma.com (Donovan Preston) Date: Mon, 14 Jan 2002 11:36:42 -0800 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <4C6602AB-0829-11D6-A3F6-0030656E8732@switchedonsoftware.com> Message-ID: <0984B1A6-0926-11D6-AD04-0050E425C324@ulaluma.com> --Apple-Mail-2-517548007 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Sunday, January 13, 2002, at 05:27 AM, Adam Eijdenberg wrote: > Hello all, > > I'm toying around with the idea of developing a Python rapid > application development tool, initially just for the Mac. This tool is > written in C for Carbon, so it is native in all regards and uses the > Unix mach-o version of Python. > Sounds cool. Myself, I'm just using Interface Builder -- It already has a RAD tool for designing interfaces, and likewise saves them in an XML format. Apple has provided as a part of Carbon, IBCarbonRuntime, which allows dearchiving of Carbon Interface Builder nibs on both OS X and OS 9. I just wrapped the IBCarbonRuntime.h header provided by Apple and it has been very easy for me to load nibs and attach event handlers to them using Carbon Events. Here's an example of how little code it takes to use the module: -------------------- from Carbon import IBCarbon from Carbon import CarbonEvt # The CarbonEvents functions from Carbon import CarbonEvents # The CarbonEvents constants windowlist = [] def commandCallback(handler, event): # Get the event record describing what command was executed result = event.GetEventParameter(CarbonEvents.kEventParamDirectObject, CarbonEvents.typeHICommand) event = result[4:8] if event == 'new ': # If the user selected new window, load a nib and unarchive a window global windowlist # Create a reference to the nib named 'main' in my Application Bundle nib = IBCarbon.CreateNibReference('main') # Unarchive a window from the nib window = nib.CreateWindowFromNib('MyWindowNameInTheMainNib') # Keep the window from disappearing after the function falls out of scope windowlist.append(window) window.ShowWindow() # Get the application event target AppTarget = CarbonEvt.GetApplicationEventTarget() # Install a handler for "command" events on the application # Command events can be set using the inspector panel in Interface Builder # Many basic commands, such as new, quit, copy, paste, are already set (and many are handled automatically) cmdsHandler = target.InstallEventHandler(('cmds', 1), commandCallback) ---------------------- It's great because the window objects that CreateWindowFromNib are standard wrapped WindowRef objects in Python, and you have full access to the PythonMac toolbox wrappers. Of course, you're programming more at a C level but with a little effort, a nicer Python framework API could be constructed that used these commands (similar to W. I'm writing my own very simple one, dspFramework, for my own purposes.) The nice thing about using the PythonMac toolbox wrappers is that there is lots of documentation -- any of the C Carbon or C Toolbox documentation can be used as a reference, with minor changes for use with python. I'm attaching the IBCarbonRuntime.c file as well as the bgen files I used to generate it, in case anyone wants to play with it. Jack, maybe you'd consider putting it in the distribution this time? Donovan --Apple-Mail-2-517548007 Content-Disposition: attachment; filename=_IBCarbon.c Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-mac-creator=43574945; x-unix-mode=0644; x-mac-type=54455854; name="_IBCarbon.c" /* ======================== Module _IBCarbon ======================== */ #include "Python.h" #ifdef WITHOUT_FRAMEWORKS #include #else #include #endif /* WITHOUT_FRAMEWORKS */ #include "macglue.h" #ifdef USE_TOOLBOX_OBJECT_GLUE extern int _CFStringRefObj_Convert(PyObject *, CFStringRef *); //#define CFStringRefObj_Convert _CFStringRefObj_Convert #endif //extern int CFBundleRefObj_Convert(PyObject *, CFBundleRef *); // need to wrap CFBundle static PyObject *IBCarbon_Error; /* ---------------------- Object type IBNibRef ---------------------- */ PyTypeObject IBNibRef_Type; #define IBNibRefObj_Check(x) ((x)->ob_type == &IBNibRef_Type) typedef struct IBNibRefObject { PyObject_HEAD IBNibRef ob_itself; } IBNibRefObject; PyObject *IBNibRefObj_New(IBNibRef itself) { IBNibRefObject *it; it = PyObject_NEW(IBNibRefObject, &IBNibRef_Type); if (it == NULL) return NULL; it->ob_itself = itself; return (PyObject *)it; } int IBNibRefObj_Convert(PyObject *v, IBNibRef *p_itself) { if (!IBNibRefObj_Check(v)) { PyErr_SetString(PyExc_TypeError, "IBNibRef required"); return 0; } *p_itself = ((IBNibRefObject *)v)->ob_itself; return 1; } static void IBNibRefObj_dealloc(IBNibRefObject *self) { DisposeNibReference(self->ob_itself); PyMem_DEL(self); } static PyObject *IBNibRefObj_CreateWindowFromNib(IBNibRefObject *_self, PyObject *_args) { PyObject *_res = NULL; OSStatus _err; CFStringRef inName; WindowPtr outWindow; if (!PyArg_ParseTuple(_args, "O&", CFStringRefObj_Convert, &inName)) return NULL; Py_BEGIN_ALLOW_THREADS _err = CreateWindowFromNib(_self->ob_itself, inName, &outWindow); Py_END_ALLOW_THREADS if (_err != noErr) return PyMac_Error(_err); _res = Py_BuildValue("O&", WinObj_New, outWindow); return _res; } static PyObject *IBNibRefObj_CreateMenuFromNib(IBNibRefObject *_self, PyObject *_args) { PyObject *_res = NULL; OSStatus _err; CFStringRef inName; MenuHandle outMenuRef; if (!PyArg_ParseTuple(_args, "O&", CFStringRefObj_Convert, &inName)) return NULL; Py_BEGIN_ALLOW_THREADS _err = CreateMenuFromNib(_self->ob_itself, inName, &outMenuRef); Py_END_ALLOW_THREADS if (_err != noErr) return PyMac_Error(_err); _res = Py_BuildValue("O&", MenuObj_New, outMenuRef); return _res; } static PyObject *IBNibRefObj_CreateMenuBarFromNib(IBNibRefObject *_self, PyObject *_args) { PyObject *_res = NULL; OSStatus _err; CFStringRef inName; Handle outMenuBar; if (!PyArg_ParseTuple(_args, "O&", CFStringRefObj_Convert, &inName)) return NULL; Py_BEGIN_ALLOW_THREADS _err = CreateMenuBarFromNib(_self->ob_itself, inName, &outMenuBar); Py_END_ALLOW_THREADS if (_err != noErr) return PyMac_Error(_err); _res = Py_BuildValue("O&", ResObj_New, outMenuBar); return _res; } static PyObject *IBNibRefObj_SetMenuBarFromNib(IBNibRefObject *_self, PyObject *_args) { PyObject *_res = NULL; OSStatus _err; CFStringRef inName; if (!PyArg_ParseTuple(_args, "O&", CFStringRefObj_Convert, &inName)) return NULL; Py_BEGIN_ALLOW_THREADS _err = SetMenuBarFromNib(_self->ob_itself, inName); Py_END_ALLOW_THREADS if (_err != noErr) return PyMac_Error(_err); Py_INCREF(Py_None); _res = Py_None; return _res; } static PyMethodDef IBNibRefObj_methods[] = { {"CreateWindowFromNib", (PyCFunction)IBNibRefObj_CreateWindowFromNib, 1, "(CFStringRef inName) -> (WindowPtr outWindow)"}, {"CreateMenuFromNib", (PyCFunction)IBNibRefObj_CreateMenuFromNib, 1, "(CFStringRef inName) -> (MenuHandle outMenuRef)"}, {"CreateMenuBarFromNib", (PyCFunction)IBNibRefObj_CreateMenuBarFromNib, 1, "(CFStringRef inName) -> (Handle outMenuBar)"}, {"SetMenuBarFromNib", (PyCFunction)IBNibRefObj_SetMenuBarFromNib, 1, "(CFStringRef inName) -> None"}, {NULL, NULL, 0} }; PyMethodChain IBNibRefObj_chain = { IBNibRefObj_methods, NULL }; static PyObject *IBNibRefObj_getattr(IBNibRefObject *self, char *name) { return Py_FindMethodInChain(&IBNibRefObj_chain, (PyObject *)self, name); } #define IBNibRefObj_setattr NULL #define IBNibRefObj_compare NULL #define IBNibRefObj_repr NULL #define IBNibRefObj_hash NULL PyTypeObject IBNibRef_Type = { PyObject_HEAD_INIT(NULL) 0, /*ob_size*/ "_IBCarbon.IBNibRef", /*tp_name*/ sizeof(IBNibRefObject), /*tp_basicsize*/ 0, /*tp_itemsize*/ /* methods */ (destructor) IBNibRefObj_dealloc, /*tp_dealloc*/ 0, /*tp_print*/ (getattrfunc) IBNibRefObj_getattr, /*tp_getattr*/ (setattrfunc) IBNibRefObj_setattr, /*tp_setattr*/ (cmpfunc) IBNibRefObj_compare, /*tp_compare*/ (reprfunc) IBNibRefObj_repr, /*tp_repr*/ (PyNumberMethods *)0, /* tp_as_number */ (PySequenceMethods *)0, /* tp_as_sequence */ (PyMappingMethods *)0, /* tp_as_mapping */ (hashfunc) IBNibRefObj_hash, /*tp_hash*/ }; /* -------------------- End object type IBNibRef -------------------- */ static PyObject *IBCarbon_CreateNibReference(PyObject *_self, PyObject *_args) { PyObject *_res = NULL; OSStatus _err; CFStringRef inNibName; IBNibRef outNibRef; if (!PyArg_ParseTuple(_args, "O&", CFStringRefObj_Convert, &inNibName)) return NULL; Py_BEGIN_ALLOW_THREADS _err = CreateNibReference(inNibName, &outNibRef); Py_END_ALLOW_THREADS if (_err != noErr) return PyMac_Error(_err); _res = Py_BuildValue("O&", IBNibRefObj_New, outNibRef); return _res; } static PyMethodDef IBCarbon_methods[] = { {"CreateNibReference", (PyCFunction)IBCarbon_CreateNibReference, 1, "(CFStringRef inNibName) -> (IBNibRef outNibRef)"}, {NULL, NULL, 0} }; void init_IBCarbon(void) { PyObject *m; PyObject *d; m = Py_InitModule("_IBCarbon", IBCarbon_methods); d = PyModule_GetDict(m); IBCarbon_Error = PyMac_GetOSErrException(); if (IBCarbon_Error == NULL || PyDict_SetItemString(d, "Error", IBCarbon_Error) != 0) return; IBNibRef_Type.ob_type = &PyType_Type; Py_INCREF(&IBNibRef_Type); if (PyDict_SetItemString(d, "IBNibRefType", (PyObject *)&IBNibRef_Type) != 0) Py_FatalError("can't initialize IBNibRefType"); } /* ====================== End module _IBCarbon ====================== */ --Apple-Mail-2-517548007 Content-Disposition: attachment Content-Type: multipart/appledouble; boundary=Apple-Mail-3-517548009 --Apple-Mail-3-517548009 Content-Disposition: attachment; filename=IBCarbonscan.py Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="IBCarbonscan.py" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAAAoAAAADAAAASAAAAA8AAAACAAAA VwAAAX5URVhUUipjaAEASUJDYXJib25zY2FuLnB5AAABAAAAAUwAAABMAAAAMgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEgACU1vbmFjbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYABABPAAMCvwJ9AE8AAwK/ An24aG9uAAABggAAAYIAAAAAAQAAAAEAAAABTAAAAEwAAAAyACbAkAH7AAAAHAAyAABNUFNSAAAA CgPt//8AAAAAAh9UwA== --Apple-Mail-3-517548009 Content-Disposition: attachment; filename=IBCarbonscan.py Content-Transfer-Encoding: 7bit Content-Type: application/text; x-mac-creator=522A6368; x-unix-mode=0644; x-mac-type=54455854; name="IBCarbonscan.py" # IBCarbonscan.py import sys import os import string import MacOS BGENDIR= '/Users/dp/python/dist/src/Tools/bgen/bgen' sys.path.append(BGENDIR) print sys.path, sys.prefix from bgenlocations import TOOLBOXDIR from scantools import Scanner_OSX def main(): print "---Scanning IBCarbonRuntime.h---" input = ["IBCarbonRuntime.h"] output = "IBCarbongen.py" defsoutput = TOOLBOXDIR + "IBCarbonRuntime.py" scanner = IBCarbon_Scanner(input, output, defsoutput) scanner.scan() scanner.close() print "--done scanning, importing--" import IBCarbonsupport print "done" class IBCarbon_Scanner(Scanner_OSX): def destination(self, type, name, arglist): classname = "IBCarbonFunction" listname = "functions" if arglist: t, n, m = arglist[0] if t == "IBNibRef" and m == "InMode": classname = "IBCarbonMethod" listname = "methods" return classname, listname def makeblacklistnames(self): return [ "DisposeNibReference", # taken care of by destructor "CreateNibReferenceWithCFBundle", ## need to wrap CFBundle.h properly first ] if __name__ == "__main__": main() --Apple-Mail-3-517548009-- --Apple-Mail-2-517548007 Content-Disposition: attachment Content-Type: multipart/appledouble; boundary=Apple-Mail-4-517548011 --Apple-Mail-4-517548011 Content-Disposition: attachment; filename=IBCarbonsupport.py Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="IBCarbonsupport.py" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAAAoAAAADAAAASAAAABIAAAACAAAA WgAAAX5URVhUUipjaAEASUJDYXJib25zdXBwb3J0LnB5AAABAAAAAUwAAABMAAAAMgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAEgACU1vbmFjbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYABABTAJgCvQMSAFMA mAK9AxK4aHCPAAABdAAAAXQAAAAAAQAAAAEAAAABTAAAAEwAAAAyACbAkALQAAAAHAAyAABNUFNS AAAACgPt//8AAAAAAh9GpA== --Apple-Mail-4-517548011 Content-Disposition: attachment; filename=IBCarbonsupport.py Content-Transfer-Encoding: 7bit Content-Type: application/text; x-mac-creator=522A6368; x-unix-mode=0644; x-mac-type=54455854; name="IBCarbonsupport.py" # IBCarbonsupport.py from macsupport import * CFStringRef = OpaqueByValueType('CFStringRef', 'CFStringRefObj') IBNibRef = OpaqueByValueType('IBNibRef', 'IBNibRefObj') #CFBundleRef = OpaqueByValueType('CFBundleRef') IBCarbonFunction = OSErrFunctionGenerator IBCarbonMethod = OSErrMethodGenerator includestuff = """ #ifdef WITHOUT_FRAMEWORKS #include #else #include #endif /* WITHOUT_FRAMEWORKS */ #include "macglue.h" #ifdef USE_TOOLBOX_OBJECT_GLUE extern int _CFStringRefObj_Convert(PyObject *, CFStringRef *); //#define CFStringRefObj_Convert _CFStringRefObj_Convert #endif //extern int CFBundleRefObj_Convert(PyObject *, CFBundleRef *); // need to wrap CFBundle """ initstuff = """ """ module = MacModule('_IBCarbon', 'IBCarbon', includestuff, finalstuff, initstuff) class CFReleaserObject(GlobalObjectDefinition): def outputFreeIt(self, name): Output("CFRelease(%s);" % name) class CFNibDesc(GlobalObjectDefinition): def outputFreeIt(self, name): Output("DisposeNibReference(%s);" % name) #cfstringobject = CFReleaserObject("CFStringRef") #module.addobject(cfstringobject) #cfbundleobject = CFReleaserObject("CFBundleRef") #module.addobject(cfbundleobject) ibnibobject = CFNibDesc("IBNibRef", "IBNibRefObj") module.addobject(ibnibobject) functions = [] methods = [] execfile('IBCarbongen.py') for f in functions: module.add(f) for m in methods: ibnibobject.add(m) SetOutputFileName('_IBCarbon.c') module.generate() --Apple-Mail-4-517548011-- --Apple-Mail-2-517548007-- From dp@ulaluma.com Mon Jan 14 19:43:53 2002 From: dp@ulaluma.com (Donovan Preston) Date: Mon, 14 Jan 2002 11:43:53 -0800 Subject: [Pythonmac-SIG] Mach-O MacPython In-Reply-To: <20020111235043.3AEF7E8451@oratrix.oratrix.nl> Message-ID: <0A142DC1-0927-11D6-AD04-0050E425C324@ulaluma.com> Hey, Jack. Having been busy over the holidays and thereafter I haven't looked at SourceForge for a while, but just before christmas (I think) I submitted a Patch which implements the beginning of what we were talking about doing as far as handling FSSpec/FSRefs on Mach-O Python, as well as patches to the IDE .py files using your suggested syntax hasattr(MacOS, 'whatever'). I just looked in SourceForge and noticed the patch is still sitting there, unnoticed. Should I have sent mail at the same time I submitted the patch? I had assumed you would get some sort of automatic notification, since it is assigned to you. Anyway, the patch is there, and with that patch applied, I have had the MacPython IDE up and running in a Mach-O Python bundle for a few weeks now. It's cool! http://sourceforge.net/tracker/index.php?func=detail&aid=496096&group_id=5470& atid=305470 Donovan From adam@switchedonsoftware.com Mon Jan 14 20:15:03 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Tue, 15 Jan 2002 07:15:03 +1100 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <0984B1A6-0926-11D6-AD04-0050E425C324@ulaluma.com> Message-ID: <65129484-092B-11D6-A55B-0030656E8732@switchedonsoftware.com> > I just wrapped the IBCarbonRuntime.h header provided by Apple and it > has been very easy for me to load nibs and attach event handlers to > them using Carbon Events. That looks a fine module, but it is approaching the problem from the opposite end of where I'm coming from. I don't want a Python program with native tie-ins, I want a native program that happens to use Python as a scripting language. Probably only just a philosophical difference, but hopefully it will become clearer as I progress a bit further. Adam From dp@ulaluma.com Mon Jan 14 20:42:07 2002 From: dp@ulaluma.com (Donovan Preston) Date: Mon, 14 Jan 2002 12:42:07 -0800 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <65129484-092B-11D6-A55B-0030656E8732@switchedonsoftware.com> Message-ID: <2D3141BA-092F-11D6-AD04-0050E425C324@ulaluma.com> On Monday, January 14, 2002, at 12:15 PM, Adam Eijdenberg wrote: >> I just wrapped the IBCarbonRuntime.h header provided by Apple and it >> has been very easy for me to load nibs and attach event handlers to >> them using Carbon Events. > > That looks a fine module, but it is approaching the problem from the > opposite end of where I'm coming from. I don't want a Python program > with native tie-ins, I want a native program that happens to use Python > as a scripting language. Probably only just a philosophical difference, > but hopefully it will become clearer as I progress a bit further. I understand what you are saying. However, I don't really think it's all that different from what you are trying to achieve. The advantages of using the Python interpreter as the application's main binary and performing all OS-level API access using wrapped Python modules are many. You don't have to deal with memory management, and you can write your application in a much more dynamic fashion. The speed you gain by going with a straight-c application which calls out to Python occasionally is negligible. For example, in an application I am writing, I need to be able to do some 2d drawing. I started by writing an OpenGL wrapper module which would set up the GL context in the constructor and destroy it in the destructor, and had a very small set of well-defined calls for drawing, clearing the drawing area, and setting and restoring the drawing state. This module works equally well on OS 9 as it does on X, and should work with a minor amount of tweaking on Windows as well. The only changes will be in the C module, not my Python code. However, the real power revealed itself to me when I decided to write an adapter for CoreGraphics on OS X. Since CoreGraphics doesn't run anywhere but X, this module will only be useful on X. In 5 minutes, thanks to Just's CG module, I was able to write an adapter which set up the CG context and implemented all of the drawing and state commands I had defined for my GL module. Big deal, you say? Well, I was able, with a few minutes more work, to put a pop-up list in a preference panel and allow the user to switch between GL and CG rendering. While the program is running. With almost no additional work, since all of the setup/tear down is handled in the Python constructors/destructors. Basically, the switching code looks like this: self._draw = CGDrawAdapter(self._window) The simple act of assignment destroys the old context, and the constructor for CGDrawAdapter handles the setup for the new context. Just like that. While I admire the progress you have made with your RAD tool, personally I would rather spend more of my time programming in Python than in C. You'd be amazed at how well it works, and how easy it makes programming an otherwise yucky C API. Donovan From dp@ulaluma.com Mon Jan 14 21:33:26 2002 From: dp@ulaluma.com (Donovan Preston) Date: Mon, 14 Jan 2002 13:33:26 -0800 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <6A3ABF6A-092F-11D6-9FFD-00039315F03C@swdev.com> Message-ID: <587CC3B2-0936-11D6-B14A-0050E425C324@ulaluma.com> --Apple-Mail-1-524552443 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Monday, January 14, 2002, at 12:43 PM, Patrick Curtain wrote: > Donovan, how does one -build- that library from _IBCarbon.c. I'd love > to try it. --p Cool. Yeah, I meant to add that, but my message got a bit long. First, let me start by assuming you have built Python as a framework on OS X from the 2.2 source or CVS. Details are in the README. I will also assume you have built the Python interpreter bundle in Mac/OSX as detailed in the README there. You also need to have installed the Mac subtree and add the Mac subtree to your path, also as detailed in the README in Mac/OSX. It's possible to use the module on OS 9 as well, and I have done so, but it's a bit more involved so I'll leave that out for now. In your Python source tree, navigate to Mac/Modules. Create a folder called ibcarbon. Place my attached files from the previous message there. In the main level of the python source, there is a setup.py file. This file builds all of the modules. Open this in your favorite text editor and search for one of the Mac modules, say, CarbonEvt. Here are the lines that sets up the CarbonEvt module to be compiled: exts.append( Extension('_CarbonEvt', ['carbonevt/_CarbonEvtmodule.c'], extra_link_args=['-framework', 'Carbon']) ) Copy and paste these two lines and change CarbonEvt to IBCarbon, like this: exts.append( Extension('_IBCarbon', ['ibcarbon/_IBCarbon.c'], extra_link_args=['-framework', 'Carbon']) ) Save setup.py and in a terminal at the top level of the Python source tree, run 'make sharedinstall'. This will remake all the shared libraries and install them. Oh, and one more thing. We've just created a module called _IBCarbon, but we want to say 'import IBCarbon' (no underscore). Not sure why things are set up this way, but you need to create a file: /Library/Frameworks/Python.framework/Versions/Current/Mac/Lib/Carbon/IBCarbon. py Containing the line: from _IBCarbon import * Next, we need to execute some Python code from within a Bundle. If you built the Python interpreter bundle as I mentioned previously, there will be one available in /Applications/Python.app. Right click (or control click) on this bundle and choose "Show package contents." Navigate into Contents/Resources inside of the bundle. Here is where we can put a __main__.py file which will be run when the application is double clicked. Inside of English.lproj is where the Interface Builder nib we will load goes. I have attached a __main__.py file which you can drag into Contents/Resources. There's a few bug fixes from the code in my last message. I've also attached a nib which you can drag inside of English.lproj. Try adding widgets to this nib! Now you can fire up Python.app and create all the new windows you want! Donovan --Apple-Mail-1-524552443 Content-Disposition: attachment Content-Type: multipart/appledouble; boundary=Apple-Mail-2-524552446 --Apple-Mail-2-524552446 Content-Disposition: attachment; filename=__main__.py Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="__main__.py" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAAAoAAAADAAAASAAAAAsAAAACAAAA UwAAAX5URVhUUipjaAAAX19tYWluX18ucHkAAAEAAAABTAAAAEwAAAAyAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA SAAJTW9uYWNvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAEAC8AAwL3AxkALwADAvcDGbho jOEAAANLAAADSwAAAAABAAAAAQAAAAFMAAAATAAAADIAJsCQAVoAAAAcADIAAE1QU1IAAAAKA+3/ /wAAAAAB5MDU --Apple-Mail-2-524552446 Content-Disposition: attachment; filename=__main__.py Content-Transfer-Encoding: 7bit Content-Type: application/text; x-mac-creator=522A6368; x-unix-mode=0644; x-mac-type=54455854; name="__main__.py" from Carbon import IBCarbon from Carbon import CarbonEvt # The CarbonEvents functions from Carbon import CarbonEvents # The CarbonEvents constants windowlist = [] def commandCallback(handler, event): print "yo" # Get the event record describing what command was executed result = event.GetEventParameter(CarbonEvents.kEventParamDirectObject, CarbonEvents.typeHICommand) event = result[4:8] if event == 'new ': # If the user selected new window, load a nib and unarchive a window global windowlist # Create a reference to the nib named 'main' in my Application Bundle nib = IBCarbon.CreateNibReference('main') # Unarchive a window from the nib window = nib.CreateWindowFromNib('MainWindow') # Keep the window from disappearing after the function falls out of scope windowlist.append(window) window.ShowWindow() return CarbonEvents.eventNotHandledErr # Install a menu bar nib = IBCarbon.CreateNibReference('main') nib.SetMenuBarFromNib('MenuBar') # Get the application event target AppTarget = CarbonEvt.GetApplicationEventTarget() # Install a handler for "command" events on the application # Command events can be set using the inspector panel in Interface Builder # Many basic commands, such as new, quit, copy, paste, are already set (and many are handled automatically) cmdsHandler = AppTarget.InstallEventHandler(('cmds', 1), commandCallback) CarbonEvt.RunApplicationEventLoop() --Apple-Mail-2-524552446-- --Apple-Mail-1-524552443 Content-Disposition: attachment; filename=main.nib Content-Type: multipart/x-folder; boundary=Apple-Mail-3-524552448; x-unix-mode=0777; name="main.nib" --Apple-Mail-3-524552448 Content-Disposition: attachment; filename=classes.nib Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="classes.nib" { IBClasses = (); IBVersion = 1; } --Apple-Mail-3-524552448 Content-Disposition: attachment; filename=objects.xib Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="objects.xib" IBCarbonFramework NSApplication main NewApplication NewApplication About NewApplication 0 abou TRUE _NSAppleMenu File File New n new Open... o open TRUE Close w clos Save s save Save As... S svas Revert r rvrt TRUE Page Setup... P page Print... p prnt Edit Edit Undo z undo Redo Z redo TRUE Cut x cut Copy c copy Paste v past Clear clea Select All a sall Window Window TRUE Minimize Window m mini TRUE Minimize All Windows m 1572864 mina TRUE TRUE Bring All to Front bfrt TRUE Arrange in Front 1572864 frnt _NSWindowsMenu _NSMainMenu 49 5 209 501 Window 0 0 160 496 20 142 36 341 Hello from IBCarbonRuntime! 6 5 4 Files Owner MainWindow MenuBar 197 --Apple-Mail-3-524552448 Content-Disposition: attachment; filename=info.nib Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="info.nib" IBEditorPositions 29 69 252 273 44 0 0 1024 746 IBFramework Version 219.0 IBMainMenuLocation 69 252 273 44 0 0 1024 746 IBOpenObjects 29 166 IBSystem Version 5P48 targetFramework IBCarbonFramework --Apple-Mail-3-524552448-- --Apple-Mail-1-524552443-- From adam@switchedonsoftware.com Mon Jan 14 21:39:54 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Tue, 15 Jan 2002 08:39:54 +1100 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <2D3141BA-092F-11D6-AD04-0050E425C324@ulaluma.com> Message-ID: <3F269375-0937-11D6-95D2-0030656E8732@switchedonsoftware.com> >> That looks a fine module, but it is approaching the problem from the >> opposite end of where I'm coming from. I don't want a Python program >> with native tie-ins, I want a native program that happens to use >> Python as a scripting language. Probably only just a philosophical >> difference, but hopefully it will become clearer as I progress a bit >> further. > > I understand what you are saying. However, I don't really think it's > all that different from what you are trying to achieve. The advantages > of using the Python interpreter as the application's main binary and > performing all OS-level API access using wrapped Python modules are > many. You don't have to deal with memory management, and you can write > your application in a much more dynamic fashion. The speed you gain by > going with a straight-c application which calls out to Python > occasionally is negligible. I'm not going for speed, I'm trying to target a lower-end user. You and I and probably most people on this list are developers. We can write programs from scratch in Python/C/Java/whatever takes our fancy. Although what I've done so far doesn't make the context clear, I want an environment where programming isn't the main emphasis. To reiterate, my eventual goal is to make a frontend for databases. Look at the scripting in FileMaker if you have it. Non programmers can write scripts in this. Programmers are frustrated by it. I want Python to achieve the middle ground within my application. If I manage to provide similar functionality in my final app (with preset "wizards" (in MS terminology) for common actions like in Access) then I feel I achieved something. Perhaps I chose an inappropriate title for this thread. For "real" programmers you probably are better off starting from scratch using modules such as your own or PythonCard. For a gentler introduction to programming, I think it would be nice not to have code as the central emphasis. Adam From lmeyn@mail.arc.nasa.gov Mon Jan 14 21:41:51 2002 From: lmeyn@mail.arc.nasa.gov (Larry Meyn) Date: Mon, 14 Jan 2002 13:41:51 -0800 Subject: [Pythonmac-SIG] Tkinter strikes again In-Reply-To: <20020111235043.3AEF7E8451@oratrix.oratrix.nl> References: <20020111235043.3AEF7E8451@oratrix.oratrix.nl> Message-ID: I'm getting the same "Cannot load init.tcl" error as before, even though Tcl/Tk 8.3.4 is installed. One thing I did notice the first time around is that the old _tkinter libraries were still being used after I moved them out of the lib-dynload and replaced them with the new files. This might account for the strange restart behavior people are seeing. >Folks, >new versions of _tkinter for Carbon and classic PPC are available in >http://www.cwi.nl/ftp/jack/python/mac/newer . > >These versions require an installed Tcl/Tk 8.3.4, which you can get >via http://prdownloads.sourceforge.net/tcl/TclTk_8.3.4_WebInstall.bin >. Alternative installers are available through >http://tcl.sourceforge.net . > >Unfortunately if you *don't* install Tcl/Tk, you get the error message >at a rather late stage: not when you're importing Tkinter but when you >first try to use it. And the message is rather cryptic, something like >"Cannot load init.tcl, maybe you need to install Tcl or set TCL_PATH". >Suggestions as to how to fix this are welcome. >-- >- Jack Jansen http://www.cwi.nl/~jack - >- If I can't dance I don't want to be part of your revolution -- Emma Goldman - > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ---------------------------------------------------------------------- Larry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center FAX: (650) 604-0222 Moffett Field, CA 94035-1000 email: lmeyn@mail.arc.nasa.gov E-FAX: (425) 944-5526 sent via e-mail ---------------------------------------------------------------------- From altis@semi-retired.com Mon Jan 14 22:12:59 2002 From: altis@semi-retired.com (Kevin Altis) Date: Mon, 14 Jan 2002 14:12:59 -0800 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: <3F269375-0937-11D6-95D2-0030656E8732@switchedonsoftware.com> Message-ID: I think you are missing the point I and some others are trying to make about developing apps. What language, toolkits, etc. you as a developer use to program your solution is independent of what the users of your program will see and use. You say you want to create a frontend for databases with scripting capabilities using Python as the scripting language and you want it to be easy for non-programmers to use. Correct? You could build that solution with C and embed Python. You could use tkinter (maybe), you could use raw wxPython or PythonCard, you could probably even create it with AppleScript Studio. The user won't know or care. What you should care about is the time and effort involved in creating and maintaining your solution and whether one language or toolkit simplifies getting the behavior you're looking for better than others. I know that you can dynamically add components, functions and methods and event handlers at runtime using PythonCard and you should be able to do the same with tkinter or some of the other Mac solutions MacPython developers already use. That takes care of what could otherwise be a tough dynamic UI design problem, since that sounds like one of your issues. If it isn't then the runtime capabilities of your development solution are not as important. We definitely have several people in the PythonCard group that are specifically interested in apps doing almost exactly what you've described, there is even a dbBrowser sample for viewing MySQL and Oracle databases that will grow in capabilities, maybe like those you've described. In general, you don't need to be concerned with runtime speed of the UI when programming with Python, especially if native widgets are used. I can echo the sentiments on using Python even for drawing operations. PythonCard has a few samples that I was surprised to find run faster than the same algorithm that I did as a Java applet. You won't be able to tell the difference between C and Python for things like menus, dialog boxes, buttons, fields, etc. and if there is a particular function that is slow for some reason like a long drawing routine, then optimize that later and wrap it with Python. This is common practice. If you want a Mac-only solution, IB with Python bindings might in fact be the best choice, I don't know. Obviously, if you want the potential of a cross-platform solution, IB is out of the picture. If what you really want is to program your own solution for fun or a sense of accomplishment, whatever, that's also fine. The point I want to make is that Python can do what you want. Your project does overlap others already in progress, so if you want to contribute instead of going it alone that is also good. ka > From: Adam Eijdenberg > > >> That looks a fine module, but it is approaching the problem from the > >> opposite end of where I'm coming from. I don't want a Python program > >> with native tie-ins, I want a native program that happens to use > >> Python as a scripting language. Probably only just a philosophical > >> difference, but hopefully it will become clearer as I progress a bit > >> further. > > > > I understand what you are saying. However, I don't really think it's > > all that different from what you are trying to achieve. The advantages > > of using the Python interpreter as the application's main binary and > > performing all OS-level API access using wrapped Python modules are > > many. You don't have to deal with memory management, and you can write > > your application in a much more dynamic fashion. The speed you gain by > > going with a straight-c application which calls out to Python > > occasionally is negligible. > > I'm not going for speed, I'm trying to target a lower-end user. You and > I and probably most people on this list are developers. We can write > programs from scratch in Python/C/Java/whatever takes our fancy. > Although what I've done so far doesn't make the context clear, I want an > environment where programming isn't the main emphasis. To reiterate, my > eventual goal is to make a frontend for databases. Look at the scripting > in FileMaker if you have it. Non programmers can write scripts in this. > Programmers are frustrated by it. I want Python to achieve the middle > ground within my application. If I manage to provide similar > functionality in my final app (with preset "wizards" (in MS terminology) > for common actions like in Access) then I feel I achieved something. > > Perhaps I chose an inappropriate title for this thread. For "real" > programmers you probably are better off starting from scratch using > modules such as your own or PythonCard. For a gentler introduction to > programming, I think it would be nice not to have code as the central > emphasis. > > Adam From bob@redivi.com Mon Jan 14 22:26:19 2002 From: bob@redivi.com (Bob Ippolito) Date: Mon, 14 Jan 2002 17:26:19 -0500 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: Message-ID: On Monday, January 14, 2002, at 05:12 PM, Kevin Altis wrote: =snip= > > If you want a Mac-only solution, IB with Python bindings might in fact > be > the best choice, I don't know. Obviously, if you want the potential of a > cross-platform solution, IB is out of the picture. > =snip= IB's nibs are in XML, no? Why wouldn't it be possible to write something to turn IB stuff into GTK, wxWindows, etc descriptions of a UI? If the destination thing doesn't have a template system, it could automagically generate the python or C code to create said interface. I wouldn't rule it out entirely. IB is a powerful tool and would be a good thing to use until something open and cross-platform is developed to take its place. In any case, a conduit to/from IB would be a good thing anyways. -bob From dp@ulaluma.com Tue Jan 15 00:03:17 2002 From: dp@ulaluma.com (Donovan Preston) Date: Mon, 14 Jan 2002 16:03:17 -0800 Subject: [Pythonmac-SIG] Python RAD tools In-Reply-To: Message-ID: <4759152D-094B-11D6-B24A-0050E425C324@ulaluma.com> On Monday, January 14, 2002, at 02:26 PM, Bob Ippolito wrote: > > On Monday, January 14, 2002, at 05:12 PM, Kevin Altis wrote: > > =snip= >> >> If you want a Mac-only solution, IB with Python bindings might in fact >> be >> the best choice, I don't know. Obviously, if you want the potential >> of a >> cross-platform solution, IB is out of the picture. >> > =snip= > > IB's nibs are in XML, no? Why wouldn't it be possible to write > something to turn IB stuff into GTK, wxWindows, etc descriptions of a > UI? If the destination thing doesn't have a template system, it could > automagically generate the python or C code to create said interface. > I wouldn't rule it out entirely. IB is a powerful tool and would be a > good thing to use until something open and cross-platform is developed > to take its place. In any case, a conduit to/from IB would be a good > thing anyways. Bingo. That's on my Todo list as well as many other things. My thought was, since I am targeting MacOS as the initial platform, it's nice to have InterfaceBuilder to build a rich interface quickly. But since I plan on targeting Windows eventually, I will at some point parse the Interface Builder XML and (probably) produce wxWindows widgets. Donovan From jack@oratrix.nl Tue Jan 15 12:31:52 2002 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 15 Jan 2002 13:31:52 +0100 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples Message-ID: <20020115123152.4A24EE8451@oratrix.oratrix.nl> Folks, it seems we now have a large choice of ways to program an Aqua interface: - Old-style resource based, with or without Framework - W - IB with Carbon? (not sure if that works yet) - AppleScript Studio? - Adam's Vyper - Tkinter - wxWindows to come soon - IB with ObjC interface module to come at some point in the future. How about picking a single simple example, like Apple's own currency converter example, and building that with all the various toolkits we have, so that we can all see what the advantages and drawbacks of the various methods are? -- - 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@oratrix.nl Tue Jan 15 20:29:11 2002 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 15 Jan 2002 21:29:11 +0100 Subject: [Pythonmac-SIG] Forwarded: "Josephson, Neal": ANN: HAP Python Remote Debugger 0.2 Released Message-ID: <20020115202916.79D12E8451@oratrix.oratrix.nl> --boogadaboogadabooga Content-Type: text/plain; charset="us-ascii" This just came by on the python-announce list, is anyone willing to have a look at it and see whether it could be integrated with the MacPython IDE debugger? If it can that might allow a couple of nice things that aren't currently possible, such as debugging Tkinter scripts from the IDE (by running the script in a separate interpreter, outside of the IDE) and debugging MachoPython scripts with IDE running under MacPython on OSX. --boogadaboogadabooga Content-Type: message/rfc822 >From python-announce-list-admin@python.org Tue Jan 15 16: 50:58 2002 Return-Path: Delivered-To: jack@oratrix.nl Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.8]) by oratrix.oratrix.nl (Postfix) with ESMTP id D0E9EE8451 for ; Tue, 15 Jan 2002 16:50:58 +0100 (MET) Received: from mail.python.org (mail.python.org [63.102.49.29]) by hera.cwi.nl with ESMTP id QAA07011 for ; Tue, 15 Jan 2002 16:50:57 +0100 (MET) Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org) by mail.python.org with esmtp (Exim 3.21 #1) id 16QVnU-00005i-00; Tue, 15 Jan 2002 10:46:48 -0500 Path: news.baymountain.net!not-for-mail From: "Josephson, Neal" Newsgroups: comp.lang.python.announce Subject: ANN: HAP Python Remote Debugger 0.2 Released Organization: Baymountain Lines: 36 Message-ID: NNTP-Posting-Host: mail.python.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: news.baymountain.net 1011112719 9663 63.102.49.29 (15 Jan 2002 16:38: 39 GMT) X-Complaints-To: abuse@baymountain.net NNTP-Posting-Date: 15 Jan 2002 16:38:39 GMT X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: clpa-moderators@python.org X-Mailman-Version: 2.0.8 (101270) Precedence: bulk X-BeenThere: clpa-moderators@python.org X-Original-Cc: bruced@humongous.com X-Original-Cc: nmjoseph@earthlink.net X-Original-To: python-announce@python.org Xref: news.baymountain.net comp.lang.python.announce:1407 To: python-announce-list@python.org Sender: python-announce-list-admin@python.org Errors-To: python-announce-list-admin@python.org X-BeenThere: python-announce-list@python.org List-Help: List-Post: List-Subscribe: , List-Id: Announcement-only list for the Python programming language List-Unsubscribe: , List-Archive: Date: Mon, 14 Jan 2002 10:54:16 -0800 The HAP Debugger is a remote debugger and IDE for Python. It was developed by the systems group at Humongous Entertainment for use with internal tools. We hope that by releasing it to the Python community (LGPL), others can use and extend it. We began work on this primarily because we needed a remote debugger. This made it easier to debug full screen apps and it also allowed us to handle other systems (Mac) by porting only the remote portion of the debugger and leaving the rest of the IDE on the Windows platform only. Once we added the scintilla control and started using it, we got to liking it and decided to release it in the hope that others would find it useful as well. Some of the features: -Local and remote debugging -Break into running code -Debug applications with their own message pump, since the debugger and debuggee are separate processes. -Source editing by Scintilla -Set breakpoints in running code -Modify values in watch, locals and globals windows -Visual Studio style interface We welcome all comments and suggestions as well as any submissions. The HAP Debugger is hosted by SourceForge: http://sourceforge.net/projects/hapdebugger/

Hap Debugger Beta 0.2 - A new open source (LGPL) remote debugger (and IDE) for Python. (14-Jan-02) -- http://mail.python.org/mailman/listinfo/python-announce-list --boogadaboogadabooga-- From jack@oratrix.nl Tue Jan 15 21:14:45 2002 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 15 Jan 2002 22:14:45 +0100 Subject: [Pythonmac-SIG] Tkinter - out of good ideas Message-ID: <20020115211445.13AB7E8451@oratrix.oratrix.nl> Folks, I'm out of good ideas. The new Tkinter worked for at least one person besides me, and didn't work for three people. I've tried renaming both my disk and paths leading to the Tk home folder to contain non-ascii characters, but everything still works. I can't make Tkinter fail for me. Unless people have bright new ideas I think I will revert to Tcl/Tk 8.3.0 and redo the trick I did for 8.3.4 Carbon Tkinter with that. That is, unless anyone has a bright idea as to anything else I can try to repeat the behaviour Larry, Christian and ... uhm.. forgot who else are seeing. -- - 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@oratrix.nl Tue Jan 15 21:32:15 2002 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 15 Jan 2002 22:32:15 +0100 Subject: [Pythonmac-SIG] OSX Multiprocessor - tentative fix available Message-ID: <20020115213215.33062E8451@oratrix.oratrix.nl> Folks, after Alexandre's work to make GUSI safe on OSX multiprocessors I've created a new PythonCoreCarbon that should work on multiprocessors. At least, that's the theory:-) If some people with an OSX multiprocessor machine could test this that would be great, and please report back here. MacPython 2.2.1 shouldn't be too far off, and it would be really great if we could include this fix. Here's the procedure to follow: - Download MacPython 2.2 and install, if you haven't already done so. This will probably already fail during ConfigurePythonCarbon or else the resulting MacPython will hang quickly. - Download http://www.cwi.nl/ftp/jack/python/mac/newer/PythonCoreCarbon.sit, unpack and put the resulting PythonCoreCarbon in your Python folder. - Run ConfigurePythonCarbon again. Now, everything should work. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From adam@switchedonsoftware.com Tue Jan 15 22:06:44 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Wed, 16 Jan 2002 09:06:44 +1100 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples In-Reply-To: <20020115123152.4A24EE8451@oratrix.oratrix.nl> Message-ID: <2980B949-0A04-11D6-95D2-0030656E8732@switchedonsoftware.com> > - Adam's Vyper FWIW, I've just put together the currency converter example: http://www.switchedonsoftware.com/python/ then control-click on "currency.xml" to make sure IE saves it to disk (if that's the web browser you are using) It should also be noted that I've changed the name away from Viper as it has come to my attention that there is an existing Python related project named "Vyper". For the time being I'm going to go with the name "Adder". As far as a general purpose style of Aqua UI programming, I think that Donovan Preston's IB services wrapper looks like a real winner. It will give developers much more freedom than Adder ever will. Kind regards, Adam Eijdenberg Switched on Software From joerg@kantel.de Tue Jan 15 22:40:09 2002 From: joerg@kantel.de (=?iso-8859-1?Q?J=F6rg?= Kantel) Date: Tue, 15 Jan 2002 23:40:09 +0100 Subject: [Pythonmac-SIG] OSX Multiprocessor - tentative fix available In-Reply-To: <20020115213215.33062E8451@oratrix.oratrix.nl> Message-ID: <20020115234011-r01010800-15c0d6a2-0920-010c@192.168.1.75> On 15.01.2002 at 22:32 Uhr, jack@oratrix.nl (Jack Jansen) wrote: >If some people with an OSX multiprocessor machine could test this that >would be great, and please report back here. MacPython 2.2.1 shouldn't >be too far off, and it would be really great if we could include this >fix. > >Here's the procedure to follow: >- Download MacPython 2.2 and install, if you haven't already done >so. This will probably already fail during ConfigurePythonCarbon or >else the resulting MacPython will hang quickly. >- Download >http://www.cwi.nl/ftp/jack/python/mac/newer/PythonCoreCarbon.sit, >unpack and put the resulting PythonCoreCarbon in your Python folder. >- Run ConfigurePythonCarbon again. I did it on a two processor Mac G4 and it works. But it seems that the Python Interpreter is very slow at startup and either I'm to impatient at the moment (it's nearly midnight here in Europe) or the tests hangs by test_longexp. But both the IDE and the Interpreter works and some little testscripts worked, too. Congratulations J"org -- mail: joerg@kantel.de # jkantel@mac.com visit: http://www.rollberg.de/ - die etwas anderen Nachrichten http://www.schockwellenreiter.de/ - (m)ein Weblog From fancher@pacbell.net Tue Jan 15 23:33:17 2002 From: fancher@pacbell.net (bill fancher) Date: Tue, 15 Jan 2002 15:33:17 -0800 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples In-Reply-To: <20020115123152.4A24EE8451@oratrix.oratrix.nl> Message-ID: <40BD2CDE-0A10-11D6-9860-0005029E8B13@pacbell.net> On Tuesday, January 15, 2002, at 04:31 AM, Jack Jansen wrote: > How about picking a single simple example, like Apple's own currency > converter > example, and building that with all the various toolkits we have, so > that we > can all see what the advantages and drawbacks of the various methods > are? For ASS/OSA Python: select "New Project" in PB and choose "Python Application". In your new project, double-click "Main.nib" to start IB. In IB, drag three NSTextFields and an NSButton to your window. Add labels, image, tab order support as in Apple example. Select "AppleScript" from the pulldown in the NSButton Info window and check "clicked" and "Application.applescript". Give the fields some names (I used "rate", "amount" and "result".) Drop an NSNumberFormatter on each field to let Cocoa handle input validation and numeric conversion. In PB, enter the following in "Application.applescript": def clicked(theObject): w = theObject.super_view rate = w.text_field['rate'].contents._value amount = w.text_field['amount'].contents._value w.text_field['result'].contents = rate * amount Click "Build". Done. Some advantages: Uses standard Apple supported tools. Leverages ASK. Easy to combine Python, C, Objc, C++ in the same project. Interapplication communication is trivial. Python HTML documentation accessible from PB. Fringe benefits: OSA component enables Python scripting/recording/execution in Script Editor and other OSA aware apps. Use Script Editor to create applets or droplets. Use Standard Additions for UI. (Maybe you don't need all the power of PB/IB. This is yet another route to basic Aqua UI.) Some drawbacks: Not standalone; apps require OSA component and Python framework. Not cross-platform. Communicates with interface via AppleEvents, which have a fair amount of overhead. Tools currently AppleScript-centric. No debugger support yet. -- bill From Chris.Barker@noaa.gov Tue Jan 15 23:16:48 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Tue, 15 Jan 2002 15:16:48 -0800 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples References: <2980B949-0A04-11D6-95D2-0030656E8732@switchedonsoftware.com> Message-ID: <3C44B858.87172FE4@noaa.gov> Adam Eijdenberg wrote: > It should also be noted that I've changed the name away from Viper as it > has come to my attention that there is an existing Python related > project named "Vyper". > > For the time being I'm going to go with the name "Adder". for what it is worth, there is an IDE for Python named "BlackAdder": http://www.thekompany.com/products/blackadder/ darn-all-the-good-snake-names-are-taken-ly-yours, 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 adam@switchedonsoftware.com Wed Jan 16 00:25:17 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Wed, 16 Jan 2002 11:25:17 +1100 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples In-Reply-To: <3C44B858.87172FE4@noaa.gov> Message-ID: <84201886-0A17-11D6-95D2-0030656E8732@switchedonsoftware.com> > for what it is worth, there is an IDE for Python named "BlackAdder": > darn-all-the-good-snake-names-are-taken-ly-yours, Damn. As with Viper, I searched VersionTracker.com, Download.com and Sourceforge. I was going to go with Black Adder after Viper was shot down in flames, but I didn't want to upset Rowan Atkinson. Time to think of another one... :) Kind regards, Adam Eijdenberg From kevino@tulane.edu Wed Jan 16 00:51:12 2002 From: kevino@tulane.edu (Kevin Ollivier) Date: Tue, 15 Jan 2002 19:51:12 -0500 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples References: <84201886-0A17-11D6-95D2-0030656E8732@switchedonsoftware.com> Message-ID: <013401c19e28$06958ff0$6401a8c0@cj622768a> What about "Snake Skin"? I doubt its taken and there's the allusion to the interface component of it. =) Just a thought! Kevin ----- Original Message ----- From: "Adam Eijdenberg" To: "Chris Barker" Cc: Sent: Tuesday, January 15, 2002 7:25 PM Subject: Re: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples > > for what it is worth, there is an IDE for Python named "BlackAdder": > > darn-all-the-good-snake-names-are-taken-ly-yours, > > Damn. > As with Viper, I searched VersionTracker.com, Download.com and > Sourceforge. > > I was going to go with Black Adder after Viper was shot down in flames, > but I didn't want to upset Rowan Atkinson. > > Time to think of another one... :) > > Kind regards, > Adam Eijdenberg > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From adam@switchedonsoftware.com Wed Jan 16 01:01:13 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Wed, 16 Jan 2002 12:01:13 +1100 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples In-Reply-To: <013401c19e28$06958ff0$6401a8c0@cj622768a> Message-ID: <898779CB-0A1C-11D6-95D2-0030656E8732@switchedonsoftware.com> > What about "Snake Skin"? I doubt its taken and there's the allusion to > the > interface component of it. =) Sounds OK, but not altogether relevant to the original aims of the project. Leave it with me. I'm sure I'll come up with something as the project moves along. A good name is the least of my problems. Adam From jack@oratrix.nl Wed Jan 16 01:14:59 2002 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 16 Jan 2002 02:14:59 +0100 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples In-Reply-To: Message by Adam Eijdenberg , Wed, 16 Jan 2002 11:25:17 +1100 , <84201886-0A17-11D6-95D2-0030656E8732@switchedonsoftware.com> Message-ID: <20020116011504.B9171E8451@oratrix.oratrix.nl> Recently, Adam Eijdenberg said: > I was going to go with Black Adder after Viper was shot down in flames, > but I didn't want to upset Rowan Atkinson. > > Time to think of another one... :) Well, how about Basil? As with your tool you don't really have to actually _do_ anything (such as programming) but you just boss around (widgets, in this case)? And then if you create an even simpler version you can call it Manuel (I know nothing! I come from Barcelona!). -- - 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 guess-who@kevin-masako.com Wed Jan 16 02:07:31 2002 From: guess-who@kevin-masako.com (Kevin & Masako Ollivier) Date: Tue, 15 Jan 2002 21:07:31 -0500 Subject: [Pythonmac-SIG] wxPython for OS X - now with menus! Message-ID: <014f01c19e32$91662b30$6401a8c0@cj622768a> Hi everyone, I've (finally!) been able to get menus working on wxPython for Mac OS X. =) Of course, I did not forget the obligatory screenshot: http://payson.tulane.edu/kollivier/wxPythonMac-menu.JPG I tested a number of samples out (including demo.py, hangman.py, slashdot.py, and wxProject.py) and all the menu code ran fine. There was one time where there did not appear to be any space between a menu title text and the shortcut key, but that was the only issue I encountered. So how did I do it? Actually, all I did was remove a few lines from the wxWindows/wxMac source code which read in the menubar resource. Here's the code I removed: File: src/mac/menu.cpp in Function wxMenuBar::MacInstallMenuBar Handle menubar = ::GetNewMBar( kwxMacMenuBarResource ) ; wxString message ; wxCHECK_RET( menubar != NULL, wxT("can't read MBAR resource")); ::SetMenuBar( menubar ) ; ::DisposeHandle( menubar ) ; Feel free to try this at home! I'm sure this will cause problems when creating compiled apps on OS X though. My question is: is there a place we can "move" the menubar initialization code so that it will get run by compiled applications, but not by scripted apps? Maybe add an "InitMenuBar()" function into the IMPLEMENT_APP macro for Mac? Once we get this code issue resolved, I'm thinking we may want to build an "alpha" binary version of wxPython for Mac, so that people can play with it and see what has been done so far. What do you think? A majority of the other issues I've found in the samples are simply visual "glitches" (like text alignment and control overlap issues) that should have a more straight-forward fix for them. =) Thanks, Kevin From seanh@real.com Wed Jan 16 02:34:20 2002 From: seanh@real.com (Sean Hummel) Date: Tue, 15 Jan 2002 18:34:20 -0800 (PST) Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples In-Reply-To: <20020116011504.B9171E8451@oratrix.oratrix.nl> Message-ID: I like the term sluff (sic?) you know like what they call the leftover after a snake sheds it's skin? On Wed, 16 Jan 2002, Jack Jansen wrote: > > Recently, Adam Eijdenberg said: > > I was going to go with Black Adder after Viper was shot down in flames, > > but I didn't want to upset Rowan Atkinson. > > > > Time to think of another one... :) > > Well, how about Basil? As with your tool you don't really have to > actually _do_ anything (such as programming) but you just boss around > (widgets, in this case)? > > And then if you create an even simpler version you can call it Manuel > (I know nothing! I come from Barcelona!). > -- > - Jack Jansen http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma Goldman - > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From robin@alldunn.com Wed Jan 16 02:58:43 2002 From: robin@alldunn.com (Robin Dunn) Date: Tue, 15 Jan 2002 18:58:43 -0800 Subject: [Pythonmac-SIG] Re: [wxPython-mac] wxPython for OS X - now with menus! References: <014f01c19e32$91662b30$6401a8c0@cj622768a> Message-ID: <0c8001c19e39$b6f33080$0214a8c0@Rogue> > > I've (finally!) been able to get menus working on wxPython for Mac OS X. =) > Of course, I did not forget the obligatory screenshot: > > http://payson.tulane.edu/kollivier/wxPythonMac-menu.JPG WooHoo! > I tested a number of samples out (including demo.py, hangman.py, > slashdot.py, and wxProject.py) and all the menu code ran fine. There was one > time where there did not appear to be any space between a menu title text > and the shortcut key, but that was the only issue I encountered. > > So how did I do it? Actually, all I did was remove a few lines from the > wxWindows/wxMac source code which read in the menubar resource. ... Yes, there's got to be a better way, but at least this lets us know where the conflict is at... -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From jack@oratrix.nl Wed Jan 16 10:36:21 2002 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 16 Jan 2002 11:36:21 +0100 Subject: [Pythonmac-SIG] Re: [wxPython-mac] wxPython for OS X - now with menus! In-Reply-To: Message by "Kevin & Masako Ollivier" , Tue, 15 Jan 2002 21:07:31 -0500 , <014f01c19e32$91662b30$6401a8c0@cj622768a> Message-ID: <20020116103621.E275CE8451@oratrix.oratrix.nl> > So how did I do it? Actually, all I did was remove a few lines from the > wxWindows/wxMac source code which read in the menubar resource. Here's the > code I removed: > > File: src/mac/menu.cpp > in Function wxMenuBar::MacInstallMenuBar > > Handle menubar = ::GetNewMBar( kwxMacMenuBarResource ) ; > wxString message ; > wxCHECK_RET( menubar != NULL, wxT("can't read MBAR resource")); > ::SetMenuBar( menubar ) ; > ::DisposeHandle( menubar ) ; There's a couple of issues with this code. First of all, the Carbon docs warn that you should *not* call DisposeHandle() on a MenuBar anymore, use DisposeMenuBar(). Second, you're missing a DrawMenuBar() call after the SetMenuBar(). Third, I'm not sure that you actually want to dispose the menubar: the docs do say that SetMenuBar copies the menus, but all code I've ever seen keeps a reference to the menubar handle nonetheless. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From kevino@tulane.edu Wed Jan 16 15:26:45 2002 From: kevino@tulane.edu (Kevin Ollivier) Date: Wed, 16 Jan 2002 10:26:45 -0500 Subject: [Pythonmac-SIG] Re: [wxPython-mac] wxPython for OS X - now with menus! References: <014f01c19e32$91662b30$6401a8c0@cj622768a> <0d5f01c19e63$3c1f9c20$2501000a@core.advancedconcepts.ch> Message-ID: <003101c19ea2$366d2e20$2101a8c0@kevinnew> > Hi actually you are then modifying somebody elses menubar - this is not at > all a recommended action - event if it works ;-) I know it is far from ideal behavior, but so far this is the only solution to the problem I have been able to come up with. The problem is caused because wxPython scripts are identified as "documents" belonging to Python instead of applications. So instead of creating a new application, wxPython code is executed within Python itself. Any attempt to create a new menubar will fail, because Python already has a menubar. I haven't yet found any Carbon code for dynamically creating a new Application, but I'm new to Mac coding so I could be missing something. From what I've found though, it seems we have to consider Python as a "host" application, which can be taken over by wxPython when a wxPython script is run. I believe this behavior is also used by Tkinter on Mac OS 9, but I just ran a couple tests so I could be wrong. (I actually got the idea when looking at Tk's Mac menu code.) We could do something like split Python into two executables - one for the IDE and one which only runs scripts. I'm open to any other suggestions that could get this working! =) Also, as a more "gentle" way of handling this issue, I basically added some code to check and see if a menubar already exists, and if not, create it. So the code now looks like: if (GetMenuBar() == NULL) { Handle menubar = ::GetNewMBar( kwxMacMenuBarResource ) ; wxString message ; wxCHECK_RET( menubar != NULL, wxT("can't read MBAR resource")); ::SetMenuBar( menubar ) ; ::DisposeHandle( menubar ) ; } I've both run wxPython apps and compiled wxMac apps successfully with this code. This code as I see it should do no harm - as I understand it, if GetMenuBar() is not null, the following lines of code will fail anyways. (Although I realize that it will go ahead and execute the other code.) GetMenuBar should always return null for wxMac apps, and if GetMenuBar does not return null, the only plausable situation I can see for that is if wxWindows is running through a scripting language. Is this correct? > Could somebody tell me what I need to follow get things building (or where > to look at them) macos x might be ok for the moment. makes things easier for > me to try at the classic level Yeah, realizing that all these components use Carbon as the GUI code, I realized that wxPython for Mac Classic may be a realistic option. In any case, here are the steps to build wxPython on Mac OS X: Step 1: Get the Python 2.2 source code from www.python.org and build twice. First as normal (configure/make/make install) and then as instructed in the dist/src/mac/osx/ folder (from the beginning). This will create both a "traditional" Python binary (in /usr/local/bin/) and a Carbon-based Python.app (in /Applications). When you run scripts from the shell, you'll be using the traditional binary. When you double-click in the Finder, then you'll use Python.app. (These two will probably merge in the future.) Step 2: Get the latest CVS of wxWindows and wxPython and build as usual. =) Step 3: Copy the wxPython folder from /usr/local/lib/python2.2/site-packages/ to /Library/Frameworks/Python.Framework/Versions/2.2/python2.2/lib/site-package s/ Step 4: Double-click on wxPython/demo/demo.py and see what happens! I believe this is it. Let me know how it goes. Thanks for your help! Kevin From robin@alldunn.com Wed Jan 16 16:32:44 2002 From: robin@alldunn.com (Robin Dunn) Date: Wed, 16 Jan 2002 08:32:44 -0800 Subject: [Pythonmac-SIG] Re: [wxPython-mac] wxPython for OS X - now with menus! References: <014f01c19e32$91662b30$6401a8c0@cj622768a> <0d5f01c19e63$3c1f9c20$2501000a@core.advancedconcepts.ch> <003101c19ea2$366d2e20$2101a8c0@kevinnew> Message-ID: <0d3501c19eab$6d597520$0214a8c0@Rogue> > > Step 1: Get the Python 2.2 source code from www.python.org and build twice. > First as normal (configure/make/make install) and then as instructed in the > dist/src/mac/osx/ folder (from the beginning). This will create both a > "traditional" Python binary (in /usr/local/bin/) and a Carbon-based > Python.app (in /Applications). When you run scripts from the shell, you'll > be using the traditional binary. When you double-click in the Finder, then > you'll use Python.app. (These two will probably merge in the future.) I've found that only one build is needed. Build as described in MacOSX/README to do the framework and then just put a link to /Library/Frameworks/Python.framework/Versions/2.2/bin/python in /usr/local/bin or anywhere else on the PATH. > > Step 2: Get the latest CVS of wxWindows and wxPython and build as usual. =) > I've got a (slightly outdated) set of instructions in wxWindows/wxPython/BUILD.osx.txt -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From ariza@flexatone.com Wed Jan 16 09:53:40 2002 From: ariza@flexatone.com (christopher ariza) Date: Wed, 16 Jan 2002 04:53:40 -0500 (EST) Subject: [Pythonmac-SIG] Installing unix Python on OS X...a few details wanted In-Reply-To: Message-ID: i realize this is a bit out of date, but i was on vacation. concerning using fink to run tkinter in X11: i apologize for making possibly over-enthusiastic claims about fink! i will try to clarify a bit. i forgot to mention that i had been using the "dselect" application that comes with fink, which automatically checks for dependencies for a given software component. thus if you select gnome to be installed, gtk+ and all the other necessary packages are selected as well. which python/tk to use: when using dselect with fink, all software selected is installed in the /sw directory, and nowhere else. if you have a normal osx mach-o python intalled in /usr/local/lib it will not be effected at all. dselect installs python in /sw/lib. same with tk. assuming you are not concerned with hard disc space, it seems easiest to me to just have duplicate copies of python, tk, and whatever else: one in /sw for when using X11, and the other for using in darwin/osx land, if needed. from dselect, the python and tk i have installed are displayed as: Up-to-date Optional packages in section languages *** Opt language python 2.1.1-3 2.1.1-3 Python is an interpreted, interactive, ob *** Opt language tcltk 8.3.3-5 8.3.3-5 Tcl (Tool Command Language, pronounced ti the python NOT installed is the one that is "nox", no X11. this means that it doesnt expect to find tk: Available Optional packages in section languages __ Opt language python-nox 2.1.1-3 Python is an interpreted, interactive, ob from dselect, my x11 packages are as follows: Up-to-date Optional packages in section x11-system *** Opt x11-syst xfree86-base 4.1.0-8 4.1.0-8 XFree86 libraries, utilities and data *** Opt x11-syst xfree86-serv 4.1.0-5 4.1.0-5 XFree86 display server (stable release) Up-to-date Optional packages in section x11-wm *** Opt x11-wm blackbox-roo 0.61.1-1 0.61.1-1 Blackbox patched for rootless X environme *** Opt x11-wm enlightenmen 0.16.5-6 0.16.5-6 Themeable, featureful window manager *** Opt x11-wm icewm 1.0.8-1 1.0.8-1 Window manager with Windows, OS/2 and Mot finally, I highly reccomend the blackbox wm. of all the wms i tried with x11 on a little 300mhz powerbook, blackbox was by far the fastest, as fast as normal aqua. gnome plus a wm was too slow for my machine. christopher ariza From stephenm@humongous.com Wed Jan 16 17:51:33 2002 From: stephenm@humongous.com (Magladry, Stephen) Date: Wed, 16 Jan 2002 09:51:33 -0800 Subject: [Pythonmac-SIG] Forwarded: "Josephson, Neal": ANN: HAP Python Remote Debugger 0.2 Released Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE62A@sea-horse.humongous.com> HAP is an open source project which originated out of Humongous Entertainment. Being that I have an inside connection, I went two cubies down and got the information. There is and IDE portion which is unfortunately based on MFC. But there is the ability to remote debugging using TCP/IP. The remote client code base is relatively small, < 4000 lines, most of which is cross-platform. With and existing sockets system, maybe a few dozen line of code would need to be modified in order to have a remote Mac client. -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Tuesday, January 15, 2002 12:29 PM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] Forwarded: "Josephson, Neal": ANN: HAP Python Remote Debugger 0.2 Released << Message: ANN: HAP Python Remote Debugger 0.2 Released >> This just came by on the python-announce list, is anyone willing to have a look at it and see whether it could be integrated with the MacPython IDE debugger? If it can that might allow a couple of nice things that aren't currently possible, such as debugging Tkinter scripts from the IDE (by running the script in a separate interpreter, outside of the IDE) and debugging MachoPython scripts with IDE running under MacPython on OSX. From smithsm@samuelsmith.org Wed Jan 16 19:07:23 2002 From: smithsm@samuelsmith.org (Samuel Smith) Date: Wed, 16 Jan 2002 12:07:23 -0700 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples In-Reply-To: <84201886-0A17-11D6-95D2-0030656E8732@switchedonsoftware.com> References: <84201886-0A17-11D6-95D2-0030656E8732@switchedonsoftware.com> Message-ID: For a list of venomous snake names see: http://www-surgery.ucsd.edu/ENT/DAVIDSON/snake/3cnames.htm A few names seemed unique mamba massasauga diamondback cottonmouth bushmaster habu krait boomslang >>for what it is worth, there is an IDE for Python named "BlackAdder": >>darn-all-the-good-snake-names-are-taken-ly-yours, > >Damn. >As with Viper, I searched VersionTracker.com, Download.com and Sourceforge. > >I was going to go with Black Adder after Viper was shot down in >flames, but I didn't want to upset Rowan Atkinson. > >Time to think of another one... :) > >Kind regards, >Adam Eijdenberg > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ********************************************** Samuel M. Smith Ph.D. 360 W. 920 N. Orem, Utah 84057 801-226-7607 x112 (voice) 801-226-7608 (fax) http://www.samuelsmith.org (web) ********************************************* From bob@redivi.com Wed Jan 16 20:18:55 2002 From: bob@redivi.com (Bob Ippolito) Date: Wed, 16 Jan 2002 15:18:55 -0500 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples In-Reply-To: Message-ID: <43FBCB6E-0ABE-11D6-939A-0003938210D6@redivi.com> Perhaps water snakes would be more appropriate, being that it's for (at least, originally for) the Aqua UI? Though, I can't come up with anything off the top of my head that doesn't remind me of bad movies starring ice cube and jennifer lopez. -bob On Wednesday, January 16, 2002, at 02:07 PM, Samuel Smith wrote: > For a list of venomous snake names see: > > > http://www-surgery.ucsd.edu/ENT/DAVIDSON/snake/3cnames.htm > > A few names seemed unique > > mamba > massasauga > diamondback > cottonmouth > bushmaster > habu > krait > boomslang > > > >>> for what it is worth, there is an IDE for Python named "BlackAdder": >>> darn-all-the-good-snake-names-are-taken-ly-yours, >> >> Damn. >> As with Viper, I searched VersionTracker.com, Download.com and >> Sourceforge. >> >> I was going to go with Black Adder after Viper was shot down in >> flames, but I didn't want to upset Rowan Atkinson. >> >> Time to think of another one... :) >> >> Kind regards, >> Adam Eijdenberg >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > > -- ********************************************** > > Samuel M. Smith Ph.D. > > 360 W. 920 N. > Orem, Utah 84057 > > 801-226-7607 x112 (voice) > 801-226-7608 (fax) > http://www.samuelsmith.org (web) > > ********************************************* > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.nl Wed Jan 16 21:02:48 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Wed, 16 Jan 2002 22:02:48 +0100 Subject: [Pythonmac-SIG] Installing unix Python on OS X...a few details wanted In-Reply-To: Message-ID: <657E7FE6-0AC4-11D6-B88F-003065517236@oratrix.nl> On Wednesday, January 16, 2002, at 10:53 AM, christopher ariza wrote: > finally, I highly reccomend the blackbox wm. of all the wms i > tried with > x11 on a little 300mhz powerbook, blackbox was by far the > fastest, as fast > as normal aqua. gnome plus a wm was too slow for my machine. > I've found the same about oroborus. Also lean and mean and fink-supported. Oh yes, on fink: I like the automatism in there, loading everything you need, it reminds me a lot of the SGI Irix installation system inst (I wouldn't be surprised if it was modelled after it). But before fink is ready for prime time (and I mean mac-users primetime, not unix-users primetime) it'll have to be a whole lot more understandable. The terminology it uses is unclear, shortcuts are very strange (even by unix standards) and feedback is missing (very difficult to see what you selected to install, absolutely no feedback on what is going on during installation except the flashing messages which I would see more as "progress bar"). SGI inst (both in the commandline version and in the graphic version) are a lot clearer. From Jack.Jansen@oratrix.nl Wed Jan 16 21:04:53 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Wed, 16 Jan 2002 22:04:53 +0100 Subject: [Pythonmac-SIG] Forwarded: "Josephson, Neal": ANN: HAP Python Remote Debugger 0.2 Released In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE62A@sea-horse.humongous.com> Message-ID: On Wednesday, January 16, 2002, at 06:51 PM, Magladry, Stephen wrote: > HAP is an open source project which originated out of Humongous > Entertainment. Being that I have an inside connection, I went > two cubies > down and got the information. > > There is and IDE portion which is unfortunately based on MFC. > But there is > the ability to remote debugging using TCP/IP. The remote > client code base > is relatively small, < 4000 lines, most of which is > cross-platform. With and > existing sockets system, maybe a few dozen line of code would > need to be > modified in order to have a remote Mac client. > This is probably the interesting bit. Anyone willing to have a look at how much work it would be to connect the IDE debugger to this remote client code? From erik@letterror.com Thu Jan 17 00:28:53 2002 From: erik@letterror.com (Erik van Blokland) Date: Thu, 17 Jan 2002 01:28:53 +0100 Subject: [Pythonmac-SIG] Umpteen styles of Aqua UI programming - need examples In-Reply-To: Message-ID: <20020117012856-r01010800-ba0faf96-0910-0108@10.0.0.1> smithsm@samuelsmith.org (Samuel Smith): [1/16/02 at 12:07 PM] > A few names seemed unique > > mamba > massasauga > diamondback > cottonmouth > bushmaster > habu > krait > boomslang -- parselmouth the snake language in Harry Potter. Erik LettError.com/shop Type & Typography From cjl@physics.otago.ac.nz Thu Jan 17 00:41:40 2002 From: cjl@physics.otago.ac.nz (Chris Lee) Date: Thu, 17 Jan 2002 13:41:40 +1300 Subject: [Pythonmac-SIG] OT: getting at the XML in nib files Message-ID: <7D2111.D2928.9D243A.Nisus.ID@physics.otago.ac.nz> Hi All, does anyone know how to extract the xml text file from a nib file for = viewing (rather than using)? Cheers Chris ######################### Chris Lee Department of Physics phone: ++64 3 379 7750 fax: ++64 3 479 0964 #########################= From bobsavage@mac.com Thu Jan 17 01:41:40 2002 From: bobsavage@mac.com (Bob Savage) Date: Wed, 16 Jan 2002 19:41:40 -0600 Subject: [Pythonmac-SIG] OT: getting at the XML in nib files In-Reply-To: <7D2111.D2928.9D243A.Nisus.ID@physics.otago.ac.nz> Message-ID: on 1/16/02 6:41 PM, Chris Lee wrote: > > does anyone know how to extract the xml text file from a nib file for viewing > (rather than using)? > Chris, I think there are three XML files: if I remember correctly they are object.nib, info.nib, and classes.nib. What you do is look inside the XXX.nib file (not the three I just mentioned, this one is actually a directory) by either selecting it in the finder and (from a contextual menu) select view package contents, or cd to it in the terminal. Then you can open it with a text viewer -- e.g. in the terminal use the bbedit tool if you have it, or open them with bbedit some other way, like drag-n-drop, even though they are named .nib these three files are text files (but probably have unix line endings). One thing, though. One of the files (objects.nib?) is actually a binary file. It has serialized objects from IB. best, Bob From euphoriadj@adamswells.com Thu Jan 17 02:52:30 2002 From: euphoriadj@adamswells.com (Edd Thompson) Date: Wed, 16 Jan 2002 21:52:30 -0500 Subject: [Pythonmac-SIG] tk or gui for os X Message-ID: <3FD73D62-0AF5-11D6-8910-00039351029A@adamswells.com> when I downloaded python for os X it said I could not use tkinter yet has this changed yet. if not how would I go about using interface builder aren't those .nib files xml or something? From mmiller@adobe.com Thu Jan 17 03:12:30 2002 From: mmiller@adobe.com (Martin Miller) Date: Wed, 16 Jan 2002 19:12:30 -0800 Subject: [Pythonmac-SIG] Newbie Question: xstat() function? Message-ID: <3C46411F.AF74860D@adobe.com> I have a dumb newbie question. The documentation at for the MacPython mac module says: ==snip== > One additional function is available: > > xstat(path) > This function returns the same information as stat(), but with three additional values appended: the size of the resource fork of the file and its > 4-character creator and type. ==snip== However the xstat() function does not appear to be available in either the "mac" or "os" module that is distributed with MacPython 2.2. I would like to access the 4-byte creator and type of a Macintosh file. Is it missing by mistake or am I doing something wrong? I have tried both mac.xstat(path) and os.xstat(path). I also tried the standard os.stat(), but it does not return any extra values as described. TIA, Martin From mmiller@adobe.com Thu Jan 17 03:39:30 2002 From: mmiller@adobe.com (Martin Miller) Date: Wed, 16 Jan 2002 19:39:30 -0800 Subject: [Pythonmac-SIG] Re: Newbie Question: xstat() function? References: <3C46411F.AF74860D@adobe.com> Message-ID: <3C464772.557A9E08@adobe.com> I discovered (by looking at the source code for some other Mac-specific modules that come with the distribution), that I can use the GetCreatorAndType() function in the MacOS module to accomplish what the task. I tried it an it works fine. I would still like to know about the xstat() function, if anyone knows and cares to answer. Thanks, Martin =============== Earlier I wrote: > > I have a dumb newbie question. The documentation at > for the > MacPython mac module says: > > ==snip== > > One additional function is available: > > > > xstat(path) > > This function returns the same information as stat(), but with three additional values appended: the size of the resource fork of the file and its > > 4-character creator and type. > ==snip== > > However the xstat() function does not appear to be available in either > the "mac" or "os" module that is distributed with MacPython 2.2. I would > like to access the 4-byte creator and type of a Macintosh file. Is it > missing by mistake or am I doing something wrong? I have tried both > mac.xstat(path) and os.xstat(path). I also tried the standard os.stat(), > but it does not return any extra values as described. > > TIA, > Martin From fgranger@altern.org Thu Jan 17 09:28:07 2002 From: fgranger@altern.org (Francois Granger) Date: Thu, 17 Jan 2002 10:28:07 +0100 Subject: [Pythonmac-SIG] Newbie Question: xstat() function? In-Reply-To: <3C46411F.AF74860D@adobe.com> Message-ID: on 17/01/02 4:12, Martin Miller at mmiller@adobe.com wrote: > I have a dumb newbie question. The documentation at > for the > MacPython mac module says: > > ==snip== >> One additional function is available: >> >> xstat(path) >> This function returns the same information as stat(), but with three >> additional values appended: the size of the resource fork of the file and its >> 4-character creator and type. > ==snip== > > However the xstat() function does not appear to be available in either > the "mac" or "os" module that is distributed with MacPython 2.2. I would > like to access the 4-byte creator and type of a Macintosh file. Is it > missing by mistake or am I doing something wrong? I have tried both > mac.xstat(path) and os.xstat(path). I also tried the standard os.stat(), > but it does not return any extra values as described. It is in the mac module: >>> import mac >>> dir(mac) ['__doc__', '__name__', 'chdir', 'close', 'dup', 'error', 'fdopen', 'fstat', 'getbootvol', 'getcwd', 'listdir', 'lseek', 'mkdir', 'open', 'read', 'remove', 'rename', 'rmdir', 'stat', 'sync', 'unlink', 'write', 'xstat'] >>> mac.xstat('README') (33206, 310280, -1, 1, 0, 0, 9209, 3079632124.0, 3079632124.0, 3078256323.0, 428, 'CWIE', 'TEXT') >>> From hansv@net4all.be Thu Jan 17 17:36:54 2002 From: hansv@net4all.be (Hans verschooten) Date: Thu, 17 Jan 2002 18:36:54 +0100 Subject: [Pythonmac-SIG] Sound advice Message-ID: I'm trying to split a large number of sound files as soon as the volume drops below a certain level. So I'm looking for a way to measure the volume of the sound files. And then split them to separate files. These sound files are AIFF and MP3 files. Does anybody have an idea if this is possible in Python, I'm using the UNIX version on OS 10.1.2 at the moment. Thanks for any help, Hans From mmiller@adobe.com Thu Jan 17 21:02:31 2002 From: mmiller@adobe.com (Martin Miller) Date: Thu, 17 Jan 2002 13:02:31 -0800 Subject: [Pythonmac-SIG] Newbie Question: xstat() function? References: Message-ID: <3C473BE7.7361F65E@adobe.com> On 17/01/02 10:28:07, Francois Granger wrote: > on 17/01/02 4:12, Martin Miller at mmiller@adobe.com wrote: > > > I have a dumb newbie question. The documentation at > > for the > > MacPython mac module says: > > > > ==snip== > >> One additional function is available: > >> > >> xstat(path) > >> This function returns the same information as stat(), but with three > >> additional values appended: the size of the resource fork of the file and its > >> 4-character creator and type. > > ==snip== > > > > However the xstat() function does not appear to be available in either > > the "mac" or "os" module that is distributed with MacPython 2.2. I would > > like to access the 4-byte creator and type of a Macintosh file. Is it > > missing by mistake or am I doing something wrong? I have tried both > > mac.xstat(path) and os.xstat(path). I also tried the standard os.stat(), > > but it does not return any extra values as described. > > It is in the mac module: > > >>> import mac > >>> dir(mac) > ['__doc__', '__name__', 'chdir', 'close', 'dup', 'error', 'fdopen', 'fstat', > 'getbootvol', 'getcwd', 'listdir', 'lseek', 'mkdir', 'open', 'read', > 'remove', 'rename', 'rmdir', 'stat', 'sync', 'unlink', 'write', 'xstat'] > >>> mac.xstat('README') > (33206, 310280, -1, 1, 0, 0, 9209, 3079632124.0, 3079632124.0, 3078256323.0, > 428, 'CWIE', 'TEXT') > >>> Well, as I indicated, it is not in the mac module I have: Python 2.2 (#124, Dec 22 2001, 17:36:41) [CW CARBON GUSI2 THREADS GC] Type "copyright", "credits" or "license" for more information. MacPython IDE 1.0.1 >>> import mac >>> dir(mac) ['F_OK', 'O_APPEND', 'O_CREAT', 'O_EXCL', 'O_NOCTTY', 'O_NONBLOCK', 'O_RDONLY', 'O_RDWR', 'O_TRUNC', 'O_WRONLY', 'R_OK', 'TMP_MAX', 'W_OK', 'X_OK', '__doc__', '__name__', 'chdir', 'close', 'dup', 'error', 'fdopen', 'fstat', 'getcwd', 'listdir', 'lseek', 'mkdir', 'open', 'read', 'remove', 'rename', 'rmdir', 'stat', 'stat_result', 'sync', 'unlink', 'write'] >>> From Jack.Jansen@oratrix.nl Thu Jan 17 21:15:52 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Thu, 17 Jan 2002 22:15:52 +0100 Subject: [Pythonmac-SIG] OT: getting at the XML in nib files In-Reply-To: Message-ID: <6318FD6A-0B8F-11D6-B884-003065517236@oratrix.nl> On Thursday, January 17, 2002, at 02:41 AM, Bob Savage wrote: > One thing, though. One of the files (objects.nib?) is actually a binary > file. It has serialized objects from IB. Has anyone ever tried using ObjC's introspective features to dump out these objects after reading them in? From my short exposure to Cocoa I got the impression that this might be possible... -- - 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.nl Thu Jan 17 21:18:27 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Thu, 17 Jan 2002 22:18:27 +0100 Subject: [Pythonmac-SIG] Sound advice In-Reply-To: Message-ID: On Thursday, January 17, 2002, at 06:36 PM, Hans verschooten wrote: > I'm trying to split a large number of sound files as soon as > the volume drops below a certain level. So I'm looking for a > way to measure the volume of the sound files. And then split > them to separate files. These sound files are AIFF and MP3 > files. > > Does anybody have an idea if this is possible in Python, I'm > using the UNIX version on OS 10.1.2 at the moment. Once you have the files in memory you can use the audioop module to operate on the samples reasonably efficiently. I think the aiff module is part of the standard distribution, but I know of nothing for MP3. -- - 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.nl Thu Jan 17 21:19:41 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Thu, 17 Jan 2002 22:19:41 +0100 Subject: [Pythonmac-SIG] Newbie Question: xstat() function? In-Reply-To: <3C46411F.AF74860D@adobe.com> Message-ID: On Thursday, January 17, 2002, at 04:12 AM, Martin Miller wrote: > I have a dumb newbie question. The documentation at > for the > MacPython mac module says: > > ==snip== >> One additional function is available: >> >> xstat(path) >> This function returns the same information as stat(), >> but with three additional values appended: the size of the >> resource fork of the file and its >> 4-character creator and type. > ==snip== > > However the xstat() function does not appear to be available in either > the "mac" or "os" module that is distributed with MacPython 2.2. Well, yes and no. mac.xstat() is still available under PPC MacPython but not under Carbon MacPython. I should update the documentation, could you file a bugreport please? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From owen@astro.washington.edu Thu Jan 17 21:28:55 2002 From: owen@astro.washington.edu (Russell E Owen) Date: Thu, 17 Jan 2002 13:28:55 -0800 Subject: [Pythonmac-SIG] bug in MacPython 2.1.1 BuildApplet -- can trash files! Message-ID: If the name of the file dropped on BuildApplet (MacPython 2.1.1 configured for Carbon) is the right length, BuildApplet will work and then will delete the source file!!! For instance: "Cvt cmm -> Igor data 2-0 long name.py" first produces a working droplet with name: "Cvt cmm -> Igor data 2#7F2E4" and then the source file simply vanishes. It's really gone, too (or perhaps moved and renamed) -- a disk search doesn't turn it up anywhere. I suspect the file name has to be longer than Mac OS classic allows. On the other hand, REALLY long file names simply cause BuildApplet to quit instantly without doing anything. So there's some magic length or range of lengths that causes the problem. I just lost some work this way and so wanted to warn others. Regards, -- Russell From Jack.Jansen@oratrix.nl Thu Jan 17 21:30:30 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Thu, 17 Jan 2002 22:30:30 +0100 Subject: [Pythonmac-SIG] Third attempt at Carbon Tkinter Message-ID: <6E8CE39C-0B91-11D6-B884-003065517236@oratrix.nl> Folks, a third atttempt at an _tkinter.carbon.slb is now available at http://www.cwi.nl/ftp/jack/python/mac/newer . This is built with the same 8.4.0 Tcl/Tk that the _tkinter.ppc.slb that is in the 2.2 distribution was built with (so that's why there's no accompanying PPC version, you have it already). Please give this a try and let me know whether this is a feasible solution for MacPython 2.2.1. Thanks, -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From sdm7g@Virginia.EDU Thu Jan 17 23:06:27 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Thu, 17 Jan 2002 18:06:27 -0500 (EST) Subject: [Pythonmac-SIG] OT: getting at the XML in nib files In-Reply-To: <6318FD6A-0B8F-11D6-B884-003065517236@oratrix.nl> Message-ID: On Thu, 17 Jan 2002, Jack Jansen wrote: > On Thursday, January 17, 2002, at 02:41 AM, Bob Savage wrote: > > > One thing, though. One of the files (objects.nib?) is actually a binary > > file. It has serialized objects from IB. > > Has anyone ever tried using ObjC's introspective features to > dump out these objects after reading them in? From my short > exposure to Cocoa I got the impression that this might be > possible... You would have to load them before you could inspect them with the introspection API. I don't think you load these objects as a NSBundle, but you use NSUnarchiver instead. However, if I give it a try from Python2.1.2/pyobjc, I get: >>> runtime.NSUnarchiver.unarchiveObjectWithFile_( './objects.nib' ) Traceback (most recent call last): File "", line 1, in ? pyobjc.error: *** class error for 'NSIBObjectData': class not loaded So I tried loading AppKit.framework first (guessing that that's where NSIBObjectData classes hide!) and I got back a object from the Unarchiver. I don't see the docs for NSIBObjectData, so I might have to use the introspection classes to see what methods they have. However, there's a bunch of stuff I haven't moved over to my laptop since the upgrade, and I don't have the NeoData introspection classes. I'll see if I can get them set up to work from Python again. BTW: You can load a class browser app and the framework from: ( But since the files are serialized object archives and not frameworks/bundles, you can't use the app directly on the nib file (I believe) -- which is why I have to do it from Python after they are unarchived. ) -- Steve From sdm7g@Virginia.EDU Thu Jan 17 23:26:17 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Thu, 17 Jan 2002 18:26:17 -0500 (EST) Subject: [Pythonmac-SIG] OT: getting at the XML in nib files In-Reply-To: Message-ID: On Thu, 17 Jan 2002, Steven Majewski wrote: > > So I tried loading AppKit.framework first (guessing that that's > where NSIBObjectData classes hide!) and I got back a > object from > the Unarchiver. > > I don't see the docs for NSIBObjectData, so I might have to > use the introspection classes to see what methods they have. > > However, there's a bunch of stuff I haven't moved over to my > laptop since the upgrade, and I don't have the NeoData introspection > classes. I'll see if I can get them set up to work from Python > again. > > > BTW: You can load a class browser app and the framework from: > > > > ( But since the files are serialized object archives and not > frameworks/bundles, you can't use the app directly on the > nib file (I believe) -- which is why I have to do it > from Python after they are unarchived. ) > I hadn't used this in some time, so I forgot what I could actually do. I downloaded the introspector.app This shows all of the classes in a framework, not just the documented ones, so I could find NSIBObjectData -- among it's methods: - (void) nibInstantiateWithOwner: (id) topLevelObjects: (id); - (void) nibInstantiateWithOwner: (id); There also seem to be some instance variables holding some tables -- I assume one of these is the 'table of contents', but I'm not sure how to access them. -- Steve From sdm7g@Virginia.EDU Thu Jan 17 23:36:56 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Thu, 17 Jan 2002 18:36:56 -0500 (EST) Subject: [Pythonmac-SIG] Knock me over with a spoon! [was: getting at the XML in nib files] In-Reply-To: Message-ID: On Thu, 17 Jan 2002, Steven Majewski wrote: > > - (void) nibInstantiateWithOwner: (id) topLevelObjects: (id); > - (void) nibInstantiateWithOwner: (id); Knock me over with a spoon, but when I did: >>> app = rt.NSApplication.sharedApplication() >>> app >>> o ## <-- this is the previously loaded objects.nib >>> o.nibInstantiateWithOwner_ ' on at fafe50> >>> o.nibInstantiateWithOwner_( app ) 2002-01-17 18:30:14.247 python2.1[419] Unknown class `Foo' in nib file, using `NSObject' instead. 2002-01-17 18:30:14.252 python2.1[419] Could not connect the action seed: to target of class NSObject 2002-01-17 18:30:14.261 python2.1[419] Could not connect the action generate: to target of class NSObject And the window popped up on the screen -- non functioning because this was a nib from Random.App in Aaron Hillegass's book, and, as you can see from the messages above, the targets in the nibs didn't match up with any of the classes in Python. -- Steve From sdm7g@Virginia.EDU Thu Jan 17 23:55:09 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Thu, 17 Jan 2002 18:55:09 -0500 (EST) Subject: [Pythonmac-SIG] Knock me over with a spoon! [was: getting at the XML in nib files] In-Reply-To: Message-ID: On Thu, 17 Jan 2002, Steven Majewski wrote: > > >>> o.nibInstantiateWithOwner_( app ) > 2002-01-17 18:30:14.247 python2.1[419] Unknown class `Foo' in nib file, > using `NSObject' instead. > 2002-01-17 18:30:14.252 python2.1[419] Could not connect the action seed: > to target of class NSObject > 2002-01-17 18:30:14.261 python2.1[419] Could not connect the action > generate: to target of class NSObject > > And the window popped up on the screen -- non functioning because this > was a nib from Random.App in Aaron Hillegass's book, and, as you can > see from the messages above, the targets in the nibs didn't match up > with any of the classes in Python. > And, I expect that those targets come from the classes.nib file, which is one of the XML text files. It might be possible to just edit that file and replace CLASS and ACTIONS with another class and methods. Now, the trick would be to figure out how to link it to a Python object. Don't know if that's possible, or if it will be more possible with new version that fixes the class/type split. { IBClasses = ( {CLASS = FirstResponder; LANGUAGE = ObjC; SUPERCLASS = NSObject; }, { ACTIONS = {generate = id; seed = id; }; CLASS = Foo; LANGUAGE = ObjC; OUTLETS = {textField = id; }; SUPERCLASS = NSObject; } ); IBVersion = 1; } -- Steve From dan@grassi.org Fri Jan 18 00:50:55 2002 From: dan@grassi.org (Dan Grassi) Date: Thu, 17 Jan 2002 19:50:55 -0500 Subject: [Pythonmac-SIG] Apple Events from MachO Python In-Reply-To: Message-ID: <6DF27ED9-0BAD-11D6-A3D7-003065F99F04@grassi.org> Hi All, I'm wondering what the status of Apple Event support in the MachO (unix) version of Python? Is this currently possible and if not is it on the radar? Thanks, Dan From sdm7g@Virginia.EDU Fri Jan 18 02:07:04 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Thu, 17 Jan 2002 21:07:04 -0500 (EST) Subject: [Pythonmac-SIG] Apple Events from MachO Python In-Reply-To: <6DF27ED9-0BAD-11D6-A3D7-003065F99F04@grassi.org> Message-ID: On Thu, 17 Jan 2002, Dan Grassi wrote: > I'm wondering what the status of Apple Event support in the MachO (unix) > version of Python? Is this currently possible and if not is it on the > radar? AE is one of the Carbon modules that's been ported, and I've already discovered that AppleEvents *DO* work to/from unix command line programs, so it ought to work. 'osascript' does it and I wrote a C cmd-line program that sent and received AppleEvents. I believe with 2.2, the carbon modules get built but they don't get installed, but if you copy them into a directory on the path ( plat-darwin ? I've been putting mine in site-packages/Carbon for now. ) 2 differences I've noticed: Unix apps don't have a 4 char signature but it's worked for me using the process name. Unix apps don't have an aete dictionary ( although, you can add one with Rez and it won't at all interfere with the normal non-macish operation. (I wonder if you can make a bundled App without it being a GUI app ? )) Another option: bill fancher has an OSA Python ( Python as a scripting addition to use instead of AppleScript ) ready for testing. I was thinking about adding support for a DoScript AppleEvent to Python so you could send it a python script. I wondered if there are any synchronization problems: what happens when it gets the DoScript AE when it's in the middle of executing a python script ? I supposed this is similar to the case where you have some sort of callback registered for a toolbox event. Are there any known problems with this sort of async. dispatching ? ( I was going to wait until I had time to poke around the source before I brought this up, but as long as Dan has brought up the subject... ) ( The C program I mentioned was talking to 'classic' XlispStat, which has a DoScript AE that evaluates a Lisp form and returns the answer as a string. ) -- Steve Majewski From fgranger@altern.org Thu Jan 17 21:55:17 2002 From: fgranger@altern.org (Francois Granger) Date: Thu, 17 Jan 2002 22:55:17 +0100 Subject: [Pythonmac-SIG] Third attempt at Carbon Tkinter In-Reply-To: <6E8CE39C-0B91-11D6-B884-003065517236@oratrix.nl> References: <6E8CE39C-0B91-11D6-B884-003065517236@oratrix.nl> Message-ID: At 22:30 +0100 17/01/02, in message [Pythonmac-SIG] Third attempt at Carbon Tkinter, Jack Jansen wrote: >Folks, >a third atttempt at an _tkinter.carbon.slb is now available at >http://www.cwi.nl/ftp/jack/python/mac/newer . > >This is built with the same 8.4.0 Tcl/Tk that the _tkinter.ppc.slb >that is in the 2.2 distribution was built with (so that's why >there's no accompanying PPC version, you have it already). Please >give this a try and let me know whether this is a feasible solution >for MacPython 2.2.1. Quick test: Traceback (most recent call last): File "HD:Python misc:anygui:test:test_button.py", line 4, in ? app = Application() File "HD:Python 2.2:Lib:anygui:backends:tkgui.py", line 574, in __init__ self._root = Tk() File "HD:Python 2.2:Lib:lib-tk:Tkinter.py", line 1487, in __init__ self.tk = _tkinter.create(screenName, baseName, className) TclError: can't find Init resource or a usable Init.tcl file in the following directories: {HD:Dossier Système:Extensions:Tool Command Language:tcl8.3} perhaps you need to install Tcl or set your TCL_LIBRARY environment variable? From jack@oratrix.com Fri Jan 18 09:52:24 2002 From: jack@oratrix.com (Jack Jansen) Date: Fri, 18 Jan 2002 10:52:24 +0100 Subject: [Pythonmac-SIG] Third attempt at Carbon Tkinter In-Reply-To: Message-ID: <12BFEE69-0BF9-11D6-BE0A-0030655234CE@oratrix.com> On Thursday, January 17, 2002, at 10:55 , Francois Granger wrote: > At 22:30 +0100 17/01/02, in message [Pythonmac-SIG] Third attempt at=20= > Carbon Tkinter, Jack Jansen wrote: >> Folks, >> a third atttempt at an _tkinter.carbon.slb is now available [...] > Quick test: [...] > TclError: can't find Init resource or a usable Init.tcl file > in the following directories: > {HD:Dossier Syst=E8me:Extensions:Tool Command Language:tcl8.3} > perhaps you need to install Tcl or set your > TCL_LIBRARY environment variable? > I am completely baffled. Just to make sure that I fully understand the=20= problem: if you ConfigurePythonClassic then this test works fine, but if=20= you ConfigurePythonCarbon it does not work? Could you send me your Apple System Profiler output, please? From jack@oratrix.com Fri Jan 18 09:58:01 2002 From: jack@oratrix.com (Jack Jansen) Date: Fri, 18 Jan 2002 10:58:01 +0100 Subject: [Pythonmac-SIG] Knock me over with a spoon! [was: getting at the XML in nib files] In-Reply-To: Message-ID: Steve, I am *very* interested in what you're finding, and I think I'm going to find that I absolutely need the info once I dive into objC/Cocoa, but for now you've completely lost me. As you seem to be the most knowledgeable on the subject in this group, could you try going a little slower and explain a bit of the terminology as you go? From jack@oratrix.com Fri Jan 18 12:05:53 2002 From: jack@oratrix.com (Jack Jansen) Date: Fri, 18 Jan 2002 13:05:53 +0100 Subject: [Pythonmac-SIG] Third attempt at Carbon Tkinter In-Reply-To: <8DE147AF-0BFB-11D6-9F43-0030657770F8@othermedia.com> Message-ID: On Friday, January 18, 2002, at 11:10 , Tom Smith wrote: > On Thursday, January 17, 2002, at 09:30 PM, Jack Jansen wrote: > >> Folks, >> a third atttempt at an _tkinter.carbon.slb is now available at >> http://www.cwi.nl/ftp/jack/python/mac/newer . > > I installed 2.2 > ran ConfigurePythonCarbon, > put _tkinter.carbon.slb and PythonCoreCarbon into my python folder and > then... > > import Tkinter > Traceback (most recent call last): > File "", line 1, in ? > File "Stuff:Carbon Apps:Python 2.2:Lib:lib-tk:Tkinter.py", line 35, > in ? > import _tkinter # If this fails your Python may not be configured > for Tk > ImportError: <_tkinter.carbon><_tkinter.carbon><>: The > named library was not found. > > Have I done something wrong? > Yes: you're trying this on Mac OS X:-) The "Carbon" version of Tkinter will only work on OS9 or earlier, as it isn't really a Carbon plugin module: it's a classic module that allows itself to be loaded into a Carbon MacPython. This is probably not going to be fixed: if you want Tkinter on Mac OS X use MachoPython and the Aqua Tcl/Tk Tkinter. From mjb@uma.pt Fri Jan 18 12:08:11 2002 From: mjb@uma.pt (Michael J. Barber) Date: Fri, 18 Jan 2002 12:08:11 +0000 Subject: [Pythonmac-SIG] rewritten documentation for OSA Message-ID: <0AD2CDC3-0C0C-11D6-88EB-0050E4794D0F@uma.pt> I have rewritten the documentation for using OSA in Python. Mainly, I reorganized the document to make it easier to use when I was generating some packages with gensuitemodule. The modified version is at . I duplicated the Disk_Copy package there as well to make the hyperlinks work, but nothing is changed in the other files. The revised version stands pretty well as it is, but there were some spots that I wasn't entirely clear on. These are generally marked by comments in the html source. I didn't make any attempt to address OS X, so that could be addressed as well. Comments welcome. Michael From sdm7g@Virginia.EDU Fri Jan 18 12:52:03 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Fri, 18 Jan 2002 07:52:03 -0500 (EST) Subject: [Pythonmac-SIG] Knock me over with a spoon! [was: getting at the XML in nib files] In-Reply-To: Message-ID: On Fri, 18 Jan 2002, Jack Jansen wrote: > > Steve, > I am *very* interested in what you're finding, and I think I'm going to > find that I absolutely need the info once I dive into objC/Cocoa, but > for now you've completely lost me. As you seem to be the most > knowledgeable on the subject in this group, could you try going a little > slower and explain a bit of the terminology as you go? > Yes. I'll draft a brief tutorial (with a couple of links to some StepWise articles that explain some of the plumbing). As you might guess from the replies to my own replies, it was a stream-of-conciousness dump caused by the excitement that it was actually working that far! -- Steve. From tony.mcdonald@ncl.ac.uk Fri Jan 18 13:52:07 2002 From: tony.mcdonald@ncl.ac.uk (Tony McDonald) Date: Fri, 18 Jan 2002 13:52:07 +0000 Subject: [Pythonmac-SIG] Impressed! Message-ID: Hi all, Longtime lurker, first (or so) time poster... I just wanted to say how impressed I am with all the activity and enthusiasm there is on this list at the moment!. It seems to me (sitting on the sidelines, using python on Suns and my Mac-OSX unix python) that people are revving up to some really *interesting* projects. I admit, I had not a clue about the 'spoons' email ;), but it seems to portend of great things, then there's the plethora of Aqua UI programming styles. Activity on wxPython and then everything else. It seems every day I check the list, someone has come up with some wicked cool piece of information that's going to make our MacPython (MachoPython) into an extremely useful tool. Wow-ly, Tone -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope From jack@oratrix.com Fri Jan 18 13:53:14 2002 From: jack@oratrix.com (Jack Jansen) Date: Fri, 18 Jan 2002 14:53:14 +0100 Subject: [Pythonmac-SIG] bug in MacPython 2.1.1 BuildApplet -- can trash files! In-Reply-To: Message-ID: On Thursday, January 17, 2002, at 10:28 , Russell E Owen wrote: > If the name of the file dropped on BuildApplet (MacPython 2.1.1 > configured for Carbon) is the right length, BuildApplet will work and > then will delete the source file!!! > > For instance: > "Cvt cmm -> Igor data 2-0 long name.py" > first produces a working droplet with name: > "Cvt cmm -> Igor data 2#7F2E4" > and then the source file simply vanishes. It's really gone, too (or > perhaps moved and renamed) -- a disk search doesn't turn it up anywhere. > Ouch! I assume this is on OSX, right? Could you file a bug report (with a fairly high priority), please? From bobsavage@mac.com Fri Jan 18 14:22:33 2002 From: bobsavage@mac.com (Bob Savage) Date: Fri, 18 Jan 2002 08:22:33 -0600 Subject: [Pythonmac-SIG] Knock me over with a spoon! [was: getting at the XML in nib files] In-Reply-To: Message-ID: on 1/18/02 6:52 AM, Steven Majewski wrote: > > Yes. I'll draft a brief tutorial (with a couple of links to some > StepWise articles that explain some of the plumbing). Excellent! I think your findings are fascinating, but I haven't been able to get a handle on the way of PyObjC yet. > as you can see from the messages above, the targets in the nibs > didn't match up with any of the classes in Python. So you think we can create an interface in IB, then create a class in python which has methods and properties with names which will match the actions and outlets of the nib file. Then theNibFile.nibInstantiateWithOwner_( thePythonObject ) will run the application? Or did you mean that we would do something to the sharedApplication to set thePythonObject as its delegate, then instantiate as you described? Bob From sdm7g@Virginia.EDU Fri Jan 18 14:27:18 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Fri, 18 Jan 2002 09:27:18 -0500 (EST) Subject: [Pythonmac-SIG] rewritten documentation for OSA In-Reply-To: <0AD2CDC3-0C0C-11D6-88EB-0050E4794D0F@uma.pt> Message-ID: On Fri, 18 Jan 2002, Michael J. Barber wrote: > I have rewritten the documentation for using OSA in Python. Mainly, I > reorganized the document to make it easier to use when I was generating > some packages with gensuitemodule. Nice work, Michael! (and nice timing, since I was about to delve into trying to do some of that stuff.) I'll send you more detailed comments after I've worked thru the examples. > > The revised version stands pretty well as it is, but there were some > spots that I wasn't entirely clear on. These are generally marked by > comments in the html source. I didn't make any attempt to address OS X, > so that could be addressed as well. > The main point to make for OSX is that (as I was telling Dan) AppleEvents do actually work to and from the unix command line mach-o python. I wasn't even sure whether it was supposed to work when I tried it -- I asked on one of the osx lists if this ( AEs from non GUI apps ) was likely to disappear or would be supported in the future and someone reminded me (Duh!) about Apple's osascript/osacompile command line tools. One termonological point: I thought an 'Open Scripting Extension' meant something more specifically like what bill fancher is doing -- actually writing an extension for OSA rather than a program that uses OSA and AppleEvents. -- Steve Majewski From sdm7g@Virginia.EDU Fri Jan 18 14:52:32 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Fri, 18 Jan 2002 09:52:32 -0500 (EST) Subject: [Pythonmac-SIG] Knock me over with a spoon! [was: getting at the XML in nib files] In-Reply-To: Message-ID: On Fri, 18 Jan 2002, Bob Savage wrote: > So you think we can create an interface in IB, then create a class in python > which has methods and properties with names which will match the actions and > outlets of the nib file. Then > > theNibFile.nibInstantiateWithOwner_( thePythonObject ) > > will run the application? Or did you mean that we would do something to the > sharedApplication to set thePythonObject as its delegate, then instantiate > as you described? This is the part I'm not so sure about! In IB I linked the GUI elements to my (objective-c) classes -- one of them had an initialization routine in awakeFromNib, which is supposed to get called when the nib is loaded and instantiated, and from the error message, that's what it tried to do. There probably needs to be a proxy class to forward the method call from obj-c to python. That's what the plumbing in pyobjc already does, but since this seems to be a "call by name", it might take adding a special bridge class just to handle this kind of forwarding. I'll have to think about this. But possibly, delegates might work -- I'll have to look at the delegation protocol again. But even when I made an NSApplication the nib owner, it looks like it's still looking for the defined target classes and methods by name. Possibly, the new design for 2.2 type/classes might help (except that I'm finished figuring out how to do it! ) -- Steve. BTW: I did these tests with Python2.1.2. The pyobjc on SourceForge ( either the .so or building from tar ) still works with 2.1.x . It doesn't work with 2.2 (intentionally -- a version mismatch) and when I try to build using 2.2, it builds, but on import, I get a: ImportError: Failure linking new module so something has to be different in the build. Anyone have a guess? I've stepped thru in gdb and found where it's getting an error but I'm not sure what that means. Jack -- I looked thru the Makefiles for both versions of Python looking for a difference in library link options -- I couldn't find a likely culprit, but maybe I was looking in the wrong place. Do you have any notion about what needs to change ? Maybe this is an issue with the newer developer tools? From jack@oratrix.com Fri Jan 18 16:36:44 2002 From: jack@oratrix.com (Jack Jansen) Date: Fri, 18 Jan 2002 17:36:44 +0100 Subject: [Pythonmac-SIG] Knock me over with a spoon! [was: getting at the XML in nib files] In-Reply-To: Message-ID: <8F364340-0C31-11D6-AD94-0030655234CE@oratrix.com> On Friday, January 18, 2002, at 03:52 , Steven Majewski wrote: > > BTW: I did these tests with Python2.1.2. The pyobjc on SourceForge > ( either the .so or building from tar ) still works with 2.1.x . > It doesn't work with 2.2 (intentionally -- a version mismatch) > and when I try to build using 2.2, it builds, but on import, I get a: > > ImportError: Failure linking new module > > so something has to be different in the build. Anyone have a guess? > I've stepped thru in gdb and found where it's getting an error > but I'm not sure what that means. > > Jack -- I looked thru the Makefiles for both versions of Python > looking for a difference in library link options -- I couldn't > find a likely culprit, but maybe I was looking in the wrong place. > Do you have any notion about what needs to change ? Maybe this > is an issue with the newer developer tools? Could you give some (as detailed as possible) instructions as to how to get the ObjC module and how you've built it? Then I'll try and find the time to give it a spin. Or, preferrably, someone else will beat me to it:-) The error, incidentally, is NSLinkModule() failing, down in dynload_next.c. You could try setting some of the DYLD_xxxxx environment variables or running under gdb to see what the problem is. Maybe 2-level namespaces, maybe an external from Python you use that was there in 2.1 but missing in 2.2 (but you should have gotten a warning on compilation, because the prototype will also have gone). -- - 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 jacobkm@cats.ucsc.edu Fri Jan 18 16:53:41 2002 From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss) Date: Fri, 18 Jan 2002 08:53:41 -0800 Subject: [Pythonmac-SIG] rewritten documentation for OSA In-Reply-To: <0AD2CDC3-0C0C-11D6-88EB-0050E4794D0F@uma.pt> References: <0AD2CDC3-0C0C-11D6-88EB-0050E4794D0F@uma.pt> Message-ID: Michael -- First off, great job. I actually tried my hand at something like this a while ago, and it really is hard. This document makes a lot of sense out of some tricky stuff. I've read your comments, and I have some answers to the questions you raised: >If you want to re-create the StdSuite modules, >you should look in one of two places. On older systems you will find the > AFAIK, the "English Dialect" file was removed with AppleScript 1.3.4, which shipped with MacOS 8.5, so I belive that generating StdSuites should be done from the AppleScript extension itself in all post-8.5 systems. I've you've upgraded 8.5 from 8.0, the Dialect file may still be floating around, but it is out of date. >Examine aetools and aetools.TalkTo > > Yup. aetools has most of the code for OSA communication, and the aetools.TalkTo class parent class for all application classes generated by gensuitemodule. >The exception handling does warrant a few comments, though. Since >AppleScript is basically a connectionless RPC protocol, >nothing happens when we create the talker object. >Hence, if the destination application is not running, we will not >notice until we send our first command. There is another thing to >note about errors returned by >AppleScript calls: MacOS.Error is raised for all of the >errors that are known to be OSErr-type errors, while >server generated errors raise aetools.Error.

This paragraph sounds right to me, although you should probably note that the best way to ensure that the application you want to talk to is running is to create the class with "start=1" or to call talker.start() right off the bat, ie: # Either do this: talker = Eudora.Eudora(start=1) # or whatever app you are using # Or do this: talker = Eudora.Eudora() talker.start() >If you want to use any of the scripting additions (or OSAXen, in >everyday speech) from a Python program, you can use the same method >as for applications, i.e. run gensuitemodule on the >OSAX (commonly found in System Folder:Scripting >Additions or something similar). There is one minor gotcha: >the application signature to use is MACS. > The best way to do it is to edit the main class in the __init__.py file from the created package and change _signature to "MACS": # For some hypothetical OSAX "MyCoolOSAX", in # lib-scriptpackages/MyCoolOSAX/__init__.py: class MyCoolOSAX(MyCoolOSAX_Events): _signature = 'MACS' Hope all that makes sense to you; let me know if you have any questions. Jacob Kaplan-Moss From mjb@uma.pt Fri Jan 18 17:30:20 2002 From: mjb@uma.pt (Michael J. Barber) Date: Fri, 18 Jan 2002 17:30:20 +0000 Subject: [Pythonmac-SIG] rewritten documentation for OSA In-Reply-To: Message-ID: <0C2D765D-0C39-11D6-88EB-0050E4794D0F@uma.pt> On Friday, January 18, 2002, at 02:27 PM, Steven Majewski wrote: > > Nice work, Michael! (and nice timing, since I was about to delve into > trying to do some of that stuff.) I'll send you more detailed > comments after I've worked thru the examples. > Thanks. I'm looking forward to the comments. I've made a few changes based on what you've already said. Still at: . > The main point to make for OSX is that (as I was telling Dan) > AppleEvents > do actually work to and from the unix command line mach-o python. > I wasn't even sure whether it was supposed to work when I tried it -- > I asked on one of the osx lists if this ( AEs from non GUI apps ) was > likely to disappear or would be supported in the future and someone > reminded me (Duh!) about Apple's osascript/osacompile command line > tools. > Duh for me, too! I had been aware of those tools, but hadn't made the connection to using them with python for some reason. Probably because I was already using gensuitemodule. At any rate, I think I'll have to rewrite a couple of scripts and play a bit. I've added a brief section on OS X. Right now, it mainly mentions osascript and osacompile with a RTFM-like comment. Possibly, I can expand that after some experimentation. > One termonological point: I thought an 'Open Scripting Extension' > meant something more specifically like what bill fancher > > is doing -- actually writing an extension for OSA rather than a > program that uses OSA and AppleEvents. > That is my understanding as well. I had just kept the title of the original version, but I see that "Open Scripting Architecture" is used at another point in the MacPython docs. I've changed the title. Since I'm now expanding the scope of the document a bit, it seems like Bill Fancher's OSA Python should be mentioned as well. Unfortunately, the link I had to his web page seems to be invalid now. If there is a new page for it, I'll gladly add a brief description and relevant links. I'll email him and ask. Anyone know of other related tools that should be mentioned? From laptoplyrik@gmx.net Fri Jan 18 17:49:44 2002 From: laptoplyrik@gmx.net (Christian Ebert) Date: Fri, 18 Jan 2002 18:49:44 +0100 Subject: [Pythonmac-SIG] Third attempt at Carbon Tkinter In-Reply-To: Message-ID: <20020118185031-r01010800-3cff5ac3-0922-0108@217.0.163.51> Hi Jack, Jack Jansen at 13:05 on Friday, January 18, 2002: > > Have I done something wrong? > > > Yes: you're trying this on Mac OS X:-) Well, I am the guy with the bad news: Still looking in vain for tcl8.3 on OS 9.2 ... Very stupid question: Are you sure you uploaded the changed version? Because the one I downloaded still says Jan 12. Sorry. Christian -- I'm only happy when it rains. (Garbage) From fancher@pacbell.net Fri Jan 18 18:03:52 2002 From: fancher@pacbell.net (bill fancher) Date: Fri, 18 Jan 2002 10:03:52 -0800 Subject: [Pythonmac-SIG] rewritten documentation for OSA In-Reply-To: Message-ID: On Friday, January 18, 2002, at 06:27 AM, Steven Majewski wrote: > One termonological point: I thought an 'Open Scripting Extension' > meant something more specifically like what bill fancher > > is doing -- actually writing an extension for OSA rather than a > program that uses OSA and AppleEvents. What I've been working on is actually an OSA component (lives in "/Library/Components/" in OS X, though though such things did live in the "Extensions" on earlier system versions.) On Friday, January 18, 2002, at 09:30 AM, Michael J. Barber wrote: > Since I'm now expanding the scope of the document a bit, it seems like > Bill Fancher's OSA Python should be mentioned as well. Unfortunately, > the link I had to his web page seems to be invalid now. If there is a > new page for it, I'll gladly add a brief description and relevant > links. I'll email him and ask. That page was really old and misleading so I dumped it. Sorry. I'll have something new up as soon as I get a chance (no telling when that will be, tied up with 1.0a5 and work for $ at the moment). I'll make an announcement to the list. If you're interested, contact me privately and I'll gladly send a copy of the current stuff, which contains the existing "documentation" and a bunch of example scripts. -- bill From anton@seul.org Fri Jan 18 18:13:56 2002 From: anton@seul.org (anton@seul.org) Date: Fri, 18 Jan 2002 13:13:56 -0500 (EST) Subject: [Pythonmac-SIG] PyGreSQL on Mac OS X Message-ID: I'm trying to get PyGreSQL to work on a mac running OS 10.1.2, postgresql 7.1.3 and python 2.2 (unix command-line version). The first thing I tried was rebuilding postgres after running configure with the --with-python option, but make exits with cp /usr/local/lib/python2.2/config/Makefile.pre.in Makefile.pre.in make -f Makefile.pre.in boot srcdir=. VPATH=. make[4]: *** No rule to make target `boot'. Stop. make[3]: *** [Makefile] Error 2 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 So then I tried compiling the PyGreSQL module as a stand-alone, and after figuring out how to work around some issues related to non-GNU linkers by using the information from fink's porting documentation, I managed to compile without errors by using cc -bundle -flat_namespace -undefined suppress -o _pg.so -I/usr/local/include/python2.2 -I/usr/local/pgsql/src/include -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpq pgmodule.c However, I cannot import the compiled _pg into python. The errors it gives are: >>> import _pg Traceback (most recent call last): File "", line 1, in ? ImportError: Failure linking new module I'm new enough to all of python, postgres and unix in general to not really know where to go next to get more information about what the problem is and how to solve it, and would appreciate any hints or pointers... Thanks, Anton. From sdm7g@Virginia.EDU Fri Jan 18 18:14:39 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Fri, 18 Jan 2002 13:14:39 -0500 (EST) Subject: [Pythonmac-SIG] Knock me over with a spoon! [was: getting at the XML in nib files] In-Reply-To: <8F364340-0C31-11D6-AD94-0030655234CE@oratrix.com> Message-ID: On Fri, 18 Jan 2002, Jack Jansen wrote: > > On Friday, January 18, 2002, at 03:52 , Steven Majewski wrote: > > Could you give some (as detailed as possible) instructions as to how to > get the ObjC module and how you've built it? Then I'll try and find the > time to give it a spin. Or, preferrably, someone else will beat me to > it:-) Grab and unpack: and in that pyobjc directory do: python setup.py build or, if you do: python setup.py install it'll get installed in site-packages/ If you have several versions of python installed, if you do: python2.1 setup.py install it'll get built for that version and install in (most likely): /usr/local/lib/python2.1/site-packages (likewise for python2.2) On my latest attempt, it builds, imports and functions properly (or at least, nearly as well as it ever did!) with 2.1 . For 2.2, it builds OK but gives that error on import. > The error, incidentally, is NSLinkModule() failing, down in > dynload_next.c. You could try setting some of the DYLD_xxxxx environment > variables or running under gdb to see what the problem is. Maybe 2-level > namespaces, maybe an external from Python you use that was there in 2.1 > but missing in 2.2 (but you should have gotten a warning on compilation, > because the prototype will also have gone). running in gdb, I find: in _PyImport_LoadDynamicModule, in _PyImport_GetDynLoadFunc, after: rc = NSCreateObjectFileImageFromFile(pathname, &image); rc == NSObjectImageFileSuccess but when it hits NSLinkModule, it seems to be returning 0x0: 150 if (errString == NULL) { 151 newModule = NSLinkModule(image, pathname, 152 NSLINKMODULE_OPTION_BINDNOW|NSLINKMODULE_OPTION_RETURN_ON_ERROR); 153 if (!newModule) 154 errString = "Failure linking new module"; 155 } ... maybe those options don't match the type of bundle ? I'll give your suggestions a try. -- Steve From sdm7g@Virginia.EDU Fri Jan 18 18:29:35 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Fri, 18 Jan 2002 13:29:35 -0500 (EST) Subject: [Pythonmac-SIG] pyobjc.so [was: Knock me over with a spoon!] In-Reply-To: Message-ID: On Fri, 18 Jan 2002, Steven Majewski wrote: > Grab and unpack: > BTW: There is also a prebuilt pyobjc.so that works for 2.1.x at sourceforge: > > in _PyImport_LoadDynamicModule, > in _PyImport_GetDynLoadFunc, > after: > rc = NSCreateObjectFileImageFromFile(pathname, &image); > > rc == NSObjectImageFileSuccess > > but when it hits NSLinkModule, it seems to be returning 0x0: > > 150 if (errString == NULL) { > 151 newModule = NSLinkModule(image, pathname, > 152 NSLINKMODULE_OPTION_BINDNOW|NSLINKMODULE_OPTION_RETURN_ON_ERROR); > 153 if (!newModule) > 154 errString = "Failure linking new module"; > 155 } > I keep forgetting where to find the docs for those routines -- 'man -k' never seems to find it for me. ( It's 'man NSModule', BTW.) NSLINKMODULE_OPTION_RETURN_ON_ERROR With this option if errors occur while binding this module it is automaticly unloaded and NULL is returned as the module handle. To get the error information for the module that failed to load the routine NSLinkEditError is then used. It has the same parameters as the link edit error handler (see below) except all the parameters are pointers in which the information is returned indirectly. Looks like I need to insert a call to NSLinkEditError to get the specific error info. -- Steve From jacobkm@cats.ucsc.edu Fri Jan 18 19:26:05 2002 From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss) Date: Fri, 18 Jan 2002 11:26:05 -0800 Subject: [Pythonmac-SIG] Python/XDarwin/Tkinter on OS X 10.1 Message-ID: All -- Jack asked for descriptions of the various Aqua UI options, so I thought I'd throw in what I've done. Using Fink, I've gotten MachoPython and Tkinter working with OSX 10.1 and XDarwin. I've now done this on a bunch of machines, and its a really nice way of getting Tkinter working easily. The short version: - Install Fink - Add "unstable/main" to the "Trees:" line in /sw/etc/fink.conf - From the command line: [localhost:~] jacob% fink selfupdate (say yes to "packages from CVS") [localhost:~] jacob% fink install xfree86-base [localhost:~] jacob% fink install xfree86-rootless [localhost:~] jacob% fink install windowmaker [localhost:~] jacob% fink install python [localhost:~] jacob% python >>> import Tkinter >>> #YAY! The longer version: 1. Install Fink (see fink.sf.net for specific instructions). I use the source install option, which seemed the best for me since I like the change the default directory and such. 2. Set Fink to use the unstable/main branch (some of the packages (xfree86-rootless, for one) are in the unstable branch, so we'll need Fink to use it). The way to do this is to edit the fink.conf file (/sw/etc/fink.conf) and add "unstable/main" to the end of the "Trees:" line. My "Trees:" line is: "Trees: local/main stable/main stable/crypto local/bootstrap unstable/main" 3. Update Fink (fink selfupdate). When it asks you if you want to get curent packages from CVS, say yes. 4. Install xfree86. Fink's xfree86 is split into two packages, you'll need to install xfree86-base, then xfree86-rootless. I use "fink install ..." to install those packages, which builds them from source but takes a long time, if time is an issue you might want to use "apt-get install ..." 5. Install a window manager. I use WindowMaker, but any one with a Fink package should work in theory. 6. Install Python ("fink install python"). 7. Enjoy; you should be good to go! Should I write this up as a web page? Jacob From sdm7g@Virginia.EDU Fri Jan 18 19:52:18 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Fri, 18 Jan 2002 14:52:18 -0500 (EST) Subject: [Pythonmac-SIG] (PyMapping|PyDict|PyObject)_DelItemString [was: [Pythonmac-SIG] pyobjc.so ] In-Reply-To: Message-ID: [ Background note for cc: to python-dev: pyobjc.so builds under both python2.1.2 and python2.2. It works under 2.1.2, but under 2.2, it gives a 'Failure linking new module' error. ] Added a call to NSLinkEditError to get back more info from the error (I'll submit this as a patch to SF after I clean it up a bit.): >>> import pyobjc Traceback (most recent call last): File "", line 1, in ? ImportError: dyld: /usr/local/src/Python-2.2/python.exe Undefined symbols: _PyObject_DelItemString Failure linking new module >>> grepping for this in 2.1.2 finds nothing. In 2.2, there seems to be one occurance: grep PyObject_DelItemString */*.[ch] Include/abstract.h:#define PyMapping_DelItemString(O,K) PyObject_DelItemString((O),(K)) Searching for PyMapping_DelItemString, it looks like this changed from PyDict_DelItemString() in 2.1.2 to PyObject_DelItemString() in 2.2: dm7g% grep PyMapping_DelItemString Python-2.*/*/*.[ch] Python-2.1.2/Include/abstract.h: int PyMapping_DelItemString(PyObject *o, char *key); Python-2.1.2/Include/abstract.h:#define PyMapping_DelItemString(O,K) PyDict_DelItemString((O),(K)) Python-2.2/Include/abstract.h: int PyMapping_DelItemString(PyObject *o, char *key); Python-2.2/Include/abstract.h:#define PyMapping_DelItemString(O,K) PyObject_DelItemString((O),(K)) Is this change of name an inadvertant bug, or is it something that was intentionally changed, but incompletely? -- Steve From guido@python.org Fri Jan 18 20:57:21 2002 From: guido@python.org (Guido van Rossum) Date: Fri, 18 Jan 2002 15:57:21 -0500 Subject: [Python-Dev] (PyMapping|PyDict|PyObject)_DelItemString [was: [Pythonmac-SIG] pyobjc.so ] In-Reply-To: Your message of "Fri, 18 Jan 2002 14:52:18 EST." References: Message-ID: <200201182057.PAA21273@cj20424-a.reston1.va.home.com> > >>> import pyobjc > Traceback (most recent call last): > File "", line 1, in ? > ImportError: dyld: /usr/local/src/Python-2.2/python.exe Undefined symbols: > _PyObject_DelItemString > Failure linking new module > >>> > > grepping for this in 2.1.2 finds nothing. > > In 2.2, there seems to be one occurance: > > grep PyObject_DelItemString */*.[ch] > Include/abstract.h:#define PyMapping_DelItemString(O,K) PyObject_DelItemString((O),(K)) > > Searching for PyMapping_DelItemString, it looks like this changed from > PyDict_DelItemString() in 2.1.2 to PyObject_DelItemString() in 2.2: > > dm7g% grep PyMapping_DelItemString Python-2.*/*/*.[ch] > Python-2.1.2/Include/abstract.h: int PyMapping_DelItemString(PyObject *o, char *key); > Python-2.1.2/Include/abstract.h:#define PyMapping_DelItemString(O,K) PyDict_DelItemString((O),(K)) > Python-2.2/Include/abstract.h: int PyMapping_DelItemString(PyObject *o, char *key); > Python-2.2/Include/abstract.h:#define PyMapping_DelItemString(O,K) PyObject_DelItemString((O),(K)) > > > Is this change of name an inadvertant bug, or is it something that > was intentionally changed, but incompletely? The latter. See: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=498915 --Guido van Rossum (home page: http://www.python.org/~guido/) From martin@v.loewis.de Fri Jan 18 20:57:48 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Fri, 18 Jan 2002 21:57:48 +0100 Subject: [Pythonmac-SIG] Re: [Python-Dev] (PyMapping|PyDict|PyObject)_DelItemString [was: [Pythonmac-SIG] pyobjc.so ] In-Reply-To: (message from Steven Majewski on Fri, 18 Jan 2002 14:52:18 -0500 (EST)) References: Message-ID: <200201182057.g0IKvms01998@mira.informatik.hu-berlin.de> > Is this change of name an inadvertant bug, or is it something that > was intentionally changed, but incompletely? This is bug #498915, fixed in abstract.h 2.43 and 2.42.6.1, abstract.c 2.94 and 2.93.6.1 Regards, Martin From prastawa@cs.unc.edu Fri Jan 18 21:03:12 2002 From: prastawa@cs.unc.edu (Marcelinus Prastawa) Date: Fri, 18 Jan 2002 16:03:12 -0500 Subject: [Pythonmac-SIG] PyGreSQL on Mac OS X In-Reply-To: Message-ID: On Friday, January 18, 2002, at 01:13 , wrote: > cc -bundle -flat_namespace -undefined suppress -o _pg.so > -I/usr/local/include/python2.2 -I/usr/local/pgsql/src/include > -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpq pgmodule.c ... > >>> import _pg > Traceback (most recent call last): > File "", line 1, in ? > ImportError: Failure linking new module Disclaimer: I am not familiar with PyGreSQL. I've experienced the same thing with VTK (a visualization toolkit). Try adding this option when building the extension module: '-bundle_loader /path/to/python-executable' Marcel From anton@seul.org Fri Jan 18 21:47:02 2002 From: anton@seul.org (anton@seul.org) Date: Fri, 18 Jan 2002 16:47:02 -0500 (EST) Subject: [Pythonmac-SIG] PyGreSQL on Mac OS X Message-ID: Thanks Marcel! That worked like a charm. At least, it imports without errors. Anton. On Friday, January 18, 2002, at 01:13 , wrote: > cc -bundle -flat_namespace -undefined suppress -o _pg.so > -I/usr/local/include/python2.2 -I/usr/local/pgsql/src/include > -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpq pgmodule.c ... > >>> import _pg > Traceback (most recent call last): > File "", line 1, in ? > ImportError: Failure linking new module Disclaimer: I am not familiar with PyGreSQL. I've experienced the same thing with VTK (a visualization toolkit). Try adding this option when building the extension module: '-bundle_loader /path/to/python-executable' Marcel From fgranger@altern.org Fri Jan 18 21:39:05 2002 From: fgranger@altern.org (Francois Granger) Date: Fri, 18 Jan 2002 22:39:05 +0100 Subject: [Pythonmac-SIG] Third attempt at Carbon Tkinter In-Reply-To: <12BFEE69-0BF9-11D6-BE0A-0030655234CE@oratrix.com> References: <12BFEE69-0BF9-11D6-BE0A-0030655234CE@oratrix.com> Message-ID: At 10:52 +0100 18/01/02, in message Re: [Pythonmac-SIG] Third attempt at Carbon Tkinter, Jack Jansen wrote: >Could you send me your Apple System Profiler output, please? Private answer with file enclosed. From sdm7g@Virginia.EDU Fri Jan 18 22:49:38 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Fri, 18 Jan 2002 17:49:38 -0500 (EST) Subject: [Pythonmac-SIG] Re: several messages In-Reply-To: <200201182057.g0IKvms01998@mira.informatik.hu-berlin.de> Message-ID: On Fri, 18 Jan 2002, Guido van Rossum wrote: > http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=498915 On Fri, 18 Jan 2002, Martin v. Loewis wrote: > This is bug #498915, fixed in abstract.h 2.43 and 2.42.6.1, > abstract.c 2.94 and 2.93.6.1 Thanks. I changed it back to PyDict_... With that patch, pyobjc seems to build and work with Python-2.2 as well as 2.1.2. -- Steve. From tom@othermedia.com Fri Jan 18 16:45:45 2002 From: tom@othermedia.com (Tom Smith) Date: Fri, 18 Jan 2002 16:45:45 +0000 Subject: [Pythonmac-SIG] Third attempt at Carbon Tkinter HELP In-Reply-To: Message-ID: --Apple-Mail-8-852890686 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Friday, January 18, 2002, at 12:05 PM, Jack Jansen wrote: > This is probably not going to be fixed: if you want Tkinter on Mac OS X > use MachoPython and > the Aqua Tcl/Tk Tkinter. MachoPython? What's that? I seem to have missed the Aqua Tcl/Tk Tkinter bit too....and another thing, wX doesn't work on OSX yet does it...I mean with out having to recompile my brain (i.e easy install) cheers tom -- tom smith | tom@othermedia.com http://www.othermedia.com/blog 3rd Floor, The Pavilion, Newhams Row, London, SE1 3UZ 0207 089 5959 --Apple-Mail-8-852890686 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII On Friday, January 18, 2002, at 12:05 PM, Jack Jansen wrote: This is probably not going to be fixed: if you want Tkinter on Mac OS X use MachoPython and the Aqua Tcl/Tk Tkinter. MachoPython? What's that? I seem to have missed the Aqua 0000,0000,DEDETcl/Tk Tkinter bit too....and another thing, wX doesn't work on OSX yet does it...I mean with out having to recompile my brain (i.e easy install) cheers tom -- tom smith | tom@othermedia.com http://www.othermedia.com/blog 3rd Floor, The Pavilion, Newhams Row, London, SE1 3UZ 0207 089 5959 --Apple-Mail-8-852890686-- From bob@redivi.com Fri Jan 18 22:52:01 2002 From: bob@redivi.com (Bob Ippolito) Date: Fri, 18 Jan 2002 17:52:01 -0500 Subject: [Pythonmac-SIG] Python/XDarwin/Tkinter on OS X 10.1 In-Reply-To: Message-ID: Without fink, there's my package that doesn't depend on xfree at all that I put together when I decided to port pygame to OS X. It's available at: http://redivi.com/~bob/ It's kinda hefty because all debug symbols and development headers for all the frameworks are included, and it includes a slew of stuff, but it covers more or less anything you could need for general python stuff (at least, more or less everything I use). The installer is readily available and has been reported working by a bunch of people other than myself... but to my surprise IE and Stuffit truncate filenames to 31 characters or so.. so you'll have to download/rename and untar with something other than stuffit. I will be making a new package with a shorter name and such in the coming few weeks when/if I get my altivec optimizations (don't worry, it won't break G3 support) for SDL finished and possibly even a few into Numeric and/or PIL when I'm at it. For any of you that like low level bit twiddling (or have a thirst for performance), and can grok C.. I highly suggest learning how to use the altivec instructions. -bob On Friday, January 18, 2002, at 02:26 PM, Jacob Kaplan-Moss wrote: > All -- > > Jack asked for descriptions of the various Aqua UI options, so I > thought I'd throw in what I've done. Using Fink, I've gotten > MachoPython and Tkinter working with OSX 10.1 and XDarwin. I've now > done this on a bunch of machines, and its a really nice way of getting > Tkinter working easily. > > The short version: > > - Install Fink > - Add "unstable/main" to the "Trees:" line in /sw/etc/fink.conf > - From the command line: > > [localhost:~] jacob% fink selfupdate > (say yes to "packages from CVS") > [localhost:~] jacob% fink install xfree86-base > [localhost:~] jacob% fink install xfree86-rootless > [localhost:~] jacob% fink install windowmaker > [localhost:~] jacob% fink install python > [localhost:~] jacob% python > >>> import Tkinter > >>> #YAY! > > The longer version: > > 1. Install Fink (see fink.sf.net for specific instructions). I use > the source install option, which seemed the best for me since I like > the change the default directory and such. > > 2. Set Fink to use the unstable/main branch (some of the packages > (xfree86-rootless, for one) are in the unstable branch, so we'll need > Fink to use it). The way to do this is to edit the fink.conf file > (/sw/etc/fink.conf) and add "unstable/main" to the end of the "Trees:" > line. My "Trees:" line is: "Trees: local/main stable/main > stable/crypto local/bootstrap unstable/main" > > 3. Update Fink (fink selfupdate). When it asks you if you want to get > curent packages from CVS, say yes. > > 4. Install xfree86. Fink's xfree86 is split into two packages, you'll > need to install xfree86-base, then xfree86-rootless. I use "fink > install ..." to install those packages, which builds them from source > but takes a long time, if time is an issue you might want to use > "apt-get install ..." > > 5. Install a window manager. I use WindowMaker, but any one with a > Fink package should work in theory. > > 6. Install Python ("fink install python"). > > 7. Enjoy; you should be good to go! > > Should I write this up as a web page? > > Jacob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.nl Fri Jan 18 23:30:35 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sat, 19 Jan 2002 00:30:35 +0100 Subject: [Pythonmac-SIG] Fourth attempt at Carbon Tkinter In-Reply-To: <20020118185031-r01010800-3cff5ac3-0922-0108@217.0.163.51> Message-ID: <5F4C856C-0C6B-11D6-BED2-003065517236@oratrix.nl> On Friday, January 18, 2002, at 06:49 PM, Christian Ebert wrote: > Well, I am the guy with the bad news: Still looking in vain AAAAAAAAAAAAAARGH!!!!!! I reverted the _tkinter project to go back to Tcl/Tk 8.3.0, but I only did half the work. And of course for me it still worked, even with 8.3.4, as it always did. I now present you the fourth, and hopefully final, version of _tkinter.carbon.slb at http://www.cwi.nl/ftp/jack/python/mac/newer. -- - 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.nl Fri Jan 18 23:34:16 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sat, 19 Jan 2002 00:34:16 +0100 Subject: [Pythonmac-SIG] pyobjc.so [was: Knock me over with a spoon!] In-Reply-To: Message-ID: On Friday, January 18, 2002, at 07:29 PM, Steven Majewski wrote: > > I keep forgetting where to find the docs for those routines -- > 'man -k' never seems to find it for me. ( It's 'man NSModule', BTW.) > > NSLINKMODULE_OPTION_RETURN_ON_ERROR > With this option if errors occur while binding this > module it is automaticly unloaded and NULL is > returned as the module handle. To get the error > information for the module that failed to load the > routine NSLinkEditError is then used. It has the > same parameters as the link edit error handler (see > below) except all the parameters are pointers in > which the information is returned indirectly. > > > Looks like I need to insert a call to NSLinkEditError to > get the specific error info. > If you get a better exception could you post a patch? -- - 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 sdm7g@Virginia.EDU Fri Jan 18 23:53:32 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Fri, 18 Jan 2002 18:53:32 -0500 (EST) Subject: [Pythonmac-SIG] pyobjc.so [was: Knock me over with a spoon!] In-Reply-To: Message-ID: On Sat, 19 Jan 2002, Jack Jansen wrote: > > Looks like I need to insert a call to NSLinkEditError to > > get the specific error info. > > > If you get a better exception could you post a patch? Courtesy of Guido, the bug that I was hitting was: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=498915 But below is that change that gave me the following more detailed error string: >>> import pyobjc Traceback (most recent call last): File "", line 1, in ? ImportError: dyld: /usr/local/src/Python-2.2/python.exe Undefined symbols: _PyObject_DelItemString Failure linking new module >>> -- Steve *** dynload_next.c.0 Fri Jan 18 13:50:06 2002 --- dynload_next.c Fri Jan 18 14:08:13 2002 *************** *** 150,157 **** if (errString == NULL) { newModule = NSLinkModule(image, pathname, NSLINKMODULE_OPTION_BINDNOW|NSLINKMODULE_OPTION_RETURN_ON_ERROR); ! if (!newModule) ! errString = "Failure linking new module"; } if (errString != NULL) { PyErr_SetString(PyExc_ImportError, errString); --- 150,164 ---- if (errString == NULL) { newModule = NSLinkModule(image, pathname, NSLINKMODULE_OPTION_BINDNOW|NSLINKMODULE_OPTION_RETURN_ON_ERROR); ! if (!newModule) { // sdm7g ! int errNo; ! char *fileName, *moreErrorStr; ! NSLinkEditErrors c; ! errString = "Failure linking new module"; ! NSLinkEditError( &c, &errNo, &fileName, &moreErrorStr ); ! errString = strcat( fileName, errString ); ! errString = strcat( moreErrorStr, errString ); ! } // sdm7g } if (errString != NULL) { PyErr_SetString(PyExc_ImportError, errString); From bob@redivi.com Sat Jan 19 00:06:59 2002 From: bob@redivi.com (Bob Ippolito) Date: Fri, 18 Jan 2002 19:06:59 -0500 Subject: [Pythonmac-SIG] pyobjc.so [was: Knock me over with a spoon!] In-Reply-To: Message-ID: <75131B0B-0C70-11D6-A5DE-0003938210D6@redivi.com> Do _not_ use the dynload_next that ships with python 2.2! It's broke as hell. If you have say, MyPackage/blah.so and MyOtherPackage/blah.so it will confuse the two. The version that Apple wrote works perfectly with the libdl stuff in Python. What you need to do is download libdlcompat (may be called libcompat) from Darwin CVS, and hack the configure script to use the bsd style dynamic loader (-ldl, but not -ldld). It's pretty easy, if you need more help let me know and I can backtrack to figure out what exactly I did. -bob On Friday, January 18, 2002, at 06:53 PM, Steven Majewski wrote: > > > On Sat, 19 Jan 2002, Jack Jansen wrote: > >>> Looks like I need to insert a call to NSLinkEditError to >>> get the specific error info. >>> >> If you get a better exception could you post a patch? > > Courtesy of Guido, the bug that I was hitting was: > http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid= > 498915 > > > But below is that change that gave me the following more detailed > error string: > >>>> import pyobjc > Traceback (most recent call last): > File "", line 1, in ? > ImportError: dyld: /usr/local/src/Python-2.2/python.exe Undefined > symbols: > _PyObject_DelItemString > Failure linking new module >>>> > > > -- Steve > > > *** dynload_next.c.0 Fri Jan 18 13:50:06 2002 > --- dynload_next.c Fri Jan 18 14:08:13 2002 > *************** > *** 150,157 **** > if (errString == NULL) { > newModule = NSLinkModule(image, pathname, > NSLINKMODULE_OPTION_BINDNOW|NSLINKMODULE_OPTION_RETURN_ON_ERROR); > ! if (!newModule) > ! errString = "Failure linking new module"; > } > if (errString != NULL) { > PyErr_SetString(PyExc_ImportError, errString); > --- 150,164 ---- > if (errString == NULL) { > newModule = NSLinkModule(image, pathname, > NSLINKMODULE_OPTION_BINDNOW|NSLINKMODULE_OPTION_RETURN_ON_ERROR); > ! if (!newModule) { // sdm7g > ! int errNo; > ! char *fileName, *moreErrorStr; > ! NSLinkEditErrors c; > ! errString = "Failure linking new module"; > ! NSLinkEditError( &c, &errNo, &fileName, &moreErrorStr ); > ! errString = strcat( fileName, errString ); > ! errString = strcat( moreErrorStr, errString ); > ! } // sdm7g > } > if (errString != NULL) { > PyErr_SetString(PyExc_ImportError, errString); > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From fgranger@altern.org Sat Jan 19 00:12:12 2002 From: fgranger@altern.org (Francois Granger) Date: Sat, 19 Jan 2002 01:12:12 +0100 Subject: Good news thanks to Jack (was: Re: [Pythonmac-SIG] Fourth attempt at Carbon Tkinter In-Reply-To: <5F4C856C-0C6B-11D6-BED2-003065517236@oratrix.nl> References: <5F4C856C-0C6B-11D6-BED2-003065517236@oratrix.nl> Message-ID: At 0:30 +0100 19/01/02, in message Re: [Pythonmac-SIG] Fourth attempt at Carbon Tkinter, Jack Jansen wrote: >I now present you the fourth, and hopefully final, version of >_tkinter.carbon.slb at http://www.cwi.nl/ftp/jack/python/mac/newer. I could not help but stay awake doing various other "urgent" things. This turned out to be a good idea. I just quickly tested your latest effort. IT WORKS !!!!!!!!!!!!!!!!!!!! Thanks a lot for all the hard work you put into MacPython for those of us wich will not switch to MacOS X before some time. From mjb@uma.pt Sat Jan 19 11:25:06 2002 From: mjb@uma.pt (Michael J. Barber) Date: Sat, 19 Jan 2002 11:25:06 +0000 Subject: [Pythonmac-SIG] rewritten documentation for OSA In-Reply-To: Message-ID: <308389E1-0CCF-11D6-88EB-0050E4794D0F@uma.pt> On Friday, January 18, 2002, at 04:53 PM, Jacob Kaplan-Moss wrote: > Michael -- > > First off, great job. I actually tried my hand at something like this > a while ago, and it really is hard. This document makes a lot of sense > out of some tricky stuff. > Thanks, but a lot of credit must go to the original author (whoever that may be - Jack Jansen?). I mostly just reorganized, and added a little that was new. > I've read your comments, and I have some answers to the questions you > raised: > Most everything is clear, except for this: >> If you want to re-create the StdSuite modules, >> you should look in one of two places. On older systems you will find >> the >> > > AFAIK, the "English Dialect" file was removed with AppleScript 1.3.4, > which shipped with MacOS 8.5, so I belive that generating StdSuites > should be done from the AppleScript extension itself in all post-8.5 > systems. I've you've upgraded 8.5 from 8.0, the Dialect file may still > be floating around, but it is out of date. > Are you certain? My PowerBook came with 8.6. I still have that old system folder (probably don't need that any more, but...), and I've got AppleScript 1.3.7 and the dialect file. I can't imagine how I'd have gotten the dialect file if it was done away with for 8.5? > > Hope all that makes sense to you; let me know if you have any questions. > It definitely did make sense, thanks. I've made some changes based on your suggestions. The new file is at . Michael From Jack.Jansen@oratrix.nl Sat Jan 19 19:58:56 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sat, 19 Jan 2002 20:58:56 +0100 Subject: [Pythonmac-SIG] pyobjc.so [was: Knock me over with a spoon!] In-Reply-To: <75131B0B-0C70-11D6-A5DE-0003938210D6@redivi.com> Message-ID: On Saturday, January 19, 2002, at 01:06 AM, Bob Ippolito wrote: > Do _not_ use the dynload_next that ships with python 2.2! It's > broke as hell. If you have say, MyPackage/blah.so and > MyOtherPackage/blah.so it will confuse the two. The version > that Apple wrote works perfectly with the libdl stuff in Python. Bob, you mentioned this earlier (or was that someone else?), but I'm not sure I fully understand the problem. Also, if there is a problem I would prefer to fix it in the Python source rather than depend on yet another external package. Moreover, I think the dynload_next magic may be needed for the ObjC stuff (Steve?). Could you explain the problem, and why it is fixed if you use the libdl version? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From sdm7g@Virginia.EDU Sat Jan 19 20:32:18 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Sat, 19 Jan 2002 15:32:18 -0500 (EST) Subject: [Pythonmac-SIG] pyobjc.so [was: Knock me over with a spoon!] In-Reply-To: Message-ID: On Sat, 19 Jan 2002, Jack Jansen wrote: > > On Saturday, January 19, 2002, at 01:06 AM, Bob Ippolito wrote: > > > Do _not_ use the dynload_next that ships with python 2.2! It's > > broke as hell. If you have say, MyPackage/blah.so and > > MyOtherPackage/blah.so it will confuse the two. The version > > that Apple wrote works perfectly with the libdl stuff in Python. > > Bob, > you mentioned this earlier (or was that someone else?), but I'm > not sure I fully understand the problem. I also don't understand the problem, and if there was an earlier discussion, I must have missed it. > Also, if there is a > problem I would prefer to fix it in the Python source rather > than depend on yet another external package. I've got the package (I used it for XlispStat and some other ports) -- it's used, I believe in Apache, but the libs are not part of Mac OSX, even with the development tools installed, so, unless we include it with Python, builds by folks who don't read the 'first install libdl' instruction are going to fail. > Moreover, I think > the dynload_next magic may be needed for the ObjC stuff (Steve?). pyobjc is a normal python extension so loading it is not dependent (I believe) on a particular type of dynamic loading. Once pyobjc is loaded, it uses the NSBundle and NSUnarchiver routines to load other obj-c extensions like AppKit. If I can figure out how to disable dynload and enable libdl, I'll give it a try and see if it still works. Do you know if this makes any difference for how the shared modules are built ? (I wouldn't think so, but...) > Could you explain the problem, and why it is fixed if you use > the libdl version? Ditto. You said that dynload_next is broken -- so I assume the other solution is just to write a new dynload_darwin that does it the right way, rather than to depend on the dlopen emulation being installed. (i.e. I think you're saying this is a problem with dynload_next's implementation and not the darwin dynload libs themself. ) The other option would be to make configure make using the emulation libs the default if they are installed, otherwise, fall back on the current method. -- Steve Majewski From bob@redivi.com Sat Jan 19 21:51:01 2002 From: bob@redivi.com (Bob Ippolito) Date: Sat, 19 Jan 2002 16:51:01 -0500 Subject: [Pythonmac-SIG] pyobjc.so [was: Knock me over with a spoon!] In-Reply-To: Message-ID: On Saturday, January 19, 2002, at 03:32 PM, Steven Majewski wrote: > > > On Sat, 19 Jan 2002, Jack Jansen wrote: > >> >> On Saturday, January 19, 2002, at 01:06 AM, Bob Ippolito wrote: >> >>> Do _not_ use the dynload_next that ships with python 2.2! It's >>> broke as hell. If you have say, MyPackage/blah.so and >>> MyOtherPackage/blah.so it will confuse the two. The version >>> that Apple wrote works perfectly with the libdl stuff in Python. >> >> Bob, >> you mentioned this earlier (or was that someone else?), but I'm >> not sure I fully understand the problem. > > I also don't understand the problem, and if there was an earlier > discussion, I must have missed it. Okay. Let's see. I have two C modules called time.so. One is part of the standard python distribution, and the other is in the pygame package. Sometimes, quite often really, I would like to use them both at the same time. Using dynload_next, if you do: import time import pygame.time python will load the first time.so, and it will create a module PyObject for the second, but it will initialize it with the contents of the first time.so and not try and load another dynlib. In other words, time.__dict__ == pygame.time.__dict__, they both have the contents of the first module loaded with the name time.so, even though they are on different paths. If I had loaded them in reverse order, both modules would have the contents of site-packages/pygame/time.so .. Python reports no errors during this process. If you turn on DYLD_PRINT_LIBRARIES (setenv DYLD_PRINT_LIBRARIES) it will only show the first time.so Using apple's libdl, everything works perfectly fine. It recognizes both libraries as separate, they have separate dictionaries, and DYLD_PRINT_LIBRARIES shows two libraries being linked. > >> Also, if there is a >> problem I would prefer to fix it in the Python source rather >> than depend on yet another external package. > > I've got the package (I used it for XlispStat and some other ports) > -- it's used, I believe in Apache, but the libs are not part of > Mac OSX, even with the development tools installed, so, unless > we include it with Python, builds by folks who don't read the > 'first install libdl' instruction are going to fail. Okay, so why doesn't someone take libdl and inject it into the python source tree? I haven't had time for this myself. I was hoping someone would hear what I was saying and patch the original or just throw libdl into python. I'm expecting that libdl will be included in later releases of the developers toolkit and/or OS X itself, I don't see why apple would write it and leave it out.w > >> Moreover, I think >> the dynload_next magic may be needed for the ObjC stuff (Steve?). > > pyobjc is a normal python extension so loading it is not dependent > (I believe) on a particular type of dynamic loading. Once pyobjc > is loaded, it uses the NSBundle and NSUnarchiver routines to load > other obj-c extensions like AppKit. > > If I can figure out how to disable dynload and enable libdl, > I'll give it a try and see if it still works. Do you know if > this makes any difference for how the shared modules are built ? > (I wouldn't think so, but...) > It's all in python's configure script, it's only a couple lines you need to change. Python already detects the presence of libdl on systems that have it installed, it just ignores it entirely when it goes to choose the dynamic loader because it thinks dynload_next is a better fit. There is no difference in the way that shared modules are built either way, only that when you load them, they work as expected with libdl :) -bob From jwblist@olympus.net Sat Jan 19 23:53:23 2002 From: jwblist@olympus.net (John W Baxter) Date: Sat, 19 Jan 2002 15:53:23 -0800 Subject: [Pythonmac-SIG] rewritten documentation for OSA In-Reply-To: <308389E1-0CCF-11D6-88EB-0050E4794D0F@uma.pt> References: <308389E1-0CCF-11D6-88EB-0050E4794D0F@uma.pt> Message-ID: At 11:25 +0000 1/19/2002, Michael J. Barber wrote: >Are you certain? My PowerBook came with 8.6. I still have that old >system folder (probably don't need that any more, but...), and I've got >AppleScript 1.3.7 and the dialect file. I can't imagine how I'd have >gotten the dialect file if it was done away with for 8.5? A very good AppleScript information source is Bill Cheeseman's AppleScript Sourcebook http://www.applescriptsourcebook.com/ >From this page http://www.applescriptsourcebook.com/applescript/applescript140.html there, one learns (search for dialect) that the separate English Dialect file went away with AppleScript 1.4.0 (Mac OS 9.0). (A version or two later, AppleScript would crash if there were any folder inside the Scripting Additions folder, including the empty Dialects folder.) >From the page for Applescript 1.3.7, one learns that the English Dialect file was adjusted for that version...obviously still present then. The demise of English Dialect falls into my "too long ago to bother remembering, so I'll look it up" category. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From mmiller@adobe.com Sun Jan 20 06:58:59 2002 From: mmiller@adobe.com (Martin Miller) Date: Sat, 19 Jan 2002 22:58:59 -0800 Subject: Good news thanks to Jack (was: Re: [Pythonmac-SIG] Fourth attempt at Carbon Tkinter References: Message-ID: <3C4A6AB3.28BCA152@adobe.com> At 01:12:12 +0100 19/01/02, Francois Granger wrote: > At 0:30 +0100 19/01/02, in message Re: [Pythonmac-SIG] Fourth attempt > at Carbon Tkinter, Jack Jansen wrote: > >I now present you the fourth, and hopefully final, version of > >_tkinter.carbon.slb at http://www.cwi.nl/ftp/jack/python/mac/newer. > > I could not help but stay awake doing various other "urgent" things. > This turned out to be a good idea. I just quickly tested your latest > effort. > > IT WORKS !!!!!!!!!!!!!!!!!!!! > > Thanks a lot for all the hard work you put into MacPython for those > of us wich will not switch to MacOS X before some time. I wish to second all of the above sentiments, especially the "thanks a lot". -Martin From english@spiritone.com Mon Jan 21 07:47:14 2002 From: english@spiritone.com (Josh English) Date: 20 Jan 2002 23:47:14 -0800 Subject: [Pythonmac-SIG] What happened to the Output Window? Message-ID: <3C4BC782.9766BEA3@spiritone.com> After several months I am back working with Python and I've upgraded to 2.2, but I don't have an output window and I can't find anything in the docs that states that this is missing. Has it been removed or is there something wrong with my installation? Josh English english@spiritone.com http://www.spiritone.com/~english From junior52353@yahoo.com Mon Jan 21 08:25:25 2002 From: junior52353@yahoo.com (joe crossett) Date: Mon, 21 Jan 2002 00:25:25 -0800 (PST) Subject: [Pythonmac-SIG] (no subject) Message-ID: <20020121082525.6006.qmail@web14901.mail.yahoo.com> __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From jack@oratrix.com Mon Jan 21 10:02:48 2002 From: jack@oratrix.com (Jack Jansen) Date: Mon, 21 Jan 2002 11:02:48 +0100 Subject: [Pythonmac-SIG] Mac and unix pathnames Message-ID: <062AB5F1-0E56-11D6-B433-0030655234CE@oratrix.com> Folks, I started implementing the changes to macfs.FSRef() and FSSpec() and the as_pathname() methods to allow an optional parameter (either "mac" or "unix") to specify which style pathnames you want, but the more I think about it the more I think this isn't the right solution after all. [*] I think we should simply always use "native" pathnames, i.e. colon-separated pathnames in MacPython and unix-pathnames in MachoPython. All the use-cases for "other" pathnames I could think of are really a question of sloppy programming to begin with. If you disagree and can come up with valid (and common) use cases let me know. If the use cases are not all that common I think I prefer to add a special Python module that will do the conversion in stead of bogging down the core with it. [*] Read: implementing it turned out to be more difficult than expected:-) -- - 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@oratrix.com Mon Jan 21 10:22:56 2002 From: jack@oratrix.com (Jack Jansen) Date: Mon, 21 Jan 2002 11:22:56 +0100 Subject: [Pythonmac-SIG] What happened to the Output Window? In-Reply-To: <3C4BC782.9766BEA3@spiritone.com> Message-ID: On Monday, January 21, 2002, at 08:47 , Josh English wrote: > After several months I am back working with Python and I've upgraded to > 2.2, but I don't have an output window and I can't find anything in the > docs that states that this is missing. Has it been removed or is there > something wrong with my installation? Josh, you need to give a bit more detail: MacPython or unix-Python? If we're talking MacPython here, PythonInterpreter (i.e. the input/output console window) or IDE (where there is a real output-only window which is separate from the console window)? If this is indeed about MacPython the first thing to try if you see funny behaviour is throw away all your Python-related preferences files, rerun ConfigurePythonCarbon (or ...Classic) 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 mjb@uma.pt Mon Jan 21 11:16:27 2002 From: mjb@uma.pt (Michael J. Barber) Date: Mon, 21 Jan 2002 11:16:27 +0000 Subject: [Pythonmac-SIG] rewritten documentation for OSA In-Reply-To: Message-ID: <4FF01413-0E60-11D6-A268-0050E4794D0F@uma.pt> On Saturday, January 19, 2002, at 11:53 PM, John W Baxter wrote: > At 11:25 +0000 1/19/2002, Michael J. Barber wrote: >> [when did the Dialect files go away?] > A very good AppleScript information source is Bill Cheeseman's > AppleScript > Sourcebook > http://www.applescriptsourcebook.com/ > That is an excellent site. I wish I'd known about that when I working more with AppleScript. > [it went away with AppleScript 1.4.0] > The demise of English Dialect falls into my "too long ago to bother > remembering, so I'll look it up" category. > The dialect file failed the "turn the key and she goes" test for me; it is the sort of thing that I've never had call to worry about. Apart from regenerating the Standard Suites for Python use (which I've only done once, just to see), I can't imagine where I'd need to be concerned about it. That said, adding in this detail fills in the last substantive point for the OSA doc, so thank you very much. New version is at . Comments are, of course, still welcome! From mjb@uma.pt Mon Jan 21 12:58:32 2002 From: mjb@uma.pt (Michael J. Barber) Date: Mon, 21 Jan 2002 12:58:32 +0000 Subject: [Pythonmac-SIG] Mac and unix pathnames In-Reply-To: <062AB5F1-0E56-11D6-B433-0030655234CE@oratrix.com> Message-ID: <92DEF662-0E6E-11D6-A268-0050E4794D0F@uma.pt> On Monday, January 21, 2002, at 10:02 AM, Jack Jansen wrote: > > I think we should simply always use "native" pathnames, i.e. > colon-separated pathnames in MacPython and unix-pathnames in > MachoPython. All the use-cases for "other" pathnames I could think of > are really a question of sloppy programming to begin with. If you > disagree and can come up with valid (and common) use cases let me know. > If the use cases are not all that common I think I prefer to add a > special Python module that will do the conversion in stead of bogging > down the core with it. > I don't disagree, but I do have an example that (I think) isn't just sloppy programming. It is a recent discovery, so there may be a simple solution that I haven't though of. Yesterday, I came across a case where I need Mac-style pathnames from MachoPython. If you have read the messages on "rewritten documentation for OSA," it will come as no surprise that I've been thinking about inter-application communication. If you create a temporary file with MachoPython, you get Unix-style pathnames, which can't be used with osacompile and osascript. As an example (without messing with the temp files): Python 2.2 (#1, Jan 9 2002, 15:28:46) [GCC 2.95.2 19991024 (release)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.popen("""osascript -e 'tell application "TextEdit" to open alias "Macintosh HD:Users:mjb:applescript.html"'""").readlines() [] >>> >>> os.popen("""osascript -e 'tell application "TextEdit" to open alias "/Users/mjb/applescript.html"'""").readlines() syntax error: File /Users/mjb/applescript.html wasn't found. (-43) [] >>> This particular example could be done by calling 'open' instead of 'osascript,' but it's not the only spot where file names are needed in AppleScripts. It appears to me that a module to do the conversion would be more suitable for this task, so I'd agree that it should be left out of the core. Here's my own quick little script to make the change: GETNAMESCRIPT="""osascript -e 'tell app "Finder" to return the name of the startup disk'""" def u2m(upath, diskname=None): if diskname == None: import os diskname = os.popen(GETNAMESCRIPT).readline()[:-1] return ":".join([diskname] + upath.split('/')[1:]) Python 2.2 (#1, Jan 9 2002, 15:28:46) [GCC 2.95.2 19991024 (release)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pathDialects >>> pathDialects.u2m('/Users/mjb/applescript.html') 'Macintosh HD:Users:mjb:applescript.html' >>> pathDialects.u2m('/Users/mjb/applescript.html','Some Other HD') 'Some Other HD:Users:mjb:applescript.html' >>> I'm not too thrilled with the way this functions, but I think the way I get the disk name should be an at least somewhat portable way to work with temp files. I don't have an inverse function, but haven't needed it yet. Regardless, maybe it will be useful to someone. From jack@oratrix.com Mon Jan 21 14:31:28 2002 From: jack@oratrix.com (Jack Jansen) Date: Mon, 21 Jan 2002 15:31:28 +0100 Subject: [Pythonmac-SIG] Mac and unix pathnames In-Reply-To: <92DEF662-0E6E-11D6-A268-0050E4794D0F@uma.pt> Message-ID: <8E5EDCBE-0E7B-11D6-B724-0030655234CE@oratrix.com> On Monday, January 21, 2002, at 01:58 , Michael J. Barber wrote: > I don't disagree, but I do have an example that (I think) isn't just > sloppy programming. It is a recent discovery, so there may be a simple > solution that I haven't though of. Ah, talking to external programs is exactly the sort of use case I had in mind. Here is a function that does the trick (but I'm not 100% sure it will work in 2.2 as distributed). Are people also interested in the reverse, i.e. obtaining Unix pathnames in a MacPython program running on MacOSX? # Classicpath - convert unix pathnames (or fsspecs, or fsrefs) to # classic MacOS colon-separated pathnames. # Will only work in MachoPython 2.2+ and later (because part of the magic # is that the first FSSpec() call interprets unix pathnames). import macfs def classicpath(item): import macfs fss = macfs.FSSpec(item) vrefnum, dirid, filename = fss.as_tuple() path = filename while dirid != 1: fss = macfs.FSSpec((vrefnum, dirid, '')) vrefnum, dirid, filename = fss.as_tuple() path = filename + ':' + path return path -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Y.Benita@pharm.uu.nl Mon Jan 21 17:15:34 2002 From: Y.Benita@pharm.uu.nl (Yair Benita) Date: Mon, 21 Jan 2002 18:15:34 +0100 Subject: [Pythonmac-SIG] Problems with urllib? Message-ID: I try to run a simple query using urllib. For example: import urllib x=urllib.urlopen("http://www.ebi.ac.uk/cgi-bin/emblfetch?db=embl&format=fast a&style=raw&id=AB002378") print x.read() It looks like macpython is trying to read x before it is finished loading, resulting in incomplete files. When I run it step by step in the debugger it works perfectly. Is there something different in the mac urllib which I should know? The mac documentation refers to a mactcp module but I could not find it in my installation (python 2.2). Maybe I need to put a command so that the program waits until the communication is done. Can anyone give some solution to this? Thanks Yair -- Yair Benita Pharmaceutical Proteomics Faculty of Pharmacy Utrecht University The Netherlands Tel: +31 30 2539340 Fax: +31-30-2534662 E-mail: Y.Benita@pharm.uu.nl From paul@fxtech.com Mon Jan 21 17:24:14 2002 From: paul@fxtech.com (Paul Miller) Date: Mon, 21 Jan 2002 11:24:14 -0600 Subject: [Pythonmac-SIG] What happened to the Output Window? In-Reply-To: References: <3C4BC782.9766BEA3@spiritone.com> Message-ID: <5.1.0.14.2.20020121112335.02964e88@cedar.he.net> >If this is indeed about MacPython the first thing to try if you see funny >behaviour is throw away all your Python-related preferences files, rerun >ConfigurePythonCarbon (or ...Classic) and try again. On a similar thread, are the issues with the output window and Python prefs resolved when using MacPython (Carbon) under OS/X? I still can't disable the output window under OS/X. -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From Y.Benita@pharm.uu.nl Mon Jan 21 17:34:25 2002 From: Y.Benita@pharm.uu.nl (Yair Benita) Date: Mon, 21 Jan 2002 18:34:25 +0100 Subject: [Pythonmac-SIG] More on urllib Message-ID: I now have the latest documentation and I see there is no mactcp anymore. I assume ctb should be used (is this true?). However, I have no idea how it works. The documentation is very minimal. Can anyone give a short example? Thanks, Yair -- Yair Benita Pharmaceutical Proteomics Utrecht University From mjb@uma.pt Mon Jan 21 17:40:23 2002 From: mjb@uma.pt (Michael J. Barber) Date: Mon, 21 Jan 2002 17:40:23 +0000 Subject: [Pythonmac-SIG] package structure for OSA interfaces Message-ID: I've been taking a closer look at the structure of the packages produced by gensuitemodule. I'm a bit confused about the logic of the Standard Suites package. The StdSuites package is used to build packages for other applications, so is a fundamental part of gensuitemodule. As far as I can tell, the structure is suboptimal; hopefully someone can let me know what I'm missing, if anything. The modules I'm concerned with are StdSuites.Required_Suite and StdSuites.Standard_Suite. The required events are open, run, print, and quit. These four events are defined in Pythonic terms in StdSuites.Standard_Suite rather than StdSuites.Required_Suite. Apps that define the required events in their 'AppleScript Dictionary' work fine with this approach. However, many apps don't specify the required events, just relying on the default behavior (how that's done in terms of the apps' resources, I don't know) for AppleScript. For Python, gensuitemodule overlooks these four events, so that basic functionality is missing. One way to get that functionality is to copy the definitions for the required events from StdSuites.Standard_Suite into the Required_Suite for the app. It is also necessary to copy the _Enum_savo dictionary and the _enumdeclaration for 'savo' in order to get quit to work properly. I learned this trick from this list some time ago, and have applied it myself to a couple of apps since. It works, but I think there is a better way. If those definitions are in StdSuites.Required_Suite, then every app has them, no editing needed. It doesn't matter if the required events are also defined in StdSuites.Standard_Suite - no harm done either way. I've tried this out some, and it seems to work just fine. Another advantage to this set up is that we could easily generate interfaces for 'unscriptable' apps (which respond to the four required events regardless). All that would be needed is to include a skeleton for the __init__.py file, which can be changed to get the correct application signature, and maybe a 'friendlier' name for the main class. The only downside that I can see to defining the required events in StdSuites.Required_Suite is that gensuitemodule doesn't currently generate the appropriate structure, so if someone were to rebuild StdSuites, they'd have a problem. I've briefly looked through the source for gensuitemodule.py to see if that could be changed, but do not yet understand it well enough to say. Given a little more free time, I'll dig deeper. Does this make sense? Am I missing something important, or would this be a real improvement? -- Michael From dp@ulaluma.com Mon Jan 21 17:37:59 2002 From: dp@ulaluma.com (Donovan Preston) Date: Mon, 21 Jan 2002 09:37:59 -0800 Subject: [Pythonmac-SIG] Mac and unix pathnames In-Reply-To: <062AB5F1-0E56-11D6-B433-0030655234CE@oratrix.com> Message-ID: <9C8CA3AE-0E95-11D6-B361-0050E425C324@ulaluma.com> Same conclusion I came to when implementing the same thing, Jack. The patch is in the patch manager. Donovan On Monday, January 21, 2002, at 02:02 AM, Jack Jansen wrote: > Folks, > I started implementing the changes to macfs.FSRef() and FSSpec() and > the as_pathname() methods to allow an optional parameter (either "mac" > or "unix") to specify which style pathnames you want, but the more I > think about it the more I think this isn't the right solution after > all. [*] > > I think we should simply always use "native" pathnames, i.e. > colon-separated pathnames in MacPython and unix-pathnames in > MachoPython. All the use-cases for "other" pathnames I could think of > are really a question of sloppy programming to begin with. If you > disagree and can come up with valid (and common) use cases let me know. > If the use cases are not all that common I think I prefer to add a > special Python module that will do the conversion in stead of bogging > down the core with it. > > [*] Read: implementing it turned out to be more difficult than > expected:-) > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From fgranger@altern.org Mon Jan 21 18:04:49 2002 From: fgranger@altern.org (Francois Granger) Date: Mon, 21 Jan 2002 19:04:49 +0100 Subject: [Pythonmac-SIG] Locale on MacOS 9 Message-ID: I am currently working on a multilinguale module. At the same time, PythonCard team is starting to think about localisation. So I did some search. On MacPython ther is an emulation of locale. But it does not work exactly the way I'd like ;-) On Windows: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> locale.getdefaultlocale() ('fr_FR', 'cp1252') On the Mac: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'C' >>> locale.getdefaultlocale() (None, 'mac-roman') Inside the file lib:locale.py line 303 it is said : To maintain compatibility with other platforms, not only the LANG variable is tested, but a list of variables given as envvars parameter. The first found to be defined will be used. envvars defaults to the search path used in GNU gettext; it must always contain the variable name 'LANG'. Where the list is 'LANGUAGE', 'LC_ALL', 'LC_CTYPE', 'LANG' I test defining os.envar before calling locale, but same answer. Any idea where I can look for this ? From blacktrash@gmx.net Mon Jan 21 18:10:25 2002 From: blacktrash@gmx.net (Christian Ebert) Date: Mon, 21 Jan 2002 19:10:25 +0100 Subject: Good news thanks to Jack (was: Re: [Pythonmac-SIG] Fourth attempt at Carbon Tkinter In-Reply-To: <3C4A6AB3.28BCA152@adobe.com> Message-ID: <20020121191214-r01010800-568a0b85-0922-0108@217.0.162.81> Martin Miller at 22:58 on Saturday, January 19, 2002: > At 01:12:12 +0100 19/01/02, Francois Granger > wrote: > > At 0:30 +0100 19/01/02, in message Re: [Pythonmac-SIG] Fourth attempt > > at Carbon Tkinter, Jack Jansen wrote: > > >I now present you the fourth, and hopefully final, version of > > >_tkinter.carbon.slb at http://www.cwi.nl/ftp/jack/python/mac/newer. [...] > > IT WORKS !!!!!!!!!!!!!!!!!!!! Well ... almost. The good news is that it apparently finds tcl and opens the trial Hello World window. Ahem. The bad news is that after that there is a freeze. Escape works if applied two times - btw. I also need two clicks to close the window in classic config. > > Thanks a lot for all the hard work you put into MacPython for those > > of us wich will not switch to MacOS X before some time. > > I wish to second all of the above sentiments, Almost all. > especially the "thanks a > lot". A real whole lot. - Important: For me this is _not_ urgent, I just wanted to give feedback. Bad guy Christian From Jack.Jansen@oratrix.nl Mon Jan 21 20:44:50 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Mon, 21 Jan 2002 21:44:50 +0100 Subject: [Pythonmac-SIG] What happened to the Output Window? In-Reply-To: <5.1.0.14.2.20020121112335.02964e88@cedar.he.net> Message-ID: On Monday, January 21, 2002, at 06:24 PM, Paul Miller wrote: > On a similar thread, are the issues with the output window and > Python prefs resolved when using MacPython (Carbon) under > OS/X? I still can't disable the output window under OS/X. No, I have completely forgotten to look into this. Please file a sourceforge bug report so that maybe some day I will remember (or be nagged when the next distribution is due:-) -- - 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.nl Mon Jan 21 20:47:21 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Mon, 21 Jan 2002 21:47:21 +0100 Subject: [Pythonmac-SIG] Problems with urllib? In-Reply-To: Message-ID: <110D61D6-0EB0-11D6-A294-003065517236@oratrix.nl> On Monday, January 21, 2002, at 06:15 PM, Yair Benita wrote: > I try to run a simple query using urllib. For example: > > import urllib > > x=urllib.urlopen("http://www.ebi.ac.uk/cgi- > bin/emblfetch?db=embl&format=fast > a&style=raw&id=AB002378") > print x.read() > > It looks like macpython is trying to read x before it is > finished loading, > resulting in incomplete files. The problem is slightly different: MacPython may do short reads on sockets. I've always maintained that this was correct (which reasoning was quietly accepted by everyone here), but last year I finally admitted that it may actually be incorrect (which was again quietly accepted:-) Could you please file a sourceforge bug report? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.nl Mon Jan 21 21:01:10 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Mon, 21 Jan 2002 22:01:10 +0100 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: Message-ID: On Monday, January 21, 2002, at 06:40 PM, Michael J. Barber wrote: > I've been taking a closer look at the structure of the packages > produced by gensuitemodule. I'm a bit confused about the logic > of the Standard Suites package. The StdSuites package is used > to build packages for other applications, so is a fundamental > part of gensuitemodule. As far as I can tell, the structure is > suboptimal; hopefully someone can let me know what I'm missing, > if anything. > > The modules I'm concerned with are StdSuites.Required_Suite and > StdSuites.Standard_Suite. The required events are open, run, > print, and quit. These four events are defined in Pythonic > terms in StdSuites.Standard_Suite rather than > StdSuites.Required_Suite. Apps that define the required events > in their 'AppleScript Dictionary' work fine with this approach. There is something going on here that I don't understand, maybe someone else knows more about OSA can give me a hint? It used to be that the required events were declared in the AETE resource for Required (which is also where I would expect them, reading Apple's documentation). However, as of a few years ago (Mac OS 9? The demise of the english dialect file?) Apple moved the declarations to the Standard suite. Therefore, in the Python suites they end up in the standard suite module, because after all the suite modules are generated. But somehow the inheritance used by (say) Script Editor is better than what the Python OSA architecture uses: whereas Python sometimes cannot find open (because it's declared in Standard in stead of in Required) Script Editor has no such problem. What I would prefer is somehow use a construct that is orthogonal to how Apple's suite inheritance scheme works. If that can't be done then fixing it up manually is an option, but it is not an option I like. First of all there's the problem with regenerating the suites, but that is solvable (and should be solved: you shouldn't be counting on me to remember doing manual edits after I regenerate the suite modules:-). More serious is that if the events are defined in multiple suites we may end up with the wrong one. Think of the following situation class StdSuites.Standard_Suite: def open(): .... class StdSuites.Required_Suite: def open(): .... # Same as above class MyApp.Standard_Suite(StdSuites.Standard_Suite): pass class MyApp.Required_Suite(StdSuites.Required_Suite): def open(): # version of open with, say, an extra optional parameter clas MyApp(Standard_Suite, Required_Suite): pass (Phew, that was a long example:-) Anyway: now MyApp.open will be the wrong method: it will be the method declared in StdSuites.Standard_Suite in stead of the one from MyApp.Required_Suite! -- - 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 adam@switchedonsoftware.com Mon Jan 21 22:45:36 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Tue, 22 Jan 2002 09:45:36 +1100 Subject: [Pythonmac-SIG] Mac and Unix newlines Message-ID: <95F76B28-0EC0-11D6-B652-0030656E8732@switchedonsoftware.com> Speaking of Mac and Unix file separators, what about newlines? Unix python seems not to mind DOS newlines, but certainly spews on Mac ones. I'm having a fiddle with the source now to try and write a little fix for this, but does anyone know if this would break anything? Kind regards, Adam Eijdenberg Switched on Software adam@switchedonsoftware.com http://www.switchedonsoftware.com/ Phone: +61 3 6231 3467 Fax: +61 3 6231 3476 Mobile: +61 4 0704 6857 47 Molle Street Hobart TAS 7000 Australia From Jack.Jansen@oratrix.nl Mon Jan 21 23:12:34 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Tue, 22 Jan 2002 00:12:34 +0100 Subject: [Pythonmac-SIG] Mac and Unix newlines In-Reply-To: <95F76B28-0EC0-11D6-B652-0030656E8732@switchedonsoftware.com> Message-ID: <5A868BA0-0EC4-11D6-97FD-003065517236@oratrix.nl> On Monday, January 21, 2002, at 11:45 PM, Adam Eijdenberg wrote: > Speaking of Mac and Unix file separators, what about newlines? I've done a patch for this, the "universal newlines patch", that allows Python to use files with any newline on any platform. A PEP is forthcoming, I've submitted it to the PEPmaster but he hasn't replied yet (but he's cc'd on this message:-). In the mean time you can download and try the patch, it's at https://sourceforge.net/tracker/?func=detail&aid=476814&group_id=5470&atid= 305470 -- - 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 adam@switchedonsoftware.com Mon Jan 21 23:26:53 2002 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Tue, 22 Jan 2002 10:26:53 +1100 Subject: [Pythonmac-SIG] Mac and Unix newlines In-Reply-To: <5A868BA0-0EC4-11D6-97FD-003065517236@oratrix.nl> Message-ID: <5A652488-0EC6-11D6-B652-0030656E8732@switchedonsoftware.com> > I've done a patch for this, the "universal newlines patch", that allows > Python to use files with any newline on any platform. A PEP is > forthcoming, I've submitted it to the PEPmaster but he hasn't replied > yet (but he's cc'd on this message:-). Damn, I was having all sorts of fun looking through all that code. :) Your patch does a lot more than I was originally looking for. I just wanted something to stop the parser spewing every time I moved development machines. It's not really that hard to write a fgets that takes anything and converts it to a given convention (such as \n), so I'm not really sure why this wasn't done by anyone earlier. Keep up the good work, and let me know if there's anything I can do to help. Kind regards, Adam Eijdenberg Switched on Software adam@switchedonsoftware.com http://www.switchedonsoftware.com/ Phone: +61 3 6231 3467 Fax: +61 3 6231 3476 Mobile: +61 4 0704 6857 47 Molle Street Hobart TAS 7000 Australia From johann@surfbest.net Tue Jan 22 00:31:15 2002 From: johann@surfbest.net (Johann Hibschman) Date: Mon, 21 Jan 2002 16:31:15 -0800 Subject: [Pythonmac-SIG] Tkinter on OS X Message-ID: <582A0D4C-0ECF-11D6-BBE2-003065B5C6B6@surfbest.net> Hi folks, I've been trying to get tkinter to compile on OS X, using some of the hints that went by here in December, using the Tcl/Tk frameworks that recently came out. However, I can't get them to compile, since they look for the X11 header files, and I don't seem to have them anywhere, since I don't have X11 installed. I don't understand why Mac OSX Tcl/Tk would need the X11 headers, so I'm suspecting that something is mis-configured. Can anyone shed some light on this? Cheers, --Johann -- Johann Hibschman jhibschman@yahoo.com -- Johann Hibschman jhibschman@yahoo.com From tony@metanet.com Tue Jan 22 00:46:40 2002 From: tony@metanet.com (Tony Lownds) Date: Mon, 21 Jan 2002 16:46:40 -0800 Subject: [Pythonmac-SIG] Tkinter on OS X In-Reply-To: <582A0D4C-0ECF-11D6-BBE2-003065B5C6B6@surfbest.net> References: <582A0D4C-0ECF-11D6-BBE2-003065B5C6B6@surfbest.net> Message-ID: Hi Johann, Tcl/Tk actually emulates X11 drawing on non-X11 platforms, that's why it needs X11 headers. They were missing in 8.4a4. To link Tk 8.4a4 with python you will need those headers - either from the Tcl/Tk source (get it via cvs) or, if you've downloaded an X Windows server with those headers, they will work as well. -Tony At 4:31 PM -0800 1/21/02, Johann Hibschman wrote: >Hi folks, > >I've been trying to get tkinter to compile on OS X, using some of >the hints that went by here in December, using the Tcl/Tk frameworks >that recently came out. However, I can't get them to compile, since >they look for the X11 header files, and I don't seem to have them >anywhere, since I don't have X11 installed. > >I don't understand why Mac OSX Tcl/Tk would need the X11 headers, so >I'm suspecting that something is mis-configured. Can anyone shed >some light on this? > >Cheers, > >--Johann > >-- >Johann Hibschman >jhibschman@yahoo.com > > >-- >Johann Hibschman >jhibschman@yahoo.com > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- From Laurent.Pierron@loria.fr Tue Jan 22 08:32:37 2002 From: Laurent.Pierron@loria.fr (Laurent Pierron) Date: Tue, 22 Jan 2002 09:32:37 +0100 Subject: [Pythonmac-SIG] Problems with urllib? References: Message-ID: <3C4D23A5.7030402@loria.fr> Yair Benita wrote: > I try to run a simple query using urllib. For example: > > import urllib > > x=urllib.urlopen("http://www.ebi.ac.uk/cgi-bin/emblfetch?db=embl&format=fast > a&style=raw&id=AB002378") > print x.read() > I had the same problem and I do that : ================================================ import urllib x=urllib.urlopen("http://www.ebi.ac.uk/cgi-bin/emblfetch?db=embl&format=fasta&style=raw&id=AB002378") data = x.read() while data: print data data = x.read() ================================================ Another solution could be : =========================================== import urllib (file,headers)=urllib.urlretrieve("http://www.ebi.ac.uk/cgi-bin/emblfetch?db=embl&format=fasta&style=raw&id=AB002378") x=open(file) print x.read() x.close() import os os.remove(file) ============================================= -- Laurent PIERRON From mjb@uma.pt Tue Jan 22 11:22:10 2002 From: mjb@uma.pt (Michael J. Barber) Date: Tue, 22 Jan 2002 11:22:10 +0000 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: Message-ID: <47329DD8-0F2A-11D6-A268-0050E4794D0F@uma.pt> On Monday, January 21, 2002, at 09:01 PM, Jack Jansen wrote: > > On Monday, January 21, 2002, at 06:40 PM, Michael J. Barber wrote: > >> [where should the required events be defined?] > There is something going on here that I don't understand, maybe someone > else knows more about OSA can give me a hint? > I don't claim any great understanding of OSA, but I'll take a stab at this. This is all based on how tools for AppleScript work, rather than how AETE resources are implemented - consider yourself warned! > It used to be that the required events were declared in the AETE > resource for Required (which is also where I would expect them, reading > Apple's documentation). However, as of a few years ago (Mac OS 9? The > demise of the english dialect file?) Apple moved the declarations to > the Standard suite. Therefore, in the Python suites they end up in the > standard suite module, because after all the suite modules are > generated. > > But somehow the inheritance used by (say) Script Editor is better than > what the Python OSA architecture uses: whereas Python sometimes cannot > find open (because it's declared in Standard in stead of in Required) > Script Editor has no such problem. > I think that the main difference is that Script Editor "knows" about the required events. For example, consider the following simple AppleScript: tell application "SimpleText" to run Works fine, of course. But SimpleText is not a scriptable app, and doesn't have an AETE resource. Thus, gensuitemodule just produces: """ Macintosh HD:Applications (Mac OS 9):SimpleText LISTING aete+aeut RESOURCES IN 'Macintosh HD:Applications (Mac OS 9):SimpleText' """ and quits. It seems like a number of scriptable apps don't bother to define the required events, and just rely on the default behavior available to all apps. Looking through my Applications folder, it appears that only Apple does define them. > More serious is that if the events are defined in multiple suites we > may end up with the wrong one. Think of the following situation > > class StdSuites.Standard_Suite: > def open(): .... > > class StdSuites.Required_Suite: > def open(): .... # Same as above > > class MyApp.Standard_Suite(StdSuites.Standard_Suite): pass > > class MyApp.Required_Suite(StdSuites.Required_Suite): > def open(): > # version of open with, say, an extra optional parameter > > clas MyApp(Standard_Suite, Required_Suite): pass > > (Phew, that was a long example:-) > Anyway: now MyApp.open will be the wrong method: it will be the method > declared in StdSuites.Standard_Suite in stead of the one from > MyApp.Required_Suite! > Couldn't this already be a problem? No matter what is defined in StdSuites.Required_Suite, the method from StdSuites.Standard_Suite gets used, right? Since most apps use vanilla versions of the required events and define them in the Standard Suite (or simply don't define them), it could easily be missed for a long time. Also, I don't know of any apps where Standard_Suite gets imported before Required_Suite, which might make this very pathological. There is a surprisingly simple solution, but unfortunately only for Python 2.2+. Define the required events in StdSuites.Required_Suite, remove the required events from StdSuites.Standard_Suite, and make StdSuites.Standard_Suite a subclass of StdSuites.Required_Suite. Everything else stays as it is. With the new "diamond rule" for multiple inheritance, that takes care of everything. I'm not up to the ASCII art to show the structure. See for a diagram. (If I have the arrows backwards in that diagram, sorry - I know very little about how inheritance diagrams "should be" drawn.) The question remains: is there a fix for Python 2.1 and earlier? I don't see one. The restructuring I suggested for 2.2 would fix the original difficulty that I had, but it leaves the problem that Jack has pointed out unchanged. Maybe this should just be documented for earlier versions, since it requires an app that defines the required events (not too uncommon), defines them in the Required Suite instead of Standard Suite (rare), and defines the Standard Suite before the Required Suite (very rare, possibly nonexistant). I'll take a closer look at gensuitemodule to see if I can understand it well enough to make the modification I suggested above. For the next few weeks, that needs to be pretty low priority for me (work-related travel), but I'll try to find the time. From jack@oratrix.com Tue Jan 22 11:38:33 2002 From: jack@oratrix.com (Jack Jansen) Date: Tue, 22 Jan 2002 12:38:33 +0100 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: <47329DD8-0F2A-11D6-A268-0050E4794D0F@uma.pt> Message-ID: <90955251-0F2C-11D6-9BBF-0030655234CE@oratrix.com> On Tuesday, January 22, 2002, at 12:22 , Michael J. Barber wrote: > There is a surprisingly simple solution, but unfortunately only for > Python 2.2+. Define the required events in StdSuites.Required_Suite, > remove the required events from StdSuites.Standard_Suite, and make > StdSuites.Standard_Suite a subclass of StdSuites.Required_Suite. > Everything else stays as it is. With the new "diamond rule" for > multiple inheritance, that takes care of everything. > This sounds like a great idea! I think we can do one better, even: define these events in a magic, handwritten suite (StdSuites._builtin_Suite comes to mind) and use this as the base class for both StdSuites.Standard_Suite and StdSuites.Required_Suite. These latter two are then still generated, and there's a one-line bit of magic in gensuitemodules that recognizes we're reading an AETE (not AEUT) for standard or required and inserts the magic baseclass. Would this do the trick? > The question remains: is there a fix for Python 2.1 and earlier? I > don't see one. It doesn't really interest me all that much. I don't think there are good reasons not to switch from 2.1 to 2.2, which is if anything more compatible with older machines. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mjb@uma.pt Tue Jan 22 13:15:10 2002 From: mjb@uma.pt (Michael J. Barber) Date: Tue, 22 Jan 2002 13:15:10 +0000 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: <90955251-0F2C-11D6-9BBF-0030655234CE@oratrix.com> Message-ID: <106A125A-0F3A-11D6-A268-0050E4794D0F@uma.pt> On Tuesday, January 22, 2002, at 11:38 AM, Jack Jansen wrote: > > On Tuesday, January 22, 2002, at 12:22 , Michael J. Barber wrote: >> There is a surprisingly simple solution, but unfortunately only for >> Python 2.2+. Define the required events in StdSuites.Required_Suite, >> remove the required events from StdSuites.Standard_Suite, and make >> StdSuites.Standard_Suite a subclass of StdSuites.Required_Suite. >> Everything else stays as it is. With the new "diamond rule" for >> multiple inheritance, that takes care of everything. >> > This sounds like a great idea! > Good, thanks. > I think we can do one better, even: define these events in a magic, > handwritten suite (StdSuites._builtin_Suite comes to mind) and use this > as the base class for both StdSuites.Standard_Suite and > StdSuites.Required_Suite. These latter two are then still generated, > and there's a one-line bit of magic in gensuitemodules that recognizes > we're reading an AETE (not AEUT) for standard or required and inserts > the magic baseclass. > > Would this do the trick? Hmm, depends on some implementation details that I'm not so sure of. Let me make sure I understand the distinction between AEUT and AETE. Checking a bit with ResEdit seems to indicate that AETE goes with applications and AEUT is in the AppleScript extension (and possibly elsewhere?). If that's the case, shouldn't the magic baseclass get inserted for AEUT, and for AETE gensuitemodule just grabs StdSuites.Standard_Suite and StdSuites.Required_Suite, so that the only difference is in how the StdSuites package is generated? Basically, I think the 'one-line bit of magic' depends on implementation details that I don't understand very well. Or maybe I'm just missing the logic you have in mind. The package structure sounds beautiful, though. The magic baseclass should be easy to write; in fact, I think the hacked version I suggested in the original message would work just fine. There is another piece of checking that could be done. If there is neither an AEUT nor an AETE resource, then we know that we'll want an interface that only offers the required events. Whether that should be based on StdSuites._builtin_Suite or StdSuites.Required_Suite is probably a matter of taste. I would go with Required_Suite for consistency with other packages. >> The question remains: is there a fix for Python 2.1 and earlier? I >> don't see one. > > It doesn't really interest me all that much. I don't think there are > good reasons not to switch from 2.1 to 2.2, which is if anything more > compatible with older machines. > And since it looks to be a quite obscure problem, I can't say as I'm terribly interested either. From jack@oratrix.com Tue Jan 22 14:13:35 2002 From: jack@oratrix.com (Jack Jansen) Date: Tue, 22 Jan 2002 15:13:35 +0100 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: <106A125A-0F3A-11D6-A268-0050E4794D0F@uma.pt> Message-ID: <395E9EC4-0F42-11D6-B35C-0030655234CE@oratrix.com> On Tuesday, January 22, 2002, at 02:15 , Michael J. Barber wrote: >> I think we can do one better, even: define these events in a magic, >> handwritten suite (StdSuites._builtin_Suite comes to mind) and use >> this as the base class for both StdSuites.Standard_Suite and >> StdSuites.Required_Suite. These latter two are then still generated, >> and there's a one-line bit of magic in gensuitemodules that recognizes >> we're reading an AETE (not AEUT) for standard or required and inserts >> the magic baseclass. >> >> Would this do the trick? > > Hmm, depends on some implementation details that I'm not so sure of. > Let me make sure I understand the distinction between AEUT and AETE. > Checking a bit with ResEdit seems to indicate that AETE goes with > applications and AEUT is in the AppleScript extension (and possibly > elsewhere?). If that's the case, shouldn't the magic baseclass get > inserted for AEUT, and for AETE gensuitemodule just grabs > StdSuites.Standard_Suite and StdSuites.Required_Suite, so that the only > difference is in how the StdSuites package is generated? Absolutely right. I had apparently reversed AEUT and AETE: AEUT is indeed OSA-supplied and AETE is the application-supplied extension. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mjb@uma.pt Tue Jan 22 15:19:13 2002 From: mjb@uma.pt (Michael J. Barber) Date: Tue, 22 Jan 2002 15:19:13 +0000 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: <395E9EC4-0F42-11D6-B35C-0030655234CE@oratrix.com> Message-ID: <64242352-0F4B-11D6-A268-0050E4794D0F@uma.pt> On Tuesday, January 22, 2002, at 02:13 PM, Jack Jansen wrote: > > Absolutely right. I had apparently reversed AEUT and AETE: AEUT is > indeed OSA-supplied and AETE is the application-supplied extension. > In that case, I agree completely that that is the way to do it. Transparent change in usage from the current version of gensuitemodule, and generally more robust. To make sure we have the same thing in mind, I have made a starting point for _builtin_Suite.py. I made it by assembling bits and pieces from Standard_Suite and Required_Suite, basically as I described before. It is at: The first _code = 'reqd' statement should probably be set to another value, but I'm not sure what to use. Possibly, it is unnecessary, since the class only exists to be subclassed? From Aureli.Soria_Frisch@ipk.fhg.de Tue Jan 22 16:35:08 2002 From: Aureli.Soria_Frisch@ipk.fhg.de (Aureli Soria Frisch) Date: Tue, 22 Jan 2002 17:35:08 +0100 Subject: [Pythonmac-SIG] signal module on the Mac In-Reply-To: <582A0D4C-0ECF-11D6-BBE2-003065B5C6B6@surfbest.net> Message-ID: Hi, I want to catch a KeyboardInterrupt through Python on a Mac with MacOS8.6 and Python version 2.0. I know this is possible to do with the module signal in Unix-Python, but I cannot find this module in the mentioned Python distribution. The problem can not be easily be solved thorugh try/except. Do you know if this module has another name under Mac? Does it exist at all? Is there any other alternatives (more than the try/except)? Thanks in advance. Best regards, Aureli ################################# Aureli Soria Frisch Fraunhofer IPK Dept. Pattern Recognition post: Pascalstr. 8-9, 10587 Berlin, Germany e-mail: aureli@ipk.fhg.de fon: +49 30 39006-150 fax: +49 30 3917517 web: http://vision.fhg.de/~aureli/web-aureli_en.html ################################# From Jack.Jansen@oratrix.nl Tue Jan 22 21:05:22 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Tue, 22 Jan 2002 22:05:22 +0100 Subject: [Pythonmac-SIG] signal module on the Mac In-Reply-To: Message-ID: On Tuesday, January 22, 2002, at 05:35 PM, Aureli Soria Frisch wrote: > Hi, > > I want to catch a KeyboardInterrupt through Python on a Mac > with MacOS8.6 > and Python version 2.0. Are you sure you mean Python 2.0? That's pretty old, and as far as I know there are no reasons for sticking with it (unlike 1.5.2, which was the last 68K version). The solution sketched below will work for MacPython 2.2, but probably not for earlier versions (maybe for 2.1.1, but I'm not sure). > > I know this is possible to do with the module signal in > Unix-Python, but I > cannot find this module in the mentioned Python distribution. > The problem > can not be easily be solved thorugh try/except. The only reasonable alternative for try/except would be to disable command-. processing with MacOS.SchedParams(), and then test for cmd-. with Carbon.Evt.CheckEventQueueForUserCancel() whenever it suits you. But be warned that if you do output to the console window (or if there is any other reason why SIOUX, the console handler, gets control) there is a good chance that it will eat your cmd-. and you may get a KeyboardInterrupt nonetheless. For older Pythons this latter routine is not available and you will have to write a fullblown event loop, I'm afraid. -- - 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.nl Tue Jan 22 23:17:24 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Wed, 23 Jan 2002 00:17:24 +0100 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: <64242352-0F4B-11D6-A268-0050E4794D0F@uma.pt> Message-ID: <31AE8A46-0F8E-11D6-A0C2-003065517236@oratrix.nl> On Tuesday, January 22, 2002, at 04:19 PM, Michael J. Barber wrote: > On Tuesday, January 22, 2002, at 02:13 PM, Jack Jansen wrote: > >> >> Absolutely right. I had apparently reversed AEUT and AETE: >> AEUT is indeed OSA-supplied and AETE is the >> application-supplied extension. >> > In that case, I agree completely that that is the way to do it. > Transparent change in usage from the current version of > gensuitemodule, and generally more robust. > > To make sure we have the same thing in mind, I have made a > starting point for _builtin_Suite.py. I made it by assembling > bits and pieces from Standard_Suite and Required_Suite, > basically as I described before. It is at: > Thanks! I'm about to check this stuff in. I've made two minor changes to your module (adding a reopen() call and changing the _code), and I've restructured things slightly: this module is now called builtin_Suite in a package _builtinSuites, with a handwritten __init__ module that maps both 'core' and 'reqd' to builtin_Suite. The advantage of this is that no magic is needed in gensuitemodule: builtinSuites is now simply the base package for StdSuites (as StdSuites is for all other suites). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From altis@semi-retired.com Wed Jan 23 00:07:46 2002 From: altis@semi-retired.com (Kevin Altis) Date: Tue, 22 Jan 2002 16:07:46 -0800 Subject: [Pythonmac-SIG] Locale on MacOS 9 In-Reply-To: Message-ID: I've checked changes into cvs for PythonCard to support localized language and country resources as described in this message: http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/993748 http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/993792 has some screen shots of the addresses sample running in French. There are some other related threads on the PythonCard mailing list. Does the locale module work correctly under MachoPython? If it doesn't work under OS 9 or OS X, what is an alternative on the Mac that would produce similar results? locale really should be available, but if not, I could potentially do a platform check and a workaround for the Mac. Ever hopeful on wxPython Mac, Real Soon Now, ka > -----Original Message----- > From: pythonmac-sig-admin@python.org > [mailto:pythonmac-sig-admin@python.org]On Behalf Of Francois Granger > Sent: Monday, January 21, 2002 10:05 AM > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] Locale on MacOS 9 > > > > I am currently working on a multilinguale module. At the same time, > PythonCard team is starting to think about localisation. So I did some > search. > > On MacPython ther is an emulation of locale. But it does not work exactly > the way I'd like ;-) > > On Windows: > > >>> import locale > >>> locale.setlocale(locale.LC_ALL, '') > 'French_France.1252' > >>> locale.getdefaultlocale() > ('fr_FR', 'cp1252') > > On the Mac: > >>> import locale > >>> locale.setlocale(locale.LC_ALL, '') > 'C' > >>> locale.getdefaultlocale() > (None, 'mac-roman') > > Inside the file lib:locale.py line 303 it is said : > > To maintain compatibility with other platforms, not only the > LANG variable is tested, but a list of variables given as > envvars parameter. The first found to be defined will be > used. envvars defaults to the search path used in GNU gettext; > it must always contain the variable name 'LANG'. > > Where the list is 'LANGUAGE', 'LC_ALL', 'LC_CTYPE', 'LANG' > > I test defining os.envar before calling locale, but same answer. > > Any idea where I can look for this ? > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From dwilkins@iglide.net Wed Jan 23 06:21:14 2002 From: dwilkins@iglide.net (David Wilkins) Date: Tue, 22 Jan 2002 22:21:14 -0800 Subject: [Pythonmac-SIG] Python on Dual Processor G4 working Message-ID: <66DFA90E-0FC9-11D6-9AA7-003065C04C28@iglide.net> --Apple-Mail-2--900064073 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I followed the procedure you outlined, and after doing it, I could finally start up Python on my dual processor G4 450 MHz under Mac OS X 10.1.2. I have tested a few scripts I wrote using classes that I use at work under Windows. They work. It is such a pleasure to have the G4 dual processor running Python instead of stalling out. Thanks > Date: Tue, 15 Jan 2002 22:32:15 +0100 > From: Jack Jansen > Subject: [Pythonmac-SIG] OSX Multiprocessor - tentative fix available > ... > Folks, > after Alexandre's work to make GUSI safe on OSX multiprocessors I've > created a new PythonCoreCarbon that should work on multiprocessors. At > least, that's the theory:-) > > If some people with an OSX multiprocessor machine could test this that > would be great, and please report back here. MacPython 2.2.1 shouldn't > be too far off, and it would be really great if we could include this > fix. > > Here's the procedure to follow: > - Download MacPython 2.2 and install, if you haven't already done > so. This will probably already fail during ConfigurePythonCarbon or > else the resulting MacPython will hang quickly. > - Download > http://www.cwi.nl/ftp/jack/python/mac/newer/PythonCoreCarbon.sit, > unpack and put the resulting PythonCoreCarbon in your Python folder. > - Run ConfigurePythonCarbon again. > > Now, everything should work. > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > Dave Wilkins --Apple-Mail-2--900064073 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII I followed the procedure you outlined, and after doing it, I could finally start up Python on my dual processor G4 450 MHz under Mac OS X 10.1.2. I have tested a few scripts I wrote using classes that I use at work under Windows. They work. It is such a pleasure to have the G4 dual processor running Python instead of stalling out. Thanks Date: Tue, 15 Jan 2002 22:32:15 +0100 From: Jack Jansen < Subject: [Pythonmac-SIG] OSX Multiprocessor - tentative fix available ... Folks, after Alexandre's work to make GUSI safe on OSX multiprocessors I've created a new PythonCoreCarbon that should work on multiprocessors. At least, that's the theory:-) If some people with an OSX multiprocessor machine could test this that would be great, and please report back here. MacPython 2.2.1 shouldn't be too far off, and it would be really great if we could include this fix. Here's the procedure to follow: - Download MacPython 2.2 and install, if you haven't already done so. This will probably already fail during ConfigurePythonCarbon or else the resulting MacPython will hang quickly. - Download 1A19,1A19,FFFEhttp://www.cwi.nl/ftp/jack/python/mac/newer/PythonCoreCarbon.sit, unpack and put the resulting PythonCoreCarbon in your Python folder. - Run ConfigurePythonCarbon again. Now, everything should work. -- - Jack Jansen < 1A19,1A19,FFFEhttp://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - Dave Wilkins < --Apple-Mail-2--900064073-- From mjb@uma.pt Wed Jan 23 11:01:14 2002 From: mjb@uma.pt (Michael J. Barber) Date: Wed, 23 Jan 2002 11:01:14 +0000 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: <31AE8A46-0F8E-11D6-A0C2-003065517236@oratrix.nl> Message-ID: <846CD511-0FF0-11D6-A268-0050E4794D0F@uma.pt> On Tuesday, January 22, 2002, at 11:17 PM, Jack Jansen wrote: > > I'm about to check this stuff in. I've made two minor changes to your > module (adding a reopen() call and changing the _code), and I've > restructured things slightly: this module is now called builtin_Suite > in a package _builtinSuites, with a handwritten __init__ module that > maps both 'core' and 'reqd' to builtin_Suite. The advantage of this is > that no magic is needed in gensuitemodule: builtinSuites is now simply > the base package for StdSuites (as StdSuites is for all other suites). > Good, I'm glad to hear that my module was a useful starting point. Let me just summarize a bit. As I understand it, the current status is: 1) No changes are needed in gensuitemodule. 2) Generating an OSA interface package is done using gensuitemodule exactly as before. 3) The package will have the four required events, whether the application defines them in Standard Suite, Required Suite, or not at all. 4) StdSuites can still be generated using gensuitemodule, but we now need to select builtinSuites as the base package instead of hitting cancel. (I'll change the documentation if this is correct.) 5) The subtle problem with multiple inheritance that you pointed out is fixed for Python 2.2+, and still very unlikely in earlier versions. I'm not totally certain about point 5, actually. I would expect that generating StdSuites using gensuitemodule would define the required events in StdSuites.Standard_Suite, much in the way that apps can override Standard Suite events in their own dictionaries. If that is so, the new inheritance rule wouldn't help us without some change to gensuitemodule (which probably just consists of checking the name of the base package and filtering out the required events if we're inheriting from builtinSuites instead of StdSuites). One more thing. There is a comment in gensuitemodule asking about a list of python keywords. Using 'help' from pydoc, they are: ["and", "elif", "global", "or", "assert", "else", "if", "pass", "break", "except", "import", "print", "class", "exec", "in", "raise", "continue", "finally", "is", "return", "def", "for", "lambda", "try", "del", "from", "not", "while"]. Some of them are pretty unlikely as AppleScript verbs, of course! Michael From jacobkm@cats.ucsc.edu Wed Jan 23 18:15:55 2002 From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss) Date: Wed, 23 Jan 2002 10:15:55 -0800 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: <846CD511-0FF0-11D6-A268-0050E4794D0F@uma.pt> References: <846CD511-0FF0-11D6-A268-0050E4794D0F@uma.pt> Message-ID: At 11:01 AM +0000 1/23/02, Michael J. Barber wrote: >One more thing. There is a comment in gensuitemodule asking about a >list of python keywords. Using 'help' from pydoc, they are: ["and", >"elif", "global", "or", "assert", "else", "if", "pass", "break", >"except", "import", "print", "class", "exec", "in", "raise", >"continue", "finally", "is", "return", "def", "for", "lambda", >"try", "del", "from", "not", "while"]. Some of them are pretty >unlikely as AppleScript verbs, of course! One more thing along those lines: Python OSA uses "start" as the function to activate an application, but I've come across a few applications which use start themselves as a function. THe StdSuites definition of "start" shaddows the application's function in these cases. How about changing "start" to "activate"? That's what AppleScript calls the same function anyway; it seems more clear to me. Jacob From Jack.Jansen@oratrix.nl Wed Jan 23 22:08:00 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Wed, 23 Jan 2002 23:08:00 +0100 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: Message-ID: On Wednesday, January 23, 2002, at 07:15 PM, Jacob Kaplan-Moss wrote: > Python OSA uses "start" as the function to activate an > application, but I've come across a few applications which use > start themselves as a function. THe StdSuites definition of > "start" shaddows the application's function in these cases. > How about changing "start" to "activate"? That's what > AppleScript calls the same function anyway; it seems more clear > to me. Hmm, good one! (Or actually "bad one":-) Although I think the shadowing happens the other way around: start() isn't defined in StdSuites but in aetools.TalkTo, which is the very last in the base class list. And while aetools.TalkTo.start() has a completely different implementation than StdSuites.Appletalk_Suite_Events.activate() I think you're right in saying they're equivalent. Hmm, no, they're not: activate() will always bring the target to the foreground, start() will not. I'll rename TalkTo.start() to _start(), so there's no problem with appsuite.start() overriding TalkTo.start() anymore (which makes TalkTo.__init__(self, start=1) fail). I'll add a TalkTo.start() which calls TalkTo._start() for compatibility. How does this sound? -- - 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 jacobkm@cats.ucsc.edu Wed Jan 23 22:21:27 2002 From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss) Date: Wed, 23 Jan 2002 14:21:27 -0800 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: References: Message-ID: At 11:08 PM +0100 1/23/02, Jack Jansen wrote: >Although I think the shadowing happens the other way around: start() >isn't defined in StdSuites but in aetools.TalkTo, which is the very >last in the base class list. Yah, that's right; I didn't read the comments on my workarounds closely enough >And while aetools.TalkTo.start() has a completely different >implementation than StdSuites.Appletalk_Suite_Events.activate() I >think you're right in saying they're equivalent. Hmm, no, they're >not: activate() will always bring the target to the foreground, >start() will not. Cool; that's a distinction I didn't know before. Should be usefull... >I'll rename TalkTo.start() to _start(), so there's no problem with >appsuite.start() overriding TalkTo.start() anymore (which makes >TalkTo.__init__(self, start=1) fail). > >I'll add a TalkTo.start() which calls TalkTo._start() for compatibility. > >How does this sound? Great -- I've been doing exactally that by hand in the generated files to work around the conflict. Thanks! Jacob From Jack.Jansen@oratrix.nl Wed Jan 23 22:55:16 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Wed, 23 Jan 2002 23:55:16 +0100 Subject: [Pythonmac-SIG] Locale on MacOS 9 In-Reply-To: Message-ID: <448AB132-1054-11D6-B9C4-003065517236@oratrix.nl> On Wednesday, January 23, 2002, at 01:07 AM, Kevin Altis wrote: > Does the locale module work correctly under MachoPython? Not really. /usr/share/locales as shipped by Apple is hopelessly incomplete. This may be because they feel the native APIs are superior to the BSD setlocale() and friends, but it would be nice if there was a compatible workaround. If someone wants to put some effort into getting the locale module to work on MacOSX (and maybe even OS9: I think the APIs are available there too) that would be very welcome. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From csmith@blakeschool.org Thu Jan 24 03:23:00 2002 From: csmith@blakeschool.org (Christopher Smith) Date: Wed, 23 Jan 2002 21:23:00 -0600 Subject: [Pythonmac-SIG] Carbon Tkinter/Python 2.2 In-Reply-To: References: Message-ID: Hello all, I'm having problems getting a program I use to be able to run to run under the new release (2.2) with Carbon/Tk upgrades. BACKGROUND The program is recon (a regular expression console) located at http://erburley.home.netcom.com/recon.py I have installed the "fourth attempt" PythonCoreCarbon and _tkinter* library file. I am using MacOS 8.6. BEHAVIOR The script is executed by the interpreter and successfully builds the console. However, as soon as I press any key, the cursor appears and the program does not respond to mouse clicks or typing (you are suppose to be able to enter text in a couple different text boxes and interact with check-boxes. I *was* able to see Hanoi from the Demo folder run successfully, so I know that it is possible to run a tkinter program. I am able to run the program under Classic (not Carbon) IDE and the interpreter on my non-carbon OS 8.5.1 system. Any ideas about why this is happening? /c From jacobkm@cats.ucsc.edu Thu Jan 24 05:10:02 2002 From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss) Date: Wed, 23 Jan 2002 21:10:02 -0800 Subject: [Pythonmac-SIG] Python/XDarwin/Tkinter on OS X 10.1 In-Reply-To: References: Message-ID: At 6:27 PM -0800 1/23/02, Tony Lownds wrote: >A lot of people looking for Python on OSX point to my page. I'd like >to either link to your excellent recipe, or paste it on my page... > >Have you posted a web page? Or may I paste your info on my web page? Tony, et alia: I've posted a web page describing how to get Tkinter running on OS X with XDarwin, all installed with Fink: Enjoy, and let me know if there are bugs. Jacob From fgranger@altern.org Thu Jan 24 09:50:05 2002 From: fgranger@altern.org (Francois Granger) Date: Thu, 24 Jan 2002 10:50:05 +0100 Subject: [Pythonmac-SIG] Locale on MacOS 9 In-Reply-To: <448AB132-1054-11D6-B9C4-003065517236@oratrix.nl> Message-ID: on 23/01/02 23:55, Jack Jansen at Jack.Jansen@oratrix.nl wrote: > If someone wants to put some effort into getting the locale > module to work on MacOSX (and maybe even OS9: I think the APIs > are available there too) that would be very welcome. I wonder how difficult it is for MacOS 9 if the only aim is getting the language and country code instead of 'none' as an answser to locale.getdefaultlocale(). I don't know where to look in the rich MacPython lib for a way to get the MacOS language and country ? A stupid proposal in the mean time could be to insert the following at line 326 of lib:locale.py elif sys.platform == "mac": import os for variable in ['LANGUAGE', 'LANG']: localename = os.environ.get(variable,None) if localename is not None: break if localename is not None: code = localename This allow one to do in his own script: os.environ['LANGUAGE'] = 'fr_FR' lang, encoding = locale.getdefaultlocale() From dp@ulaluma.com Thu Jan 24 16:56:32 2002 From: dp@ulaluma.com (Donovan Preston) Date: Thu, 24 Jan 2002 08:56:32 -0800 Subject: [Pythonmac-SIG] package structure for OSA interfaces In-Reply-To: Message-ID: <5176F2E0-10EB-11D6-A019-0050E425C324@ulaluma.com> On Wednesday, January 23, 2002, at 02:08 PM, Jack Jansen wrote: > > And while aetools.TalkTo.start() has a completely different > implementation than StdSuites.Appletalk_Suite_Events.activate() I think > you're right in saying they're equivalent. Hmm, no, they're not: > activate() will always bring the target to the foreground, start() will > not. Wouldn't that then be the distinction between the AppleEvent "run" and the AppleEvent "activate"? I believe run doesn't always bring the app to the foreground; activate does... Donovan From altis@semi-retired.com Thu Jan 24 17:08:30 2002 From: altis@semi-retired.com (Kevin Altis) Date: Thu, 24 Jan 2002 09:08:30 -0800 Subject: [Pythonmac-SIG] Locale on MacOS 9 In-Reply-To: Message-ID: It would be much better for someone to really fix locale otherwise Mac programs won't have the date, currency, number separators, calendar and day names, etc. I know the Mac libraries have all that info and a lot of international functions since I used to use it in my code, but I no longer have my copies of Inside Mac or the code, plus I'm sure the library and functions calls changed with OS X... Anyone interested in fixing locale should look at: http://www.python.org/doc/current/lib/module-locale.html However, just having the language and country code would at least help if all you needed was to be able to handle basic string localization. ka > -----Original Message----- > From: pythonmac-sig-admin@python.org > [mailto:pythonmac-sig-admin@python.org]On Behalf Of Francois Granger > Sent: Thursday, January 24, 2002 1:50 AM > To: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] Locale on MacOS 9 > > > on 23/01/02 23:55, Jack Jansen at Jack.Jansen@oratrix.nl wrote: > > > If someone wants to put some effort into getting the locale > > module to work on MacOSX (and maybe even OS9: I think the APIs > > are available there too) that would be very welcome. > > I wonder how difficult it is for MacOS 9 if the only aim is getting the > language and country code instead of 'none' as an answser to > locale.getdefaultlocale(). > > I don't know where to look in the rich MacPython lib for a way to get the > MacOS language and country ? > > A stupid proposal in the mean time could be to insert the > following at line > 326 of lib:locale.py > > elif sys.platform == "mac": > import os > for variable in ['LANGUAGE', 'LANG']: > localename = os.environ.get(variable,None) > if localename is not None: > break > if localename is not None: > code = localename > > > This allow one to do in his own script: > > os.environ['LANGUAGE'] = 'fr_FR' > lang, encoding = locale.getdefaultlocale() > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From terabaap@yumpee.org Thu Jan 24 18:58:01 2002 From: terabaap@yumpee.org (Manoj Plakal) Date: Thu, 24 Jan 2002 12:58:01 -0600 Subject: [Pythonmac-SIG] OS X import bug? Message-ID: <3C505939.1000703@yumpee.org> This is a multi-part message in MIME format. --------------000802010502030105080006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I've just noticed a weird problem with importing modules on MacOS X 10.1 and Python 2.2. Say I have two modules foo and bar, both of which are built with a common file baz.c with some variables defined in it. I make a setup.py which specifies that module foo is built from foomodule.c and baz.c, and module bar is built from barmodule.c and baz.c. On Red Hat Linux 7.2 with Python 2.2, this builds fine and I can import both foo and bar into the same interpreter session. On OS X 10.1 with Python 2.2, this builds fine but I can only import *ONE* of foo or bar into the same interpreter session. E.g., if I import foo first and then bar, Python craps out saying "Failure linking new module". Similary for bar first and then foo. This is both with a version built from the 2.2 source release, as well as a binary version from Fink (fink.sourceforge.net). I've attached the files which can be used to reproduce this: setup.py, foomodule.c, barmodule.c, baz.c. In case the attachments don't work, you can grab them off the web: http://yumpee.org/python/setup.py http://yumpee.org/python/foomodule.c http://yumpee.org/python/barmodule.c http://yumpee.org/python/baz.c Is this a bug? Undefined behavior? Feature? Is it a fluke that it works on Linux? If someone else with OS X can reproduce this error, (and people on other OSes can confirm that it's working), that would be great ... Manoj --------------000802010502030105080006 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="setup.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="setup.py" # # Targets: build test install help # from distutils.core import setup, Extension # Distutils setup call setup ( ext_modules = [Extension('foo', ['foomodule.c', 'baz.c'], ), Extension('bar', ['barmodule.c', 'baz.c'], ), ] ) --------------000802010502030105080006 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="foomodule.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="foomodule.c" #include #include extern int var_for_foo; static char foofun_doc[] = "Function fun in module foo"; static PyObject* foofun(PyObject* self, PyObject* args) { printf( "In foofun()\n" ); printf( "var_for_foo = %d\n", var_for_foo); return NULL; } static PyMethodDef kModuleMethods[] = { {"foofun", foofun, METH_VARARGS, foofun_doc}, {NULL, NULL } /* sentinel */ }; void initfoo() { PyObject* module; module = Py_InitModule("foo", kModuleMethods); printf( "var_for_foo = %d\n", var_for_foo); return; } --------------000802010502030105080006 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="barmodule.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="barmodule.c" #include #include extern int var_for_bar; static char barfun_doc[] = "Function fun in module bar"; static PyObject* barfun(PyObject* self, PyObject* args) { printf( "In barfun()\n" ); printf( "var_for_bar = %d\n", var_for_bar); return NULL; } static PyMethodDef kModuleMethods[] = { {"barfun", barfun, METH_VARARGS, barfun_doc}, {NULL, NULL } /* sentinel */ }; void initbar() { PyObject* module; module = Py_InitModule("bar", kModuleMethods); printf( "var_for_bar = %d\n", var_for_bar); return; } --------------000802010502030105080006 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="baz.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="baz.c" int var_for_foo = 1; int var_for_bar = 6; --------------000802010502030105080006-- From Jack.Jansen@oratrix.nl Thu Jan 24 23:04:29 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Fri, 25 Jan 2002 00:04:29 +0100 Subject: [Pythonmac-SIG] Carbon Tkinter/Python 2.2 In-Reply-To: References: Message-ID: At 21:23 -0600 23-01-2002, Christopher Smith wrote: >Hello all, > >I'm having problems getting a program I use to be able to run to run under >the new release (2.2) with Carbon/Tk upgrades. > >BACKGROUND > >The program is recon (a regular expression console) located at > >http://erburley.home.netcom.com/recon.py > >I have installed the "fourth attempt" PythonCoreCarbon and _tkinter* >library file. > >I am using MacOS 8.6. > >BEHAVIOR > >The script is executed by the interpreter and successfully builds the >console. However, as soon as I press any key, the cursor appears and the >program does not respond to mouse clicks or typing (you are suppose to be >able to enter text in a couple different text boxes and interact with >check-boxes. Chris, I can repeat this behaviour, thanks for the good example (nice program, by the way!). I need help debugging this, so all Tkinter fans please try this program and come up with theories. One problem is simple (at least, simple to describe:-): the default mouse cursor, the arrow, isn't shown. Other cursors, such as the text cursor when you're over any of the text fields, show up fine. The next problem, the event problem, is more complex. At least, the way I get to see the problem. All events happen, but some happen late, and the order in which they happen seems to be different from the order in which they should happen. I've been clicking back and forth between the two text fields and trying to click the "evaluate" button. Every time you actually generate an event (mouseclick, key press) an old event will happen, but which one is unknown. Also, mouse clicks don't always seem to be interpreted at the place at which they actually happened. If people can helkp me find the pattern in what exactly is happening here that would be really helpful. Also, if you think you have the pattern, please give a recipe for how to see it From csmith@blakeschool.org Fri Jan 25 00:52:41 2002 From: csmith@blakeschool.org (Christopher Smith) Date: Thu, 24 Jan 2002 18:52:41 -0600 Subject: [Pythonmac-SIG] Re: Carbon Tkinter/Python 2.2 In-Reply-To: References: Message-ID: Jack.Jansen@oratrix.nl writes: >I can repeat this behaviour, thanks for the good example (nice >program, by the way!). Hat's off to author Brent Burley. (When I was trying to find this program again I had to search through the tutor archive to try find the original reference to it.) I confirmed that the program does work under the classic configuration under OS 9.2 but not under the Carbon version. I did notice that under the Classic version a double click is needed to initially to get the program responding to my mouse, but after that, everything works fine: mouse clicks switch me between boxes and toggle checkboxes. Under Carbon, as I mentioned, there is no cursor until I press a key, but after I press a key there is not further response. I cannot even get your observed sporadic behavior. When I did it tonight, the system froze and I needed to reboot. /c From Benjamin.Schollnick@usa.xerox.com Fri Jan 25 13:04:06 2002 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 25 Jan 2002 08:04:06 -0500 Subject: [Pythonmac-SIG] Re: Carbon Tkinter/Python 2.2 Message-ID: > I confirmed that the program does work under the classic > configuration under OS 9.2 but not under the Carbon version. > I did notice that under the Classic version a double click is needed > to initially to get the program responding to my mouse, but after >that, everything works fine: mouse clicks switch me between boxes >and toggle checkboxes. > Under Carbon, as I mentioned, there is no cursor until I press a > key, but after I press a key there is not further response. I >cannot even get your observed sporadic behavior. When I did it > tonight, the system froze and I needed to reboot. Crazy question... Are any of you running Multiprocessor systems? I realize that the MOSX issue was with Multiprocessors, but I'm just curious if some version of the carbon libraries may also have issues with multiprocessors? And what version of the Carbon Libraries are you folks using? Has anyone tried the most recent release, I believe v1.5? - Benjamin From jbradley@thinqinteractive.com Fri Jan 25 13:41:46 2002 From: jbradley@thinqinteractive.com (Jon Bradley) Date: Fri, 25 Jan 2002 08:41:46 -0500 Subject: [Pythonmac-SIG] Problems building 2.2 Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3094792906_89699_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hey everyone, Up and running with the new version - minus one thing. I can't get ConfigurePythonCarbon to run. ;( The traceback is a path that obviously doesn't exist - something on Jack's machine. Not only that but the application can't find the OS module, which is very odd. Doesn't make sense to me. I've tried a bunch of things, to no avail. Anyone have this problem or is able to help? thanks in advance! Jon Bradley Multimedia Developer --MS_Mac_OE_3094792906_89699_MIME_Part Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Problems building 2.2 Hey everyone,

Up and running with the new version - minus one thing.  I can't get Co= nfigurePythonCarbon to run.  ;(

The traceback is a path that obviously doesn't exist - something on Jack's = machine.  Not only that but the application can't find the OS module, w= hich is very odd.  Doesn't make sense to me.

I've tried a bunch of things, to no avail.  Anyone have this problem o= r is able to help?

thanks in advance!

Jon Bradley
Multimedia Developer --MS_Mac_OE_3094792906_89699_MIME_Part-- From csmith@blakeschool.org Fri Jan 25 18:14:20 2002 From: csmith@blakeschool.org (Christopher Smith) Date: Fri, 25 Jan 2002 12:14:20 -0600 Subject: [Pythonmac-SIG] Re: Carbon Tkinter/Python 2.2 In-Reply-To: References: Message-ID: >From: "Schollnick, Benjamin" >Crazy question... > >Are any of you running Multiprocessor systems? no, just regular 9.2.1 > > > >And what version of the Carbon Libraries are you folks using? I had an older verion (1.4, I think). I now installed 1.5. Here is the behavior that I note now (though this may not be due to library changes, just a different sequence of user events): I drop the recon.py script on the interpreeter I do not see any cursor ==> If I press a key then the Pointer cursor appears but I can't do anything with it in the console. I *can* however, collapse the window. I can also select the interpreter's window which makes it active, but then when I reclick on the console's window it doesn't come forward but it can still be collapsed. Furthermore, if I click in the menu bar (anywhere) the program crashes with a 1010 error. (After doing this several times, the system finally crashed as well with a bomb and error 10.) ==> If I click the mouse first, the cursor does not appear until the second click. I can successfully navigate between text boxes but when the mouse gets down in the check box region, it disappears but remains active (so I can blindly click on the check boxes even though I can't see the cursor). I can get the "event delayed" behavior that Jack noted by clicking on the desktop first AND THEN clicking in the console. If I anticipate where the console is going to be and move my mouse there before it disappears, then I can sussessfully navigate the window as I started this paragraph by saying. /c From jbradley@thinqinteractive.com Fri Jan 25 20:59:12 2002 From: jbradley@thinqinteractive.com (Jon Bradley) Date: Fri, 25 Jan 2002 15:59:12 -0500 Subject: [Pythonmac-SIG] Python Reentrant? In-Reply-To: Message-ID: Does anyone know forsure whether or not Python 2.2 is reentrant? I was posed this question and just got a free moment to type up an e-mail to ask you all. We're embedding Python and will want to be able to have more than one thread evaluating a Python expression at one time. I'm all sorts of looking forward to a positive answer. Another 'simple' question ... with embedding again. How can I return focus to my application after creating/using modal dialogs or windows within the embedded interpreter? On evaluating a script with windows, everything works fine until the window is closed, then I can't get back to the application. Odd, and I don't know what may be the problem (or what I need to do to return focus). thanks in advance, Jon From bas@andrew.cmu.edu Fri Jan 25 22:02:13 2002 From: bas@andrew.cmu.edu (Bruce Sherwood) Date: Fri, 25 Jan 2002 17:02:13 -0500 Subject: [Pythonmac-SIG] install problems Message-ID: <2660819170.1011978133@muon> In the service of the VPython project (http://vpython.org), we are trying to compile Python 2.2 from source on a Mac. "Out of the box" we can't get compiles to work. We take the source for Python 2.2 and for GUSI2, and try to build using Metrowerks 7.0. We can't get GUSI to build because we get lots of compile errors. We can't build Python because it needs to link some missing GUSI libraries. We also got Python by CVS from sourceforge and tried to build, but an attempt to build gives large numbers of errors talking about missing files. The project settings for access paths in fact look wrong, listing only (Project): and (Compiler):. We thought we saw various statements about being able to compile "out of the box" (and also that the CVS download would give us everything, including GUSI files). Help? Thanks. David Andersen and Bruce Sherwood From Jack.Jansen@oratrix.nl Fri Jan 25 23:27:49 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sat, 26 Jan 2002 00:27:49 +0100 Subject: [Pythonmac-SIG] Re: Carbon Tkinter/Python 2.2 In-Reply-To: Message-ID: <259B9B44-11EB-11D6-96E9-003065517236@oratrix.nl> On Friday, January 25, 2002, at 07:14 PM, Christopher Smith wrote: > ==> If I click the mouse first, the cursor does not appear until the > second click. I can successfully navigate between text boxes > but when the > mouse gets down in the check box region, it disappears but > remains active > (so I can blindly click on the check boxes even though I can't see the > cursor). I can get the "event delayed" behavior that Jack noted by > clicking on the desktop first AND THEN clicking in the console. There's a good chance I got into this mode through similar means, or maybe through selecting the Apple menu first or something. Everything we've seen so far, even though the symptoms are pretty different in different circumstances, seems to point to a problem with WaitNextEvent(). Now, in CarbonLib WaitNextEvent() is really a simulated call implemented with Carbon Events, i.e. the lowlevel mechanism is Carbon Events. So in the one process part of the code (Python's cmd-. handler, GUSI's wait spinloop) uses the Carbon simulated WNE and another part of the code (Tk) uses the real old-style WNE in InterfaceLib. It could be that this leads to the strange behaviour we see. Does anyone here know whether this hunch is worth pursuing? Any idea where we could find more info on 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@oratrix.nl Fri Jan 25 23:36:02 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sat, 26 Jan 2002 00:36:02 +0100 Subject: [Pythonmac-SIG] install problems In-Reply-To: <2660819170.1011978133@muon> Message-ID: <4B0F043E-11EC-11D6-96E9-003065517236@oratrix.nl> On Friday, January 25, 2002, at 11:02 PM, Bruce Sherwood wrote: > In the service of the VPython project (http://vpython.org), we > are trying to compile Python 2.2 from source on a Mac. "Out of > the box" we can't get compiles to work. Not many people develop from source, and most tend to be "old hands", so there's a good chance you're running into problems. Let's try and solve them:-) > We take the source for Python 2.2 and for GUSI2, and try to > build using Metrowerks 7.0. We can't get GUSI to build because > we get lots of compile errors. We can't build Python because it > needs to link some missing GUSI libraries. Which GUSI did you try? You need the special GUSI that comes with MacPython (referenced on the homepage). It's not so special anymore, it's in the main GUSI CVS repository nowadays, but there are no official (i.e. by Matthias) distributions of it. If you did indeed use that GUSI please send a list of the errors you get. > We also got Python by CVS from sourceforge and tried to build, > but an attempt to build gives large numbers of errors talking > about missing files. The project settings for access paths in > fact look wrong, listing only (Project): and (Compiler):. Again, if you can post the error messages we should be able what goes wrong. > We thought we saw various statements about being able to > compile "out of the box" (and also that the CVS download would > give us everything, including GUSI files). Help? Nope, GUSI is completely separate, as are some other modules you need to build a complete Python (expat, zlib, possibly tcl/tk, image libraries...). :Mac:Demo:building.html should have explained all this, if information is missing there I would love to hear it so we can fix the document. How many people would like to build MacPython from source but haven't started with it because there's no "batteries included" source distribution? Doing such a distribution would be some effort, but not an inordinate amount, so I could probably be tempted to do it if enough people are interested (and if someone else then fixes the Tkinter problems in return:-) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From aparente@adobe.com Sat Jan 26 01:02:48 2002 From: aparente@adobe.com (Alexandre Parenteau) Date: Fri, 25 Jan 2002 17:02:48 -0800 Subject: [Pythonmac-SIG] install problems In-Reply-To: <4B0F043E-11EC-11D6-96E9-003065517236@oratrix.nl> Message-ID: > How many people would like to build MacPython from source but > haven't started with it because there's no "batteries included" > source distribution? Doing such a distribution would be some > effort, but not an inordinate amount, so I could probably be > tempted to do it if enough people are interested (and if someone > else then fixes the Tkinter problems in return:-) Deal ! Seriously, it is a little bit cumbersome to build it from scratch. I wish I had your hard disk sometimes... You never posted the carbon modifications to apply to the TIFF library for example in order to build the Carbon target. But this is only one example. Here are my suggestions of things I would do to simplify the build process : 1- remove dependencies over InternetConfig and use Metrowerks's one 2- remove dependencies over Waste and use Metrowerks's one 3- Put imglibs, Tcl/Tk Folder, expat, gdbm... in CVS. Make it available by CVS so people like me can trace the advancement of Tkinter. 4- Use the nice script 'MkDistr.py' and make a MacPythonLibs distribution which includes all the third parties libraries 5- checkout python and try to build from scratch ! Alex. -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From terabaap@yumpee.org Sat Jan 26 02:09:31 2002 From: terabaap@yumpee.org (Manoj Plakal) Date: Fri, 25 Jan 2002 20:09:31 -0600 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] References: <3C520BDC.2000306@yumpee.org> Message-ID: <3C520FDB.6070706@yumpee.org> Confirmed a solution to the OS X import bug/feature. The flat namespace used in building extension modules is to blame. I just edited /usr/local/lib/python2.2/config/Makefile and changed both LDSHARED and BLDSHARED to be $(CC) $(LDFLAGS) -bundle -bundle_loader /usr/local/bin/python2.2 -undefined error (disabling the flat namespace and using two-level namespace linking) Now, I can build and import both foo and bar into the same interpreter session without problems. Note that I didn't re-build Python, just edited the Makefile. Not sure if this will have ramifications for other modules ... I think I will submit a bug on Sourceforge asking that flat namespace be disabled. Manoj Manoj Plakal wrote to support@wingide.com: > > I got a few responses to my post to > c.l.py and pythonmac-sig about the > OS X import bug. > > OS X 10.1 has two kinds of linking > of loadable modules: flat and > two-level. Two-level is what > is done on Linux (RTLD_LOCAL with > RTLD_GLOBAL not specified) as > well as Windows. However, building > Python releases on OS X enables > the flat namespace option. > > Looks like Python needs to be set > up with the flat namespace option > disabled (when you build your > extension modules). Also, see this > message: > http://mail.python.org/pipermail/pythonmac-sig/2002-January/004707.html > > Manoj > > > -------- Original Message -------- > Subject: Re: [Pythonmac-SIG] OS X import bug? > Date: Fri, 25 Jan 2002 14:46:37 -0500 > From: Marcelinus Prastawa > To: Manoj Plakal > > It worked on my machine. > > OS X's dynamic loader is a bit different. The two modules share the same > symbols. If they are built as flat namespace binaries, Python would fail > to build the second one. > > You should remove the "-flat_namespace -undefined suppress" options... If > you are using Mach-O (UNIX) Python you could edit the options in > /usr/local/lib/python2.2/config/Makefile. > > Marcel > > On Thursday, January 24, 2002, at 01:58 , Manoj Plakal wrote: > > > > > Hello, > > > > I've just noticed a weird problem with importing modules > > on MacOS X 10.1 and Python 2.2. > > > > Say I have two modules foo and bar, both of which > > are built with a common file baz.c with some variables > > defined in it. > > > > I make a setup.py which specifies that module foo > > is built from foomodule.c and baz.c, and module bar > > is built from barmodule.c and baz.c. > > > > On Red Hat Linux 7.2 with Python 2.2, this builds fine and I > > can import both foo and bar into the same interpreter session. > > > > On OS X 10.1 with Python 2.2, this builds fine but I can > > only import *ONE* of foo or bar into the same interpreter > > session. E.g., if I import foo first and then bar, > > Python craps out saying "Failure linking new module". > > Similary for bar first and then foo. > > > > This is both with a version built from the 2.2 source > > release, as well as a binary version from Fink > > (fink.sourceforge.net). > > > > I've attached the files which can be used to reproduce > > this: setup.py, foomodule.c, barmodule.c, baz.c. In > > case the attachments don't work, you can grab them > > off the web: http://yumpee.org/python/setup.py > > http://yumpee.org/python/foomodule.c > > http://yumpee.org/python/barmodule.c > > http://yumpee.org/python/baz.c > > > > Is this a bug? Undefined behavior? Feature? > > Is it a fluke that it works on Linux? > > > > If someone else with OS X can reproduce this error, > > (and people on other OSes can confirm that > > it's working), that would be great ... > > > > Manoj > > From prastawa@cs.unc.edu Sat Jan 26 03:16:17 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Fri, 25 Jan 2002 22:16:17 -0500 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] References: <3C520BDC.2000306@yumpee.org> <3C520FDB.6070706@yumpee.org> Message-ID: <3C521F81.40702@cs.unc.edu> Manoj Plakal wrote: > Now, I can build and import both foo and > bar into the same interpreter session without > problems. Note that I didn't re-build Python, > just edited the Makefile. Not sure if > this will have ramifications for other modules ... It will not affect the modules that you already have. When you build new modules, you may need to modify the file to fall back to building flat namespace binary extensions. > I think I will submit a bug on Sourceforge > asking that flat namespace be disabled. This is not really a bug. Some (very useful) modules will not compile as two-level namespace binaries, at least not without some considerable effort. It looks like you're porting an app... Be aware that there is an issue with dynload_next (see Bob Ippolito's messages). I've gotten into some trouble with identically named binaries (lots of renaming), I've switched to libdl now (thanks Bob!). Marcel From terabaap@yumpee.org Sat Jan 26 03:44:58 2002 From: terabaap@yumpee.org (Manoj Plakal) Date: Fri, 25 Jan 2002 21:44:58 -0600 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] References: <3C520BDC.2000306@yumpee.org> <3C520FDB.6070706@yumpee.org> <3C521F81.40702@cs.unc.edu> Message-ID: <3C52263A.5000104@yumpee.org> Marcel, Which modules are these? From the replies I saw on c.l.py, it seems that the two-level setup corresponds to the way extension modules are built and used on Linux and Windows (symbols within modules don't clash with each other). http://groups.google.com/groups?hl=en&threadm=j4sn8uu517.fsf%40informatik.hu-berlin.de&prev=/groups%3Fnum%3D25%26hl%3Den%26group%3Dcomp.lang.python%26start%3D75%26group%3Dcomp.lang.python Why do some modules need the flat namespace? Yeah, I am porting Wing IDE (wingide.com) to run on OS X and two of their extension modules shared a source file, leading to the import error. I have managed to get it running without requiring 2-level namespace build (changed the setup.py and import order a little bit). Now I only wish there were a native OS X version of Gtk (used by Wing). All I see are a couple of inactive Sourceforge projects (gtk-mac, gtk-quartz). Manoj Marcel Prastawa wrote: > This is not really a bug. Some (very useful) modules will not compile as > two-level namespace binaries, at least not without some considerable effort. > > It looks like you're porting an app... Be aware that there is an issue > with dynload_next (see Bob Ippolito's messages). I've gotten into some > trouble with identically named binaries (lots of renaming), I've > switched to libdl now (thanks Bob!). > > Marcel > From sdm7g@Virginia.EDU Sat Jan 26 03:56:25 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Fri, 25 Jan 2002 22:56:25 -0500 (EST) Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] In-Reply-To: <3C521F81.40702@cs.unc.edu> Message-ID: On Fri, 25 Jan 2002, Marcel Prastawa wrote: > > This is not really a bug. Some (very useful) modules will not compile as > two-level namespace binaries, at least not without some considerable effort. > > It looks like you're porting an app... Be aware that there is an issue > with dynload_next (see Bob Ippolito's messages). I've gotten into some > trouble with identically named binaries (lots of renaming), I've > switched to libdl now (thanks Bob!). After replicating the problem Bob described, I tried building with libdl, but that seems to have broken some other imports. I haven't isolated what's going on -- it seems to depend on the order or the paths used. Which version of libdl are you guys using ? (and from where?) -- Steve Majewski From terabaap@yumpee.org Sat Jan 26 04:28:33 2002 From: terabaap@yumpee.org (Manoj Plakal) Date: Fri, 25 Jan 2002 22:28:33 -0600 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] References: <3C520BDC.2000306@yumpee.org> <3C520FDB.6070706@yumpee.org> <3C521F81.40702@cs.unc.edu> <3C52263A.5000104@yumpee.org> Message-ID: <3C523071.6060304@yumpee.org> Actually, instead of only one or the other, it might be a better idea for Python to provide a distutils option for flat or 2-level namespace when building extension modules. I added this as a follow-up to my bug report on Sourceforge: http://sourceforge.net/tracker/index.php?func=detail&aid=508779&group_id=5470&atid=105470 Manoj Manoj Plakal wrote: > > Marcel, > > Which modules are these? From the replies I saw > on c.l.py, it seems that the two-level > setup corresponds to the way extension > modules are built and used on Linux > and Windows (symbols within modules > don't clash with each other). > http://groups.google.com/groups?hl=en&threadm=j4sn8uu517.fsf%40informatik.hu-berlin.de&prev=/groups%3Fnum%3D25%26hl%3Den%26group%3Dcomp.lang.python%26start%3D75%26group%3Dcomp.lang.python > Why do some modules need the flat namespace? > > > Marcel Prastawa wrote: > >> This is not really a bug. Some (very useful) modules will not compile >> as two-level namespace binaries, at least not without some >> considerable effort. >> >> It looks like you're porting an app... Be aware that there is an issue >> with dynload_next (see Bob Ippolito's messages). I've gotten into some >> trouble with identically named binaries (lots of renaming), I've >> switched to libdl now (thanks Bob!). >> >> Marcel >> > > > From prastawa@cs.unc.edu Sat Jan 26 12:53:49 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Sat, 26 Jan 2002 07:53:49 -0500 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] References: Message-ID: <3C52A6DD.9020804@cs.unc.edu> Steven Majewski wrote: > After replicating the problem Bob described, I tried building with libdl, > but that seems to have broken some other imports. I haven't isolated > what's going on -- it seems to depend on the order or the paths used. > > Which version of libdl are you guys using ? (and from where?) Note: I may have done things differently from Bob, and I am doing this with the 2.2 release source (not CVS). I am using libdl from Fink (the dlcompat package, version 20010831). Does the import problem occur with flat namespace extensions that have undefined symbols? I encountered this too. I got things to work by setting the RTLD_GLOBAL flag for dlopen, so that it behaves a bit more like dynload_next. It's an ugly hack... In dynload_shlib.c instead of: dlopenflags = PyThreadState_Get()->interp->dlopenflags; I did: dlopenflags = PyThreadState_Get()->interp->dlopenflags | RTLD_GLOBAL; So that RTLD_GLOBAL is always set. Is there a better place for doing this? I haven't tested this thoroughly yet, but it seems to work fine. Out of curiosity, is the 'identical binary name' problem with dynload_next a MacPython problem (that we could work out) or is it a problem with the OS X framework? Marcel From prastawa@cs.unc.edu Sat Jan 26 13:03:08 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Sat, 26 Jan 2002 08:03:08 -0500 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] References: <3C520BDC.2000306@yumpee.org> <3C520FDB.6070706@yumpee.org> <3C521F81.40702@cs.unc.edu> <3C52263A.5000104@yumpee.org> <3C523071.6060304@yumpee.org> Message-ID: <3C52A90C.807@cs.unc.edu> Manoj Plakal wrote: > Which modules are these? From the replies I saw > on c.l.py, it seems that the two-level > setup corresponds to the way extension > modules are built and used on Linux > and Windows (symbols within modules > don't clash with each other). > > Why do some modules need the flat namespace? I could only think of several examples: the Mac specific modules, VTK (a visualization toolkit). Two-level namespace binaries need to have all symbols resolved at compile time. This is difficult to do if your extension has some complex dependencies. When porting an application, you could save a lot of time by building it as a flat namespace binary. > Actually, instead of only one or > the other, it might be a better > idea for Python to provide > a distutils option for > flat or 2-level namespace when > building extension modules. I added > this as a follow-up to my bug report > on Sourceforge: Great idea! I got so used to editing the Makefile, the thought didn't occur to me. I certainly hope that it's possible to do so in distutils. Marcel From Jack.Jansen@oratrix.nl Sat Jan 26 14:15:35 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sat, 26 Jan 2002 15:15:35 +0100 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] In-Reply-To: <3C520FDB.6070706@yumpee.org> Message-ID: <2A0FF274-1267-11D6-8E2E-003065517236@oratrix.nl> On Saturday, January 26, 2002, at 03:09 AM, Manoj Plakal wrote: > > Confirmed a solution to the OS X import bug/feature. > The flat namespace used in building extension > modules is to blame. Ah, great that you found this. I was already thinking along these lines but I wanted to do a test before I posted here. > I think I will submit a bug on Sourceforge > asking that flat namespace be disabled. The disadvantage of this is that a Python built on 10.1 will no longer run on 10.0. So I think we should make this into a configure flag (--with-flat-namespace, default off). Or is this overkill? (a binary created on 10.0 will run on 10.0, of course, because it is automatically flat namespace). Oh yes, a bug report is a good idea, but a patch would be an even better idea:-) -- - 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.nl Sat Jan 26 14:24:20 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sat, 26 Jan 2002 15:24:20 +0100 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] In-Reply-To: <3C52A6DD.9020804@cs.unc.edu> Message-ID: <63578346-1268-11D6-8E2E-003065517236@oratrix.nl> On Saturday, January 26, 2002, at 01:53 PM, Marcel Prastawa wrote: > Out of curiosity, is the 'identical binary name' problem with > dynload_next a MacPython problem (that we could work out) or is > it a problem with the OS X framework? My feeling is that the problem is with dynload_next.c, which is a very old file that hasn't seen any development for many years (between NeXT's near-demise and OSX's appearance). The problem is exacerbated by the fact that the APIs used in dynload_next.c or very poorly documented, if at all. My guess (can anyone confirm this or point me to more info?) is that the NSIsSymbolNameDefined() call at the beginning is incorrect, and will return the wrong module upon import of a second module with the same name. Maybe someone who is experiencing the problem can comment out that quick-return section and see whether dynload_next.c then works as expected? Or will we then immedeately run into flat namespace problems (two routines called initfoo)? -- - 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 terabaap@yumpee.org Sat Jan 26 14:40:05 2002 From: terabaap@yumpee.org (Manoj Plakal) Date: Sat, 26 Jan 2002 08:40:05 -0600 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] References: <2A0FF274-1267-11D6-8E2E-003065517236@oratrix.nl> Message-ID: <3C52BFC5.60208@yumpee.org> Jack Jansen wrote: > On Saturday, January 26, 2002, at 03:09 AM, Manoj Plakal wrote: >> I think I will submit a bug on Sourceforge >> asking that flat namespace be disabled. > > The disadvantage of this is that a Python built on 10.1 will no longer > run on 10.0. So I think we should make this into a configure flag > (--with-flat-namespace, default off). Or is this overkill? (a binary > created on 10.0 will run on 10.0, of course, because it is automatically > flat namespace). > > Oh yes, a bug report is a good idea, but a patch would be an even better > idea:-) Why does this affect the Python binary itself? Doesn't the namespace option only affect the building of extension modules? Would there be a problem importing a 2-level-namespace extension on 10.0? Re patch, I'm guessing it would be a patch to distutils to provide an extra build option for distutils.core.Extension with the default = build extension as 2-level on 10.1, flat on 10.0. Manoj From terabaap@yumpee.org Sat Jan 26 15:07:04 2002 From: terabaap@yumpee.org (Manoj Plakal) Date: Sat, 26 Jan 2002 09:07:04 -0600 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] References: <63578346-1268-11D6-8E2E-003065517236@oratrix.nl> Message-ID: <3C52C618.5060105@yumpee.org> Jack Jansen wrote: > > On Saturday, January 26, 2002, at 01:53 PM, Marcel Prastawa wrote: > >> Out of curiosity, is the 'identical binary name' problem with >> dynload_next a MacPython problem (that we could work out) or is it a >> problem with the OS X framework? > > > My feeling is that the problem is with dynload_next.c, which is a very > old file that hasn't seen any development for many years (between NeXT's > near-demise and OSX's appearance). The problem is exacerbated by the > fact that the APIs used in dynload_next.c or very poorly documented, if > at all. My guess (can anyone confirm this or point me to more info?) is > that the NSIsSymbolNameDefined() call at the beginning is incorrect, and > will return the wrong module upon import of a second module with the > same name. > > Maybe someone who is experiencing the problem can comment out that > quick-return section and see whether dynload_next.c then works as > expected? Or will we then immedeately run into flat namespace problems > (two routines called initfoo)? There's some documentation from Apple: http://developer.apple.com/techpubs/macosx/ReleaseNotes/TwoLevelNamespaces.html Also man NSModule, man NSObjectFileImage, man 3 dyld ... Is there a "reference implementation" of loading extensions against which we can compare the dynload_next.c file to see if it is implementing the official semantics? Manoj From prastawa@cs.unc.edu Sat Jan 26 15:17:45 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Sat, 26 Jan 2002 10:17:45 -0500 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] References: <63578346-1268-11D6-8E2E-003065517236@oratrix.nl> Message-ID: <3C52C899.70509@cs.unc.edu> Jack Jansen wrote: > My feeling is that the problem is with dynload_next.c, which is a very > old file that hasn't seen any development for many years (between NeXT's > near-demise and OSX's appearance). The problem is exacerbated by the > fact that the APIs used in dynload_next.c or very poorly documented, if > at all. My guess (can anyone confirm this or point me to more info?) is > that the NSIsSymbolNameDefined() call at the beginning is incorrect, and > will return the wrong module upon import of a second module with the > same name. I'm glad it's not an OS X issue. It seems that libdl also uses the same NeXT functions, so a fix should be possible. > Maybe someone who is experiencing the problem can comment out that > quick-return section and see whether dynload_next.c then works as > expected? Or will we then immedeately run into flat namespace problems > (two routines called initfoo)? I will play with this idea... BTW, if we have two routines called initfoo in two different flat namespace binaries, I think we will run into problems anyway (even with libdl). Marcel From sdm7g@Virginia.EDU Sat Jan 26 18:45:26 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Sat, 26 Jan 2002 13:45:26 -0500 (EST) Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] In-Reply-To: <63578346-1268-11D6-8E2E-003065517236@oratrix.nl> Message-ID: On Sat, 26 Jan 2002, Jack Jansen wrote: > My feeling is that the problem is with dynload_next.c, which is > a very old file that hasn't seen any development for many years > (between NeXT's near-demise and OSX's appearance). The problem > is exacerbated by the fact that the APIs used in dynload_next.c > or very poorly documented, if at all. My guess (can anyone > confirm this or point me to more info?) is that the > NSIsSymbolNameDefined() call at the beginning is incorrect, and > will return the wrong module upon import of a second module with > the same name. Yes. I think a first start would be to strip out all of the code that's unused for OSX, maybe renaming it dynload_darwin, and add the extra error checking I posted earlier. [ BTW: I retract that earlier comment about libdl not working -- although it looked from configure that it was buildidng with libdl, the result of the build seems to have still used dynload_next. ] > Maybe someone who is experiencing the problem can comment out > that quick-return section and see whether dynload_next.c then > works as expected? Or will we then immedeately run into flat > namespace problems (two routines called initfoo)? I did a quick rebuild, and what happens with that return commented out is that I now get a duplicate symbol error on trying to import both timemodule.so and mypackage/timemodule.so : two inittime's. Maybe I'll try one of the other suggestions along with that and see what happens. -- Steve From prastawa@cs.unc.edu Sat Jan 26 19:11:39 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Sat, 26 Jan 2002 14:11:39 -0500 Subject: [Pythonmac-SIG] dynload_next In-Reply-To: Message-ID: <8693A317-1290-11D6-B296-000A27942780@cs.unc.edu> --Apple-Mail-1--594638709 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I've got dynload_next working with PyOpenGL! I used libdl's dlopen.c as a reference. The problem appears to be caused by the use of NSLookupAndBindSymbol(). I have switched to using NSLookupSymbolInModule() instead. I also commented out the quick return. I have attached the diff file. It is also available at: http://www.cs.unc.edu/~prastawa/macosx/dynload_next.diff Can any of you try it out and make sure it doesn't break anything? I haven't encountered any problems so far. Marcel --Apple-Mail-1--594638709 Content-Disposition: attachment; filename=dynload_next.diff Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="dynload_next.diff" 33a34 > 123d123 < /* 129d128 < */ 154,164c153,154 < NSDestroyObjectFileImage(image); < < if (newModule == NULL) { < int errNo; < char *fileName, *moreErrorStr; < NSLinkEditErrors c; < errString = "Failure linking new module"; < NSLinkEditError( &c, &errNo, &fileName, &moreErrorStr ); < errString = strcat( fileName, errString ); < errString = strcat( moreErrorStr, errString ); < } --- > if (!newModule) > errString = "Failure linking new module"; 170,172c160 < < theSym = NSLookupSymbolInModule(newModule, funcname); < if (theSym == NULL) { --- > if (!NSIsSymbolNameDefined(funcname)) { 179a168 > theSym = NSLookupAndBindSymbol(funcname); --Apple-Mail-1--594638709-- From Jack.Jansen@oratrix.nl Sat Jan 26 14:26:08 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sat, 26 Jan 2002 15:26:08 +0100 Subject: [Fwd: Re: [Pythonmac-SIG] OS X import bug?] In-Reply-To: <3C52A90C.807@cs.unc.edu> Message-ID: On Saturday, January 26, 2002, at 02:03 PM, Marcel Prastawa wrote: > > Why do some modules need the flat namespace? > > I could only think of several examples: the Mac specific > modules, VTK (a visualization toolkit). Don't know about VTK but the Mac module infrastructure was designed to be linked with all symbols resolved. That's what mactoolboxglue.c in the core is for. -- - 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 sdm7g@Virginia.EDU Sun Jan 27 03:24:04 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Sat, 26 Jan 2002 22:24:04 -0500 (EST) Subject: [Pythonmac-SIG] dynload_next In-Reply-To: <8693A317-1290-11D6-B296-000A27942780@cs.unc.edu> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2138096204-1237206507-1012101844=:13414 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 26 Jan 2002, Marcel Prastawa wrote: > I've got dynload_next working with PyOpenGL! > > I used libdl's dlopen.c as a reference. The problem appears to be caused > by the use of NSLookupAndBindSymbol(). I have switched to using > NSLookupSymbolInModule() instead. I also commented out the quick return. > > I have attached the diff file. It is also available at: > http://www.cs.unc.edu/~prastawa/macosx/dynload_next.diff > > Can any of you try it out and make sure it doesn't break anything? > I haven't encountered any problems so far. > Marcel -- I kept getting error trying to apply the patch, but it was just like one of the things I had already tried which wasn't working for me. Actually I tried two variations -- one the same as yours and another also setting NSLINKMODULE_OPTION_PRIVATE. version 1 didn't fix the problem for me. version 2 didn't work. Did you change the link options to get it to work for you ? ( two-level-namespace ? ) (Also, I believe you used my NSLinkEditError patch, which I'm sorry to say was very sloppily done for debugging purposes. All those strcat()'s onto an existing constant string were a big mistake! ) I have, however, cleaned out some of the cruft and gotten a version that works for me. Could a few of you folks who have had these problems give this a try and tell me if it fixes things for you? This one does set the PRIVATE option -- in the Python module API, all of the exported functions go into the tables built and exported by the init module, and the init function pointer is returned at the end. So it really shouldn't need any global symbols to be bound into the main program. It also seems to work for the Carbon modules. My earlier attempt to use the PRIVATE option failed because the second check for NSIsSymbolNameDefined() took not finding it as a failure and bailed out. I had to cut that test out. That also makes the first test (before the DEBUG) never pass, so the warning doesn't even print for the 'import time, package.time' test. So far, this has worked for me on everything I've thrown at it. If it works for everyone else, I'll permanenly pull out the other non-functional code and submit it. -- Steve Majewski /* Support for dynamic loading of extension modules */ #include "Python.h" #include "importdl.h" #include #define DEBUG 1 #define PRIVATE NSLINKMODULE_OPTION_PRIVATE #define OTHER_OPTIONS NSLINKMODULE_OPTION_BINDNOW|NSLINKMODULE_OPTION_RETURN_ON_ERROR #define LINK_MODULE_OPTIONS (PRIVATE | OTHER_OPTIONS) const struct filedescr _PyImport_DynLoadFiletab[] = { {".so", "rb", C_EXTENSION}, {"module.so", "rb", C_EXTENSION}, {0, 0} }; char errmessage[400]; dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, const char *pathname, FILE *fp) { NSObjectFileImageReturnCode rc; NSObjectFileImage image; NSModule newModule; NSSymbol theSym; const char *errString; dl_funcptr p = NULL; char funcname[258]; PyOS_snprintf(funcname, sizeof(funcname), "_init%.200s", shortname); if (NSIsSymbolNameDefined(funcname)) { #ifdef DEBUG fprintf(stderr,"[!warning] %s already defined.\n", funcname ); #endif } rc = NSCreateObjectFileImageFromFile(pathname, &image); switch(rc) { default: case NSObjectFileImageFailure: case NSObjectFileImageFormat: /* for these a message is printed on stderr by dyld */ errString = "Can't create object file image"; break; case NSObjectFileImageSuccess: errString = NULL; break; case NSObjectFileImageInappropriateFile: errString = "Inappropriate file type for dynamic loading"; break; case NSObjectFileImageArch: errString = "Wrong CPU type in object file"; break; case NSObjectFileImageAccess: errString = "Can't read object file (no access)"; break; } if (errString == NULL) { newModule = NSLinkModule(image, pathname,LINK_MODULE_OPTIONS); if (!newModule) { int errNo; char *filename, *errinfo; NSLinkEditErrors c; errString = "Failure linking new module"; NSLinkEditError( &c, &errNo, &filename, &errinfo ); sprintf( errmessage, "%s. %s\n%s", errString, filename, errinfo ); errString = errmessage; } } if (errString != NULL) { PyErr_SetString(PyExc_ImportError, errString); return NULL; } #ifdef NONONO if (!NSIsSymbolNameDefined(funcname)) { /* UnlinkModule() isn't implemented in current versions, but calling it does no harm */ NSUnLinkModule(newModule, FALSE); PyErr_Format(PyExc_ImportError, "Loaded module does not contain symbol %.200s", funcname); return NULL; } #endif /* theSym = NSLookupAndBindSymbol(funcname); */ theSym = NSLookupSymbolInModule(newModule,funcname); p = (dl_funcptr)NSAddressOfSymbol(theSym); return p; } ---2138096204-1237206507-1012101844=:13414 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dynload_next.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dynload_next.c" DQovKiBTdXBwb3J0IGZvciBkeW5hbWljIGxvYWRpbmcgb2YgZXh0ZW5zaW9u IG1vZHVsZXMgKi8NCg0KI2luY2x1ZGUgIlB5dGhvbi5oIg0KI2luY2x1ZGUg ImltcG9ydGRsLmgiDQoNCiNpbmNsdWRlIDxtYWNoLW8vZHlsZC5oPg0KDQoj ZGVmaW5lIERFQlVHIDENCiNkZWZpbmUgUFJJVkFURSBOU0xJTktNT0RVTEVf T1BUSU9OX1BSSVZBVEUNCiNkZWZpbmUgT1RIRVJfT1BUSU9OUyAgTlNMSU5L TU9EVUxFX09QVElPTl9CSU5ETk9XfE5TTElOS01PRFVMRV9PUFRJT05fUkVU VVJOX09OX0VSUk9SDQojZGVmaW5lIExJTktfTU9EVUxFX09QVElPTlMgIChQ UklWQVRFIHwgT1RIRVJfT1BUSU9OUykNCg0KY29uc3Qgc3RydWN0IGZpbGVk ZXNjciBfUHlJbXBvcnRfRHluTG9hZEZpbGV0YWJbXSA9IHsNCgl7Ii5zbyIs ICJyYiIsIENfRVhURU5TSU9OfSwNCgl7Im1vZHVsZS5zbyIsICJyYiIsIENf RVhURU5TSU9OfSwNCgl7MCwgMH0NCn07DQoNCmNoYXIgZXJybWVzc2FnZVs0 MDBdOw0KDQpkbF9mdW5jcHRyIF9QeUltcG9ydF9HZXREeW5Mb2FkRnVuYyhj b25zdCBjaGFyICpmcW5hbWUsIGNvbnN0IGNoYXIgKnNob3J0bmFtZSwNCgkJ CQkgICAgY29uc3QgY2hhciAqcGF0aG5hbWUsIEZJTEUgKmZwKQ0Kew0KDQoJ TlNPYmplY3RGaWxlSW1hZ2VSZXR1cm5Db2RlIHJjOw0KCU5TT2JqZWN0Rmls ZUltYWdlIGltYWdlOw0KCU5TTW9kdWxlIG5ld01vZHVsZTsNCglOU1N5bWJv bCB0aGVTeW07DQoJY29uc3QgY2hhciAqZXJyU3RyaW5nOw0KDQoJZGxfZnVu Y3B0ciBwID0gTlVMTDsNCgljaGFyIGZ1bmNuYW1lWzI1OF07DQoNCglQeU9T X3NucHJpbnRmKGZ1bmNuYW1lLCBzaXplb2YoZnVuY25hbWUpLCAiX2luaXQl LjIwMHMiLCBzaG9ydG5hbWUpOw0KCQ0KCWlmIChOU0lzU3ltYm9sTmFtZURl ZmluZWQoZnVuY25hbWUpKSB7DQojaWZkZWYgREVCVUcNCgkgIGZwcmludGYo c3RkZXJyLCJbIXdhcm5pbmddICVzIGFscmVhZHkgZGVmaW5lZC5cbiIsIGZ1 bmNuYW1lICk7DQojZW5kaWYNCgl9DQoNCglyYyA9IE5TQ3JlYXRlT2JqZWN0 RmlsZUltYWdlRnJvbUZpbGUocGF0aG5hbWUsICZpbWFnZSk7DQoJc3dpdGNo KHJjKSB7DQoJICAgIGRlZmF1bHQ6DQoJICAgIGNhc2UgTlNPYmplY3RGaWxl SW1hZ2VGYWlsdXJlOg0KCSAgICBjYXNlIE5TT2JqZWN0RmlsZUltYWdlRm9y bWF0Og0KCSAgICAvKiBmb3IgdGhlc2UgYSBtZXNzYWdlIGlzIHByaW50ZWQg b24gc3RkZXJyIGJ5IGR5bGQgKi8NCgkJZXJyU3RyaW5nID0gIkNhbid0IGNy ZWF0ZSBvYmplY3QgZmlsZSBpbWFnZSI7DQoJCWJyZWFrOw0KCSAgICBjYXNl IE5TT2JqZWN0RmlsZUltYWdlU3VjY2VzczoNCgkJZXJyU3RyaW5nID0gTlVM TDsNCgkJYnJlYWs7DQoJICAgIGNhc2UgTlNPYmplY3RGaWxlSW1hZ2VJbmFw cHJvcHJpYXRlRmlsZToNCgkJZXJyU3RyaW5nID0gIkluYXBwcm9wcmlhdGUg ZmlsZSB0eXBlIGZvciBkeW5hbWljIGxvYWRpbmciOw0KCQlicmVhazsNCgkg ICAgY2FzZSBOU09iamVjdEZpbGVJbWFnZUFyY2g6DQoJCWVyclN0cmluZyA9 ICJXcm9uZyBDUFUgdHlwZSBpbiBvYmplY3QgZmlsZSI7DQoJCWJyZWFrOw0K CSAgICBjYXNlIE5TT2JqZWN0RmlsZUltYWdlQWNjZXNzOg0KCQllcnJTdHJp bmcgPSAiQ2FuJ3QgcmVhZCBvYmplY3QgZmlsZSAobm8gYWNjZXNzKSI7DQoJ CWJyZWFrOw0KCX0NCglpZiAoZXJyU3RyaW5nID09IE5VTEwpIHsNCgkgIG5l d01vZHVsZSA9IE5TTGlua01vZHVsZShpbWFnZSwgcGF0aG5hbWUsTElOS19N T0RVTEVfT1BUSU9OUyk7DQoJICAgIGlmICghbmV3TW9kdWxlKSB7DQoJICAg ICAgaW50IGVyck5vOw0KCSAgICAgIGNoYXIgKmZpbGVuYW1lLCAqZXJyaW5m bzsNCgkgICAgICBOU0xpbmtFZGl0RXJyb3JzIGM7DQoJICAgICAgZXJyU3Ry aW5nID0gIkZhaWx1cmUgbGlua2luZyBuZXcgbW9kdWxlIjsNCgkgICAgICBO U0xpbmtFZGl0RXJyb3IoICZjLCAmZXJyTm8sICZmaWxlbmFtZSwgJmVycmlu Zm8gKTsNCgkgICAgICBzcHJpbnRmKCBlcnJtZXNzYWdlLCAiJXMuICVzXG4l cyIsDQoJCSAgICAgICBlcnJTdHJpbmcsIGZpbGVuYW1lLCBlcnJpbmZvICk7 DQoJICAgICAgZXJyU3RyaW5nID0gZXJybWVzc2FnZTsNCgkgICAgfQ0KCX0N CglpZiAoZXJyU3RyaW5nICE9IE5VTEwpIHsNCgkJUHlFcnJfU2V0U3RyaW5n KFB5RXhjX0ltcG9ydEVycm9yLCBlcnJTdHJpbmcpOw0KCQlyZXR1cm4gTlVM TDsNCgl9DQojaWZkZWYgTk9OT05PDQoJaWYgKCFOU0lzU3ltYm9sTmFtZURl ZmluZWQoZnVuY25hbWUpKSB7DQoJCS8qIFVubGlua01vZHVsZSgpIGlzbid0 IGltcGxlbWVudGVkIGluIGN1cnJlbnQgdmVyc2lvbnMsIA0KCQkgICBidXQg Y2FsbGluZyBpdCBkb2VzIG5vIGhhcm0gKi8NCgkJTlNVbkxpbmtNb2R1bGUo bmV3TW9kdWxlLCBGQUxTRSk7DQoJCVB5RXJyX0Zvcm1hdChQeUV4Y19JbXBv cnRFcnJvciwNCgkJCSAgICAgIkxvYWRlZCBtb2R1bGUgZG9lcyBub3QgY29u dGFpbiBzeW1ib2wgJS4yMDBzIiwNCgkJCSAgICAgZnVuY25hbWUpOw0KCQly ZXR1cm4gTlVMTDsNCgl9DQojZW5kaWYNCgkvKgl0aGVTeW0gPSBOU0xvb2t1 cEFuZEJpbmRTeW1ib2woZnVuY25hbWUpOyAqLw0KCXRoZVN5bSA9IE5TTG9v a3VwU3ltYm9sSW5Nb2R1bGUobmV3TW9kdWxlLGZ1bmNuYW1lKTsNCglwID0g KGRsX2Z1bmNwdHIpTlNBZGRyZXNzT2ZTeW1ib2wodGhlU3ltKTsNCg0KCXJl dHVybiBwOw0KfQ0KDQo= ---2138096204-1237206507-1012101844=:13414-- From terabaap@yumpee.org Sun Jan 27 06:30:27 2002 From: terabaap@yumpee.org (Manoj Plakal) Date: Sun, 27 Jan 2002 00:30:27 -0600 Subject: [Pythonmac-SIG] Re: [wxPython-mac] Menus for wxPythonMac References: <054801c196f8$348f8000$6401a8c0@cj622768a> <021001c19714$50414740$0214a8c0@Rogue> Message-ID: <3C539E83.6060804@yumpee.org> Robin Dunn wrote: >>Also, when I run the script it does not open as a separate application in >>OS X. All windows are listed as child windows of the Python application. I'm >>wondering if these two issues are related. wxPython may not be able to >>modify Python's menus, and since it does not have its own application, it >>has no way of showing its own menus. Does this make sense? I admit I'm >>pretty new to Mac programming, and as such I'm a bit stuck as to what can >>be done about this problem. Any help would be appreciated! >> > > An approach that I've been thinking of trying is to build a wxMac C++ > application that embeds Python, rather than a standard Python extension > module. This app can then do the housework necessary to be a well behaved > Mac app, and then hand off to the embedded Python to run the main wxPython > script. I havn't had much time lately to do more than think about this, > perhaps if you've got the time you could try it? Any more knowledgable > people have comments about this approach? Has there been any thoughts on this idea of using a wxMac app which loads Python and wxPython, rather than running Python with a script parameter? Would it then be easier to have a menubar and your own dock icon (bouncing during launch etc) so that wxPython apps look like normal OS X apps? The wxMac demos seem to work fine (with dock icons and menubars). If this approach is not feasible and we stick to running Python.app with a script, is there a way to change the dock icon (from Python's icon) within wxPython? Manoj From prastawa@cs.unc.edu Sun Jan 27 15:17:05 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Sun, 27 Jan 2002 10:17:05 -0500 (EST) Subject: [Pythonmac-SIG] dynload_next In-Reply-To: Message-ID: On Sat, 26 Jan 2002, Steven Majewski wrote: > Marcel -- I kept getting error trying to apply the patch, but it > was just like one of the things I had already tried which wasn't > working for me. Actually I tried two variations -- one the same > as yours and another also setting NSLINKMODULE_OPTION_PRIVATE. > version 1 didn't fix the problem for me. > version 2 didn't work. Hi Steve, NSLINKMODULE_OPTION_PRIVATE breaks VTK. The wrapper is made of a set of flat namespace bundles that have undefined symbols (defined in other bundles). A global symbol table is needed for this case, the module init function does not export C/C++ functions and classes. Is the PRIVATE flag really necessary? I think we could just keep it disabled. > Did you change the link options to get it to work for you ? > ( two-level-namespace ? ) I am not sure I understand the problem. How exactly did it fail? > (Also, I believe you used my NSLinkEditError patch, which I'm sorry to say > was very sloppily done for debugging purposes. All those strcat()'s > onto an existing constant string were a big mistake! ) Oh, it was still very useful. I have spent a lot of time doing guesswork with the cryptic "Failure linking new module" error message. Maybe we could just use a large string buffer and strncat() for now? Some message is better than nothing. Marcel From bas@andrew.cmu.edu Sun Jan 27 15:47:21 2002 From: bas@andrew.cmu.edu (Bruce Sherwood) Date: Sun, 27 Jan 2002 10:47:21 -0500 Subject: [Pythonmac-SIG] Built Python (fwd) Message-ID: <2811127100.1012128441@HYPERON.REM.CMU.EDU> Many thanks to our call for help. As you'll see below, David Andersen found that most of our problems seem to have been caused by something entirely different..... Bruce Sherwood ---------- Forwarded Message ---------- Date: Saturday, January 26, 2002 11:10 -0500 From: David Andersen To: Bruce Sherwood Subject: Built Python > The problem seems to have been due to compiling with CodeWarrior 6 before > switching to CodeWarrior 7. > > I downloaded fresh copies of the Python source, the GUSI/Carbon stuff and > deleted CodeWarrior 6 (except for a few files it said I didn't have > adequate permissions for). > > I was able to build PythonCore except for errors referring to > GUSI_MSL.CW7.PPC.Lib and GUSI_Core.CW7.PPC.Lib. I then built the two > *.CW7 GUSI libraries with no errors, and was then able to build Python. > > ---------- End Forwarded Message ---------- From sdm7g@Virginia.EDU Sun Jan 27 16:13:16 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Sun, 27 Jan 2002 11:13:16 -0500 (EST) Subject: [Pythonmac-SIG] dynload_next In-Reply-To: Message-ID: On Sun, 27 Jan 2002, Marcel Prastawa wrote: > NSLINKMODULE_OPTION_PRIVATE breaks VTK. The wrapper is made of a set of > flat namespace bundles that have undefined symbols (defined in other > bundles). A global symbol table is needed for this case, the module init > function does not export C/C++ functions and classes. > > Is the PRIVATE flag really necessary? I think we could just keep it > disabled. Without the PRIVATE flag, I still get duplicate symbol errors on trying to import both time and package.time bundles. > > (Also, I believe you used my NSLinkEditError patch, which I'm sorry to say > > was very sloppily done for debugging purposes. All those strcat()'s > > onto an existing constant string were a big mistake! ) > > Oh, it was still very useful. I have spent a lot of time doing guesswork > with the cryptic "Failure linking new module" error message. Maybe we > could just use a large string buffer and strncat() for now? Some message > is better than nothing. The version included in the last post fixes the error reporting -- it has an external message buffer. If you define PRIVATE to be 0, it should be functionally equivalent to your earlier patched code. -- Steve Majewski From prastawa@cs.unc.edu Sun Jan 27 17:03:54 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Sun, 27 Jan 2002 12:03:54 -0500 Subject: [Pythonmac-SIG] dynload_next References: Message-ID: <3C5432FA.9080107@cs.unc.edu> Steven Majewski wrote: > Without the PRIVATE flag, I still get duplicate symbol errors on > trying to import both time and package.time bundles. Ah.. I built PyOpenGL as a two-level extension, I've never actually tested this case. Using libdl seems more and more like a good idea to me. It has solved the issues we are dealing with. The 'sys' module also provides a Python interface to modify the dlopen flags, the setdlopenflags() function (so if needed, we can specify GLOBAL instead of PRIVATE dynamically). If we were to stick with dynload_next, I guess we could write a Python interface that would enable/disable the PRIVATE flag (and other flags too). Something like sys.setNSLoadFlags() or maybe sys.setdyldflags()? > The version included in the last post fixes the error reporting -- it > has an external message buffer. Oops, sorry I missed it. BTW, shouldn't we use snprintf(errMessage, sizeof(errMessage), ...) instead of plain sprintf()? Is 400 characters enough? Maybe we need more for debugging, 2048? 8192? :) The message could get really long when we have tons of undefined symbols. Marcel From sdm7g@Virginia.EDU Sun Jan 27 18:26:34 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Sun, 27 Jan 2002 13:26:34 -0500 (EST) Subject: [Pythonmac-SIG] dynload_next In-Reply-To: <3C5432FA.9080107@cs.unc.edu> Message-ID: On Sun, 27 Jan 2002, Marcel Prastawa wrote: > > > The version included in the last post fixes the error reporting -- it > > has an external message buffer. > > > Oops, sorry I missed it. > > BTW, shouldn't we use snprintf(errMessage, sizeof(errMessage), ...) > instead of plain sprintf()? Is 400 characters enough? Maybe we need more > for debugging, 2048? 8192? :) The message could get really long when we > have tons of undefined symbols. > Yes. Actually there's a PyOS_snprintf that's used elsewhere -- i assume that supports the same interface where snprintf isn't available. That's in the next version. BTW: Did you acatually test that dynload_next with VTK ? I would think that what you describe is similar to the case for the Carbon libs, which do appear to work. (At least I don't get any errors on loading them -- I'm trying to merge the resources so I can test them more completely.) Maybe Jack can comment on how the Carbon modules are cross linked now ? -- Steve From Jack.Jansen@oratrix.nl Sun Jan 27 19:51:29 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sun, 27 Jan 2002 20:51:29 +0100 Subject: [Pythonmac-SIG] Re: Couple of issues with Unix Python on Mac In-Reply-To: <3C5397A6.1040609@yumpee.org> Message-ID: <41D5067A-135F-11D6-9CBF-003065517236@oratrix.nl> On Sunday, January 27, 2002, at 07:01 AM, Manoj Plakal wrote: >>> - The installed Python.app has a dock >>> icon when it runs but no (blank) >>> menubars. Is this normal? I get >>> menubars fine with MacPython 2.2 Carbon. >> Right, because the interpreter is currently only that, an >> interpreter with the .app glue around it (and a main program >> that understands enough AppleEvents to do drag and drop). The >> script is currently responsible for doing menu bar stuff. >> What I envision is that later (for 2.3?) the default main >> program, i.e. if you doubleclick the .app, is going to be the >> IDE. > > > You mean the script has to explicitly > create a menubar? I tried running > EasyDialogs.py as well as some > console-I/O scripts and the menubar > remained blank. Moreover, the whole > left side of the menubar is blank, > *including* the Apple menu which disappears ... Well, one of the things I would like to fix for MachoPython, which has always been a problem with MacPython, is the menubar/event handling code. MacPython did (in C) some minimal event handling, which meant that Python-coded frameworks (Framework, W, the IDE) always had to cater for this. MacPython didn't have much choice, really: because it had the console window it needed an event loop. For MachoPython the situation is different. console-based scripts can be run with the commandline interpreter, so there's little reason to have something similar to the MacPython PythonInterpreter. And if people do want to run scripts in a windowing environment they're much better off with the IDE. And if someone really really wants the functionality of PythonInterpreter in MachoPython it shouldn't be more than a 200 line Python program to get the functionality. There are however two issues that need some thought. One is the creation of the menubar (only the creation, not the handling of it), it could be argued that Python.app should do this. Another one is the handling of the Quit AppleEvent. It might be a good idea if Python.app registered a handler for this, so that at least command-Q (and shutdown, and other similar situations) would work. But for this latter one I don't know how doable this is if Python.app doesn't have a fullblown event loop. Maybe doable, with Carbon Events, maybe not. If someone wants to look into this that would be nice. And even for these two things I think they shouold be handled by Python code, not C code. It's easy enough to add an init script to Python.app, and by doing it that way applets that want to do their own menubar handling could simply not include the init 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 prastawa@cs.unc.edu Sun Jan 27 20:15:32 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Sun, 27 Jan 2002 15:15:32 -0500 Subject: [Pythonmac-SIG] dynload_next References: Message-ID: <3C545FE4.6040509@cs.unc.edu> Steven Majewski wrote: > BTW: Did you acatually test that dynload_next with VTK ? I would think > that what you describe is similar to the case for the Carbon libs, which > do appear to work. (At least I don't get any errors on loading them -- > I'm trying to merge the resources so I can test them more completely.) Yes. With the PRIVATE flag set, some of the bundles would not be able to find the symbols in the other bundles. VTK is a cross-platform library, and it (sort of) assumes that the Python extensions are libraries. This is true for ELF systems: http://fink.sourceforge.net/doc/porting/shared.php Can we build the Python extensions as dynamic libraries instead of bundles? I think I saw several NeXT functions that might be useful for doing the loads (NSAddImage and company). There may be problems, though. The note from Fink claims that dynamic libraries cannot be unloaded. Any thoughts? I am clueless about these NeXT-ish things... Now, this is a bit off-topic. Is there a way to link a bundle to another bundle? If there's a way to tell bundle B to go look up some symbols in bundle A, it would really help. I think that there is none, but I want to pass this question to the list just to make sure. Marcel From Jack.Jansen@oratrix.nl Sun Jan 27 20:24:28 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sun, 27 Jan 2002 21:24:28 +0100 Subject: [Pythonmac-SIG] dynload_next In-Reply-To: Message-ID: On Sunday, January 27, 2002, at 07:26 PM, Steven Majewski wrote: > BTW: Did you acatually test that dynload_next with VTK ? I would think > that what you describe is similar to the case for the Carbon > libs, which > do appear to work. (At least I don't get any errors on loading them -- > I'm trying to merge the resources so I can test them more completely.) > > Maybe Jack can comment on how the Carbon modules are cross linked now ? I used my python-dev membership to smuggle a set of glue routines into the core:-) This glue code can be found in Python/mactoolboxglue.c. The CPP magic is in mactoolboxglue.h. The main thing I needed was that the modules need each others' _New() and _Convert() routines (the routines you pass to PyArg_Parse "O&" format). Whereas in MacPython 2.0 the various modules used to be linked against each other in devious ways (and it all worked because the shared libraries lived in a single folder so the Code Fragment Manager would load dependent modules as needed) the new setup is that each module's init routine registers its _New and _Convert routines with mactoolboxglue.c. If you use an _New or _Convert from another module you're actually calling a routine in mactoolboxglue. If the routine you want to call is already registered it's a quick indirection through a function pointer. If it isn't registered yet we import the module in which the routine we need is defined (which should then register the routine in its init routine). A fallback solution I had in mind (in case my mod to the core wasn't accepted) which might work for VTK was to put this glue code in a separate shared library, and then link all my modules against it. For my problem this wouldn't have been a 100% solution (there's a bit of other stuff in mactoolboxglue.c as well), but for the problem of getting access at each others routine pointers it would be. -- - 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.nl Sun Jan 27 21:09:29 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sun, 27 Jan 2002 22:09:29 +0100 Subject: [Pythonmac-SIG] Flat namespace problem Message-ID: <27013DF7-136A-11D6-9CBF-003065517236@oratrix.nl> I was going to jump in and look at getting rid of the flat namespace problem when I noticed that if you build a framework based Python (configure --enable-framework) you already get a two-level namespace. Before I go fixing the wrong problem, could someone who has the flat namespace problem please try and build a framework Python, and check that the name collision doesn't happen then? Also, if my understanding is right, this would mean that VTK can't be built with a framework-based Python. At least, not without fiddling LDSHARED in your setup.py. Is that correct? -- - 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 prastawa@cs.unc.edu Sun Jan 27 21:40:53 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Sun, 27 Jan 2002 16:40:53 -0500 Subject: [Pythonmac-SIG] Flat namespace problem References: <27013DF7-136A-11D6-9CBF-003065517236@oratrix.nl> Message-ID: <3C5473E5.8040804@cs.unc.edu> Jack Jansen wrote: > Also, if my understanding is right, this would mean that VTK can't be > built with a framework-based Python. At least, not without fiddling > LDSHARED in your setup.py. Is that correct? VTK is not built with distutils. It has its own Python wrapper generator and Makefile generator. It shouldn't have any issues with a two-level namespace Python. Marcel From bobsavage@mac.com Sun Jan 27 21:45:55 2002 From: bobsavage@mac.com (Bob Savage) Date: Sun, 27 Jan 2002 15:45:55 -0600 Subject: [Pythonmac-SIG] Re: Couple of issues with Unix Python on Mac In-Reply-To: <41D5067A-135F-11D6-9CBF-003065517236@oratrix.nl> Message-ID: on 1/27/02 1:51 PM, Jack Jansen wrote: > if someone really really wants the functionality of > PythonInterpreter in MachoPython it shouldn't be more than a 200 > line Python program to get the functionality. Or you could save the following into a file called "Python Interpreter.term". Double click on it and you have a windowed Python interpreter! :) (Note, it might be that the text editor you used to create the file tries to claim ownership of the file (crator nd type), in which case you will need to change it with "Show Info" -> "Open with Application" in the Finder (set it to Terminal.app). Best, Bob ---- cut ---- WindowSettings AutoFocus YES Autowrap YES Bell YES BlinkCursor YES Columns 80 CursorShape 0 CustomTitle Python Interpretor DisableAnsiColors NO DoubleBold YES ExecutionString python; exit FontHeightSpacing 1 FontWidthSpacing 1 IsMiniaturized NO Keypad NO Meta -1 NSFixedPitchFont Monaco NSFixedPitchFontSize 1.000000e+01 Rows 24 SaveLines 10000 Scrollback YES Shell /bin/tcsh ShellExitAction 2 SourceDotLogin NO StrictEmulation NO TerminalOpaqueness 8.500000e-01 TextColors 0.949 0.769 0.042 0.000 0.000 0.000 0.934 0.222 0.103 0.934 0.222 0.103 0.000 0.000 0.000 0.949 0.769 0.042 0.185 0.222 0.372 0.344 0.120 0.311 TitleBits 1 Translate YES WinLocULY 747 WinLocX 342 WinLocY 0 From Jack.Jansen@oratrix.nl Sun Jan 27 22:35:39 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sun, 27 Jan 2002 23:35:39 +0100 Subject: [Pythonmac-SIG] Serious bug with FSSpecs (and GUSI, and MacPython) on OSX Message-ID: <30659C20-1376-11D6-9305-003065517236@oratrix.nl> Folks, I need some help. It turns out that the bug Russell Owen posted here before (505562 in sourceforge) that BuildApplet can destroy sourcefiles has even more far reaching consequences. The problem isn't with BuildApplet per se, the problem is with the way MacOSX creates FSSpecs for files with names that are too long (more than 32 chars) to represent in an FSSpec. What happens is that the first 22 chars are used, then #XXXXX is appended (where the XXXXX is a number unique to the file) and then the original extension is appended (don't know what happened if the original extension was more than 3 chars). But, and this is the bad news, this extension is *not* checked if you create an FSSpec by hand. So, if your original, existing, file has a ".py" extension you can create a valid FSSpec, pointing to the same file, without the ".py" extension. Or with a ".c" extension, or anything else. The other part of the bad news is that GUSI is completely FSSpec-based. Hence, when BuildApplet gets a ".py" file, creates the applet name by stripping the .py and then does try: os.remove(outputfile) except .... The os.remove() succeeds and happily removes your sourcefile! -- - 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 prastawa@cs.unc.edu Sun Jan 27 21:42:33 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Sun, 27 Jan 2002 16:42:33 -0500 (EST) Subject: [Pythonmac-SIG] dynload_next In-Reply-To: Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1744662849-2028139461-1012167753=:4093 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 27 Jan 2002, Jack Jansen wrote: > A fallback solution I had in mind (in case my mod to the core > wasn't accepted) which might work for VTK was to put this glue > code in a separate shared library, and then link all my modules > against it. For my problem this wouldn't have been a 100% > solution (there's a bit of other stuff in mactoolboxglue.c as > well), but for the problem of getting access at each others > routine pointers it would be. The problem with building a wrapper is that VTK is a huge C++ library, where the Python wrappers are built automatically. I could do it, but it would be painful. Also, if/when the API changes I will probably bang my head against the wall, repeatedly. :) I've hacked the sys module. Now I could do something like: import sys sys.setdyldpublic() ... import things globally ... sys.setdyldprivate() # revert to default, NSLINKMODULE_OPTION_PRIVATE set The intrepreter state already has a slot for dlopen flags so I "borrowed" it for dyld. What do you guys think? FWIW, I haven't tested this one with VTK yet, only with a dummy case (I am doing things through SSH now). I've attached the source files, I didn't generate patches because our code may not be in sync (Steve had problems with my earlier patch). Marcel ---1744662849-2028139461-1012167753=:4093 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sysmodule.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="sysmodule.c" DQovKiBTeXN0ZW0gbW9kdWxlICovDQoNCi8qDQpWYXJpb3VzIGJpdHMgb2Yg aW5mb3JtYXRpb24gdXNlZCBieSB0aGUgaW50ZXJwcmV0ZXIgYXJlIGNvbGxl Y3RlZCBpbg0KbW9kdWxlICdzeXMnLg0KRnVuY3Rpb24gbWVtYmVyOg0KLSBl eGl0KHN0cyk6IHJhaXNlIFN5c3RlbUV4aXQNCkRhdGEgbWVtYmVyczoNCi0g c3RkaW4sIHN0ZG91dCwgc3RkZXJyOiBzdGFuZGFyZCBmaWxlIG9iamVjdHMN Ci0gbW9kdWxlczogdGhlIHRhYmxlIG9mIG1vZHVsZXMgKGRpY3Rpb25hcnkp DQotIHBhdGg6IG1vZHVsZSBzZWFyY2ggcGF0aCAobGlzdCBvZiBzdHJpbmdz KQ0KLSBhcmd2OiBzY3JpcHQgYXJndW1lbnRzIChsaXN0IG9mIHN0cmluZ3Mp DQotIHBzMSwgcHMyOiBvcHRpb25hbCBwcmltYXJ5IGFuZCBzZWNvbmRhcnkg cHJvbXB0cyAoc3RyaW5ncykNCiovDQoNCiNpbmNsdWRlICJQeXRob24uaCIN CiNpbmNsdWRlICJjb21waWxlLmgiDQojaW5jbHVkZSAiZnJhbWVvYmplY3Qu aCINCg0KI2luY2x1ZGUgIm9zZGVmcy5oIg0KDQojaWZkZWYgTVNfQ09SRURM TA0KZXh0ZXJuIHZvaWQgKlB5V2luX0RMTGhNb2R1bGU7DQovKiBBIHN0cmlu ZyBsb2FkZWQgZnJvbSB0aGUgRExMIGF0IHN0YXJ0dXA6ICovDQpleHRlcm4g Y29uc3QgY2hhciAqUHlXaW5fRExMVmVyc2lvblN0cmluZzsNCiNlbmRpZg0K DQojaWZkZWYgV0lUSF9EWUxEDQojaW5jbHVkZSA8bWFjaC1vL2R5bGQuaD4N CiNlbmRpZg0KDQojaWZkZWYgSEFWRV9VTklTVERfSA0KI2luY2x1ZGUgPHVu aXN0ZC5oPg0KI2VuZGlmDQoNClB5T2JqZWN0ICoNClB5U3lzX0dldE9iamVj dChjaGFyICpuYW1lKQ0Kew0KCVB5VGhyZWFkU3RhdGUgKnRzdGF0ZSA9IFB5 VGhyZWFkU3RhdGVfR2V0KCk7DQoJUHlPYmplY3QgKnNkID0gdHN0YXRlLT5p bnRlcnAtPnN5c2RpY3Q7DQoJaWYgKHNkID09IE5VTEwpDQoJCXJldHVybiBO VUxMOw0KCXJldHVybiBQeURpY3RfR2V0SXRlbVN0cmluZyhzZCwgbmFtZSk7 DQp9DQoNCkZJTEUgKg0KUHlTeXNfR2V0RmlsZShjaGFyICpuYW1lLCBGSUxF ICpkZWYpDQp7DQoJRklMRSAqZnAgPSBOVUxMOw0KCVB5T2JqZWN0ICp2ID0g UHlTeXNfR2V0T2JqZWN0KG5hbWUpOw0KCWlmICh2ICE9IE5VTEwgJiYgUHlG aWxlX0NoZWNrKHYpKQ0KCQlmcCA9IFB5RmlsZV9Bc0ZpbGUodik7DQoJaWYg KGZwID09IE5VTEwpDQoJCWZwID0gZGVmOw0KCXJldHVybiBmcDsNCn0NCg0K aW50DQpQeVN5c19TZXRPYmplY3QoY2hhciAqbmFtZSwgUHlPYmplY3QgKnYp DQp7DQoJUHlUaHJlYWRTdGF0ZSAqdHN0YXRlID0gUHlUaHJlYWRTdGF0ZV9H ZXQoKTsNCglQeU9iamVjdCAqc2QgPSB0c3RhdGUtPmludGVycC0+c3lzZGlj dDsNCglpZiAodiA9PSBOVUxMKSB7DQoJCWlmIChQeURpY3RfR2V0SXRlbVN0 cmluZyhzZCwgbmFtZSkgPT0gTlVMTCkNCgkJCXJldHVybiAwOw0KCQllbHNl DQoJCQlyZXR1cm4gUHlEaWN0X0RlbEl0ZW1TdHJpbmcoc2QsIG5hbWUpOw0K CX0NCgllbHNlDQoJCXJldHVybiBQeURpY3RfU2V0SXRlbVN0cmluZyhzZCwg bmFtZSwgdik7DQp9DQoNCnN0YXRpYyBQeU9iamVjdCAqDQpzeXNfZGlzcGxh eWhvb2soUHlPYmplY3QgKnNlbGYsIFB5T2JqZWN0ICpvKQ0Kew0KCVB5T2Jq ZWN0ICpvdXRmOw0KCVB5SW50ZXJwcmV0ZXJTdGF0ZSAqaW50ZXJwID0gUHlU aHJlYWRTdGF0ZV9HZXQoKS0+aW50ZXJwOw0KCVB5T2JqZWN0ICptb2R1bGVz ID0gaW50ZXJwLT5tb2R1bGVzOw0KCVB5T2JqZWN0ICpidWlsdGlucyA9IFB5 RGljdF9HZXRJdGVtU3RyaW5nKG1vZHVsZXMsICJfX2J1aWx0aW5fXyIpOw0K DQoJaWYgKGJ1aWx0aW5zID09IE5VTEwpIHsNCgkJUHlFcnJfU2V0U3RyaW5n KFB5RXhjX1J1bnRpbWVFcnJvciwgImxvc3QgX19idWlsdGluX18iKTsNCgkJ cmV0dXJuIE5VTEw7DQoJfQ0KDQoJLyogUHJpbnQgdmFsdWUgZXhjZXB0IGlm IE5vbmUgKi8NCgkvKiBBZnRlciBwcmludGluZywgYWxzbyBhc3NpZ24gdG8g J18nICovDQoJLyogQmVmb3JlLCBzZXQgJ18nIHRvIE5vbmUgdG8gYXZvaWQg cmVjdXJzaW9uICovDQoJaWYgKG8gPT0gUHlfTm9uZSkgew0KCQlQeV9JTkNS RUYoUHlfTm9uZSk7DQoJCXJldHVybiBQeV9Ob25lOw0KCX0NCglpZiAoUHlP YmplY3RfU2V0QXR0clN0cmluZyhidWlsdGlucywgIl8iLCBQeV9Ob25lKSAh PSAwKQ0KCQlyZXR1cm4gTlVMTDsNCglpZiAoUHlfRmx1c2hMaW5lKCkgIT0g MCkNCgkJcmV0dXJuIE5VTEw7DQoJb3V0ZiA9IFB5U3lzX0dldE9iamVjdCgi c3Rkb3V0Iik7DQoJaWYgKG91dGYgPT0gTlVMTCkgew0KCQlQeUVycl9TZXRT dHJpbmcoUHlFeGNfUnVudGltZUVycm9yLCAibG9zdCBzeXMuc3Rkb3V0Iik7 DQoJCXJldHVybiBOVUxMOw0KCX0NCglpZiAoUHlGaWxlX1dyaXRlT2JqZWN0 KG8sIG91dGYsIDApICE9IDApDQoJCXJldHVybiBOVUxMOw0KCVB5RmlsZV9T b2Z0U3BhY2Uob3V0ZiwgMSk7DQoJaWYgKFB5X0ZsdXNoTGluZSgpICE9IDAp DQoJCXJldHVybiBOVUxMOw0KCWlmIChQeU9iamVjdF9TZXRBdHRyU3RyaW5n KGJ1aWx0aW5zLCAiXyIsIG8pICE9IDApDQoJCXJldHVybiBOVUxMOw0KCVB5 X0lOQ1JFRihQeV9Ob25lKTsNCglyZXR1cm4gUHlfTm9uZTsNCn0NCg0Kc3Rh dGljIGNoYXIgZGlzcGxheWhvb2tfZG9jW10gPQ0KImRpc3BsYXlob29rKG9i amVjdCkgLT4gTm9uZVxuIg0KIlxuIg0KIlByaW50IGFuIG9iamVjdCB0byBz eXMuc3Rkb3V0IGFuZCBhbHNvIHNhdmUgaXQgaW4gX19idWlsdGluX18uX1xu IjsNCg0Kc3RhdGljIFB5T2JqZWN0ICoNCnN5c19leGNlcHRob29rKFB5T2Jq ZWN0KiBzZWxmLCBQeU9iamVjdCogYXJncykNCnsNCglQeU9iamVjdCAqZXhj LCAqdmFsdWUsICp0YjsNCglpZiAoIVB5QXJnX1VucGFja1R1cGxlKGFyZ3Ms ICJleGNlcHRob29rIiwgMywgMywgJmV4YywgJnZhbHVlLCAmdGIpKQ0KCQly ZXR1cm4gTlVMTDsNCglQeUVycl9EaXNwbGF5KGV4YywgdmFsdWUsIHRiKTsN CglQeV9JTkNSRUYoUHlfTm9uZSk7DQoJcmV0dXJuIFB5X05vbmU7DQp9DQoN CnN0YXRpYyBjaGFyIGV4Y2VwdGhvb2tfZG9jW10gPQ0KImV4Y2VwdGhvb2so ZXhjdHlwZSwgdmFsdWUsIHRyYWNlYmFjaykgLT4gTm9uZVxuIg0KIlxuIg0K IkhhbmRsZSBhbiBleGNlcHRpb24gYnkgZGlzcGxheWluZyBpdCB3aXRoIGEg dHJhY2ViYWNrIG9uIHN5cy5zdGRlcnIuXG4iOw0KDQpzdGF0aWMgUHlPYmpl Y3QgKg0Kc3lzX2V4Y19pbmZvKFB5T2JqZWN0ICpzZWxmKQ0Kew0KCVB5VGhy ZWFkU3RhdGUgKnRzdGF0ZTsNCgl0c3RhdGUgPSBQeVRocmVhZFN0YXRlX0dl dCgpOw0KCXJldHVybiBQeV9CdWlsZFZhbHVlKA0KCQkiKE9PTykiLA0KCQl0 c3RhdGUtPmV4Y190eXBlICE9IE5VTEwgPyB0c3RhdGUtPmV4Y190eXBlIDog UHlfTm9uZSwNCgkJdHN0YXRlLT5leGNfdmFsdWUgIT0gTlVMTCA/IHRzdGF0 ZS0+ZXhjX3ZhbHVlIDogUHlfTm9uZSwNCgkJdHN0YXRlLT5leGNfdHJhY2Vi YWNrICE9IE5VTEwgPw0KCQkJdHN0YXRlLT5leGNfdHJhY2ViYWNrIDogUHlf Tm9uZSk7DQp9DQoNCnN0YXRpYyBjaGFyIGV4Y19pbmZvX2RvY1tdID0NCiJl eGNfaW5mbygpIC0+ICh0eXBlLCB2YWx1ZSwgdHJhY2ViYWNrKVxuXA0KXG5c DQpSZXR1cm4gaW5mb3JtYXRpb24gYWJvdXQgdGhlIGV4Y2VwdGlvbiB0aGF0 IGlzIGN1cnJlbnRseSBiZWluZyBoYW5kbGVkLlxuXA0KVGhpcyBzaG91bGQg YmUgY2FsbGVkIGZyb20gaW5zaWRlIGFuIGV4Y2VwdCBjbGF1c2Ugb25seS4i Ow0KDQpzdGF0aWMgUHlPYmplY3QgKg0Kc3lzX2V4aXQoUHlPYmplY3QgKnNl bGYsIFB5T2JqZWN0ICphcmdzKQ0Kew0KCS8qIFJhaXNlIFN5c3RlbUV4aXQg c28gY2FsbGVycyBtYXkgY2F0Y2ggaXQgb3IgY2xlYW4gdXAuICovDQoJUHlF cnJfU2V0T2JqZWN0KFB5RXhjX1N5c3RlbUV4aXQsIGFyZ3MpOw0KCXJldHVy biBOVUxMOw0KfQ0KDQpzdGF0aWMgY2hhciBleGl0X2RvY1tdID0NCiJleGl0 KFtzdGF0dXNdKVxuXA0KXG5cDQpFeGl0IHRoZSBpbnRlcnByZXRlciBieSBy YWlzaW5nIFN5c3RlbUV4aXQoc3RhdHVzKS5cblwNCklmIHRoZSBzdGF0dXMg aXMgb21pdHRlZCBvciBOb25lLCBpdCBkZWZhdWx0cyB0byB6ZXJvIChpLmUu LCBzdWNjZXNzKS5cblwNCklmIHRoZSBzdGF0dXMgbnVtZXJpYywgaXQgd2ls bCBiZSB1c2VkIGFzIHRoZSBzeXN0ZW0gZXhpdCBzdGF0dXMuXG5cDQpJZiBp dCBpcyBhbm90aGVyIGtpbmQgb2Ygb2JqZWN0LCBpdCB3aWxsIGJlIHByaW50 ZWQgYW5kIHRoZSBzeXN0ZW1cblwNCmV4aXQgc3RhdHVzIHdpbGwgYmUgb25l IChpLmUuLCBmYWlsdXJlKS4iOw0KDQojaWZkZWYgUHlfVVNJTkdfVU5JQ09E RQ0KDQpzdGF0aWMgUHlPYmplY3QgKg0Kc3lzX2dldGRlZmF1bHRlbmNvZGlu ZyhQeU9iamVjdCAqc2VsZikNCnsNCglyZXR1cm4gUHlTdHJpbmdfRnJvbVN0 cmluZyhQeVVuaWNvZGVfR2V0RGVmYXVsdEVuY29kaW5nKCkpOw0KfQ0KDQpz dGF0aWMgY2hhciBnZXRkZWZhdWx0ZW5jb2RpbmdfZG9jW10gPQ0KImdldGRl ZmF1bHRlbmNvZGluZygpIC0+IHN0cmluZ1xuXA0KXG5cDQpSZXR1cm4gdGhl IGN1cnJlbnQgZGVmYXVsdCBzdHJpbmcgZW5jb2RpbmcgdXNlZCBieSB0aGUg VW5pY29kZSBcblwNCmltcGxlbWVudGF0aW9uLiI7DQoNCnN0YXRpYyBQeU9i amVjdCAqDQpzeXNfc2V0ZGVmYXVsdGVuY29kaW5nKFB5T2JqZWN0ICpzZWxm LCBQeU9iamVjdCAqYXJncykNCnsNCgljaGFyICplbmNvZGluZzsNCglpZiAo IVB5QXJnX1BhcnNlVHVwbGUoYXJncywgInM6c2V0ZGVmYXVsdGVuY29kaW5n IiwgJmVuY29kaW5nKSkNCgkJcmV0dXJuIE5VTEw7DQoJaWYgKFB5VW5pY29k ZV9TZXREZWZhdWx0RW5jb2RpbmcoZW5jb2RpbmcpKQ0KCSAgICAJcmV0dXJu IE5VTEw7DQoJUHlfSU5DUkVGKFB5X05vbmUpOw0KCXJldHVybiBQeV9Ob25l Ow0KfQ0KDQpzdGF0aWMgY2hhciBzZXRkZWZhdWx0ZW5jb2RpbmdfZG9jW10g PQ0KInNldGRlZmF1bHRlbmNvZGluZyhlbmNvZGluZylcblwNClxuXA0KU2V0 IHRoZSBjdXJyZW50IGRlZmF1bHQgc3RyaW5nIGVuY29kaW5nIHVzZWQgYnkg dGhlIFVuaWNvZGUgaW1wbGVtZW50YXRpb24uIjsNCg0KI2VuZGlmDQoNCi8q DQogKiBDYWNoZWQgaW50ZXJuZWQgc3RyaW5nIG9iamVjdHMgdXNlZCBmb3Ig Y2FsbGluZyB0aGUgcHJvZmlsZSBhbmQNCiAqIHRyYWNlIGZ1bmN0aW9ucy4g IEluaXRpYWxpemVkIGJ5IHRyYWNlX2luaXQoKS4NCiAqLw0Kc3RhdGljIFB5 T2JqZWN0ICp3aGF0c3RyaW5nc1s0XSA9IHtOVUxMLCBOVUxMLCBOVUxMLCBO VUxMfTsNCg0Kc3RhdGljIGludA0KdHJhY2VfaW5pdCh2b2lkKQ0Kew0KCXN0 YXRpYyBjaGFyICp3aGF0bmFtZXNbNF0gPSB7ImNhbGwiLCAiZXhjZXB0aW9u IiwgImxpbmUiLCAicmV0dXJuIn07DQoJUHlPYmplY3QgKm5hbWU7DQoJaW50 IGk7DQoJZm9yIChpID0gMDsgaSA8IDQ7ICsraSkgew0KCQlpZiAod2hhdHN0 cmluZ3NbaV0gPT0gTlVMTCkgew0KCQkJbmFtZSA9IFB5U3RyaW5nX0ludGVy bkZyb21TdHJpbmcod2hhdG5hbWVzW2ldKTsNCgkJCWlmIChuYW1lID09IE5V TEwpDQoJCQkJcmV0dXJuIC0xOw0KCQkJd2hhdHN0cmluZ3NbaV0gPSBuYW1l Ow0KICAgICAgICAgICAgICAgIH0NCgl9DQoJcmV0dXJuIDA7DQp9DQoNCg0K c3RhdGljIFB5T2JqZWN0ICoNCmNhbGxfdHJhbXBvbGluZShQeVRocmVhZFN0 YXRlICp0c3RhdGUsIFB5T2JqZWN0KiBjYWxsYmFjaywNCgkJUHlGcmFtZU9i amVjdCAqZnJhbWUsIGludCB3aGF0LCBQeU9iamVjdCAqYXJnKQ0Kew0KCVB5 T2JqZWN0ICphcmdzID0gUHlUdXBsZV9OZXcoMyk7DQoJUHlPYmplY3QgKndo YXRzdHI7DQoJUHlPYmplY3QgKnJlc3VsdDsNCg0KCWlmIChhcmdzID09IE5V TEwpDQoJCXJldHVybiBOVUxMOw0KCVB5X0lOQ1JFRihmcmFtZSk7DQoJd2hh dHN0ciA9IHdoYXRzdHJpbmdzW3doYXRdOw0KCVB5X0lOQ1JFRih3aGF0c3Ry KTsNCglpZiAoYXJnID09IE5VTEwpDQoJCWFyZyA9IFB5X05vbmU7DQoJUHlf SU5DUkVGKGFyZyk7DQoJUHlUdXBsZV9TRVRfSVRFTShhcmdzLCAwLCAoUHlP YmplY3QgKilmcmFtZSk7DQoJUHlUdXBsZV9TRVRfSVRFTShhcmdzLCAxLCB3 aGF0c3RyKTsNCglQeVR1cGxlX1NFVF9JVEVNKGFyZ3MsIDIsIGFyZyk7DQoN CgkvKiBjYWxsIHRoZSBQeXRob24tbGV2ZWwgZnVuY3Rpb24gKi8NCglQeUZy YW1lX0Zhc3RUb0xvY2FscyhmcmFtZSk7DQoJcmVzdWx0ID0gUHlFdmFsX0Nh bGxPYmplY3QoY2FsbGJhY2ssIGFyZ3MpOw0KCVB5RnJhbWVfTG9jYWxzVG9G YXN0KGZyYW1lLCAxKTsNCglpZiAocmVzdWx0ID09IE5VTEwpDQoJCVB5VHJh Y2VCYWNrX0hlcmUoZnJhbWUpOw0KDQoJLyogY2xlYW51cCAqLw0KCVB5X0RF Q1JFRihhcmdzKTsNCglyZXR1cm4gcmVzdWx0Ow0KfQ0KDQpzdGF0aWMgaW50 DQpwcm9maWxlX3RyYW1wb2xpbmUoUHlPYmplY3QgKnNlbGYsIFB5RnJhbWVP YmplY3QgKmZyYW1lLA0KCQkgICBpbnQgd2hhdCwgUHlPYmplY3QgKmFyZykN CnsNCglQeVRocmVhZFN0YXRlICp0c3RhdGUgPSBmcmFtZS0+Zl90c3RhdGU7 DQoJUHlPYmplY3QgKnJlc3VsdDsNCg0KCWlmIChhcmcgPT0gTlVMTCkNCgkJ YXJnID0gUHlfTm9uZTsNCglyZXN1bHQgPSBjYWxsX3RyYW1wb2xpbmUodHN0 YXRlLCBzZWxmLCBmcmFtZSwgd2hhdCwgYXJnKTsNCglpZiAocmVzdWx0ID09 IE5VTEwpIHsNCgkJUHlFdmFsX1NldFByb2ZpbGUoTlVMTCwgTlVMTCk7DQoJ CXJldHVybiAtMTsNCgl9DQoJUHlfREVDUkVGKHJlc3VsdCk7DQoJcmV0dXJu IDA7DQp9DQoNCnN0YXRpYyBpbnQNCnRyYWNlX3RyYW1wb2xpbmUoUHlPYmpl Y3QgKnNlbGYsIFB5RnJhbWVPYmplY3QgKmZyYW1lLA0KCQkgaW50IHdoYXQs IFB5T2JqZWN0ICphcmcpDQp7DQoJUHlUaHJlYWRTdGF0ZSAqdHN0YXRlID0g ZnJhbWUtPmZfdHN0YXRlOw0KCVB5T2JqZWN0ICpjYWxsYmFjazsNCglQeU9i amVjdCAqcmVzdWx0Ow0KDQoJaWYgKHdoYXQgPT0gUHlUcmFjZV9DQUxMKQ0K CQljYWxsYmFjayA9IHNlbGY7DQoJZWxzZQ0KCQljYWxsYmFjayA9IGZyYW1l LT5mX3RyYWNlOw0KCWlmIChjYWxsYmFjayA9PSBOVUxMKQ0KCQlyZXR1cm4g MDsNCglyZXN1bHQgPSBjYWxsX3RyYW1wb2xpbmUodHN0YXRlLCBjYWxsYmFj aywgZnJhbWUsIHdoYXQsIGFyZyk7DQoJaWYgKHJlc3VsdCA9PSBOVUxMKSB7 DQoJCVB5RXZhbF9TZXRUcmFjZShOVUxMLCBOVUxMKTsNCgkJUHlfWERFQ1JF RihmcmFtZS0+Zl90cmFjZSk7DQoJCWZyYW1lLT5mX3RyYWNlID0gTlVMTDsN CgkJcmV0dXJuIC0xOw0KCX0NCglpZiAocmVzdWx0ICE9IFB5X05vbmUpIHsN CgkJUHlPYmplY3QgKnRlbXAgPSBmcmFtZS0+Zl90cmFjZTsNCgkJZnJhbWUt PmZfdHJhY2UgPSBOVUxMOw0KCQlQeV9YREVDUkVGKHRlbXApOw0KCQlmcmFt ZS0+Zl90cmFjZSA9IHJlc3VsdDsNCgl9DQoJZWxzZSB7DQoJCVB5X0RFQ1JF RihyZXN1bHQpOw0KCX0NCglyZXR1cm4gMDsNCn0NCg0Kc3RhdGljIFB5T2Jq ZWN0ICoNCnN5c19zZXR0cmFjZShQeU9iamVjdCAqc2VsZiwgUHlPYmplY3Qg KmFyZ3MpDQp7DQoJaWYgKHRyYWNlX2luaXQoKSA9PSAtMSkNCgkJcmV0dXJu IE5VTEw7DQoJaWYgKGFyZ3MgPT0gUHlfTm9uZSkNCgkJUHlFdmFsX1NldFRy YWNlKE5VTEwsIE5VTEwpOw0KCWVsc2UNCgkJUHlFdmFsX1NldFRyYWNlKHRy YWNlX3RyYW1wb2xpbmUsIGFyZ3MpOw0KCVB5X0lOQ1JFRihQeV9Ob25lKTsN CglyZXR1cm4gUHlfTm9uZTsNCn0NCg0Kc3RhdGljIGNoYXIgc2V0dHJhY2Vf ZG9jW10gPQ0KInNldHRyYWNlKGZ1bmN0aW9uKVxuXA0KXG5cDQpTZXQgdGhl IGdsb2JhbCBkZWJ1ZyB0cmFjaW5nIGZ1bmN0aW9uLiAgSXQgd2lsbCBiZSBj YWxsZWQgb24gZWFjaFxuXA0KZnVuY3Rpb24gY2FsbC4gIFNlZSB0aGUgZGVi dWdnZXIgY2hhcHRlciBpbiB0aGUgbGlicmFyeSBtYW51YWwuIjsNCg0Kc3Rh dGljIFB5T2JqZWN0ICoNCnN5c19zZXRwcm9maWxlKFB5T2JqZWN0ICpzZWxm LCBQeU9iamVjdCAqYXJncykNCnsNCglpZiAodHJhY2VfaW5pdCgpID09IC0x KQ0KCQlyZXR1cm4gTlVMTDsNCglpZiAoYXJncyA9PSBQeV9Ob25lKQ0KCQlQ eUV2YWxfU2V0UHJvZmlsZShOVUxMLCBOVUxMKTsNCgllbHNlDQoJCVB5RXZh bF9TZXRQcm9maWxlKHByb2ZpbGVfdHJhbXBvbGluZSwgYXJncyk7DQoJUHlf SU5DUkVGKFB5X05vbmUpOw0KCXJldHVybiBQeV9Ob25lOw0KfQ0KDQpzdGF0 aWMgY2hhciBzZXRwcm9maWxlX2RvY1tdID0NCiJzZXRwcm9maWxlKGZ1bmN0 aW9uKVxuXA0KXG5cDQpTZXQgdGhlIHByb2ZpbGluZyBmdW5jdGlvbi4gIEl0 IHdpbGwgYmUgY2FsbGVkIG9uIGVhY2ggZnVuY3Rpb24gY2FsbFxuXA0KYW5k IHJldHVybi4gIFNlZSB0aGUgcHJvZmlsZXIgY2hhcHRlciBpbiB0aGUgbGli cmFyeSBtYW51YWwuIjsNCg0Kc3RhdGljIFB5T2JqZWN0ICoNCnN5c19zZXRj aGVja2ludGVydmFsKFB5T2JqZWN0ICpzZWxmLCBQeU9iamVjdCAqYXJncykN CnsNCglQeVRocmVhZFN0YXRlICp0c3RhdGUgPSBQeVRocmVhZFN0YXRlX0dl dCgpOw0KCWlmICghUHlBcmdfUGFyc2VUdXBsZShhcmdzLCAiaTpzZXRjaGVj a2ludGVydmFsIiwgJnRzdGF0ZS0+aW50ZXJwLT5jaGVja2ludGVydmFsKSkN CgkJcmV0dXJuIE5VTEw7DQoJUHlfSU5DUkVGKFB5X05vbmUpOw0KCXJldHVy biBQeV9Ob25lOw0KfQ0KDQpzdGF0aWMgY2hhciBzZXRjaGVja2ludGVydmFs X2RvY1tdID0NCiJzZXRjaGVja2ludGVydmFsKG4pXG5cDQpcblwNClRlbGwg dGhlIFB5dGhvbiBpbnRlcnByZXRlciB0byBjaGVjayBmb3IgYXN5bmNocm9u b3VzIGV2ZW50cyBldmVyeVxuXA0KbiBpbnN0cnVjdGlvbnMuICBUaGlzIGFs c28gYWZmZWN0cyBob3cgb2Z0ZW4gdGhyZWFkIHN3aXRjaGVzIG9jY3VyLiI7 DQoNCnN0YXRpYyBQeU9iamVjdCAqDQpzeXNfc2V0cmVjdXJzaW9ubGltaXQo UHlPYmplY3QgKnNlbGYsIFB5T2JqZWN0ICphcmdzKQ0Kew0KCWludCBuZXdf bGltaXQ7DQoJaWYgKCFQeUFyZ19QYXJzZVR1cGxlKGFyZ3MsICJpOnNldHJl Y3Vyc2lvbmxpbWl0IiwgJm5ld19saW1pdCkpDQoJCXJldHVybiBOVUxMOw0K CWlmIChuZXdfbGltaXQgPD0gMCkgew0KCQlQeUVycl9TZXRTdHJpbmcoUHlF eGNfVmFsdWVFcnJvciwgDQoJCQkJInJlY3Vyc2lvbiBsaW1pdCBtdXN0IGJl IHBvc2l0aXZlIik7ICANCgkJcmV0dXJuIE5VTEw7DQoJfQ0KCVB5X1NldFJl Y3Vyc2lvbkxpbWl0KG5ld19saW1pdCk7DQoJUHlfSU5DUkVGKFB5X05vbmUp Ow0KCXJldHVybiBQeV9Ob25lOw0KfQ0KDQpzdGF0aWMgY2hhciBzZXRyZWN1 cnNpb25saW1pdF9kb2NbXSA9DQoic2V0cmVjdXJzaW9ubGltaXQobilcblwN ClxuXA0KU2V0IHRoZSBtYXhpbXVtIGRlcHRoIG9mIHRoZSBQeXRob24gaW50 ZXJwcmV0ZXIgc3RhY2sgdG8gbi4gIFRoaXNcblwNCmxpbWl0IHByZXZlbnRz IGluZmluaXRlIHJlY3Vyc2lvbiBmcm9tIGNhdXNpbmcgYW4gb3ZlcmZsb3cg b2YgdGhlIENcblwNCnN0YWNrIGFuZCBjcmFzaGluZyBQeXRob24uICBUaGUg aGlnaGVzdCBwb3NzaWJsZSBsaW1pdCBpcyBwbGF0Zm9ybS1cblwNCmRlcGVu ZGVudC4iOw0KDQpzdGF0aWMgUHlPYmplY3QgKg0Kc3lzX2dldHJlY3Vyc2lv bmxpbWl0KFB5T2JqZWN0ICpzZWxmKQ0Kew0KCXJldHVybiBQeUludF9Gcm9t TG9uZyhQeV9HZXRSZWN1cnNpb25MaW1pdCgpKTsNCn0NCg0Kc3RhdGljIGNo YXIgZ2V0cmVjdXJzaW9ubGltaXRfZG9jW10gPQ0KImdldHJlY3Vyc2lvbmxp bWl0KClcblwNClxuXA0KUmV0dXJuIHRoZSBjdXJyZW50IHZhbHVlIG9mIHRo ZSByZWN1cnNpb24gbGltaXQsIHRoZSBtYXhpbXVtIGRlcHRoXG5cDQpvZiB0 aGUgUHl0aG9uIGludGVycHJldGVyIHN0YWNrLiAgVGhpcyBsaW1pdCBwcmV2 ZW50cyBpbmZpbml0ZVxuXA0KcmVjdXJzaW9uIGZyb20gY2F1c2luZyBhbiBv dmVyZmxvdyBvZiB0aGUgQyBzdGFjayBhbmQgY3Jhc2hpbmcgUHl0aG9uLiI7 DQoNCiNpZmRlZiBIQVZFX0RMT1BFTg0Kc3RhdGljIFB5T2JqZWN0ICoNCnN5 c19zZXRkbG9wZW5mbGFncyhQeU9iamVjdCAqc2VsZiwgUHlPYmplY3QgKmFy Z3MpDQp7DQoJaW50IG5ld192YWw7DQogICAgICAgIFB5VGhyZWFkU3RhdGUg KnRzdGF0ZSA9IFB5VGhyZWFkU3RhdGVfR2V0KCk7DQoJaWYgKCFQeUFyZ19Q YXJzZVR1cGxlKGFyZ3MsICJpOnNldGRsb3BlbmZsYWdzIiwgJm5ld192YWwp KQ0KCQlyZXR1cm4gTlVMTDsNCiAgICAgICAgaWYgKCF0c3RhdGUpDQoJCXJl dHVybiBOVUxMOw0KICAgICAgICB0c3RhdGUtPmludGVycC0+ZGxvcGVuZmxh Z3MgPSBuZXdfdmFsOw0KCVB5X0lOQ1JFRihQeV9Ob25lKTsNCglyZXR1cm4g UHlfTm9uZTsNCn0NCg0Kc3RhdGljIGNoYXIgc2V0ZGxvcGVuZmxhZ3NfZG9j W10gPQ0KInNldGRsb3BlbmZsYWdzKG4pIC0+IE5vbmVcblwNClxuXA0KU2V0 IHRoZSBmbGFncyB0aGF0IHdpbGwgYmUgdXNlZCBmb3IgZGxvcGVuKCkgY2Fs bHMuIEFtb25nIG90aGVyXG5cDQp0aGluZ3MsIHRoaXMgd2lsbCBlbmFibGUg YSBsYXp5IHJlc29sdmluZyBvZiBzeW1ib2xzIHdoZW4gaW1wb3JpbmdcblwN CmEgbW9kdWxlLCBpZiBjYWxsZWQgYXMgc3lzLnNldGRsb3BlbmZsYWdzKDAp XG5cDQpUbyBzaGFyZSBzeW1vbHMgYWNyb3NzIGV4dGVuc2lvbiBtb2R1bGVz LCBjYWxsIGFzXG5cDQpzeXMuc2V0ZGxvcGVuZmxhZ3MoZGwuUlRMRF9OT1d8 ZGwuUlRMRF9HTE9CQUwpIjsNCg0Kc3RhdGljIFB5T2JqZWN0ICoNCnN5c19n ZXRkbG9wZW5mbGFncyhQeU9iamVjdCAqc2VsZiwgUHlPYmplY3QgKmFyZ3Mp DQp7DQogICAgICAgIFB5VGhyZWFkU3RhdGUgKnRzdGF0ZSA9IFB5VGhyZWFk U3RhdGVfR2V0KCk7DQogICAgICAgIGlmICghdHN0YXRlKQ0KCQlyZXR1cm4g TlVMTDsNCiAgICAgICAgcmV0dXJuIFB5SW50X0Zyb21Mb25nKHRzdGF0ZS0+ aW50ZXJwLT5kbG9wZW5mbGFncyk7DQp9DQoNCnN0YXRpYyBjaGFyIGdldGRs b3BlbmZsYWdzX2RvY1tdID0NCiJnZXRkbG9wZW5mbGFncygpIC0+IGludFxu XA0KXG5cDQpSZXR1cm4gdGhlIGN1cnJlbnQgdmFsdWUgb2YgdGhlIGZsYWdz IHRoYXQgYXJlIHVzZWQgZm9yIGRsb3BlbigpXG5cDQpjYWxscy4gVGhlIGZs YWcgY29uc3RhbnRzIGFyZSBkZWZpbmVkIGluIHRoZSBkbCBtb2R1bGUuIjsN CiNlbmRpZg0KDQojaWZkZWYgV0lUSF9EWUxEDQpzdGF0aWMgUHlPYmplY3Qg Kg0Kc3lzX3NldGR5bGRwcml2YXRlKFB5T2JqZWN0ICpzZWxmKQ0Kew0KICAg ICAgICBQeVRocmVhZFN0YXRlICp0c3RhdGUgPSBQeVRocmVhZFN0YXRlX0dl dCgpOw0KICAgICAgICBpZiAoIXRzdGF0ZSkNCgkJcmV0dXJuIE5VTEw7DQog ICAgICAgIHRzdGF0ZS0+aW50ZXJwLT5kbG9wZW5mbGFncyB8PSBOU0xJTktN T0RVTEVfT1BUSU9OX1BSSVZBVEU7DQoJUHlfSU5DUkVGKFB5X05vbmUpOw0K CXJldHVybiBQeV9Ob25lOw0KfQ0KDQpzdGF0aWMgY2hhciBzZXRkeWxkcHJp dmF0ZV9kb2NbXSA9DQoic2V0ZHlsZHByaXZhdGUoKSAtPiBOb25lIjsNCg0K c3RhdGljIFB5T2JqZWN0ICoNCnN5c19zZXRkeWxkcHVibGljKFB5T2JqZWN0 ICpzZWxmKQ0Kew0KICAgICAgICBQeVRocmVhZFN0YXRlICp0c3RhdGUgPSBQ eVRocmVhZFN0YXRlX0dldCgpOw0KICAgICAgICBpZiAoIXRzdGF0ZSkNCgkJ cmV0dXJuIE5VTEw7DQogICAgICAgIHRzdGF0ZS0+aW50ZXJwLT5kbG9wZW5m bGFncyAmPSB+TlNMSU5LTU9EVUxFX09QVElPTl9QUklWQVRFOw0KCVB5X0lO Q1JFRihQeV9Ob25lKTsNCglyZXR1cm4gUHlfTm9uZTsNCn0NCg0Kc3RhdGlj IGNoYXIgc2V0ZHlsZHB1YmxpY19kb2NbXSA9DQoic2V0ZHlsZHB1YmxpYygp IC0+IE5vbmUiOw0KI2VuZGlmDQoNCiNpZmRlZiBVU0VfTUFMTE9QVA0KLyog TGluayB3aXRoIC1sbWFsbG9jIChvciAtbG1wYykgb24gYW4gU0dJICovDQoj aW5jbHVkZSA8bWFsbG9jLmg+DQoNCnN0YXRpYyBQeU9iamVjdCAqDQpzeXNf bWRlYnVnKFB5T2JqZWN0ICpzZWxmLCBQeU9iamVjdCAqYXJncykNCnsNCglp bnQgZmxhZzsNCglpZiAoIVB5QXJnX1BhcnNlVHVwbGUoYXJncywgImk6bWRl YnVnIiwgJmZsYWcpKQ0KCQlyZXR1cm4gTlVMTDsNCgltYWxsb3B0KE1fREVC VUcsIGZsYWcpOw0KCVB5X0lOQ1JFRihQeV9Ob25lKTsNCglyZXR1cm4gUHlf Tm9uZTsNCn0NCiNlbmRpZiAvKiBVU0VfTUFMTE9QVCAqLw0KDQpzdGF0aWMg UHlPYmplY3QgKg0Kc3lzX2dldHJlZmNvdW50KFB5T2JqZWN0ICpzZWxmLCBQ eU9iamVjdCAqYXJnKQ0Kew0KCXJldHVybiBQeUludF9Gcm9tTG9uZyhhcmct Pm9iX3JlZmNudCk7DQp9DQoNCiNpZmRlZiBQeV9UUkFDRV9SRUZTDQpzdGF0 aWMgUHlPYmplY3QgKg0Kc3lzX2dldHRvdGFscmVmY291bnQoUHlPYmplY3Qg KnNlbGYpDQp7DQoJZXh0ZXJuIGxvbmcgX1B5X1JlZlRvdGFsOw0KCXJldHVy biBQeUludF9Gcm9tTG9uZyhfUHlfUmVmVG90YWwpOw0KfQ0KDQojZW5kaWYg LyogUHlfVFJBQ0VfUkVGUyAqLw0KDQpzdGF0aWMgY2hhciBnZXRyZWZjb3Vu dF9kb2NbXSA9DQoiZ2V0cmVmY291bnQob2JqZWN0KSAtPiBpbnRlZ2VyXG5c DQpcblwNClJldHVybiB0aGUgY3VycmVudCByZWZlcmVuY2UgY291bnQgZm9y IHRoZSBvYmplY3QuICBUaGlzIGluY2x1ZGVzIHRoZVxuXA0KdGVtcG9yYXJ5 IHJlZmVyZW5jZSBpbiB0aGUgYXJndW1lbnQgbGlzdCwgc28gaXQgaXMgYXQg bGVhc3QgMi4iOw0KDQojaWZkZWYgQ09VTlRfQUxMT0NTDQpzdGF0aWMgUHlP YmplY3QgKg0Kc3lzX2dldGNvdW50cyhQeU9iamVjdCAqc2VsZikNCnsNCgll eHRlcm4gUHlPYmplY3QgKmdldF9jb3VudHModm9pZCk7DQoNCglyZXR1cm4g Z2V0X2NvdW50cygpOw0KfQ0KI2VuZGlmDQoNCnN0YXRpYyBjaGFyIGdldGZy YW1lX2RvY1tdID0NCiJfZ2V0ZnJhbWUoW2RlcHRoXSkgLT4gZnJhbWVvYmpl Y3RcblwNClxuXA0KUmV0dXJuIGEgZnJhbWUgb2JqZWN0IGZyb20gdGhlIGNh bGwgc3RhY2suICBJZiBvcHRpb25hbCBpbnRlZ2VyIGRlcHRoIGlzXG5cDQpn aXZlbiwgcmV0dXJuIHRoZSBmcmFtZSBvYmplY3QgdGhhdCBtYW55IGNhbGxz IGJlbG93IHRoZSB0b3Agb2YgdGhlIHN0YWNrLlxuXA0KSWYgdGhhdCBpcyBk ZWVwZXIgdGhhbiB0aGUgY2FsbCBzdGFjaywgVmFsdWVFcnJvciBpcyByYWlz ZWQuICBUaGUgZGVmYXVsdFxuXA0KZm9yIGRlcHRoIGlzIHplcm8sIHJldHVy bmluZyB0aGUgZnJhbWUgYXQgdGhlIHRvcCBvZiB0aGUgY2FsbCBzdGFjay5c blwNClxuXA0KVGhpcyBmdW5jdGlvbiBzaG91bGQgYmUgdXNlZCBmb3IgaW50 ZXJuYWwgYW5kIHNwZWNpYWxpemVkXG5cDQpwdXJwb3NlcyBvbmx5LiI7DQoN CnN0YXRpYyBQeU9iamVjdCAqDQpzeXNfZ2V0ZnJhbWUoUHlPYmplY3QgKnNl bGYsIFB5T2JqZWN0ICphcmdzKQ0Kew0KCVB5RnJhbWVPYmplY3QgKmYgPSBQ eVRocmVhZFN0YXRlX0dldCgpLT5mcmFtZTsNCglpbnQgZGVwdGggPSAtMTsN Cg0KCWlmICghUHlBcmdfUGFyc2VUdXBsZShhcmdzLCAifGk6X2dldGZyYW1l IiwgJmRlcHRoKSkNCgkJcmV0dXJuIE5VTEw7DQoNCgl3aGlsZSAoZGVwdGgg PiAwICYmIGYgIT0gTlVMTCkgew0KCQlmID0gZi0+Zl9iYWNrOw0KCQktLWRl cHRoOw0KCX0NCglpZiAoZiA9PSBOVUxMKSB7DQoJCVB5RXJyX1NldFN0cmlu ZyhQeUV4Y19WYWx1ZUVycm9yLA0KCQkJCSJjYWxsIHN0YWNrIGlzIG5vdCBk ZWVwIGVub3VnaCIpOw0KCQlyZXR1cm4gTlVMTDsNCgl9DQoJUHlfSU5DUkVG KGYpOw0KCXJldHVybiAoUHlPYmplY3QqKWY7DQp9DQoNCg0KI2lmZGVmIFB5 X1RSQUNFX1JFRlMNCi8qIERlZmluZWQgaW4gb2JqZWN0cy5jIGJlY2F1c2Ug aXQgdXNlcyBzdGF0aWMgZ2xvYmFscyBpZiB0aGF0IGZpbGUgKi8NCmV4dGVy biBQeU9iamVjdCAqX1B5X0dldE9iamVjdHMoUHlPYmplY3QgKiwgUHlPYmpl Y3QgKik7DQojZW5kaWYNCg0KI2lmZGVmIERZTkFNSUNfRVhFQ1VUSU9OX1BS T0ZJTEUNCi8qIERlZmluZWQgaW4gY2V2YWwuYyBiZWNhdXNlIGl0IHVzZXMg c3RhdGljIGdsb2JhbHMgaWYgdGhhdCBmaWxlICovDQpleHRlcm4gUHlPYmpl Y3QgKl9QeV9HZXREWFByb2ZpbGUoUHlPYmplY3QgKiwgIFB5T2JqZWN0ICop Ow0KI2VuZGlmDQoNCnN0YXRpYyBQeU1ldGhvZERlZiBzeXNfbWV0aG9kc1td ID0gew0KCS8qIE1pZ2h0IGFzIHdlbGwga2VlcCB0aGlzIGluIGFscGhhYmV0 aWMgb3JkZXIgKi8NCgl7ImRpc3BsYXlob29rIiwJc3lzX2Rpc3BsYXlob29r LCBNRVRIX08sIGRpc3BsYXlob29rX2RvY30sDQoJeyJleGNfaW5mbyIsCShQ eUNGdW5jdGlvbilzeXNfZXhjX2luZm8sIE1FVEhfTk9BUkdTLCBleGNfaW5m b19kb2N9LA0KCXsiZXhjZXB0aG9vayIsCXN5c19leGNlcHRob29rLCBNRVRI X1ZBUkFSR1MsIGV4Y2VwdGhvb2tfZG9jfSwNCgl7ImV4aXQiLAlzeXNfZXhp dCwgTUVUSF9PTERBUkdTLCBleGl0X2RvY30sDQojaWZkZWYgUHlfVVNJTkdf VU5JQ09ERQ0KCXsiZ2V0ZGVmYXVsdGVuY29kaW5nIiwgKFB5Q0Z1bmN0aW9u KXN5c19nZXRkZWZhdWx0ZW5jb2RpbmcsIE1FVEhfTk9BUkdTLA0KCSBnZXRk ZWZhdWx0ZW5jb2RpbmdfZG9jfSwgDQojZW5kaWYNCiNpZmRlZiBIQVZFX0RM T1BFTg0KCXsiZ2V0ZGxvcGVuZmxhZ3MiLCAoUHlDRnVuY3Rpb24pc3lzX2dl dGRsb3BlbmZsYWdzLCBNRVRIX05PQVJHUywgDQoJIGdldGRsb3BlbmZsYWdz X2RvY30sDQojZW5kaWYNCiNpZmRlZiBDT1VOVF9BTExPQ1MNCgl7ImdldGNv dW50cyIsCShQeUNGdW5jdGlvbilzeXNfZ2V0Y291bnRzLCBNRVRIX05PQVJH U30sDQojZW5kaWYNCiNpZmRlZiBEWU5BTUlDX0VYRUNVVElPTl9QUk9GSUxF DQoJeyJnZXRkeHAiLAlfUHlfR2V0RFhQcm9maWxlLCBNRVRIX1ZBUkFSR1N9 LA0KI2VuZGlmDQojaWZkZWYgUHlfVFJBQ0VfUkVGUw0KCXsiZ2V0b2JqZWN0 cyIsCV9QeV9HZXRPYmplY3RzLCBNRVRIX1ZBUkFSR1N9LA0KCXsiZ2V0dG90 YWxyZWZjb3VudCIsIChQeUNGdW5jdGlvbilzeXNfZ2V0dG90YWxyZWZjb3Vu dCwgTUVUSF9OT0FSR1N9LA0KI2VuZGlmDQoJeyJnZXRyZWZjb3VudCIsCShQ eUNGdW5jdGlvbilzeXNfZ2V0cmVmY291bnQsIE1FVEhfTywgZ2V0cmVmY291 bnRfZG9jfSwNCgl7ImdldHJlY3Vyc2lvbmxpbWl0IiwgKFB5Q0Z1bmN0aW9u KXN5c19nZXRyZWN1cnNpb25saW1pdCwgTUVUSF9OT0FSR1MsDQoJIGdldHJl Y3Vyc2lvbmxpbWl0X2RvY30sDQoJeyJfZ2V0ZnJhbWUiLCBzeXNfZ2V0ZnJh bWUsIE1FVEhfVkFSQVJHUywgZ2V0ZnJhbWVfZG9jfSwNCiNpZmRlZiBVU0Vf TUFMTE9QVA0KCXsibWRlYnVnIiwJc3lzX21kZWJ1ZywgTUVUSF9WQVJBUkdT fSwNCiNlbmRpZg0KI2lmZGVmIFB5X1VTSU5HX1VOSUNPREUNCgl7InNldGRl ZmF1bHRlbmNvZGluZyIsIHN5c19zZXRkZWZhdWx0ZW5jb2RpbmcsIE1FVEhf VkFSQVJHUywNCgkgc2V0ZGVmYXVsdGVuY29kaW5nX2RvY30sIA0KI2VuZGlm DQoJeyJzZXRjaGVja2ludGVydmFsIiwJc3lzX3NldGNoZWNraW50ZXJ2YWws IE1FVEhfVkFSQVJHUywNCgkgc2V0Y2hlY2tpbnRlcnZhbF9kb2N9LCANCiNp ZmRlZiBIQVZFX0RMT1BFTg0KCXsic2V0ZGxvcGVuZmxhZ3MiLCBzeXNfc2V0 ZGxvcGVuZmxhZ3MsIE1FVEhfVkFSQVJHUywgDQoJIHNldGRsb3BlbmZsYWdz X2RvY30sDQojZW5kaWYNCiNpZmRlZiBXSVRIX0RZTEQNCgl7InNldGR5bGRw cml2YXRlIiwgKFB5Q0Z1bmN0aW9uKXN5c19zZXRkeWxkcHJpdmF0ZSwgTUVU SF9OT0FSR1MsDQoJIHNldGR5bGRwcml2YXRlX2RvY30sDQoJeyJzZXRkeWxk cHVibGljIiwgKFB5Q0Z1bmN0aW9uKXN5c19zZXRkeWxkcHVibGljLCBNRVRI X05PQVJHUywNCgkgc2V0ZHlsZHB1YmxpY19kb2N9LA0KI2VuZGlmDQoJeyJz ZXRwcm9maWxlIiwJc3lzX3NldHByb2ZpbGUsIE1FVEhfT0xEQVJHUywgc2V0 cHJvZmlsZV9kb2N9LA0KCXsic2V0cmVjdXJzaW9ubGltaXQiLCBzeXNfc2V0 cmVjdXJzaW9ubGltaXQsIE1FVEhfVkFSQVJHUywNCgkgc2V0cmVjdXJzaW9u bGltaXRfZG9jfSwNCgl7InNldHRyYWNlIiwJc3lzX3NldHRyYWNlLCBNRVRI X09MREFSR1MsIHNldHRyYWNlX2RvY30sDQoJe05VTEwsCQlOVUxMfQkJLyog c2VudGluZWwgKi8NCn07DQoNCnN0YXRpYyBQeU9iamVjdCAqDQpsaXN0X2J1 aWx0aW5fbW9kdWxlX25hbWVzKHZvaWQpDQp7DQoJUHlPYmplY3QgKmxpc3Qg PSBQeUxpc3RfTmV3KDApOw0KCWludCBpOw0KCWlmIChsaXN0ID09IE5VTEwp DQoJCXJldHVybiBOVUxMOw0KCWZvciAoaSA9IDA7IFB5SW1wb3J0X0luaXR0 YWJbaV0ubmFtZSAhPSBOVUxMOyBpKyspIHsNCgkJUHlPYmplY3QgKm5hbWUg PSBQeVN0cmluZ19Gcm9tU3RyaW5nKA0KCQkJUHlJbXBvcnRfSW5pdHRhYltp XS5uYW1lKTsNCgkJaWYgKG5hbWUgPT0gTlVMTCkNCgkJCWJyZWFrOw0KCQlQ eUxpc3RfQXBwZW5kKGxpc3QsIG5hbWUpOw0KCQlQeV9ERUNSRUYobmFtZSk7 DQoJfQ0KCWlmIChQeUxpc3RfU29ydChsaXN0KSAhPSAwKSB7DQoJCVB5X0RF Q1JFRihsaXN0KTsNCgkJbGlzdCA9IE5VTEw7DQoJfQ0KCWlmIChsaXN0KSB7 DQoJCVB5T2JqZWN0ICp2ID0gUHlMaXN0X0FzVHVwbGUobGlzdCk7DQoJCVB5 X0RFQ1JFRihsaXN0KTsNCgkJbGlzdCA9IHY7DQoJfQ0KCXJldHVybiBsaXN0 Ow0KfQ0KDQpzdGF0aWMgUHlPYmplY3QgKndhcm5vcHRpb25zID0gTlVMTDsN Cg0Kdm9pZA0KUHlTeXNfUmVzZXRXYXJuT3B0aW9ucyh2b2lkKQ0Kew0KCWlm ICh3YXJub3B0aW9ucyA9PSBOVUxMIHx8ICFQeUxpc3RfQ2hlY2sod2Fybm9w dGlvbnMpKQ0KCQlyZXR1cm47DQoJUHlMaXN0X1NldFNsaWNlKHdhcm5vcHRp b25zLCAwLCBQeUxpc3RfR0VUX1NJWkUod2Fybm9wdGlvbnMpLCBOVUxMKTsN Cn0NCg0Kdm9pZA0KUHlTeXNfQWRkV2Fybk9wdGlvbihjaGFyICpzKQ0Kew0K CVB5T2JqZWN0ICpzdHI7DQoNCglpZiAod2Fybm9wdGlvbnMgPT0gTlVMTCB8 fCAhUHlMaXN0X0NoZWNrKHdhcm5vcHRpb25zKSkgew0KCQlQeV9YREVDUkVG KHdhcm5vcHRpb25zKTsNCgkJd2Fybm9wdGlvbnMgPSBQeUxpc3RfTmV3KDAp Ow0KCQlpZiAod2Fybm9wdGlvbnMgPT0gTlVMTCkNCgkJCXJldHVybjsNCgl9 DQoJc3RyID0gUHlTdHJpbmdfRnJvbVN0cmluZyhzKTsNCglpZiAoc3RyICE9 IE5VTEwpIHsNCgkJUHlMaXN0X0FwcGVuZCh3YXJub3B0aW9ucywgc3RyKTsN CgkJUHlfREVDUkVGKHN0cik7DQoJfQ0KfQ0KDQovKiBYWFggVGhpcyBkb2Mg c3RyaW5nIGlzIHRvbyBsb25nIHRvIGJlIGEgc2luZ2xlIHN0cmluZyBsaXRl cmFsIGluIFZDKysgNS4wLg0KICAgVHdvIGxpdGVyYWxzIGNvbmNhdGVuYXRl ZCB3b3JrcyBqdXN0IGZpbmUuICBJZiB5b3UgaGF2ZSBhIEsmUiBjb21waWxl cg0KICAgb3Igb3RoZXIgYWJvbWluYXRpb24gdGhhdCBob3dldmVyICpkb2Vz KiB1bmRlcnN0YW5kIGxvbmdlciBzdHJpbmdzLA0KICAgZ2V0IHJpZCBvZiB0 aGUgISEhIGNvbW1lbnQgaW4gdGhlIG1pZGRsZSBhbmQgdGhlIHF1b3RlcyB0 aGF0IHN1cnJvdW5kIGl0LiAqLw0Kc3RhdGljIGNoYXIgc3lzX2RvY1tdID0N CiJUaGlzIG1vZHVsZSBwcm92aWRlcyBhY2Nlc3MgdG8gc29tZSBvYmplY3Rz IHVzZWQgb3IgbWFpbnRhaW5lZCBieSB0aGVcblwNCmludGVycHJldGVyIGFu ZCB0byBmdW5jdGlvbnMgdGhhdCBpbnRlcmFjdCBzdHJvbmdseSB3aXRoIHRo ZSBpbnRlcnByZXRlci5cblwNClxuXA0KRHluYW1pYyBvYmplY3RzOlxuXA0K XG5cDQphcmd2IC0tIGNvbW1hbmQgbGluZSBhcmd1bWVudHM7IGFyZ3ZbMF0g aXMgdGhlIHNjcmlwdCBwYXRobmFtZSBpZiBrbm93blxuXA0KcGF0aCAtLSBt b2R1bGUgc2VhcmNoIHBhdGg7IHBhdGhbMF0gaXMgdGhlIHNjcmlwdCBkaXJl Y3RvcnksIGVsc2UgJydcblwNCm1vZHVsZXMgLS0gZGljdGlvbmFyeSBvZiBs b2FkZWQgbW9kdWxlc1xuXA0KXG5cDQpkaXNwbGF5aG9vayAtLSBjYWxsZWQg dG8gc2hvdyByZXN1bHRzIGluIGFuIGludGVyYWN0aXZlIHNlc3Npb25cblwN CmV4Y2VwdGhvb2sgLS0gY2FsbGVkIHRvIGhhbmRsZSBhbnkgdW5jYXVnaHQg ZXhjZXB0aW9uIG90aGVyIHRoYW4gU3lzdGVtRXhpdFxuXA0KICBUbyBjdXN0 b21pemUgcHJpbnRpbmcgaW4gYW4gaW50ZXJhY3RpdmUgc2Vzc2lvbiBvciB0 byBpbnN0YWxsIGEgY3VzdG9tXG5cDQogIHRvcC1sZXZlbCBleGNlcHRpb24g aGFuZGxlciwgYXNzaWduIG90aGVyIGZ1bmN0aW9ucyB0byByZXBsYWNlIHRo ZXNlLlxuXA0KXG5cDQpleGl0ZnVuYyAtLSBpZiBzeXMuZXhpdGZ1bmMgZXhp c3RzLCB0aGlzIHJvdXRpbmUgaXMgY2FsbGVkIHdoZW4gUHl0aG9uIGV4aXRz XG5cDQogIEFzc2lnbmluZyB0byBzeXMuZXhpdGZ1bmMgaXMgZGVwcmVjYXRl ZDsgdXNlIHRoZSBhdGV4aXQgbW9kdWxlIGluc3RlYWQuXG5cDQpcblwNCnN0 ZGluIC0tIHN0YW5kYXJkIGlucHV0IGZpbGUgb2JqZWN0OyB1c2VkIGJ5IHJh d19pbnB1dCgpIGFuZCBpbnB1dCgpXG5cDQpzdGRvdXQgLS0gc3RhbmRhcmQg b3V0cHV0IGZpbGUgb2JqZWN0OyB1c2VkIGJ5IHRoZSBwcmludCBzdGF0ZW1l bnRcblwNCnN0ZGVyciAtLSBzdGFuZGFyZCBlcnJvciBvYmplY3Q7IHVzZWQg Zm9yIGVycm9yIG1lc3NhZ2VzXG5cDQogIEJ5IGFzc2lnbmluZyBvdGhlciBm aWxlIG9iamVjdHMgKG9yIG9iamVjdHMgdGhhdCBiZWhhdmUgbGlrZSBmaWxl cylcblwNCiAgdG8gdGhlc2UsIGl0IGlzIHBvc3NpYmxlIHRvIHJlZGlyZWN0 IGFsbCBvZiB0aGUgaW50ZXJwcmV0ZXIncyBJL08uXG5cDQpcblwNCmxhc3Rf dHlwZSAtLSB0eXBlIG9mIGxhc3QgdW5jYXVnaHQgZXhjZXB0aW9uXG5cDQps YXN0X3ZhbHVlIC0tIHZhbHVlIG9mIGxhc3QgdW5jYXVnaHQgZXhjZXB0aW9u XG5cDQpsYXN0X3RyYWNlYmFjayAtLSB0cmFjZWJhY2sgb2YgbGFzdCB1bmNh dWdodCBleGNlcHRpb25cblwNCiAgVGhlc2UgdGhyZWUgYXJlIG9ubHkgYXZh aWxhYmxlIGluIGFuIGludGVyYWN0aXZlIHNlc3Npb24gYWZ0ZXIgYVxuXA0K ICB0cmFjZWJhY2sgaGFzIGJlZW4gcHJpbnRlZC5cblwNClxuXA0KZXhjX3R5 cGUgLS0gdHlwZSBvZiBleGNlcHRpb24gY3VycmVudGx5IGJlaW5nIGhhbmRs ZWRcblwNCmV4Y192YWx1ZSAtLSB2YWx1ZSBvZiBleGNlcHRpb24gY3VycmVu dGx5IGJlaW5nIGhhbmRsZWRcblwNCmV4Y190cmFjZWJhY2sgLS0gdHJhY2Vi YWNrIG9mIGV4Y2VwdGlvbiBjdXJyZW50bHkgYmVpbmcgaGFuZGxlZFxuXA0K ICBUaGUgZnVuY3Rpb24gZXhjX2luZm8oKSBzaG91bGQgYmUgdXNlZCBpbnN0 ZWFkIG9mIHRoZXNlIHRocmVlLFxuXA0KICBiZWNhdXNlIGl0IGlzIHRocmVh ZC1zYWZlLlxuXA0KIg0KI2lmbmRlZiBNU19XSU4xNg0KLyogY29uY2F0ZW5h dGluZyBzdHJpbmcgaGVyZSAqLw0KIlxuXA0KU3RhdGljIG9iamVjdHM6XG5c DQpcblwNCm1heGludCAtLSB0aGUgbGFyZ2VzdCBzdXBwb3J0ZWQgaW50ZWdl ciAodGhlIHNtYWxsZXN0IGlzIC1tYXhpbnQtMSlcblwNCm1heHVuaWNvZGUg LS0gdGhlIGxhcmdlc3Qgc3VwcG9ydGVkIGNoYXJhY3RlclxuXA0KYnVpbHRp bl9tb2R1bGVfbmFtZXMgLS0gdHVwbGUgb2YgbW9kdWxlIG5hbWVzIGJ1aWx0 IGludG8gdGhpcyBpbnRlcHJldGVyXG5cDQp2ZXJzaW9uIC0tIHRoZSB2ZXJz aW9uIG9mIHRoaXMgaW50ZXJwcmV0ZXIgYXMgYSBzdHJpbmdcblwNCnZlcnNp b25faW5mbyAtLSB2ZXJzaW9uIGluZm9ybWF0aW9uIGFzIGEgdHVwbGVcblwN CmhleHZlcnNpb24gLS0gdmVyc2lvbiBpbmZvcm1hdGlvbiBlbmNvZGVkIGFz IGEgc2luZ2xlIGludGVnZXJcblwNCmNvcHlyaWdodCAtLSBjb3B5cmlnaHQg bm90aWNlIHBlcnRhaW5pbmcgdG8gdGhpcyBpbnRlcnByZXRlclxuXA0KcGxh dGZvcm0gLS0gcGxhdGZvcm0gaWRlbnRpZmllclxuXA0KZXhlY3V0YWJsZSAt LSBwYXRobmFtZSBvZiB0aGlzIFB5dGhvbiBpbnRlcnByZXRlclxuXA0KcHJl Zml4IC0tIHByZWZpeCB1c2VkIHRvIGZpbmQgdGhlIFB5dGhvbiBsaWJyYXJ5 XG5cDQpleGVjX3ByZWZpeCAtLSBwcmVmaXggdXNlZCB0byBmaW5kIHRoZSBt YWNoaW5lLXNwZWNpZmljIFB5dGhvbiBsaWJyYXJ5XG5cDQoiDQojaWZkZWYg TVNfV0lORE9XUw0KLyogY29uY2F0ZW5hdGluZyBzdHJpbmcgaGVyZSAqLw0K ImRsbGhhbmRsZSAtLSBbV2luZG93cyBvbmx5XSBpbnRlZ2VyIGhhbmRsZSBv ZiB0aGUgUHl0aG9uIERMTFxuXA0Kd2ludmVyIC0tIFtXaW5kb3dzIG9ubHld IHZlcnNpb24gbnVtYmVyIG9mIHRoZSBQeXRob24gRExMXG5cDQoiDQojZW5k aWYgLyogTVNfV0lORE9XUyAqLw0KIl9fc3RkaW5fXyAtLSB0aGUgb3JpZ2lu YWwgc3RkaW47IGRvbid0IHRvdWNoIVxuXA0KX19zdGRvdXRfXyAtLSB0aGUg b3JpZ2luYWwgc3Rkb3V0OyBkb24ndCB0b3VjaCFcblwNCl9fc3RkZXJyX18g LS0gdGhlIG9yaWdpbmFsIHN0ZGVycjsgZG9uJ3QgdG91Y2ghXG5cDQpfX2Rp c3BsYXlob29rX18gLS0gdGhlIG9yaWdpbmFsIGRpc3BsYXlob29rOyBkb24n dCB0b3VjaCFcblwNCl9fZXhjZXB0aG9va19fIC0tIHRoZSBvcmlnaW5hbCBl eGNlcHRob29rOyBkb24ndCB0b3VjaCFcblwNClxuXA0KRnVuY3Rpb25zOlxu XA0KXG5cDQpkaXNwbGF5aG9vaygpIC0tIHByaW50IGFuIG9iamVjdCB0byB0 aGUgc2NyZWVuLCBhbmQgc2F2ZSBpdCBpbiBfX2J1aWx0aW5fXy5fXG5cDQpl eGNlcHRob29rKCkgLS0gcHJpbnQgYW4gZXhjZXB0aW9uIGFuZCBpdHMgdHJh Y2ViYWNrIHRvIHN5cy5zdGRlcnJcblwNCmV4Y19pbmZvKCkgLS0gcmV0dXJu IHRocmVhZC1zYWZlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjdXJyZW50IGV4 Y2VwdGlvblxuXA0KZXhpdCgpIC0tIGV4aXQgdGhlIGludGVycHJldGVyIGJ5 IHJhaXNpbmcgU3lzdGVtRXhpdFxuXA0KZ2V0ZGxvcGVuZmxhZ3MoKSAtLSBy ZXR1cm5zIGZsYWdzIHRvIGJlIHVzZWQgZm9yIGRsb3BlbigpIGNhbGxzXG5c DQpnZXRyZWZjb3VudCgpIC0tIHJldHVybiB0aGUgcmVmZXJlbmNlIGNvdW50 IGZvciBhbiBvYmplY3QgKHBsdXMgb25lIDotKVxuXA0KZ2V0cmVjdXJzaW9u bGltaXQoKSAtLSByZXR1cm4gdGhlIG1heCByZWN1cnNpb24gZGVwdGggZm9y IHRoZSBpbnRlcnByZXRlclxuXA0Kc2V0Y2hlY2tpbnRlcnZhbCgpIC0tIGNv bnRyb2wgaG93IG9mdGVuIHRoZSBpbnRlcnByZXRlciBjaGVja3MgZm9yIGV2 ZW50c1xuXA0Kc2V0ZGxvcGVuZmxhZ3MoKSAtLSBzZXQgdGhlIGZsYWdzIHRv IGJlIHVzZWQgZm9yIGRsb3BlbigpIGNhbGxzXG5cDQpzZXRwcm9maWxlKCkg LS0gc2V0IHRoZSBnbG9iYWwgcHJvZmlsaW5nIGZ1bmN0aW9uXG5cDQpzZXRy ZWN1cnNpb25saW1pdCgpIC0tIHNldCB0aGUgbWF4IHJlY3Vyc2lvbiBkZXB0 aCBmb3IgdGhlIGludGVycHJldGVyXG5cDQpzZXR0cmFjZSgpIC0tIHNldCB0 aGUgZ2xvYmFsIGRlYnVnIHRyYWNpbmcgZnVuY3Rpb25cblwNCiINCiNlbmRp ZiAvKiBNU19XSU4xNiAqLw0KLyogZW5kIG9mIHN5c19kb2MgKi8gOw0KDQpQ eU9iamVjdCAqDQpfUHlTeXNfSW5pdCh2b2lkKQ0Kew0KCVB5T2JqZWN0ICpt LCAqdiwgKnN5c2RpY3Q7DQoJUHlPYmplY3QgKnN5c2luLCAqc3lzb3V0LCAq c3lzZXJyOw0KCWNoYXIgKnM7DQoNCgltID0gUHlfSW5pdE1vZHVsZTMoInN5 cyIsIHN5c19tZXRob2RzLCBzeXNfZG9jKTsNCglzeXNkaWN0ID0gUHlNb2R1 bGVfR2V0RGljdChtKTsNCg0KCXN5c2luID0gUHlGaWxlX0Zyb21GaWxlKHN0 ZGluLCAiPHN0ZGluPiIsICJyIiwgTlVMTCk7DQoJc3lzb3V0ID0gUHlGaWxl X0Zyb21GaWxlKHN0ZG91dCwgIjxzdGRvdXQ+IiwgInciLCBOVUxMKTsNCglz eXNlcnIgPSBQeUZpbGVfRnJvbUZpbGUoc3RkZXJyLCAiPHN0ZGVycj4iLCAi dyIsIE5VTEwpOw0KCWlmIChQeUVycl9PY2N1cnJlZCgpKQ0KCQlyZXR1cm4g TlVMTDsNCglQeURpY3RfU2V0SXRlbVN0cmluZyhzeXNkaWN0LCAic3RkaW4i LCBzeXNpbik7DQoJUHlEaWN0X1NldEl0ZW1TdHJpbmcoc3lzZGljdCwgInN0 ZG91dCIsIHN5c291dCk7DQoJUHlEaWN0X1NldEl0ZW1TdHJpbmcoc3lzZGlj dCwgInN0ZGVyciIsIHN5c2Vycik7DQoJLyogTWFrZSBiYWNrdXAgY29waWVz IGZvciBjbGVhbnVwICovDQoJUHlEaWN0X1NldEl0ZW1TdHJpbmcoc3lzZGlj dCwgIl9fc3RkaW5fXyIsIHN5c2luKTsNCglQeURpY3RfU2V0SXRlbVN0cmlu ZyhzeXNkaWN0LCAiX19zdGRvdXRfXyIsIHN5c291dCk7DQoJUHlEaWN0X1Nl dEl0ZW1TdHJpbmcoc3lzZGljdCwgIl9fc3RkZXJyX18iLCBzeXNlcnIpOw0K CVB5RGljdF9TZXRJdGVtU3RyaW5nKHN5c2RpY3QsICJfX2Rpc3BsYXlob29r X18iLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQeURpY3RfR2V0 SXRlbVN0cmluZyhzeXNkaWN0LCAiZGlzcGxheWhvb2siKSk7DQoJUHlEaWN0 X1NldEl0ZW1TdHJpbmcoc3lzZGljdCwgIl9fZXhjZXB0aG9va19fIiwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUHlEaWN0X0dldEl0ZW1TdHJp bmcoc3lzZGljdCwgImV4Y2VwdGhvb2siKSk7DQoJUHlfWERFQ1JFRihzeXNp bik7DQoJUHlfWERFQ1JFRihzeXNvdXQpOw0KCVB5X1hERUNSRUYoc3lzZXJy KTsNCglQeURpY3RfU2V0SXRlbVN0cmluZyhzeXNkaWN0LCAidmVyc2lvbiIs DQoJCQkgICAgIHYgPSBQeVN0cmluZ19Gcm9tU3RyaW5nKFB5X0dldFZlcnNp b24oKSkpOw0KCVB5X1hERUNSRUYodik7DQoJUHlEaWN0X1NldEl0ZW1TdHJp bmcoc3lzZGljdCwgImhleHZlcnNpb24iLA0KCQkJICAgICB2ID0gUHlJbnRf RnJvbUxvbmcoUFlfVkVSU0lPTl9IRVgpKTsNCglQeV9YREVDUkVGKHYpOw0K CS8qDQoJICogVGhlc2UgcmVsZWFzZSBsZXZlbCBjaGVja3MgYXJlIG11dHVh bGx5IGV4Y2x1c2l2ZSBhbmQgY292ZXINCgkgKiB0aGUgZmllbGQsIHNvIGRv bid0IGdldCB0b28gZmFuY3kgd2l0aCB0aGUgcHJlLXByb2Nlc3NvciENCgkg Ki8NCiNpZiBQWV9SRUxFQVNFX0xFVkVMID09IFBZX1JFTEVBU0VfTEVWRUxf QUxQSEENCglzID0gImFscGhhIjsNCiNlbGlmIFBZX1JFTEVBU0VfTEVWRUwg PT0gUFlfUkVMRUFTRV9MRVZFTF9CRVRBDQoJcyA9ICJiZXRhIjsNCiNlbGlm IFBZX1JFTEVBU0VfTEVWRUwgPT0gUFlfUkVMRUFTRV9MRVZFTF9HQU1NQQ0K CXMgPSAiY2FuZGlkYXRlIjsNCiNlbGlmIFBZX1JFTEVBU0VfTEVWRUwgPT0g UFlfUkVMRUFTRV9MRVZFTF9GSU5BTA0KCXMgPSAiZmluYWwiOw0KI2VuZGlm DQoJUHlEaWN0X1NldEl0ZW1TdHJpbmcoc3lzZGljdCwgInZlcnNpb25faW5m byIsDQoJCQkgICAgIHYgPSBQeV9CdWlsZFZhbHVlKCJpaWlzaSIsIFBZX01B Sk9SX1ZFUlNJT04sDQoJCQkJCSAgICAgICBQWV9NSU5PUl9WRVJTSU9OLA0K CQkJCQkgICAgICAgUFlfTUlDUk9fVkVSU0lPTiwgcywNCgkJCQkJICAgICAg IFBZX1JFTEVBU0VfU0VSSUFMKSk7DQoJUHlfWERFQ1JFRih2KTsNCglQeURp Y3RfU2V0SXRlbVN0cmluZyhzeXNkaWN0LCAiY29weXJpZ2h0IiwNCgkJCSAg ICAgdiA9IFB5U3RyaW5nX0Zyb21TdHJpbmcoUHlfR2V0Q29weXJpZ2h0KCkp KTsNCglQeV9YREVDUkVGKHYpOw0KCVB5RGljdF9TZXRJdGVtU3RyaW5nKHN5 c2RpY3QsICJwbGF0Zm9ybSIsDQoJCQkgICAgIHYgPSBQeVN0cmluZ19Gcm9t U3RyaW5nKFB5X0dldFBsYXRmb3JtKCkpKTsNCglQeV9YREVDUkVGKHYpOw0K CVB5RGljdF9TZXRJdGVtU3RyaW5nKHN5c2RpY3QsICJleGVjdXRhYmxlIiwN CgkJCSAgICAgdiA9IFB5U3RyaW5nX0Zyb21TdHJpbmcoUHlfR2V0UHJvZ3Jh bUZ1bGxQYXRoKCkpKTsNCglQeV9YREVDUkVGKHYpOw0KCVB5RGljdF9TZXRJ dGVtU3RyaW5nKHN5c2RpY3QsICJwcmVmaXgiLA0KCQkJICAgICB2ID0gUHlT dHJpbmdfRnJvbVN0cmluZyhQeV9HZXRQcmVmaXgoKSkpOw0KCVB5X1hERUNS RUYodik7DQoJUHlEaWN0X1NldEl0ZW1TdHJpbmcoc3lzZGljdCwgImV4ZWNf cHJlZml4IiwNCgkJICAgdiA9IFB5U3RyaW5nX0Zyb21TdHJpbmcoUHlfR2V0 RXhlY1ByZWZpeCgpKSk7DQoJUHlfWERFQ1JFRih2KTsNCglQeURpY3RfU2V0 SXRlbVN0cmluZyhzeXNkaWN0LCAibWF4aW50IiwNCgkJCSAgICAgdiA9IFB5 SW50X0Zyb21Mb25nKFB5SW50X0dldE1heCgpKSk7DQoJUHlfWERFQ1JFRih2 KTsNCiNpZmRlZiBQeV9VU0lOR19VTklDT0RFDQoJUHlEaWN0X1NldEl0ZW1T dHJpbmcoc3lzZGljdCwgIm1heHVuaWNvZGUiLA0KCQkJICAgICB2ID0gUHlJ bnRfRnJvbUxvbmcoUHlVbmljb2RlX0dldE1heCgpKSk7DQoJUHlfWERFQ1JF Rih2KTsNCiNlbmRpZg0KCVB5RGljdF9TZXRJdGVtU3RyaW5nKHN5c2RpY3Qs ICJidWlsdGluX21vZHVsZV9uYW1lcyIsDQoJCSAgIHYgPSBsaXN0X2J1aWx0 aW5fbW9kdWxlX25hbWVzKCkpOw0KCVB5X1hERUNSRUYodik7DQoJew0KCQkv KiBBc3N1bWVzIHRoYXQgbG9uZ3MgYXJlIGF0IGxlYXN0IDIgYnl0ZXMgbG9u Zy4NCgkJICAgU2hvdWxkIGJlIHNhZmUhICovDQoJCXVuc2lnbmVkIGxvbmcg bnVtYmVyID0gMTsNCgkJY2hhciAqdmFsdWU7DQoNCgkJcyA9IChjaGFyICop ICZudW1iZXI7DQoJCWlmIChzWzBdID09IDApDQoJCQl2YWx1ZSA9ICJiaWci Ow0KCQllbHNlDQoJCQl2YWx1ZSA9ICJsaXR0bGUiOw0KCQlQeURpY3RfU2V0 SXRlbVN0cmluZyhzeXNkaWN0LCAiYnl0ZW9yZGVyIiwNCgkJCQkgICAgIHYg PSBQeVN0cmluZ19Gcm9tU3RyaW5nKHZhbHVlKSk7DQoJCVB5X1hERUNSRUYo dik7DQoJfQ0KI2lmZGVmIE1TX0NPUkVETEwNCglQeURpY3RfU2V0SXRlbVN0 cmluZyhzeXNkaWN0LCAiZGxsaGFuZGxlIiwNCgkJCSAgICAgdiA9IFB5TG9u Z19Gcm9tVm9pZFB0cihQeVdpbl9ETExoTW9kdWxlKSk7DQoJUHlfWERFQ1JF Rih2KTsNCglQeURpY3RfU2V0SXRlbVN0cmluZyhzeXNkaWN0LCAid2ludmVy IiwNCgkJCSAgICAgdiA9IFB5U3RyaW5nX0Zyb21TdHJpbmcoUHlXaW5fRExM VmVyc2lvblN0cmluZykpOw0KCVB5X1hERUNSRUYodik7DQojZW5kaWYNCglp ZiAod2Fybm9wdGlvbnMgPT0gTlVMTCkgew0KCQl3YXJub3B0aW9ucyA9IFB5 TGlzdF9OZXcoMCk7DQoJfQ0KCWVsc2Ugew0KCQlQeV9JTkNSRUYod2Fybm9w dGlvbnMpOw0KCX0NCglpZiAod2Fybm9wdGlvbnMgIT0gTlVMTCkgew0KCQlQ eURpY3RfU2V0SXRlbVN0cmluZyhzeXNkaWN0LCAid2Fybm9wdGlvbnMiLCB3 YXJub3B0aW9ucyk7DQoJfQ0KCQ0KCWlmIChQeUVycl9PY2N1cnJlZCgpKQ0K CQlyZXR1cm4gTlVMTDsNCglyZXR1cm4gbTsNCn0NCg0Kc3RhdGljIFB5T2Jq ZWN0ICoNCm1ha2VwYXRob2JqZWN0KGNoYXIgKnBhdGgsIGludCBkZWxpbSkN CnsNCglpbnQgaSwgbjsNCgljaGFyICpwOw0KCVB5T2JqZWN0ICp2LCAqdzsN CgkNCgluID0gMTsNCglwID0gcGF0aDsNCgl3aGlsZSAoKHAgPSBzdHJjaHIo cCwgZGVsaW0pKSAhPSBOVUxMKSB7DQoJCW4rKzsNCgkJcCsrOw0KCX0NCgl2 ID0gUHlMaXN0X05ldyhuKTsNCglpZiAodiA9PSBOVUxMKQ0KCQlyZXR1cm4g TlVMTDsNCglmb3IgKGkgPSAwOyA7IGkrKykgew0KCQlwID0gc3RyY2hyKHBh dGgsIGRlbGltKTsNCgkJaWYgKHAgPT0gTlVMTCkNCgkJCXAgPSBzdHJjaHIo cGF0aCwgJ1wwJyk7IC8qIEVuZCBvZiBzdHJpbmcgKi8NCgkJdyA9IFB5U3Ry aW5nX0Zyb21TdHJpbmdBbmRTaXplKHBhdGgsIChpbnQpIChwIC0gcGF0aCkp Ow0KCQlpZiAodyA9PSBOVUxMKSB7DQoJCQlQeV9ERUNSRUYodik7DQoJCQly ZXR1cm4gTlVMTDsNCgkJfQ0KCQlQeUxpc3RfU2V0SXRlbSh2LCBpLCB3KTsN CgkJaWYgKCpwID09ICdcMCcpDQoJCQlicmVhazsNCgkJcGF0aCA9IHArMTsN Cgl9DQoJcmV0dXJuIHY7DQp9DQoNCnZvaWQNClB5U3lzX1NldFBhdGgoY2hh ciAqcGF0aCkNCnsNCglQeU9iamVjdCAqdjsNCglpZiAoKHYgPSBtYWtlcGF0 aG9iamVjdChwYXRoLCBERUxJTSkpID09IE5VTEwpDQoJCVB5X0ZhdGFsRXJy b3IoImNhbid0IGNyZWF0ZSBzeXMucGF0aCIpOw0KCWlmIChQeVN5c19TZXRP YmplY3QoInBhdGgiLCB2KSAhPSAwKQ0KCQlQeV9GYXRhbEVycm9yKCJjYW4n dCBhc3NpZ24gc3lzLnBhdGgiKTsNCglQeV9ERUNSRUYodik7DQp9DQoNCnN0 YXRpYyBQeU9iamVjdCAqDQptYWtlYXJndm9iamVjdChpbnQgYXJnYywgY2hh ciAqKmFyZ3YpDQp7DQoJUHlPYmplY3QgKmF2Ow0KCWlmIChhcmdjIDw9IDAg fHwgYXJndiA9PSBOVUxMKSB7DQoJCS8qIEVuc3VyZSBhdCBsZWFzdCBvbmUg KGVtcHR5KSBhcmd1bWVudCBpcyBzZWVuICovDQoJCXN0YXRpYyBjaGFyICpl bXB0eV9hcmd2WzFdID0geyIifTsNCgkJYXJndiA9IGVtcHR5X2FyZ3Y7DQoJ CWFyZ2MgPSAxOw0KCX0NCglhdiA9IFB5TGlzdF9OZXcoYXJnYyk7DQoJaWYg KGF2ICE9IE5VTEwpIHsNCgkJaW50IGk7DQoJCWZvciAoaSA9IDA7IGkgPCBh cmdjOyBpKyspIHsNCgkJCVB5T2JqZWN0ICp2ID0gUHlTdHJpbmdfRnJvbVN0 cmluZyhhcmd2W2ldKTsNCgkJCWlmICh2ID09IE5VTEwpIHsNCgkJCQlQeV9E RUNSRUYoYXYpOw0KCQkJCWF2ID0gTlVMTDsNCgkJCQlicmVhazsNCgkJCX0N CgkJCVB5TGlzdF9TZXRJdGVtKGF2LCBpLCB2KTsNCgkJfQ0KCX0NCglyZXR1 cm4gYXY7DQp9DQoNCnZvaWQNClB5U3lzX1NldEFyZ3YoaW50IGFyZ2MsIGNo YXIgKiphcmd2KQ0Kew0KCVB5T2JqZWN0ICphdiA9IG1ha2Vhcmd2b2JqZWN0 KGFyZ2MsIGFyZ3YpOw0KCVB5T2JqZWN0ICpwYXRoID0gUHlTeXNfR2V0T2Jq ZWN0KCJwYXRoIik7DQoJaWYgKGF2ID09IE5VTEwpDQoJCVB5X0ZhdGFsRXJy b3IoIm5vIG1lbSBmb3Igc3lzLmFyZ3YiKTsNCglpZiAoUHlTeXNfU2V0T2Jq ZWN0KCJhcmd2IiwgYXYpICE9IDApDQoJCVB5X0ZhdGFsRXJyb3IoImNhbid0 IGFzc2lnbiBzeXMuYXJndiIpOw0KCWlmIChwYXRoICE9IE5VTEwpIHsNCgkJ Y2hhciAqYXJndjAgPSBhcmd2WzBdOw0KCQljaGFyICpwID0gTlVMTDsNCgkJ aW50IG4gPSAwOw0KCQlQeU9iamVjdCAqYTsNCiNpZmRlZiBIQVZFX1JFQURM SU5LDQoJCWNoYXIgbGlua1tNQVhQQVRITEVOKzFdOw0KCQljaGFyIGFyZ3Yw Y29weVsyKk1BWFBBVEhMRU4rMV07DQoJCWludCBuciA9IDA7DQoJCWlmIChh cmdjID4gMCAmJiBhcmd2MCAhPSBOVUxMKQ0KCQkJbnIgPSByZWFkbGluayhh cmd2MCwgbGluaywgTUFYUEFUSExFTik7DQoJCWlmIChuciA+IDApIHsNCgkJ CS8qIEl0J3MgYSBzeW1saW5rICovDQoJCQlsaW5rW25yXSA9ICdcMCc7DQoJ CQlpZiAobGlua1swXSA9PSBTRVApDQoJCQkJYXJndjAgPSBsaW5rOyAvKiBM aW5rIHRvIGFic29sdXRlIHBhdGggKi8NCgkJCWVsc2UgaWYgKHN0cmNocihs aW5rLCBTRVApID09IE5VTEwpDQoJCQkJOyAvKiBMaW5rIHdpdGhvdXQgcGF0 aCAqLw0KCQkJZWxzZSB7DQoJCQkJLyogTXVzdCBqb2luKGRpcm5hbWUoYXJn djApLCBsaW5rKSAqLw0KCQkJCWNoYXIgKnEgPSBzdHJyY2hyKGFyZ3YwLCBT RVApOw0KCQkJCWlmIChxID09IE5VTEwpDQoJCQkJCWFyZ3YwID0gbGluazsg LyogYXJndjAgd2l0aG91dCBwYXRoICovDQoJCQkJZWxzZSB7DQoJCQkJCS8q IE11c3QgbWFrZSBhIGNvcHkgKi8NCgkJCQkJc3RyY3B5KGFyZ3YwY29weSwg YXJndjApOw0KCQkJCQlxID0gc3RycmNocihhcmd2MGNvcHksIFNFUCk7DQoJ CQkJCXN0cmNweShxKzEsIGxpbmspOw0KCQkJCQlhcmd2MCA9IGFyZ3YwY29w eTsNCgkJCQl9DQoJCQl9DQoJCX0NCiNlbmRpZiAvKiBIQVZFX1JFQURMSU5L ICovDQojaWYgU0VQID09ICdcXCcgLyogU3BlY2lhbCBjYXNlIGZvciBNUyBm aWxlbmFtZSBzeW50YXggKi8NCgkJaWYgKGFyZ2MgPiAwICYmIGFyZ3YwICE9 IE5VTEwpIHsNCgkJCWNoYXIgKnE7DQoJCQlwID0gc3RycmNocihhcmd2MCwg U0VQKTsNCgkJCS8qIFRlc3QgZm9yIGFsdGVybmF0ZSBzZXBhcmF0b3IgKi8N CgkJCXEgPSBzdHJyY2hyKHAgPyBwIDogYXJndjAsICcvJyk7DQoJCQlpZiAo cSAhPSBOVUxMKQ0KCQkJCXAgPSBxOw0KCQkJaWYgKHAgIT0gTlVMTCkgew0K CQkJCW4gPSBwICsgMSAtIGFyZ3YwOw0KCQkJCWlmIChuID4gMSAmJiBwWy0x XSAhPSAnOicpDQoJCQkJCW4tLTsgLyogRHJvcCB0cmFpbGluZyBzZXBhcmF0 b3IgKi8NCgkJCX0NCgkJfQ0KI2Vsc2UgLyogQWxsIG90aGVyIGZpbGVuYW1l IHN5bnRheGVzICovDQoJCWlmIChhcmdjID4gMCAmJiBhcmd2MCAhPSBOVUxM KQ0KCQkJcCA9IHN0cnJjaHIoYXJndjAsIFNFUCk7DQoJCWlmIChwICE9IE5V TEwpIHsNCiNpZm5kZWYgUklTQ09TDQoJCQluID0gcCArIDEgLSBhcmd2MDsN CiNlbHNlIC8qIGRvbid0IGluY2x1ZGUgdHJhaWxpbmcgc2VwYXJhdG9yICov DQoJCQluID0gcCAtIGFyZ3YwOw0KI2VuZGlmIC8qIFJJU0NPUyAqLw0KI2lm IFNFUCA9PSAnLycgLyogU3BlY2lhbCBjYXNlIGZvciBVbml4IGZpbGVuYW1l IHN5bnRheCAqLw0KCQkJaWYgKG4gPiAxKQ0KCQkJCW4tLTsgLyogRHJvcCB0 cmFpbGluZyBzZXBhcmF0b3IgKi8NCiNlbmRpZiAvKiBVbml4ICovDQoJCX0N CiNlbmRpZiAvKiBBbGwgb3RoZXJzICovDQoJCWEgPSBQeVN0cmluZ19Gcm9t U3RyaW5nQW5kU2l6ZShhcmd2MCwgbik7DQoJCWlmIChhID09IE5VTEwpDQoJ CQlQeV9GYXRhbEVycm9yKCJubyBtZW0gZm9yIHN5cy5wYXRoIGluc2VydGlv biIpOw0KCQlpZiAoUHlMaXN0X0luc2VydChwYXRoLCAwLCBhKSA8IDApDQoJ CQlQeV9GYXRhbEVycm9yKCJzeXMucGF0aC5pbnNlcnQoMCkgZmFpbGVkIik7 DQoJCVB5X0RFQ1JFRihhKTsNCgl9DQoJUHlfREVDUkVGKGF2KTsNCn0NCg0K DQovKiBBUElzIHRvIHdyaXRlIHRvIHN5cy5zdGRvdXQgb3Igc3lzLnN0ZGVy ciB1c2luZyBhIHByaW50Zi1saWtlIGludGVyZmFjZS4NCiAgIEFkYXB0ZWQg ZnJvbSBjb2RlIHN1Ym1pdHRlZCBieSBKdXN0IHZhbiBSb3NzdW0uDQoNCiAg IFB5U3lzX1dyaXRlU3Rkb3V0KGZvcm1hdCwgLi4uKQ0KICAgUHlTeXNfV3Jp dGVTdGRlcnIoZm9ybWF0LCAuLi4pDQoNCiAgICAgIFRoZSBmaXJzdCBmdW5j dGlvbiB3cml0ZXMgdG8gc3lzLnN0ZG91dDsgdGhlIHNlY29uZCB0byBzeXMu c3RkZXJyLiAgV2hlbg0KICAgICAgdGhlcmUgaXMgYSBwcm9ibGVtLCB0aGV5 IHdyaXRlIHRvIHRoZSByZWFsIChDIGxldmVsKSBzdGRvdXQgb3Igc3RkZXJy Ow0KICAgICAgbm8gZXhjZXB0aW9ucyBhcmUgcmFpc2VkLg0KDQogICAgICBC b3RoIHRha2UgYSBwcmludGYtc3R5bGUgZm9ybWF0IHN0cmluZyBhcyB0aGVp ciBmaXJzdCBhcmd1bWVudCBmb2xsb3dlZA0KICAgICAgYnkgYSB2YXJpYWJs ZSBsZW5ndGggYXJndW1lbnQgbGlzdCBkZXRlcm1pbmVkIGJ5IHRoZSBmb3Jt YXQgc3RyaW5nLg0KDQogICAgICAqKiogV0FSTklORyAqKioNCg0KICAgICAg VGhlIGZvcm1hdCBzaG91bGQgbGltaXQgdGhlIHRvdGFsIHNpemUgb2YgdGhl IGZvcm1hdHRlZCBvdXRwdXQgc3RyaW5nIHRvDQogICAgICAxMDAwIGJ5dGVz LiAgSW4gcGFydGljdWxhciwgdGhpcyBtZWFucyB0aGF0IG5vIHVucmVzdHJp Y3RlZCAiJXMiIGZvcm1hdHMNCiAgICAgIHNob3VsZCBvY2N1cjsgdGhlc2Ug c2hvdWxkIGJlIGxpbWl0ZWQgdXNpbmcgIiUuPE4+cyB3aGVyZSA8Tj4gaXMg YQ0KICAgICAgZGVjaW1hbCBudW1iZXIgY2FsY3VsYXRlZCBzbyB0aGF0IDxO PiBwbHVzIHRoZSBtYXhpbXVtIHNpemUgb2Ygb3RoZXINCiAgICAgIGZvcm1h dHRlZCB0ZXh0IGRvZXMgbm90IGV4Y2VlZCAxMDAwIGJ5dGVzLiAgQWxzbyB3 YXRjaCBvdXQgZm9yICIlZiIsDQogICAgICB3aGljaCBjYW4gcHJpbnQgaHVu ZHJlZHMgb2YgZGlnaXRzIGZvciB2ZXJ5IGxhcmdlIG51bWJlcnMuDQoNCiAq Lw0KDQpzdGF0aWMgdm9pZA0KbXl3cml0ZShjaGFyICpuYW1lLCBGSUxFICpm cCwgY29uc3QgY2hhciAqZm9ybWF0LCB2YV9saXN0IHZhKQ0Kew0KCVB5T2Jq ZWN0ICpmaWxlOw0KCVB5T2JqZWN0ICplcnJvcl90eXBlLCAqZXJyb3JfdmFs dWUsICplcnJvcl90cmFjZWJhY2s7DQoNCglQeUVycl9GZXRjaCgmZXJyb3Jf dHlwZSwgJmVycm9yX3ZhbHVlLCAmZXJyb3JfdHJhY2ViYWNrKTsNCglmaWxl ID0gUHlTeXNfR2V0T2JqZWN0KG5hbWUpOw0KCWlmIChmaWxlID09IE5VTEwg fHwgUHlGaWxlX0FzRmlsZShmaWxlKSA9PSBmcCkNCgkJdmZwcmludGYoZnAs IGZvcm1hdCwgdmEpOw0KCWVsc2Ugew0KCQljaGFyIGJ1ZmZlclsxMDAxXTsN CgkJY29uc3QgaW50IHdyaXR0ZW4gPSBQeU9TX3ZzbnByaW50ZihidWZmZXIs IHNpemVvZihidWZmZXIpLA0KCQkJCQkJICAgZm9ybWF0LCB2YSk7DQoJCWlm IChQeUZpbGVfV3JpdGVTdHJpbmcoYnVmZmVyLCBmaWxlKSAhPSAwKSB7DQoJ CQlQeUVycl9DbGVhcigpOw0KCQkJZnB1dHMoYnVmZmVyLCBmcCk7DQoJCX0N CgkJaWYgKHdyaXR0ZW4gPCAwIHx8IHdyaXR0ZW4gPj0gc2l6ZW9mKGJ1ZmZl cikpIHsNCgkJCWNvbnN0IGNoYXIgKnRydW5jYXRlZCA9ICIuLi4gdHJ1bmNh dGVkIjsNCgkJCWlmIChQeUZpbGVfV3JpdGVTdHJpbmcodHJ1bmNhdGVkLCBm aWxlKSAhPSAwKSB7DQoJCQkJUHlFcnJfQ2xlYXIoKTsNCgkJCQlmcHV0cyh0 cnVuY2F0ZWQsIGZwKTsNCgkJCX0NCgkJfQ0KCX0NCglQeUVycl9SZXN0b3Jl KGVycm9yX3R5cGUsIGVycm9yX3ZhbHVlLCBlcnJvcl90cmFjZWJhY2spOw0K fQ0KDQp2b2lkDQpQeVN5c19Xcml0ZVN0ZG91dChjb25zdCBjaGFyICpmb3Jt YXQsIC4uLikNCnsNCgl2YV9saXN0IHZhOw0KDQoJdmFfc3RhcnQodmEsIGZv cm1hdCk7DQoJbXl3cml0ZSgic3Rkb3V0Iiwgc3Rkb3V0LCBmb3JtYXQsIHZh KTsNCgl2YV9lbmQodmEpOw0KfQ0KDQp2b2lkDQpQeVN5c19Xcml0ZVN0ZGVy cihjb25zdCBjaGFyICpmb3JtYXQsIC4uLikNCnsNCgl2YV9saXN0IHZhOw0K DQoJdmFfc3RhcnQodmEsIGZvcm1hdCk7DQoJbXl3cml0ZSgic3RkZXJyIiwg c3RkZXJyLCBmb3JtYXQsIHZhKTsNCgl2YV9lbmQodmEpOw0KfQ0K ---1744662849-2028139461-1012167753=:4093 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="pystate.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="pystate.c" DQovKiBUaHJlYWQgYW5kIGludGVycHJldGVyIHN0YXRlIHN0cnVjdHVyZXMg YW5kIHRoZWlyIGludGVyZmFjZXMgKi8NCg0KI2luY2x1ZGUgIlB5dGhvbi5o Ig0KDQojaWZkZWYgSEFWRV9ETE9QRU4NCiNpZmRlZiBIQVZFX0RMRkNOX0gN CiNpbmNsdWRlIDxkbGZjbi5oPg0KI2VuZGlmDQojaWZuZGVmIFJUTERfTEFa WQ0KI2RlZmluZSBSVExEX0xBWlkgMQ0KI2VuZGlmDQojZW5kaWYNCg0KDQoj ZGVmaW5lIFpBUCh4KSB7IFwNCglQeU9iamVjdCAqdG1wID0gKFB5T2JqZWN0 ICopKHgpOyBcDQoJKHgpID0gTlVMTDsgXA0KCVB5X1hERUNSRUYodG1wKTsg XA0KfQ0KDQoNCiNpZmRlZiBXSVRIX1RIUkVBRA0KI2luY2x1ZGUgInB5dGhy ZWFkLmgiDQpzdGF0aWMgUHlUaHJlYWRfdHlwZV9sb2NrIGhlYWRfbXV0ZXgg PSBOVUxMOyAvKiBQcm90ZWN0cyBpbnRlcnAtPnRzdGF0ZV9oZWFkICovDQoj ZGVmaW5lIEhFQURfSU5JVCgpICh2b2lkKShoZWFkX211dGV4IHx8IChoZWFk X211dGV4ID0gUHlUaHJlYWRfYWxsb2NhdGVfbG9jaygpKSkNCiNkZWZpbmUg SEVBRF9MT0NLKCkgUHlUaHJlYWRfYWNxdWlyZV9sb2NrKGhlYWRfbXV0ZXgs IFdBSVRfTE9DSykNCiNkZWZpbmUgSEVBRF9VTkxPQ0soKSBQeVRocmVhZF9y ZWxlYXNlX2xvY2soaGVhZF9tdXRleCkNCiNlbHNlDQojZGVmaW5lIEhFQURf SU5JVCgpIC8qIE5vdGhpbmcgKi8NCiNkZWZpbmUgSEVBRF9MT0NLKCkgLyog Tm90aGluZyAqLw0KI2RlZmluZSBIRUFEX1VOTE9DSygpIC8qIE5vdGhpbmcg Ki8NCiNlbmRpZg0KDQojaWZkZWYgV0lUSF9EWUxEDQojaW5jbHVkZSA8bWFj aC1vL2R5bGQuaD4NCiNlbmRpZg0KDQpzdGF0aWMgUHlJbnRlcnByZXRlclN0 YXRlICppbnRlcnBfaGVhZCA9IE5VTEw7DQoNClB5VGhyZWFkU3RhdGUgKl9Q eVRocmVhZFN0YXRlX0N1cnJlbnQgPSBOVUxMOw0KDQoNClB5SW50ZXJwcmV0 ZXJTdGF0ZSAqDQpQeUludGVycHJldGVyU3RhdGVfTmV3KHZvaWQpDQp7DQoJ UHlJbnRlcnByZXRlclN0YXRlICppbnRlcnAgPSBQeU1lbV9ORVcoUHlJbnRl cnByZXRlclN0YXRlLCAxKTsNCg0KCWlmIChpbnRlcnAgIT0gTlVMTCkgew0K CQlIRUFEX0lOSVQoKTsNCgkJaW50ZXJwLT5tb2R1bGVzID0gTlVMTDsNCgkJ aW50ZXJwLT5zeXNkaWN0ID0gTlVMTDsNCgkJaW50ZXJwLT5idWlsdGlucyA9 IE5VTEw7DQoJCWludGVycC0+Y2hlY2tpbnRlcnZhbCA9IDEwOw0KCQlpbnRl cnAtPnRzdGF0ZV9oZWFkID0gTlVMTDsNCiNpZmRlZiBIQVZFX0RMT1BFTg0K I2lmZGVmIFJUTERfTk9XDQoJCWludGVycC0+ZGxvcGVuZmxhZ3MgPSBSVExE X05PVzsNCiNlbHNlDQoJCWludGVycC0+ZGxvcGVuZmxhZ3MgPSBSVExEX0xB Wlk7DQojZW5kaWYNCiNlbmRpZg0KDQojaWZkZWYgV0lUSF9EWUxEDQoJCWlu dGVycC0+ZGxvcGVuZmxhZ3MgPSBOU0xJTktNT0RVTEVfT1BUSU9OX0JJTkRO T1cgfCBOU0xJTktNT0RVTEVfT1BUSU9OX1JFVFVSTl9PTl9FUlJPUiB8IE5T TElOS01PRFVMRV9PUFRJT05fUFJJVkFURTsNCiNlbmRpZg0KDQoJCUhFQURf TE9DSygpOw0KCQlpbnRlcnAtPm5leHQgPSBpbnRlcnBfaGVhZDsNCgkJaW50 ZXJwX2hlYWQgPSBpbnRlcnA7DQoJCUhFQURfVU5MT0NLKCk7DQoJfQ0KDQoJ cmV0dXJuIGludGVycDsNCn0NCg0KDQp2b2lkDQpQeUludGVycHJldGVyU3Rh dGVfQ2xlYXIoUHlJbnRlcnByZXRlclN0YXRlICppbnRlcnApDQp7DQoJUHlU aHJlYWRTdGF0ZSAqcDsNCglIRUFEX0xPQ0soKTsNCglmb3IgKHAgPSBpbnRl cnAtPnRzdGF0ZV9oZWFkOyBwICE9IE5VTEw7IHAgPSBwLT5uZXh0KQ0KCQlQ eVRocmVhZFN0YXRlX0NsZWFyKHApOw0KCUhFQURfVU5MT0NLKCk7DQoJWkFQ KGludGVycC0+bW9kdWxlcyk7DQoJWkFQKGludGVycC0+c3lzZGljdCk7DQoJ WkFQKGludGVycC0+YnVpbHRpbnMpOw0KfQ0KDQoNCnN0YXRpYyB2b2lkDQp6 YXB0aHJlYWRzKFB5SW50ZXJwcmV0ZXJTdGF0ZSAqaW50ZXJwKQ0Kew0KCVB5 VGhyZWFkU3RhdGUgKnA7DQoJLyogTm8gbmVlZCB0byBsb2NrIHRoZSBtdXRl eCBoZXJlIGJlY2F1c2UgdGhpcyBzaG91bGQgb25seSBoYXBwZW4NCgkgICB3 aGVuIHRoZSB0aHJlYWRzIGFyZSBhbGwgcmVhbGx5IGRlYWQgKFhYWCBmYW1v dXMgbGFzdCB3b3JkcykuICovDQoJd2hpbGUgKChwID0gaW50ZXJwLT50c3Rh dGVfaGVhZCkgIT0gTlVMTCkgew0KCQlQeVRocmVhZFN0YXRlX0RlbGV0ZShw KTsNCgl9DQp9DQoNCg0Kdm9pZA0KUHlJbnRlcnByZXRlclN0YXRlX0RlbGV0 ZShQeUludGVycHJldGVyU3RhdGUgKmludGVycCkNCnsNCglQeUludGVycHJl dGVyU3RhdGUgKipwOw0KCXphcHRocmVhZHMoaW50ZXJwKTsNCglIRUFEX0xP Q0soKTsNCglmb3IgKHAgPSAmaW50ZXJwX2hlYWQ7IDsgcCA9ICYoKnApLT5u ZXh0KSB7DQoJCWlmICgqcCA9PSBOVUxMKQ0KCQkJUHlfRmF0YWxFcnJvcigN CgkJCQkiUHlJbnRlcnByZXRlclN0YXRlX0RlbGV0ZTogaW52YWxpZCBpbnRl cnAiKTsNCgkJaWYgKCpwID09IGludGVycCkNCgkJCWJyZWFrOw0KCX0NCglp ZiAoaW50ZXJwLT50c3RhdGVfaGVhZCAhPSBOVUxMKQ0KCQlQeV9GYXRhbEVy cm9yKCJQeUludGVycHJldGVyU3RhdGVfRGVsZXRlOiByZW1haW5pbmcgdGhy ZWFkcyIpOw0KCSpwID0gaW50ZXJwLT5uZXh0Ow0KCUhFQURfVU5MT0NLKCk7 DQoJUHlNZW1fREVMKGludGVycCk7DQp9DQoNCg0KUHlUaHJlYWRTdGF0ZSAq DQpQeVRocmVhZFN0YXRlX05ldyhQeUludGVycHJldGVyU3RhdGUgKmludGVy cCkNCnsNCglQeVRocmVhZFN0YXRlICp0c3RhdGUgPSBQeU1lbV9ORVcoUHlU aHJlYWRTdGF0ZSwgMSk7DQoNCglpZiAodHN0YXRlICE9IE5VTEwpIHsNCgkJ dHN0YXRlLT5pbnRlcnAgPSBpbnRlcnA7DQoNCgkJdHN0YXRlLT5mcmFtZSA9 IE5VTEw7DQoJCXRzdGF0ZS0+cmVjdXJzaW9uX2RlcHRoID0gMDsNCgkJdHN0 YXRlLT50aWNrZXIgPSAwOw0KCQl0c3RhdGUtPnRyYWNpbmcgPSAwOw0KCQl0 c3RhdGUtPnVzZV90cmFjaW5nID0gMDsNCg0KCQl0c3RhdGUtPmRpY3QgPSBO VUxMOw0KDQoJCXRzdGF0ZS0+Y3VyZXhjX3R5cGUgPSBOVUxMOw0KCQl0c3Rh dGUtPmN1cmV4Y192YWx1ZSA9IE5VTEw7DQoJCXRzdGF0ZS0+Y3VyZXhjX3Ry YWNlYmFjayA9IE5VTEw7DQoNCgkJdHN0YXRlLT5leGNfdHlwZSA9IE5VTEw7 DQoJCXRzdGF0ZS0+ZXhjX3ZhbHVlID0gTlVMTDsNCgkJdHN0YXRlLT5leGNf dHJhY2ViYWNrID0gTlVMTDsNCg0KCQl0c3RhdGUtPmNfcHJvZmlsZWZ1bmMg PSBOVUxMOw0KCQl0c3RhdGUtPmNfdHJhY2VmdW5jID0gTlVMTDsNCgkJdHN0 YXRlLT5jX3Byb2ZpbGVvYmogPSBOVUxMOw0KCQl0c3RhdGUtPmNfdHJhY2Vv YmogPSBOVUxMOw0KDQoJCUhFQURfTE9DSygpOw0KCQl0c3RhdGUtPm5leHQg PSBpbnRlcnAtPnRzdGF0ZV9oZWFkOw0KCQlpbnRlcnAtPnRzdGF0ZV9oZWFk ID0gdHN0YXRlOw0KCQlIRUFEX1VOTE9DSygpOw0KCX0NCg0KCXJldHVybiB0 c3RhdGU7DQp9DQoNCg0Kdm9pZA0KUHlUaHJlYWRTdGF0ZV9DbGVhcihQeVRo cmVhZFN0YXRlICp0c3RhdGUpDQp7DQoJaWYgKFB5X1ZlcmJvc2VGbGFnICYm IHRzdGF0ZS0+ZnJhbWUgIT0gTlVMTCkNCgkJZnByaW50ZihzdGRlcnIsDQoJ CSAgIlB5VGhyZWFkU3RhdGVfQ2xlYXI6IHdhcm5pbmc6IHRocmVhZCBzdGls bCBoYXMgYSBmcmFtZVxuIik7DQoNCglaQVAodHN0YXRlLT5mcmFtZSk7DQoN CglaQVAodHN0YXRlLT5kaWN0KTsNCg0KCVpBUCh0c3RhdGUtPmN1cmV4Y190 eXBlKTsNCglaQVAodHN0YXRlLT5jdXJleGNfdmFsdWUpOw0KCVpBUCh0c3Rh dGUtPmN1cmV4Y190cmFjZWJhY2spOw0KDQoJWkFQKHRzdGF0ZS0+ZXhjX3R5 cGUpOw0KCVpBUCh0c3RhdGUtPmV4Y192YWx1ZSk7DQoJWkFQKHRzdGF0ZS0+ ZXhjX3RyYWNlYmFjayk7DQoNCgl0c3RhdGUtPmNfcHJvZmlsZWZ1bmMgPSBO VUxMOw0KCXRzdGF0ZS0+Y190cmFjZWZ1bmMgPSBOVUxMOw0KCVpBUCh0c3Rh dGUtPmNfcHJvZmlsZW9iaik7DQoJWkFQKHRzdGF0ZS0+Y190cmFjZW9iaik7 DQp9DQoNCg0KLyogQ29tbW9uIGNvZGUgZm9yIFB5VGhyZWFkU3RhdGVfRGVs ZXRlKCkgYW5kIFB5VGhyZWFkU3RhdGVfRGVsZXRlQ3VycmVudCgpICovDQpz dGF0aWMgdm9pZA0KdHN0YXRlX2RlbGV0ZV9jb21tb24oUHlUaHJlYWRTdGF0 ZSAqdHN0YXRlKQ0Kew0KCVB5SW50ZXJwcmV0ZXJTdGF0ZSAqaW50ZXJwOw0K CVB5VGhyZWFkU3RhdGUgKipwOw0KCWlmICh0c3RhdGUgPT0gTlVMTCkNCgkJ UHlfRmF0YWxFcnJvcigiUHlUaHJlYWRTdGF0ZV9EZWxldGU6IE5VTEwgdHN0 YXRlIik7DQoJaW50ZXJwID0gdHN0YXRlLT5pbnRlcnA7DQoJaWYgKGludGVy cCA9PSBOVUxMKQ0KCQlQeV9GYXRhbEVycm9yKCJQeVRocmVhZFN0YXRlX0Rl bGV0ZTogTlVMTCBpbnRlcnAiKTsNCglIRUFEX0xPQ0soKTsNCglmb3IgKHAg PSAmaW50ZXJwLT50c3RhdGVfaGVhZDsgOyBwID0gJigqcCktPm5leHQpIHsN CgkJaWYgKCpwID09IE5VTEwpDQoJCQlQeV9GYXRhbEVycm9yKA0KCQkJCSJQ eVRocmVhZFN0YXRlX0RlbGV0ZTogaW52YWxpZCB0c3RhdGUiKTsNCgkJaWYg KCpwID09IHRzdGF0ZSkNCgkJCWJyZWFrOw0KCX0NCgkqcCA9IHRzdGF0ZS0+ bmV4dDsNCglIRUFEX1VOTE9DSygpOw0KCVB5TWVtX0RFTCh0c3RhdGUpOw0K fQ0KDQoNCnZvaWQNClB5VGhyZWFkU3RhdGVfRGVsZXRlKFB5VGhyZWFkU3Rh dGUgKnRzdGF0ZSkNCnsNCglpZiAodHN0YXRlID09IF9QeVRocmVhZFN0YXRl X0N1cnJlbnQpDQoJCVB5X0ZhdGFsRXJyb3IoIlB5VGhyZWFkU3RhdGVfRGVs ZXRlOiB0c3RhdGUgaXMgc3RpbGwgY3VycmVudCIpOw0KCXRzdGF0ZV9kZWxl dGVfY29tbW9uKHRzdGF0ZSk7DQp9DQoNCg0KI2lmZGVmIFdJVEhfVEhSRUFE DQp2b2lkDQpQeVRocmVhZFN0YXRlX0RlbGV0ZUN1cnJlbnQoKQ0Kew0KCVB5 VGhyZWFkU3RhdGUgKnRzdGF0ZSA9IF9QeVRocmVhZFN0YXRlX0N1cnJlbnQ7 DQoJaWYgKHRzdGF0ZSA9PSBOVUxMKQ0KCQlQeV9GYXRhbEVycm9yKA0KCQkJ IlB5VGhyZWFkU3RhdGVfRGVsZXRlQ3VycmVudDogbm8gY3VycmVudCB0c3Rh dGUiKTsNCglfUHlUaHJlYWRTdGF0ZV9DdXJyZW50ID0gTlVMTDsNCgl0c3Rh dGVfZGVsZXRlX2NvbW1vbih0c3RhdGUpOw0KCVB5RXZhbF9SZWxlYXNlTG9j aygpOw0KfQ0KI2VuZGlmIC8qIFdJVEhfVEhSRUFEICovDQoNCg0KUHlUaHJl YWRTdGF0ZSAqDQpQeVRocmVhZFN0YXRlX0dldCh2b2lkKQ0Kew0KCWlmIChf UHlUaHJlYWRTdGF0ZV9DdXJyZW50ID09IE5VTEwpDQoJCVB5X0ZhdGFsRXJy b3IoIlB5VGhyZWFkU3RhdGVfR2V0OiBubyBjdXJyZW50IHRocmVhZCIpOw0K DQoJcmV0dXJuIF9QeVRocmVhZFN0YXRlX0N1cnJlbnQ7DQp9DQoNCg0KUHlU aHJlYWRTdGF0ZSAqDQpQeVRocmVhZFN0YXRlX1N3YXAoUHlUaHJlYWRTdGF0 ZSAqbmV3KQ0Kew0KCVB5VGhyZWFkU3RhdGUgKm9sZCA9IF9QeVRocmVhZFN0 YXRlX0N1cnJlbnQ7DQoNCglfUHlUaHJlYWRTdGF0ZV9DdXJyZW50ID0gbmV3 Ow0KDQoJcmV0dXJuIG9sZDsNCn0NCg0KLyogQW4gZXh0ZW5zaW9uIG1lY2hh bmlzbSB0byBzdG9yZSBhcmJpdHJhcnkgYWRkaXRpb25hbCBwZXItdGhyZWFk IHN0YXRlLg0KICAgUHlUaHJlYWRTdGF0ZV9HZXREaWN0KCkgcmV0dXJucyBh IGRpY3Rpb25hcnkgdGhhdCBjYW4gYmUgdXNlZCB0byBob2xkIHN1Y2gNCiAg IHN0YXRlOyB0aGUgY2FsbGVyIHNob3VsZCBwaWNrIGEgdW5pcXVlIGtleSBh bmQgc3RvcmUgaXRzIHN0YXRlIHRoZXJlLiAgSWYNCiAgIFB5VGhyZWFkU3Rh dGVfR2V0RGljdCgpIHJldHVybnMgTlVMTCwgYW4gZXhjZXB0aW9uIGhhcyBi ZWVuIHJhaXNlZCAobW9zdA0KICAgbGlrZWx5IE1lbW9yeUVycm9yKSBhbmQg dGhlIGNhbGxlciBzaG91bGQgcGFzcyBvbiB0aGUgZXhjZXB0aW9uLiAqLw0K DQpQeU9iamVjdCAqDQpQeVRocmVhZFN0YXRlX0dldERpY3Qodm9pZCkNCnsN CglpZiAoX1B5VGhyZWFkU3RhdGVfQ3VycmVudCA9PSBOVUxMKQ0KCQlQeV9G YXRhbEVycm9yKCJQeVRocmVhZFN0YXRlX0dldERpY3Q6IG5vIGN1cnJlbnQg dGhyZWFkIik7DQoNCglpZiAoX1B5VGhyZWFkU3RhdGVfQ3VycmVudC0+ZGlj dCA9PSBOVUxMKQ0KCQlfUHlUaHJlYWRTdGF0ZV9DdXJyZW50LT5kaWN0ID0g UHlEaWN0X05ldygpOw0KCXJldHVybiBfUHlUaHJlYWRTdGF0ZV9DdXJyZW50 LT5kaWN0Ow0KfQ0KDQoNCi8qIFJvdXRpbmVzIGZvciBhZHZhbmNlZCBkZWJ1 Z2dlcnMsIHJlcXVlc3RlZCBieSBEYXZpZCBCZWF6bGV5Lg0KICAgRG9uJ3Qg dXNlIHVubGVzcyB5b3Uga25vdyB3aGF0IHlvdSBhcmUgZG9pbmchICovDQoN ClB5SW50ZXJwcmV0ZXJTdGF0ZSAqDQpQeUludGVycHJldGVyU3RhdGVfSGVh ZCh2b2lkKQ0Kew0KCXJldHVybiBpbnRlcnBfaGVhZDsNCn0NCg0KUHlJbnRl cnByZXRlclN0YXRlICoNClB5SW50ZXJwcmV0ZXJTdGF0ZV9OZXh0KFB5SW50 ZXJwcmV0ZXJTdGF0ZSAqaW50ZXJwKSB7DQoJcmV0dXJuIGludGVycC0+bmV4 dDsNCn0NCg0KUHlUaHJlYWRTdGF0ZSAqDQpQeUludGVycHJldGVyU3RhdGVf VGhyZWFkSGVhZChQeUludGVycHJldGVyU3RhdGUgKmludGVycCkgew0KCXJl dHVybiBpbnRlcnAtPnRzdGF0ZV9oZWFkOw0KfQ0KDQpQeVRocmVhZFN0YXRl ICoNClB5VGhyZWFkU3RhdGVfTmV4dChQeVRocmVhZFN0YXRlICp0c3RhdGUp IHsNCglyZXR1cm4gdHN0YXRlLT5uZXh0Ow0KfQ0K ---1744662849-2028139461-1012167753=:4093 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dynload_next.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dynload_next.c" DQovKiBTdXBwb3J0IGZvciBkeW5hbWljIGxvYWRpbmcgb2YgZXh0ZW5zaW9u IG1vZHVsZXMgKi8NCg0KI2luY2x1ZGUgIlB5dGhvbi5oIg0KI2luY2x1ZGUg ImltcG9ydGRsLmgiDQoNCg0KI2lmZGVmIFdJVEhfRFlMRA0KDQojZGVmaW5l IFVTRV9EWUxEDQoNCiNpbmNsdWRlIDxtYWNoLW8vZHlsZC5oPg0KDQojZWxz ZSAvKiBXSVRIX0RZTEQgKi8NCg0KI2RlZmluZSBVU0VfUkxEDQovKiBEZWZp bmUgdGhpcyB0byAxIGlmIHlvdSB3YW50IGJlIGFibGUgdG8gbG9hZCBPYmpD IG1vZHVsZXMgYXMgd2VsbDoNCiAgIGl0IHN3aXRjaGVzIGJldHdlZW4gdHdv IGRpZmZlcmVudCB3YXkgb2YgbG9hZGluZyBtb2R1bGVzIG9uIHRoZSBOZVhU LA0KICAgb25lIHRoYXQgZGlyZWN0bHkgaW50ZXJmYWNlcyB3aXRoIHRoZSBk eW5hbWljIGxvYWRlciAocmxkX2xvYWQoKSwgd2hpY2gNCiAgIGRvZXMgbm90 IGNvcnJlY3RseSBsb2FkIE9iakMgb2JqZWN0IGZpbGVzKSwgYW5kIGFub3Ro ZXIgdGhhdCB1c2VzIHRoZQ0KICAgT2JqQyBydW50aW1lIChvYmpjX2xvYWRN b2R1bGVzKCkpIHRvIGRvIHRoZSBqb2IuDQogICBZb3UnbGwgaGF2ZSB0byBh ZGQgYGAtT2JqQycnIHRvIHRoZSBjb21waWxlciBmbGFncyBpZiB5b3Ugc2V0 IHRoaXMgdG8gMS4NCiovDQojZGVmaW5lIEhBTkRMRV9PQkpDX01PRFVMRVMg MQ0KI2lmIEhBTkRMRV9PQkpDX01PRFVMRVMNCiNpbmNsdWRlIDxvYmpjL09i amVjdC5oPg0KI2luY2x1ZGUgPG9iamMvb2JqYy1sb2FkLmg+DQojZW5kaWYN Cg0KI2luY2x1ZGUgPG1hY2gtby9ybGQuaD4NCg0KI2VuZGlmIC8qIFdJVEhf RFlMRCAqLw0KDQpjb25zdCBzdHJ1Y3QgZmlsZWRlc2NyIF9QeUltcG9ydF9E eW5Mb2FkRmlsZXRhYltdID0gew0KCXsiLnNvIiwgInJiIiwgQ19FWFRFTlNJ T059LA0KCXsibW9kdWxlLnNvIiwgInJiIiwgQ19FWFRFTlNJT059LA0KCXsw LCAwfQ0KfTsNCg0Kc3RhdGljIGNoYXIgZXJyTWVzc2FnZVsxMDI0XTsNCg0K ZGxfZnVuY3B0ciBfUHlJbXBvcnRfR2V0RHluTG9hZEZ1bmMoY29uc3QgY2hh ciAqZnFuYW1lLCBjb25zdCBjaGFyICpzaG9ydG5hbWUsDQoJCQkJICAgIGNv bnN0IGNoYXIgKnBhdGhuYW1lLCBGSUxFICpmcCkNCnsNCglkbF9mdW5jcHRy IHAgPSBOVUxMOw0KCWNoYXIgZnVuY25hbWVbMjU4XTsNCg0KCVB5T1Nfc25w cmludGYoZnVuY25hbWUsIHNpemVvZihmdW5jbmFtZSksICJfaW5pdCUuMjAw cyIsIHNob3J0bmFtZSk7DQoNCiNpZmRlZiBVU0VfUkxEDQoJew0KCQlOWFN0 cmVhbSAqZXJyb3JTdHJlYW07DQoJCXN0cnVjdCBtYWNoX2hlYWRlciAqbmV3 X2hlYWRlcjsNCgkJY29uc3QgY2hhciAqZmlsZW5hbWVzWzJdOw0KCQlsb25n IHJldDsNCgkJdW5zaWduZWQgbG9uZyBwdHI7DQoNCgkJZXJyb3JTdHJlYW0g PSBOWE9wZW5NZW1vcnkoTlVMTCwgMCwgTlhfV1JJVEVPTkxZKTsNCgkJZmls ZW5hbWVzWzBdID0gcGF0aG5hbWU7DQoJCWZpbGVuYW1lc1sxXSA9IE5VTEw7 DQoNCiNpZiBIQU5ETEVfT0JKQ19NT0RVTEVTDQoNCi8qIFRoZSBmb2xsb3dp bmcgdmVyeSBib2d1cyBsaW5lIG9mIGNvZGUgZW5zdXJlcyB0aGF0DQogICBv YmpjX21zZ1NlbmQsIGV0YyBhcmUgbGlua2VkIGludG8gdGhlIGJpbmFyeS4g IFdpdGhvdXQNCiAgIGl0LCBkeW5hbWljIGxvYWRpbmcgb2YgYSBtb2R1bGUg dGhhdCBpbmNsdWRlcyBvYmplY3RpdmUtYw0KICAgbWV0aG9kIGNhbGxzIHdp bGwgZmFpbCB3aXRoICJ1bmRlZmluZWQgc3ltYm9sIF9vYmpjX21zZ1NlbmQo KSIuDQogICBUaGlzIHJlbWFpbnMgdHJ1ZSBldmVuIGluIHRoZSBwcmVzZW5j ZSBvZiB0aGUgLU9iakMgZmxhZw0KICAgdG8gdGhlIGNvbXBpbGVyDQoqLw0K DQoJCVtPYmplY3QgbmFtZV07DQoNCi8qIG9iamNfbG9hZE1vZHVsZXMoKSBk eW5hbWljYWxseSBsb2FkcyB0aGUgb2JqZWN0IGZpbGVzDQogICBpbmRpY2F0 ZWQgYnkgdGhlIHBhdGhzIGluIGZpbGVuYW1lcy4gIElmIHRoZXJlIGFyZSBh bnkNCiAgIGVycm9ycyBnZW5lcmF0ZWQgZHVyaW5nIGxvYWRpbmcgLS0gdHlw aWNhbGx5IGR1ZSB0byB0aGUNCiAgIGluYWJpbGl0eSB0byBmaW5kIHBhcnRp Y3VsYXIgc3ltYm9scyAtLSBhbiBlcnJvciBtZXNzYWdlDQogICB3aWxsIGJl IHdyaXR0ZW4gdG8gZXJyb3JTdHJlYW0uDQogICBJdCByZXR1cm5zIDAgaWYg dGhlIG1vZHVsZSBpcyBzdWNjZXNzZnVsbHkgbG9hZGVkLCAxDQogICBvdGhl cndpc2UuDQoqLw0KDQoJCXJldCA9ICFvYmpjX2xvYWRNb2R1bGVzKGZpbGVu YW1lcywgZXJyb3JTdHJlYW0sDQoJCQkJCU5VTEwsICZuZXdfaGVhZGVyLCBO VUxMKTsNCg0KI2Vsc2UgLyogIUhBTkRMRV9PQkpDX01PRFVMRVMgKi8NCg0K CQlyZXQgPSBybGRfbG9hZChlcnJvclN0cmVhbSwgJm5ld19oZWFkZXIsIA0K CQkJCWZpbGVuYW1lcywgTlVMTCk7DQoNCiNlbmRpZiAvKiBIQU5ETEVfT0JK Q19NT0RVTEVTICovDQoNCgkJLyogZXh0cmFjdCB0aGUgZXJyb3IgbWVzc2Fn ZXMgZm9yIHRoZSBleGNlcHRpb24gKi8NCgkJaWYoIXJldCkgew0KCQkJY2hh ciAqc3RyZWFtQnVmOw0KCQkJaW50IGxlbiwgbWF4TGVuOw0KDQoJCQlOWFB1 dGMoZXJyb3JTdHJlYW0sIChjaGFyKTApOw0KDQoJCQlOWEdldE1lbW9yeUJ1 ZmZlcihlcnJvclN0cmVhbSwNCgkJCQkmc3RyZWFtQnVmLCAmbGVuLCAmbWF4 TGVuKTsNCgkJCVB5RXJyX1NldFN0cmluZyhQeUV4Y19JbXBvcnRFcnJvciwg c3RyZWFtQnVmKTsNCgkJfQ0KDQoJCWlmKHJldCAmJiBybGRfbG9va3VwKGVy cm9yU3RyZWFtLCBmdW5jbmFtZSwgJnB0cikpDQoJCQlwID0gKGRsX2Z1bmNw dHIpIHB0cjsNCg0KCQlOWENsb3NlTWVtb3J5KGVycm9yU3RyZWFtLCBOWF9G UkVFQlVGRkVSKTsNCg0KCQlpZighcmV0KQ0KCQkJcmV0dXJuIE5VTEw7DQoJ fQ0KI2VuZGlmIC8qIFVTRV9STEQgKi8NCiNpZmRlZiBVU0VfRFlMRA0KCS8q IFRoaXMgaXMgYWxzbyBOZVhULXNwZWNpZmljLiBIb3dldmVyLCBmcmFtZXdv cmtzICh0aGUgbmV3IHN0eWxlDQoJb2Ygc2hhcmVkIGxpYnJhcnkpIGFuZCBy bGQoKSBjYW4ndCBiZSB1c2VkIGluIHRoZSBzYW1lIHByb2dyYW07DQoJaW5z dGVhZCwgeW91IGhhdmUgdG8gdXNlIGR5bGQsIHdoaWNoIGlzIG1vc3RseSB1 bmltcGxlbWVudGVkLiAqLw0KCXsNCgkJTlNPYmplY3RGaWxlSW1hZ2VSZXR1 cm5Db2RlIHJjOw0KCQlOU09iamVjdEZpbGVJbWFnZSBpbWFnZTsNCgkJTlNN b2R1bGUgbmV3TW9kdWxlOw0KCQlOU1N5bWJvbCB0aGVTeW07DQoJCWNoYXIg KmVyclN0cmluZzsNCgkNCgkJcmMgPSBOU0NyZWF0ZU9iamVjdEZpbGVJbWFn ZUZyb21GaWxlKHBhdGhuYW1lLCAmaW1hZ2UpOw0KCQlzd2l0Y2gocmMpIHsN CgkJICAgIGRlZmF1bHQ6DQoJCSAgICBjYXNlIE5TT2JqZWN0RmlsZUltYWdl RmFpbHVyZToNCgkJICAgIGNhc2UgTlNPYmplY3RGaWxlSW1hZ2VGb3JtYXQ6 DQoJCSAgICAvKiBmb3IgdGhlc2UgYSBtZXNzYWdlIGlzIHByaW50ZWQgb24g c3RkZXJyIGJ5IGR5bGQgKi8NCgkJCWVyclN0cmluZyA9ICJDYW4ndCBjcmVh dGUgb2JqZWN0IGZpbGUgaW1hZ2UiOw0KCQkJYnJlYWs7DQoJCSAgICBjYXNl IE5TT2JqZWN0RmlsZUltYWdlU3VjY2VzczoNCgkJCWVyclN0cmluZyA9IE5V TEw7DQoJCQlicmVhazsNCgkJICAgIGNhc2UgTlNPYmplY3RGaWxlSW1hZ2VJ bmFwcHJvcHJpYXRlRmlsZToNCgkJCWVyclN0cmluZyA9ICJJbmFwcHJvcHJp YXRlIGZpbGUgdHlwZSBmb3IgZHluYW1pYyBsb2FkaW5nIjsNCgkJCWJyZWFr Ow0KCQkgICAgY2FzZSBOU09iamVjdEZpbGVJbWFnZUFyY2g6DQoJCQllcnJT dHJpbmcgPSAiV3JvbmcgQ1BVIHR5cGUgaW4gb2JqZWN0IGZpbGUiOw0KCQkJ YnJlYWs7DQoJCSAgICBjYXNlIE5TT2JqZWN0RmlsZUltYWdlQWNjZXNzOg0K CQkJZXJyU3RyaW5nID0gIkNhbid0IHJlYWQgb2JqZWN0IGZpbGUgKG5vIGFj Y2VzcykiOw0KCQkJYnJlYWs7DQoJCX0NCgkJaWYgKGVyclN0cmluZyA9PSBO VUxMKSB7DQoJCQlpbnQgb3B0aW9ucz0gUHlUaHJlYWRTdGF0ZV9HZXQoKS0+ aW50ZXJwLT5kbG9wZW5mbGFnczsNCgkJCW5ld01vZHVsZSA9IE5TTGlua01v ZHVsZShpbWFnZSwgcGF0aG5hbWUsIG9wdGlvbnMpOw0KCQkJTlNEZXN0cm95 T2JqZWN0RmlsZUltYWdlKGltYWdlKTsNCg0KCQkJaWYgKG5ld01vZHVsZSA9 PSBOVUxMKSB7DQoJCQkgICAgaW50IGVyck5vOw0KCQkJICAgIGNoYXIgKmZp bGVOYW1lLCAqbW9yZUVycm9yU3RyOw0KCQkJICAgIE5TTGlua0VkaXRFcnJv cnMgYzsNCgkJCSAgICANCgkJCSAgICBOU0xpbmtFZGl0RXJyb3IoICZjLCAm ZXJyTm8sICZmaWxlTmFtZSwgJm1vcmVFcnJvclN0ciApOw0KCQkJICAgIFB5 T1Nfc25wcmludGYoZXJyTWVzc2FnZSwgc2l6ZW9mKGVyck1lc3NhZ2UpLCAi JXMuICVzXG4lcyIsICJGYWlsdXJlIGxpbmtpbmcgbmV3IG1vZHVsZSIsIGZp bGVOYW1lLCBtb3JlRXJyb3JTdHIpOw0KCQkJICAgIA0KCQkJICAgIGVyclN0 cmluZyA9IGVyck1lc3NhZ2U7DQoJCQl9DQoJCX0NCgkJaWYgKGVyclN0cmlu ZyAhPSBOVUxMKSB7DQoJCQlQeUVycl9TZXRTdHJpbmcoUHlFeGNfSW1wb3J0 RXJyb3IsIGVyclN0cmluZyk7DQoJCQlyZXR1cm4gTlVMTDsNCgkJfQ0KDQoJ CXRoZVN5bSA9IE5TTG9va3VwU3ltYm9sSW5Nb2R1bGUobmV3TW9kdWxlLCBm dW5jbmFtZSk7DQoJCWlmICh0aGVTeW0gPT0gTlVMTCkgew0KCQkJLyogVW5s aW5rTW9kdWxlKCkgaXNuJ3QgaW1wbGVtZW50ZWQgaW4gY3VycmVudCB2ZXJz aW9ucywgYnV0IGNhbGxpbmcgaXQgZG9lcyBubyBoYXJtICovDQoJCQlOU1Vu TGlua01vZHVsZShuZXdNb2R1bGUsIEZBTFNFKTsNCgkJCVB5RXJyX0Zvcm1h dChQeUV4Y19JbXBvcnRFcnJvciwNCgkJCQkgICAgICJMb2FkZWQgbW9kdWxl IGRvZXMgbm90IGNvbnRhaW4gc3ltYm9sICUuMjAwcyIsDQoJCQkJICAgICBm dW5jbmFtZSk7DQoJCQlyZXR1cm4gTlVMTDsNCgkJfQ0KCQlwID0gKGRsX2Z1 bmNwdHIpTlNBZGRyZXNzT2ZTeW1ib2wodGhlU3ltKTsNCiAJfQ0KI2VuZGlm IC8qIFVTRV9EWUxEICovDQoNCglyZXR1cm4gcDsNCn0NCg== ---1744662849-2028139461-1012167753=:4093-- From prastawa@cs.unc.edu Mon Jan 28 01:33:51 2002 From: prastawa@cs.unc.edu (Marcel Prastawa) Date: Sun, 27 Jan 2002 20:33:51 -0500 Subject: [Pythonmac-SIG] dynload_next References: <3C545FE4.6040509@cs.unc.edu> Message-ID: <3C54AA7F.3040309@cs.unc.edu> Marcel Prastawa wrote: > Can we build the Python extensions as dynamic libraries instead of > bundles? I think I saw several NeXT functions that might be useful for > doing the loads (NSAddImage and company). Well, it turns out that this is possible. I used NSAddImage() and NSLoadSymbolFromImage(). I could only build (and load) flat namespace dynamic libraries though. When building two-level libraries, certain symbols need to be resolved by linking to the Python executable (ex: _environ). Bundles have the -bundle_loader option, there doesn't seem to be anything equivalent to it for dynamic libraries. [I wish Apple would lower the restriction for two-level namespaces to -undefined warning.] Marcel From alexp@strata.com Mon Jan 28 06:26:47 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Sun, 27 Jan 2002 22:26:47 -0800 Subject: [Pythonmac-SIG] Serious bug with FSSpecs (and GUSI, and MacPython) on OSX References: <30659C20-1376-11D6-9305-003065517236@oratrix.nl> Message-ID: <002501c1a7c4$c3b6a4c0$0400a8c0@veropc> Jack, I think it is difficult to get a FSRef support in GUSI : plus I think we need to get rid of GUSI ASAP. Now I failed to understand the exact problem : isn't GUSI supposed to fail to create a FSSpec with a name >= 32 ? May be it is not, I remember I had to do something special in MacCvs. alex. ----- Original Message ----- From: "Jack Jansen" To: Sent: Sunday, January 27, 2002 2:35 PM Subject: [Pythonmac-SIG] Serious bug with FSSpecs (and GUSI, and MacPython) on OSX > Folks, > I need some help. It turns out that the bug Russell Owen posted > here before (505562 in sourceforge) that BuildApplet can destroy > sourcefiles has even more far reaching consequences. > > The problem isn't with BuildApplet per se, the problem is with > the way MacOSX creates FSSpecs for files with names that are too > long (more than 32 chars) to represent in an FSSpec. What > happens is that the first 22 chars are used, then #XXXXX is > appended (where the XXXXX is a number unique to the file) and > then the original extension is appended (don't know what > happened if the original extension was more than 3 chars). > > But, and this is the bad news, this extension is *not* checked > if you create an FSSpec by hand. So, if your original, existing, > file has a ".py" extension you can create a valid FSSpec, > pointing to the same file, without the ".py" extension. Or with > a ".c" extension, or anything else. > > The other part of the bad news is that GUSI is completely > FSSpec-based. Hence, when BuildApplet gets a ".py" file, creates > the applet name by stripping the .py and then does > try: > os.remove(outputfile) > except .... > > The os.remove() succeeds and happily removes your sourcefile! > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- > Emma Goldman - > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From jack@oratrix.com Mon Jan 28 10:45:35 2002 From: jack@oratrix.com (Jack Jansen) Date: Mon, 28 Jan 2002 11:45:35 +0100 Subject: [Pythonmac-SIG] Serious bug with FSSpecs (and GUSI, and MacPython) on OSX In-Reply-To: <002501c1a7c4$c3b6a4c0$0400a8c0@veropc> Message-ID: <28D61C6C-13DC-11D6-981B-0030655234CE@oratrix.com> On Monday, January 28, 2002, at 07:26 , Alexandre Parenteau wrote: > Jack, > > I think it is difficult to get a FSRef support in GUSI : plus I think we > need to get rid of GUSI ASAP. > > Now I failed to understand the exact problem : isn't GUSI supposed to > fail > to create a FSSpec with a name >= 32 ? May be it is not, I remember I > had to > do something special in MacCvs. The problem is easily demonstrated. Create a folder with a file 'file56789-123456789-123456789.py' in it, and go there in Python. Do the following: >>> os.listdir(':') ['file56789-123456789-12#66608.py'] >>> macfs.FSSpec('file56789-123456789-123456789.py') FSSpec((-100, 419338, 'file56789-123456789-12#66608.py')) >>> macfs.FSSpec('file56789-123456789-123456789.pyc') Traceback (most recent call last): File "", line 1, in ? MacOS.Error: (-37, 'there may be no bad names in the final system!') >>> macfs.FSSpec('file56789-123456789-12#66608.pyc') # XXXX FSSpec((-100, 419338, 'file56789-123456789-12#66608.py')) >>> os.remove('file56789-123456789-12#66608.pyc') # XXXX >>> os.listdir(':') [] >>> As you can see, if you mangled the original filename (I changed .py to .pyc here) things work fine, i.e. the system knows that the .pyc file doesn't exist. However, if you mangle the filename as it appears when it has been processed as an FSSpec at some point you're hosed. What I'm now thinking of is a bit of code in the pathname->fsspec code (both for MacPython and for GUSI) that tries to detect this situation, i.e. something like (in pseudo-Python here, but should be C) fss = FSSpec(pathname) if '#' in fss.name: p1 = strrchr('#', pathname) p2 = strrchr('#', fss.name) if p1 and strcmp(p1, p2) != 0: raise 'FSSpec for non-existing file would point to existing 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 owen@astro.washington.edu Mon Jan 28 16:17:08 2002 From: owen@astro.washington.edu (Russell E Owen) Date: Mon, 28 Jan 2002 08:17:08 -0800 Subject: [Pythonmac-SIG] Re: Python Reentrant? Message-ID: Jon Bradley wrote: >Does anyone know forsure whether or not Python 2.2 is reentrant?...We're embedding Python and will want to be able to have more than one thread >evaluating a Python expression at one time. I'm not expert on this, but I hope others will correct any errors. By the way, you'd probably get a better response on a more general Python discussion list or on the news group. I don't believe Python is reentrant, based on: - Only one copy of the Python interpreter can be running at a given time (at least on certain platforms) - Python has a global interpreter lock. Your simplest solution would probably be to write your application using Python's own threads. If you need to have external code running parts of your application, build Python extensions (not that hard to do, though you will have to be careful with the Python interpreter lock). As an alternative, it is conceivable you could get various threads to call Python in a way that obtains the interpreter lock. I have no idea if this is possible or how to go about it. -- Russell From aparente@adobe.com Tue Jan 29 00:52:25 2002 From: aparente@adobe.com (Alexandre Parenteau) Date: Mon, 28 Jan 2002 16:52:25 -0800 Subject: [Pythonmac-SIG] AE support and FSRef Message-ID: Hello, Trying to use FSRef with MacPython and AppleEvents, I run into all sort of N/A : 1) There is no typeFSRef in AppleEvents.py 2) there is no pack/unpack in aepack.py for FSRef 3) no AEPutKeyDesc support in _AEModule.c 4) no Alias, as_pathname... In macfsmodule.c 5) no RawFSRef in macfsmodule.c (see aepack.py) Did you plan to add these to MacPython ? Are you interested in a patch ? If so, in which CVS branch are you working ? Another related thing : in GenericEventHandler of _AEModule.c it would help a lot if we had a function like : PyObject *AEDesc_New_FromMacOS(AEDesc *itself) This function would create a python AEDesc object which doesn't call AEDisposeDesc when destroyed (by possibly adding a boolean in AEDescObject). This would avoid us from doing the ugly : requestObject->ob_itself.descriptorType = 'null'; requestObject->ob_itself.dataHandle = NULL; replyObject->ob_itself.descriptorType = 'null'; replyObject->ob_itself.dataHandle = NULL; Py_DECREF(args); ... Which took me some time to understand... If we had that, we could pass safely AEDesc coming from MacOS API to Python. I run in this problem because I'm working for fun on a Python context menu plug in for the finder on OSX. Alex. -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From mday@mac.com Tue Jan 29 01:17:52 2002 From: mday@mac.com (Mark Day) Date: Mon, 28 Jan 2002 17:17:52 -0800 Subject: [Pythonmac-SIG] Serious bug with FSSpecs (and GUSI, and MacPython) on OSX In-Reply-To: <30659C20-1376-11D6-9305-003065517236@oratrix.nl> Message-ID: <04468B7E-1456-11D6-9D1D-00039354009A@mac.com> Jack, You've found a bug in the Carbon File Manager on Mac OS X. When you pass in a mangled filename, the File Manager is supposed to try finding the name literally, then try finding it based by its ID (the XXXXX part). If it finds the file by ID, it is supposed to then derive the mangled name again and compare it to what you passed in. Carbon isn't doing this. You can definitely write up a bug and describe how it has data losing consequences (in the hopes that a fix gets released sooner). -Mark On Sunday, January 27, 2002, at 02:35 PM, Jack Jansen wrote: > The problem isn't with BuildApplet per se, the problem is with the way > MacOSX creates FSSpecs for files with names that are too long (more > than 32 chars) to represent in an FSSpec. What happens is that the > first 22 chars are used, then #XXXXX is appended (where the XXXXX is a > number unique to the file) and then the original extension is appended > (don't know what happened if the original extension was more than 3 > chars). > > But, and this is the bad news, this extension is *not* checked if you > create an FSSpec by hand. So, if your original, existing, file has a > ".py" extension you can create a valid FSSpec, pointing to the same > file, without the ".py" extension. Or with a ".c" extension, or > anything else. > > The other part of the bad news is that GUSI is completely FSSpec-based. > Hence, when BuildApplet gets a ".py" file, creates the applet name by > stripping the .py and then does > try: > os.remove(outputfile) > except .... > > The os.remove() succeeds and happily removes your sourcefile! From pfroehli@ics.uci.edu Tue Jan 29 04:23:53 2002 From: pfroehli@ics.uci.edu (Peter H. Froehlich) Date: Mon, 28 Jan 2002 20:23:53 -0800 Subject: [Pythonmac-SIG] PyOpenGL on OS X? Message-ID: <0093FFDE-1470-11D6-A315-003065F6D8BE@ics.uci.edu> Hi there! I was trying to play with PyOpenGL and noticed that it does not currently work under OS X. Note that I am not talking about PyOpenGL + MacPython on OS X, but PyOpenGL + fink/unix Python on OS X. If anybody would like to help me in getting it to work just send email. Thanks! Peter -- Peter H. Froehlich []->[!]<-[] http://nil.ics.uci.edu/~phf/ OpenPGP: D465 CBDD D9D2 0D77 C5AF 353E C86C 2AD9 A6E2 309E From jbradley@thinqinteractive.com Tue Jan 29 19:54:30 2002 From: jbradley@thinqinteractive.com (Jon Bradley) Date: Tue, 29 Jan 2002 14:54:30 -0500 Subject: [Pythonmac-SIG] sys.exit() functionality In-Reply-To: <0093FFDE-1470-11D6-A315-003065F6D8BE@ics.uci.edu> Message-ID: hey all, In embedded Python - why does sys.exit() quit out of the application that's embedding the interpreter? Is there any way to trap or disregard this? If a user creates an application with Python and runs it through the embedded interpreter, calling quit or exit on the Python application itself is more than ok, but allowing it to force out of the parent application isn't. I do not want Python to have that type of control. I haven't done enough research on the sys module, but I thought I would pose this question here since some of you may have experienced this and found ways around it. thanks in advance. Jon From paul@fxtech.com Tue Jan 29 20:32:07 2002 From: paul@fxtech.com (Paul Miller) Date: Tue, 29 Jan 2002 14:32:07 -0600 Subject: [Pythonmac-SIG] sys.exit() functionality In-Reply-To: References: <0093FFDE-1470-11D6-A315-003065F6D8BE@ics.uci.edu> Message-ID: <5.1.0.14.2.20020129143026.022e5eb0@cedar.he.net> >In embedded Python - why does sys.exit() quit out of the application that's >embedding the interpreter? Is there any way to trap or disregard this? Can you replace sys.exit with your own function? While you're initializing the interpreter, couldn't you just run a string that has a dummy exit function and a "sys.exit = my_exit" statement? Similar to how you would re-map the stdout and sterr write() calls. While I've got your ear - are you using MacPython with OS/X, and if so, have you found a way to keep the SIOUX console from appearing? -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From jack@oratrix.com Wed Jan 30 14:29:21 2002 From: jack@oratrix.com (Jack Jansen) Date: Wed, 30 Jan 2002 15:29:21 +0100 Subject: [Pythonmac-SIG] sys.exit() functionality In-Reply-To: Message-ID: On Tuesday, January 29, 2002, at 08:54 , Jon Bradley wrote: > hey all, > > In embedded Python - why does sys.exit() quit out of the application > that's > embedding the interpreter? Is there any way to trap or disregard this? > > If a user creates an application with Python and runs it through the > embedded interpreter, calling quit or exit on the Python application > itself > is more than ok, but allowing it to force out of the parent application > isn't. Sounds reasonable. How about a routine PyMac_SetExitFunc() that you could call to set your own exit function, (similar to PyMac_SetConsoleHandler())? MacPython would then do all it's normal cleanup, but at the very end call your routine in stead of exit(). -- - 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 jbradley@thinqinteractive.com Wed Jan 30 15:17:52 2002 From: jbradley@thinqinteractive.com (Jon Bradley) Date: Wed, 30 Jan 2002 10:17:52 -0500 Subject: [Pythonmac-SIG] sys.exit() functionality In-Reply-To: Message-ID: > From: Jack Jansen > > Sounds reasonable. How about a routine PyMac_SetExitFunc() that you > could call to set your own exit function, (similar to > PyMac_SetConsoleHandler())? MacPython would then do all it's normal > cleanup, but at the very end call your routine in stead of exit(). > -- > - Jack Jansen :) That does sound good. Now - the main question is, would calling that function end up exiting the interpreter as well? Er, what I mean is, does the normal cleanup of MacPython affect the interpreter or does it only affect the application that calls it? The thought is that people could write applications in Python that easily run over the host, but exiting would only exit the actual Python application, leaving the interpreter still active and the application intact. I think I need to spend some more time learning the inner workings of the sys functionality in Python (obviously). Jon From jbradley@thinqinteractive.com Wed Jan 30 15:34:58 2002 From: jbradley@thinqinteractive.com (Jon Bradley) Date: Wed, 30 Jan 2002 10:34:58 -0500 Subject: [Pythonmac-SIG] SIOUX Console ( was sys.exit ) In-Reply-To: <5.1.0.14.2.20020129143026.022e5eb0@cedar.he.net> Message-ID: > From: Paul Miller > > Can you replace sys.exit with your own function? While you're initializing > the interpreter, couldn't you just run a string that has a dummy exit > function and a "sys.exit = my_exit" statement? Similar to how you would > re-map the stdout and sterr write() calls. > > > While I've got your ear - are you using MacPython with OS/X, and if so, > have you found a way to keep the SIOUX console from appearing? Sorry I didn't respond sooner. Yes, I could do that. Jack also recommended something similiar by creating a PyMac_SetExitFunc() which, if defined would override the normal sys.exit with my own custom exit func. On the topic about the SIOUX console, there was a thread about this in Sept. that discussed the usefulness of a PyMac_SetWindowless() function (Alex P.). Gary Bringhurst discussed MW 7 and MSL where there was a function "to make something linked against SIOUX 'windowless'", in his words. Gary's comments are here: http://mail.python.org/pipermail/pythonmac-sig/2001-September/004150.html I do not know what came of this, nor do I know if anyone has succeeded in making it happen. Alex, have you had any success? I think I should check sourceforge to see if there are any patches or unfilled requests for this functionality. As I jump into testing embedded Python on X, I'll be more and more concerned with this matter in the coming days I think. One way or the other I've got to look into it. Thanks for bringing this up. Jon Bradley Multimedia Developer T H I N Q Interactive ------ 693 East Avenue - Suite 102 Rochester, New York 14607 From alexp@strata.com Wed Jan 30 17:42:28 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Wed, 30 Jan 2002 09:42:28 -0800 Subject: [Pythonmac-SIG] SIOUX Console ( was sys.exit ) In-Reply-To: Message-ID: > http://mail.python.org/pipermail/pythonmac-sig/2001-September/004150.html > > I do not know what came of this, nor do I know if anyone has succeeded in > making it happen. Alex, have you had any success? Jon, Yes the windowless functionality made it inside 2.2. We use it now in our project. We are guaranteed that the SIOUX window won't appear. This is in macglue.h of MacPython : void PyMac_SetConsoleHandler(PyReadHandler stdinH, PyWriteHandler stdoutH, PyWriteHandler stderrH); [unrelated] Jack, I understand why you put it inside #ifdef USE_GUSI2 but it forces us to have the GUSI2 header externally, whereas in theory we would not have to use GUSI in order to use for the Python SDK. [unrelated] About a SDK, I regret we don't have PEF stub library and a dedicated folder that we could copy at once to write components. Something like Python2.2/SDF/Headers, Python2.2/SDF/Headers/Mac, Python2.2/SDF/Libraries, Python2.2/SDF/Resources. Thx Alex. From managan@llnl.gov Wed Jan 30 19:08:06 2002 From: managan@llnl.gov (Rob Managan) Date: Wed, 30 Jan 2002 11:08:06 -0800 Subject: [Pythonmac-SIG] modules Message-ID: I have been out of touch with Python changes since about 1.5. Where is the best place and way to build modules I am going to write for my own use? Should I learn to use distutils or just dive back into doing it directly with Codewarrior? Historically I did all this in the Extensions folder and just added what I needed to PYTHON_PATH. My first thought is that this would be good for the development cycle. From mmiller@adobe.com Wed Jan 30 19:14:13 2002 From: mmiller@adobe.com (Martin Miller) Date: Wed, 30 Jan 2002 11:14:13 -0800 Subject: [Pythonmac-SIG] sys.exit() functionality References: Message-ID: <3C584605.5DE099D6@adobe.com> On Wed, 30 Jan 2002 15:29:21 +0100, Jack Jansen wrote: > > On Tuesday, January 29, 2002, at 08:54 , Jon Bradley wrote: > > > hey all, > > > > In embedded Python - why does sys.exit() quit out of the application > > that's > > embedding the interpreter? Is there any way to trap or disregard this? > > > > If a user creates an application with Python and runs it through the > > embedded interpreter, calling quit or exit on the Python application > > itself > > is more than ok, but allowing it to force out of the parent application > > isn't. > > Sounds reasonable. How about a routine PyMac_SetExitFunc() that you > could call to set your own exit function, (similar to > PyMac_SetConsoleHandler())? MacPython would then do all it's normal > cleanup, but at the very end call your routine in stead of exit(). With an approach like the above, wouldn't it be better to have a platform-independent way of defining a custom exit function, rather than calling a Mac-only system function -- or is this whole thing only an issue with MacPython embedding? Martin From paul@fxtech.com Wed Jan 30 22:29:02 2002 From: paul@fxtech.com (Paul Miller) Date: Wed, 30 Jan 2002 16:29:02 -0600 Subject: [Pythonmac-SIG] SIOUX Console ( was sys.exit ) In-Reply-To: References: Message-ID: <5.1.0.14.2.20020130162700.01c981e8@cedar.he.net> >This is in macglue.h of MacPython : > >void PyMac_SetConsoleHandler(PyReadHandler stdinH, PyWriteHandler stdoutH, > PyWriteHandler stderrH); I discovered this today - seems to keep the console from coming up. [aside - it would be nice to have a common function that works on all platforms, for generic override of in/out - to avoid the stdin/stdout/stderr hack] * BUT * - I STILL get the extra menu. So if I'm plugging into "Application X", once the interpreter starts up I get a second "Application X" menu that has the Quit menu in it. I tried disabling this with the SIOUXSettings structure, to no avail. Anyone know how to fix this? Cheers! -Paul -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From paul@fxtech.com Wed Jan 30 22:30:36 2002 From: paul@fxtech.com (Paul Miller) Date: Wed, 30 Jan 2002 16:30:36 -0600 Subject: [Pythonmac-SIG] sys.exit() functionality In-Reply-To: <3C584605.5DE099D6@adobe.com> References: Message-ID: <5.1.0.14.2.20020130162924.01e3e140@cedar.he.net> >With an approach like the above, wouldn't it be better to have a >platform-independent way of defining a custom exit function, rather than >calling a Mac-only system function -- or is this whole thing only an >issue with MacPython embedding? Agreed - I mentioned in my last message that it would be nice to have a standard way to trap console output as well. (Martin - in case you haven't seen it yet, this is what we're doing with Python and AE: http://www.profoundeffects.com/ut.php ) -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From sdm7g@Virginia.EDU Wed Jan 30 23:05:33 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Wed, 30 Jan 2002 18:05:33 -0500 (EST) Subject: [Pythonmac-SIG] dynload_darwin.c Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2138096204-1389522796-1012431933=:297 Content-Type: TEXT/PLAIN; charset=US-ASCII Ok. It looks like the significant difference between the dlcompat dlopen and my dynload code is that both link using the PRIVATE option, but dlopen uses an interface to a non-public function NSMakePrivateModulePublic. This two step process is done to keep from getting the duplicate symbol error. Here's a version which steals the interface definition from dlcompat/dlopen.c, and add that call. This seem to work for me. Right now there are warning messages printed for duplicate symbols, but the linking and symbol resolution continues without raising an exception to Python. Could some of the folks who are having problems give this one a try ? It's named dynload_darwin.c because we'll probably change it and the config files for the next release. You need to rename it dynload_next.c and stick it in Python-2.2/Python to replace the old dynload_next.c I hope this is finally the one!n -- Steve ---2138096204-1389522796-1012431933=:297 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dynload_darwin.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dynload_darwin.c" DQovKiBTdXBwb3J0IGZvciBkeW5hbWljIGxvYWRpbmcgb2YgZXh0ZW5zaW9u IG1vZHVsZXMgKi8NCg0KI2luY2x1ZGUgIlB5dGhvbi5oIg0KI2luY2x1ZGUg ImltcG9ydGRsLmgiDQoNCiNpbmNsdWRlIDxtYWNoLW8vZHlsZC5oPg0KDQoj ZGVmaW5lIERFQlVHIDENCg0KLyogUHJpdmF0ZSA9IDAgZm9yIG5vcm1hbCBi ZWhhdmlvdXIgKGdsb2JhbCBzeW1ib2xzKQ0KICogICAgICAgICAgIE5TTElO S01PRFVMRV9PUFRJT05fUFJJVkFURSB0byBrZWVwIHN5bWJvbHMgcHJpdmF0 ZQ0KICovDQojZGVmaW5lIFBSSVZBVEUgTlNMSU5LTU9EVUxFX09QVElPTl9Q UklWQVRFDQovKiAjZGVmaW5lIFBSSVZBVEUgMCAqLw0KDQojZGVmaW5lIE9U SEVSX09QVElPTlMgIE5TTElOS01PRFVMRV9PUFRJT05fQklORE5PV3xOU0xJ TktNT0RVTEVfT1BUSU9OX1JFVFVSTl9PTl9FUlJPUg0KI2RlZmluZSBMSU5L X01PRFVMRV9PUFRJT05TICAoUFJJVkFURSB8IE9USEVSX09QVElPTlMpDQoN CmNvbnN0IHN0cnVjdCBmaWxlZGVzY3IgX1B5SW1wb3J0X0R5bkxvYWRGaWxl dGFiW10gPSB7DQoJeyIuc28iLCAicmIiLCBDX0VYVEVOU0lPTn0sDQoJeyJt b2R1bGUuc28iLCAicmIiLCBDX0VYVEVOU0lPTn0sDQoJezAsIDB9DQp9Ow0K DQoNCi8qDQogKiBOU01ha2VQcml2YXRlTW9kdWxlUHVibGljKCkgaXMgbm90 IHBhcnQgb2YgdGhlIHB1YmxpYyBkeWxkIEFQSSBzbyB3ZSBkZWZpbmUNCiAq IGl0IGhlcmUuICBUaGUgaW50ZXJuYWwgZHlsZCBmdW5jdGlvbiBwb2ludGVy IGZvcg0KICogX19keWxkX05TTWFrZVByaXZhdGVNb2R1bGVQdWJsaWMgaXMg cmV0dXJuZWQgc28gdGhhdHMgYWxsIHRoYXQgbWF0ZXJzIHRvIGdldA0KICog dGhlIGZ1bmN0aW9uYWxpdHkgbmVlZCB0byBpbXBsZW1lbnQgdGhlIGRsb3Bl bigpIGludGVyZmFjZXMuDQogKi8NCnN0YXRpYw0KZW51bSBib29sDQpOU01h a2VQcml2YXRlTW9kdWxlUHVibGljKA0KCQkJICBOU01vZHVsZSBtb2R1bGUp DQp7DQogIHN0YXRpYyBlbnVtIGJvb2wgKCpwKShOU01vZHVsZSBtb2R1bGUp ID0gTlVMTDsNCg0KICBpZihwID09IE5VTEwpDQogICAgX2R5bGRfZnVuY19s b29rdXAoIl9fZHlsZF9OU01ha2VQcml2YXRlTW9kdWxlUHVibGljIiwNCgkJ ICAgICAgKHVuc2lnbmVkIGxvbmcgKikmcCk7DQogIGlmKHAgPT0gTlVMTCl7 DQojaWZkZWYgREVCVUcNCiAgICBwcmludGYoIl9keWxkX2Z1bmNfbG9va3Vw IG9mIF9fZHlsZF9OU01ha2VQcml2YXRlTW9kdWxlUHVibGljICINCgkgICAi ZmFpbGVkXG4iKTsNCiNlbmRpZg0KICAgIHJldHVybihGQUxTRSk7DQogIH0N CiAgcmV0dXJuKHAobW9kdWxlKSk7DQp9DQoNCg0KDQpjaGFyIGVycm1lc3Nh Z2VbNDAwXTsNCg0KZGxfZnVuY3B0ciBfUHlJbXBvcnRfR2V0RHluTG9hZEZ1 bmMoY29uc3QgY2hhciAqZnFuYW1lLCBjb25zdCBjaGFyICpzaG9ydG5hbWUs DQoJCQkJICAgIGNvbnN0IGNoYXIgKnBhdGhuYW1lLCBGSUxFICpmcCkNCnsN Cg0KCU5TT2JqZWN0RmlsZUltYWdlUmV0dXJuQ29kZSByYzsNCglOU09iamVj dEZpbGVJbWFnZSBpbWFnZTsNCglOU01vZHVsZSBuZXdNb2R1bGU7DQoJTlNT eW1ib2wgdGhlU3ltOw0KCWNvbnN0IGNoYXIgKmVyclN0cmluZzsNCg0KCWRs X2Z1bmNwdHIgcCA9IE5VTEw7DQoJY2hhciBmdW5jbmFtZVsyNThdOw0KDQoJ UHlPU19zbnByaW50ZihmdW5jbmFtZSwgc2l6ZW9mKGZ1bmNuYW1lKSwgIl9p bml0JS4yMDBzIiwgc2hvcnRuYW1lKTsNCgkNCglpZiAoTlNJc1N5bWJvbE5h bWVEZWZpbmVkKGZ1bmNuYW1lKSkgew0KI2lmZGVmIERFQlVHDQoJICBmcHJp bnRmKHN0ZGVyciwiWyF3YXJuaW5nXSAlcyBhbHJlYWR5IGRlZmluZWQuXG4i LCBmdW5jbmFtZSApOw0KI2VuZGlmDQoJfQ0KDQoJcmMgPSBOU0NyZWF0ZU9i amVjdEZpbGVJbWFnZUZyb21GaWxlKHBhdGhuYW1lLCAmaW1hZ2UpOw0KCXN3 aXRjaChyYykgew0KCSAgICBkZWZhdWx0Og0KCSAgICBjYXNlIE5TT2JqZWN0 RmlsZUltYWdlRmFpbHVyZToNCgkgICAgY2FzZSBOU09iamVjdEZpbGVJbWFn ZUZvcm1hdDoNCgkgICAgLyogZm9yIHRoZXNlIGEgbWVzc2FnZSBpcyBwcmlu dGVkIG9uIHN0ZGVyciBieSBkeWxkICovDQoJCWVyclN0cmluZyA9ICJDYW4n dCBjcmVhdGUgb2JqZWN0IGZpbGUgaW1hZ2UiOw0KCQlicmVhazsNCgkgICAg Y2FzZSBOU09iamVjdEZpbGVJbWFnZVN1Y2Nlc3M6DQoJCWVyclN0cmluZyA9 IE5VTEw7DQoJCWJyZWFrOw0KCSAgICBjYXNlIE5TT2JqZWN0RmlsZUltYWdl SW5hcHByb3ByaWF0ZUZpbGU6DQoJCWVyclN0cmluZyA9ICJJbmFwcHJvcHJp YXRlIGZpbGUgdHlwZSBmb3IgZHluYW1pYyBsb2FkaW5nIjsNCgkJYnJlYWs7 DQoJICAgIGNhc2UgTlNPYmplY3RGaWxlSW1hZ2VBcmNoOg0KCQllcnJTdHJp bmcgPSAiV3JvbmcgQ1BVIHR5cGUgaW4gb2JqZWN0IGZpbGUiOw0KCQlicmVh azsNCgkgICAgY2FzZSBOU09iamVjdEZpbGVJbWFnZUFjY2VzczoNCgkJZXJy U3RyaW5nID0gIkNhbid0IHJlYWQgb2JqZWN0IGZpbGUgKG5vIGFjY2Vzcyki Ow0KCQlicmVhazsNCgl9DQoJaWYgKGVyclN0cmluZyA9PSBOVUxMKSB7DQoJ ICBuZXdNb2R1bGUgPSBOU0xpbmtNb2R1bGUoaW1hZ2UsIHBhdGhuYW1lLExJ TktfTU9EVUxFX09QVElPTlMpOw0KCSAgICBpZiAoIW5ld01vZHVsZSkgew0K CSAgICAgIGludCBlcnJObzsNCgkgICAgICBjaGFyICpmaWxlbmFtZSwgKmVy cmluZm87DQoJICAgICAgTlNMaW5rRWRpdEVycm9ycyBjOw0KCSAgICAgIGVy clN0cmluZyA9ICJGYWlsdXJlIGxpbmtpbmcgbmV3IG1vZHVsZSI7DQoJICAg ICAgTlNMaW5rRWRpdEVycm9yKCAmYywgJmVyck5vLCAmZmlsZW5hbWUsICZl cnJpbmZvICk7DQoJICAgICAgUHlPU19zbnByaW50ZiggZXJybWVzc2FnZSwg c2l6ZW9mKGVycm1lc3NhZ2UpLCAiJXMuICVzXG4lcyIsDQoJCSAgICAgICBl cnJTdHJpbmcsIGZpbGVuYW1lLCBlcnJpbmZvICk7DQoJICAgICAgZXJyU3Ry aW5nID0gZXJybWVzc2FnZTsNCgkgICAgfQ0KCX0NCg0KCS8vCU5TRGVzdHJv eU9iamVjdEZpbGVJbWFnZShyYyk7DQoNCglpZiAoZXJyU3RyaW5nICE9IE5V TEwpIHsNCgkJUHlFcnJfU2V0U3RyaW5nKFB5RXhjX0ltcG9ydEVycm9yLCBl cnJTdHJpbmcpOw0KCQlyZXR1cm4gTlVMTDsNCgl9DQoNCglpZihOU01ha2VQ cml2YXRlTW9kdWxlUHVibGljKG5ld01vZHVsZSkgPT0gRkFMU0Upew0KCSAg ZnByaW50Ziggc3RkZXJyLCAiV2FybmluZzogRXJyb3IgcHJvbW90aW5nIHN5 bWJvbCB0byBQdWJsaWMiICk7DQogICAgICAgIH0NCg0KCXRoZVN5bSA9IE5T TG9va3VwU3ltYm9sSW5Nb2R1bGUobmV3TW9kdWxlLGZ1bmNuYW1lKTsNCglw ID0gKGRsX2Z1bmNwdHIpTlNBZGRyZXNzT2ZTeW1ib2wodGhlU3ltKTsNCg0K CXJldHVybiBwOw0KfQ0KDQo= ---2138096204-1389522796-1012431933=:297-- From sdm7g@Virginia.EDU Wed Jan 30 23:10:15 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Wed, 30 Jan 2002 18:10:15 -0500 (EST) Subject: [Pythonmac-SIG] dynload_darwin.c In-Reply-To: Message-ID: Of course, since the function I cut and pasted is covered by Apple's publicsource license, if it works, we'll have to figure out what needs to be done to include it in Python. -- Steve From sdm7g@Virginia.EDU Wed Jan 30 23:31:03 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Wed, 30 Jan 2002 18:31:03 -0500 (EST) Subject: [Pythonmac-SIG] [Python-Dev] Apple PublicSource license [was: next vs darwin] (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 30 Jan 2002 18:23:57 -0500 (EST) From: Steven Majewski To: python-dev@python.org Subject: [Python-Dev] Apple PublicSource license [was: next vs darwin] I did another version of dynload_darwin that took a >10 line function from the dlcompat/dlopen.c code which uses an undocumented (at least in the man pages -- there's probably comments in the Darwin source code) non-public way around the public/private namespace problem we were having with the previous version. I'm waiting for some folks on pythonmac-sig to test it and report back. I'm guessing that this solves the problem without requiring libdl. However it gets into the possible problem of including another license. Could someone who undestands these issues a bit more than I, look at this: Apple Public Source License: http://www.publicsource.apple.com/apsl/ -- Steve BTW: Here's the magic code I added from dlcompat/dlopen.c: ( On the one hand, it's fairly short and trivial. On the other, I wouldn't have had a clue about this without reading the code! ) /* * NSMakePrivateModulePublic() is not part of the public dyld API so we define * it here. The internal dyld function pointer for * __dyld_NSMakePrivateModulePublic is returned so thats all that maters to get * the functionality need to implement the dlopen() interfaces. */ static enum bool NSMakePrivateModulePublic( NSModule module) { static enum bool (*p)(NSModule module) = NULL; if(p == NULL) _dyld_func_lookup("__dyld_NSMakePrivateModulePublic", (unsigned long *)&p); if(p == NULL){ #ifdef DEBUG printf("_dyld_func_lookup of __dyld_NSMakePrivateModulePublic " "failed\n"); #endif return(FALSE); } return(p(module)); } _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev From sdm7g@Virginia.EDU Wed Jan 30 23:34:36 2002 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Wed, 30 Jan 2002 18:34:36 -0500 (EST) Subject: [Pythonmac-SIG] Python 10: MacPython or Mac OSX BOF ? Message-ID: Who is going to Python 10 ? Do we have enough interest for a MacPython or state-of-Python-on-OSX BOF ? -- Steve Majewski (Who only today found out that he is available to go to at least part of it! Gotta go register now. ) From sdm7g@minsky.med.virginia.edu Thu Jan 31 07:29:40 2002 From: sdm7g@minsky.med.virginia.edu (Steven D. Majewski) Date: Thu, 31 Jan 2002 02:29:40 -0500 (EST) Subject: [Pythonmac-SIG] [Pyobjc-dev] pyobjc 0.6.1 release (fwd) Message-ID: ---------- Forwarded message ---------- Date: Thu, 31 Jan 2002 02:27:57 -0500 (EST) From: Steven D. Majewski To: pyobjc-dev@lists.sourceforge.net Subject: [Pyobjc-dev] pyobjc 0.6.1 release There is a new release pyobjc-0.6.1 on SourceForge: http://prdownloads.sourceforge.net/pyobjc/pyobjc-0.6.1.tar.gz which should build and work with Python-2.2 (It includes a redefinition to correct a bug in Python-2.2/Include/abstract.h, so you don't need a patched version of Python-2.2 ) It includes a Cocoa package with Foundation.py and AppKit.py wrappers. ( You can now do "from pyobjc.Foundation import *" ) and a HelloWorld.py program in the Examples folder. It has one major bugfix and several smaller ones. Since there is still at least one major bug in this version, it has some additional support for debugging: It builds with -g for gdb debugging by default. If you run Python with '-v' switch, pyobjc will dump a log of message sends to a /tmp file. This is not yet the 'New Improved Future Version that fixes the Type/Class barrier' -- I've run into a few design questions and I thought it worth exploring some of those issues with the current model a bit longer. Is anyone else going to be at Python10 next week? Maybe we can have a BOF for pyobjc or the state of MacOSX Python? -- Steve Majewski _______________________________________________ Pyobjc-dev mailing list Pyobjc-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pyobjc-dev From Jack.Jansen@oratrix.nl Thu Jan 31 21:52:35 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Thu, 31 Jan 2002 22:52:35 +0100 Subject: [Pythonmac-SIG] modules In-Reply-To: Message-ID: On Wednesday, January 30, 2002, at 08:08 PM, Rob Managan wrote: > I have been out of touch with Python changes since about 1.5. > > Where is the best place and way to build modules I am going to > write for my own use? > > Should I learn to use distutils or just dive back into doing it > directly with Codewarrior? Both, probably:-) For development straight CodeWarrior is easier, as you can more easily set debug flags, profiling, the module browser, etc. But eventually you should use distutils, so you might as well start with that and once it has generated your project file work with that for debugging. -- - 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.nl Thu Jan 31 21:50:28 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Thu, 31 Jan 2002 22:50:28 +0100 Subject: [Pythonmac-SIG] SIOUX Console ( was sys.exit ) In-Reply-To: Message-ID: <8A6E6F35-1694-11D6-9DB9-003065517236@oratrix.nl> On Wednesday, January 30, 2002, at 06:42 PM, Alexandre Parenteau wrote: > [unrelated] Jack, I understand why you put it inside #ifdef > USE_GUSI2 but it > forces us to have the GUSI2 header externally, whereas in > theory we would > not have to use GUSI in order to use for the Python SDK. You'll have to explain what you mean here, "forces us to have the GUSI2 header externally". > [unrelated] About a SDK, I regret we don't have PEF stub library and a > dedicated folder that we could copy at once to write > components. Something > like Python2.2/SDF/Headers, Python2.2/SDF/Headers/Mac, > Python2.2/SDF/Libraries, Python2.2/SDF/Resources. Again, you have to explain, I understand neither what you're trying to accomplish, nor how:-) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.nl Thu Jan 31 21:55:20 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Thu, 31 Jan 2002 22:55:20 +0100 Subject: Fwd: [Pythonmac-SIG] sys.exit() functionality Message-ID: <38A3EBA8-1695-11D6-9DB9-003065517236@oratrix.nl> This discussion started on pythonmac-SIG, but someone suggested that it isn't really a MacPython-specific issue (even though the implementation will be different for MacPython from unix-Python). Any opinions? Begin forwarded message: > From: Martin Miller > Date: Wed Jan 30, 2002 08:14:13 PM Europe/Amsterdam > To: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] sys.exit() functionality > > On Wed, 30 Jan 2002 15:29:21 +0100, Jack Jansen wrote: >> >> On Tuesday, January 29, 2002, at 08:54 , Jon Bradley wrote: >> >>> hey all, >>> >>> In embedded Python - why does sys.exit() quit out of the application >>> that's >>> embedding the interpreter? Is there any way to trap or >>> disregard this? >>> >>> If a user creates an application with Python and runs it through the >>> embedded interpreter, calling quit or exit on the Python application >>> itself >>> is more than ok, but allowing it to force out of the parent >>> application >>> isn't. >> >> Sounds reasonable. How about a routine PyMac_SetExitFunc() that you >> could call to set your own exit function, (similar to >> PyMac_SetConsoleHandler())? MacPython would then do all it's normal >> cleanup, but at the very end call your routine in stead of exit(). > > With an approach like the above, wouldn't it be better to have a > platform-independent way of defining a custom exit function, > rather than > calling a Mac-only system function -- or is this whole thing only an > issue with MacPython embedding? > > Martin > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.nl Thu Jan 31 21:58:15 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Thu, 31 Jan 2002 22:58:15 +0100 Subject: [Pythonmac-SIG] SIOUX Console ( was sys.exit ) In-Reply-To: <5.1.0.14.2.20020130162700.01c981e8@cedar.he.net> Message-ID: On Wednesday, January 30, 2002, at 11:29 PM, Paul Miller wrote: > >> This is in macglue.h of MacPython : >> >> void PyMac_SetConsoleHandler(PyReadHandler stdinH, >> PyWriteHandler stdoutH, >> PyWriteHandler stderrH); > > I discovered this today - seems to keep the console from coming up. > > [aside - it would be nice to have a common function that works > on all platforms, for generic override of in/out - to avoid the > stdin/stdout/stderr hack] This won't work: on MacPython it works because we can override very low level I/O routines in GUSI. There's no platform-independent way to break in to the levels under stdio. > * BUT * - I STILL get the extra menu. So if I'm plugging into > "Application X", once the interpreter starts up I get a second > "Application X" menu that has the Quit menu in it. What platform? Could you create a dummy embedding app that shows the problem so I can have a look? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From paul@fxtech.com Thu Jan 31 22:31:42 2002 From: paul@fxtech.com (Paul Miller) Date: Thu, 31 Jan 2002 16:31:42 -0600 Subject: [Pythonmac-SIG] SIOUX Console ( was sys.exit ) In-Reply-To: References: <5.1.0.14.2.20020130162700.01c981e8@cedar.he.net> Message-ID: <5.1.0.14.2.20020131163016.0217c1f0@cedar.he.net> >>* BUT * - I STILL get the extra menu. So if I'm plugging into >>"Application X", once the interpreter starts up I get a second >>"Application X" menu that has the Quit menu in it. > >What platform? Could you create a dummy embedding app that shows the >problem so I can have a look? OS/X. It could have something to do with my "app" being itself a PLUGIN into After Effects. In other words, my app (linked with Python) is really a shared library. -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From alexp@strata.com Thu Jan 31 22:35:36 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Thu, 31 Jan 2002 14:35:36 -0800 Subject: [Pythonmac-SIG] SIOUX Console ( was sys.exit ) In-Reply-To: Message-ID: > What platform? Could you create a dummy embedding app that shows > the problem so I can have a look? It was fixed after 2.2. You incorporated the fix inside GUSISIOUXSocket::GUSISIOUXSocket, remember ? A work around using 2.2 is to do (prior of calling PyMac_SetConsoleHandler) : // work around for a bug of Python 2.2 which draws the // Sioux menu even though we have a custom console extern int console_output_state; console_output_state = 1; PyMac_SetConsoleHandler(PyMac_DummyReadHandler, PyMac_DummyWriteHandler, PyMac_DummyWriteHandler); PyMacSchedParams scp; PyMac_GetSchedParams(&scp); scp.process_events = 0; PyMac_SetSchedParams(&scp); Py_SetProgramName("maccvs"); You will note the 'scp.process_events = 0;' for maccvs. This is because if I don't do that, MacPython 'eats' events that should be dispatched by the Mac application (here PowerPlant). In the future however I will use the PyMac_SetEventHandler capability. Alex. From alexp@strata.com Thu Jan 31 22:37:32 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Thu, 31 Jan 2002 14:37:32 -0800 Subject: [Pythonmac-SIG] SIOUX Console ( was sys.exit ) In-Reply-To: <8A6E6F35-1694-11D6-9DB9-003065517236@oratrix.nl> Message-ID: Jack, > On Wednesday, January 30, 2002, at 06:42 PM, Alexandre Parenteau wrote: >> [unrelated] Jack, I understand why you put it inside #ifdef >> USE_GUSI2 but it >> forces us to have the GUSI2 header externally, whereas in >> theory we would >> not have to use GUSI in order to use for the Python SDK. > > You'll have to explain what you mean here, "forces us to have > the GUSI2 header externally". Let say I want to use MacPython embedded in an application Y. When I compile Y, I don't have necessarily to use GUSI 1 or 2. I can use MSL instead or anything else (it is not completely true because if I end-up using another C-library for Y, I may not be able to pass a FILE object to Python). If I don't use GUSI in Y, USE_GUSI2 is false and the console handlers functions are not exported by the headers of MacPython. However the console symbols are very much in the shared library of MacPython and I can use them from Y even if I don't use GUSI in Y. That is why it is logical to encapsulate the console handlers with USE_GUSI2 only when building MacPython. If the headers are used externally to MacPython, I should be defined every time in the MacPython headers since MacPython is built with GUSI2. >> [unrelated] About a SDK, I regret we don't have PEF stub library and a >> dedicated folder that we could copy at once to write >> components. Something >> like Python2.2/SDF/Headers, Python2.2/SDF/Headers/Mac, >> Python2.2/SDF/Libraries, Python2.2/SDF/Resources. > > Again, you have to explain, I understand neither what you're > trying to accomplish, nor how:-) I try to still embed MacPython in the application Y. I like to embed, it's me... :-) I'd like to have a MacPython SDK folder. If I'm interested only in making compiled components to Python, it is handy to get the minimal set of Headers and Libraries for doing so. Having a stub library is part of the "nice" thing. Alex. From paul@fxtech.com Thu Jan 31 22:42:24 2002 From: paul@fxtech.com (Paul Miller) Date: Thu, 31 Jan 2002 16:42:24 -0600 Subject: [Pythonmac-SIG] SIOUX Console ( was sys.exit ) In-Reply-To: References: Message-ID: <5.1.0.14.2.20020131164218.021b0700@cedar.he.net> > > What platform? Could you create a dummy embedding app that shows > > the problem so I can have a look? > >It was fixed after 2.2. You incorporated the fix inside >GUSISIOUXSocket::GUSISIOUXSocket, remember ? Bless you sir! -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From martin@v.loewis.de Thu Jan 31 23:00:34 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 01 Feb 2002 00:00:34 +0100 Subject: [Python-Dev] Fwd: [Pythonmac-SIG] sys.exit() functionality In-Reply-To: <38A3EBA8-1695-11D6-9DB9-003065517236@oratrix.nl> References: <38A3EBA8-1695-11D6-9DB9-003065517236@oratrix.nl> Message-ID: Jack Jansen writes: > This discussion started on pythonmac-SIG, but someone suggested that > it isn't really a MacPython-specific issue (even though the > implementation will be different for MacPython from unix-Python). > > Any opinions? I think allowing to replace Py_Exit is the right way to go. Make it a function pointer, initialized to _Py_Exit, and let the embedding context change its value (through a setter, or through direct assignment). Double-check that all callers of Py_Exit behave well when it actually does return (which currently is not the case), and don't forget to bump the API version. Regards, Martin From george.song@webwarecorp.com Thu Jan 31 23:07:17 2002 From: george.song@webwarecorp.com (George Song) Date: Thu, 31 Jan 2002 15:07:17 -0800 Subject: [Pythonmac-SIG] Question about MacPython and AE Message-ID: <9730220255E1D5118BD200065B040BF02138@exch.webwarecorp.com> Hi everyone, First day trying to use MacPython, fairly experienced with Python. Can someone tell me how to get a list of the processes running on the machine? I see Finder.processes and I can use Finder.Finder() Is it something like: f = Finder.Finder() f.sendevent(...?) Please help. From Jack.Jansen@oratrix.nl Thu Jan 31 21:55:20 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Thu, 31 Jan 2002 22:55:20 +0100 Subject: [Python-Dev] Fwd: [Pythonmac-SIG] sys.exit() functionality Message-ID: <38A3EBA8-1695-11D6-9DB9-003065517236@oratrix.nl> This discussion started on pythonmac-SIG, but someone suggested that it isn't really a MacPython-specific issue (even though the implementation will be different for MacPython from unix-Python). Any opinions? Begin forwarded message: > From: Martin Miller > Date: Wed Jan 30, 2002 08:14:13 PM Europe/Amsterdam > To: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] sys.exit() functionality > > On Wed, 30 Jan 2002 15:29:21 +0100, Jack Jansen wrote: >> >> On Tuesday, January 29, 2002, at 08:54 , Jon Bradley wrote: >> >>> hey all, >>> >>> In embedded Python - why does sys.exit() quit out of the application >>> that's >>> embedding the interpreter? Is there any way to trap or >>> disregard this? >>> >>> If a user creates an application with Python and runs it through the >>> embedded interpreter, calling quit or exit on the Python application >>> itself >>> is more than ok, but allowing it to force out of the parent >>> application >>> isn't. >> >> Sounds reasonable. How about a routine PyMac_SetExitFunc() that you >> could call to set your own exit function, (similar to >> PyMac_SetConsoleHandler())? MacPython would then do all it's normal >> cleanup, but at the very end call your routine in stead of exit(). > > With an approach like the above, wouldn't it be better to have a > platform-independent way of defining a custom exit function, > rather than > calling a Mac-only system function -- or is this whole thing only an > issue with MacPython embedding? > > Martin > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev From paul@fxtech.com Thu Jan 31 23:56:44 2002 From: paul@fxtech.com (Paul Miller) Date: Thu, 31 Jan 2002 17:56:44 -0600 Subject: [Pythonmac-SIG] SIOUX Console ( was sys.exit ) In-Reply-To: References: Message-ID: <5.1.0.14.2.20020131175552.023cfac0@cedar.he.net> > > What platform? Could you create a dummy embedding app that shows > > the problem so I can have a look? > >It was fixed after 2.2. You incorporated the fix inside >GUSISIOUXSocket::GUSISIOUXSocket, remember ? > >A work around using 2.2 is to do (prior of calling PyMac_SetConsoleHandler) Kludgy, but it works! Thanks much! -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From martin@v.loewis.de Thu Jan 31 23:00:34 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 01 Feb 2002 00:00:34 +0100 Subject: [Python-Dev] Fwd: [Pythonmac-SIG] sys.exit() functionality In-Reply-To: <38A3EBA8-1695-11D6-9DB9-003065517236@oratrix.nl> References: <38A3EBA8-1695-11D6-9DB9-003065517236@oratrix.nl> Message-ID: Jack Jansen writes: > This discussion started on pythonmac-SIG, but someone suggested that > it isn't really a MacPython-specific issue (even though the > implementation will be different for MacPython from unix-Python). > > Any opinions? I think allowing to replace Py_Exit is the right way to go. Make it a function pointer, initialized to _Py_Exit, and let the embedding context change its value (through a setter, or through direct assignment). Double-check that all callers of Py_Exit behave well when it actually does return (which currently is not the case), and don't forget to bump the API version. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev From aparente@adobe.com Thu Jan 31 23:08:44 2002 From: aparente@adobe.com (Alexandre Parenteau) Date: Thu, 31 Jan 2002 15:08:44 -0800 Subject: [Pythonmac-SIG] Embed example Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3095334526_5394163 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I send to the list a sample of embedding Python in a shared library since it is not too big. The purpose is to extend the context menu in the finder (ctrl left click) with python scripts. >From the README : ----- In order to use PythonCM, you need to have MacPython 2.2 (PEF format) installed. - Run the "Install PythonCM" applescript - Make an alias of "pythoncm" inside "/Library/Contextual Menu Items" Now the python scripts should show up when using Ctrl-click in the finder. Look at the console output (/Applications/Utilities/Console.app) for some runtime information Notes: - This was tested on OSX only but it should work for OS9 - This is based on http://homepage.mac.com/tkukiel/cmworkshop.html alex. ---- -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 --B_3095334526_5394163 Content-type: application/x-stuffit; name="Python Context Menu.sit"; x-mac-creator="53495421"; x-mac-type="53495435" Content-disposition: attachment Content-transfer-encoding: base64 U3R1ZmZJdCAoYykxOTk3LTIwMDEgQWxhZGRpbiBTeXN0ZW1zLCBJbmMuLCBodHRwOi8vd3d3 LmFsYWRkaW5zeXMuY29tL1N0dWZmSXQvDQoaAAUQAACrVQAAAHIAAQAAAHJV0w2lpVJlc2Vy dmVkpaUApaWlpQEAAEMAQLh/C2S4fwz4AAAAAAAAAAAAAAAAABPonwAAANkAAkBLAACqfAAF UHl0aG9uIENvbnRleHQgTWVudQAAYAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAA AKWlpaUBAAA5AAC4fwz4uH8M+AAAAHIAAAQqAAAAcgAJYroAABgEAAAC9AAAAAAPAC5EU19T dG9yZQAAtzoAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAELB1RmpmcRSem2hMzev 9BGD5ikAvKByK5iD4fQnPOy+drWnz8FHuZX0uWSUf0vi7J/0dS45NhafS2f6HFCjvEaYt9NO 8nZjXBjvCEEN58X4RJ3Pl7LW9lE8Eq90gamMN2CFbZqlMj1dxHh+iNCEkDXjnXe8MxI1J2Vj szTpI8fjU+873+0IeUBndX9s6bhtKuyX7mnErkaLd76luhuZQiyCmxIz6Jhz/+TYQDAHVY5V Tw7z3CC1gObCXhpzH4VfQhWYmZ2CVBgDJVS4Lw/uIZr9Pxub3mWWNdQG1VqYgd9IrWmkEw8s GaSaNdZr1BYn0YyTYKjc8FUtr3jidQhRqTe2uY7/8jz097Ybhw3A8KCred4yc+LA4NSUJwG9 8EiGrMikwGmI42cub8nqBGND/R1Zx3g4kA9I8WAjeNVew9HATqLuQ36BuHWPTvitxF2JMxWZ Xmam8dadXE4337xyze4M5E5qjf8YFeH1rlAdYgSVp5qA3Ug9wTBSN8+142mqwkhDvn7R0QAk aNE3mCbAgu0j6nz63JsnARCvr6oBcE2w7AXnP4nbSw/9sV8DUDz5XTJwVDNEe7bNAbs0Rm5y m7dQjJWvO5085mRH7k1GH3CHUAmRliMEk09sfjFMqpPqDsdmJAAuaB+xfpYZqeSRus4upt/c 6yH3uWXsZOzsyaIyrnEVdhesSqFfGMaGcXS4CQbkMvK4wPtWl/sNskd/MePkbwFmKdylRWgA O7JWjf4pNvFOewRjoQ1UHb0iwsgGE+ggxI4CbTbhKok2lQPIuTs0qwVVakGqZQ+KH92dN5aN o4Ro7xmHyz761loUkITpC/TnC0SiGfW0EJgni0tMuOm16VixbiCbmzmIs42vw9YozcjMLrLz 1k4NdX0ds0xFB97u5ky2cfOXLmMsySj6YuxFkDARPJhrM+xxAAV8/5UNAjDY+yMqfDQYwZzf FUyBgbwm6hZFo1INfG9r2WejZaxeWYxVcogk0KdD3PDM5bA0AEg9oKWlpaUBAABAAAC4fXwv uH8MhgAAANkAAFf4AAAAcgAQpCMAACOcAAAGBQAAAAAPAEluc3RhbGwgUHl0aG9uQ00AAQxS QVBQTGFwbHQgAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAANAaAABNVwAAAAAPAELB1QVNOmHl z27ricH0WDS35rPjKS4bupkl70Y5vzppsx5WHGm7ix9PQIU+/v0oGINGpin5UbPiPs3/1yDm 0/jyZi5DTpxFgzExmh0rOu4olMlZa1KPVZWXi0kuP2/bhqb0h3SSUyG6nsf5CwM/0cu+xr78 Bs7942gnX+m1bSofDtLj3aHM+t4BwnGSibmOmW8VdYOisaZ4lGu2Vt7bglwv8hdh7Fj+PW4g IMg+DnHZUrlZYRvHw7/lrOb8IvLcHBwYOvrjX0UOOjZDJUy2P83VlRwqBn2yh6JR1cGbrVM0 shxw1ZDbaubq/LD0i9MFL8/hV0maQeS+NSl3nVNFYm8/9XGadTMBNNBF/yyb0nIbIV4Te7dB VWCzCjTNtHC3bJfA06AsLwe4o7Zj321177ltQgKXBqVOPcp1bgiZzxt7PgCmNwdsvWlcluDI S724OJGWTIwpMKnO0VAP94Or4EkzxC672bsi6O8j4UjpFvGfPYGCHLulUrxuNsHpkYeys9cm VX2wyCh3PtVYL/Peevz9WmUrfkPrDaSU4L+fLL7Ek4qhOSCfAo2cJzVtANYVN5a4mtxvhaVZ UHAjfnpzKmAxvJKqlpoDPhcE8s4jEKck44yF+CDHr+lyQUBtnvG2DyjtL1+rRNyF1yX92H3X eiZ/fS79S2kLJVhib2hyYDS8ktCEwKyA66LfKcTyxW1AM4/tGbEhcyoQ1YgiM4tY8VgmPv4a OwmL0WWzUAYxdJGFp75nbtPwUuQqtUGr8O1JDq3KZ9XdFN66JGP6mXoJrPt/nzDkT1BK7yOq 2y1lpT9JE6jAlIJmWjics6W8PSsI2Xk2VE955u9JwkkGC5pm78/slnyXjDdVqSTV4qhy5HrU aj7DbFUyDhSGOdTg3Tgy7T+EmzAb8rY2lCyVcVzfeWupYoXShKEXj7ozqz7GlRtsllP9RSvu yQGaouQ70GC35i1kf+taZiOubbVxsKMpbzAxV9xyHMNNMNTvhPk2nCZIMSlzYpkleKUKB6Yw i0Dk6eHz1Z6jAhbG1D+WYxFEer6KBM9H/Uvz+vRkpUcngTq8NPXdwnkl+3TPrFe3JlItGLl4 Ptxdj5qzrUMsT9FtnikYZ88cXUBz5dYqP4AP5L+vpwgJPpahRqJRrFMytW4zWmc0xlUuCe0u oJBfJAK0Ft8FOr2SlCE1VWTzjkfN1PWz2eZ92zKa+DlcpeGRJXPqnnNqB14d4O+lAVgMXItb I6dR3aErSM6/GoxHVR8Md0SNRdEDpRk37QM6sLrRrV6N4qpA/AVEDmUZJNJhp7PTaGX6Ftwj 29uKxGSpXYbsZRFeP28Q656kcnXPfLVVVE2lnXCit1DQX87XalRIrOZ6n9ursMVm2fzu97vc g3q1isFrfdOVq9npNWbVKiPuMYpvj2hzIqIPz3Uslf6IaoHnZFiMVr9qvwGtkEMQK3omdpAh xtRBBBuoAoPRlNKOL9lfk5eRWwrFDceDLyJ5M/kUe/AyfeF8cLbIBaUteNKdHlfrDVkWY0oh 8qO66ccENWeFEoCiRJtp9PfUpu/RMrvFByaDIDUzUCIHRvQ2OCpoVamqphbnxhqA9QoyKUtv 9xjAI/BTn2gRNyrDjO+t/2uReYFimr2zoThG69a4A8NRP1wY1e4DCA2MLR9oljR/9MHzHpdx XdZ+dNMsbwNWYPb9omOyp+jDYELTUW/zAPBSKPDGtO0UPb9wGgP50A8dqnmk5GG3m1d5re5P hWhiwM+Tl4wVFLYXjRPp/Yw+vPzD4IvxNGYYNju5la09VxkKPcVtfVneq4fgiT/Crk0D0Ji+ ENAfpW5WY0bwHQiR9BienVqJOrnRSva6nezmFOpiK/WKo1cgooP+wsokgGU3Y1f4dBkIQ/9m 2s4Vqq03Ps5nFofocO2fzEI4AVTxMgwBwn/YCgEGJlkJFNUbrgpBhfS4HJ8eyfAR/qc3RS5G 4PX9Ktmf7HNI/Lmh/DJjwziq3dopZjEDe3Sl7SsVZfgLkB2X1wfyEMypXyMAABwQXgcy58tz +xi0zrXmBi1JhPVc+VIiusrEUrdottNRv/WGGPY66/P7QPo8XvS/7c37vVvcvMfRVJXYEXdG hWq1r8/CgJu2GhiOa/Un2vAkX2cJ9/PoPiDOIQwm4Ngrouwu7TBEUHcuNxBTJ0DibJFk97cL CZaJLv9NBRflcO8Fm0DtOTWQ++Q/H19f5opVKKB8VEJG+XuoWWOpM4rFDivukmX/coVzocKs nsvLP6GWfR6zRZYncWqyXY259zlENOUKrOvsQ5M4evIRjf+p9fhVs4LGFIYP2+R9sGsMdxh1 3ssCF6Jw7ljkZr5wDPsGWZ2ktAjQb2twfcEQg7M/dU8nlEMHugqVwHjrLA0EHZUIKY0xEC5d 4Ju0JfPAyS+GfkYY4aDdNWNDfOXWgyjy1AWsLbmyyAzsMizylWhMRBMzM5/m6/e7B1GF7W7G OvrS8uhj50FZAoYC3s4TJSi+VsheGv6Sld5owCuL5bwSC+fwumnPcTzRbQshVIiJYZ8yo69M LetCCsAgZArc5s95OKnod/GoXQeYjZnpzOF9u0oS5O9dljtvVuamIg5PP+G/bVF07Hcx620T 8psto+Ydyu/araRjdHlOQbm1gbLz2kj9arx63jbS8zyluEnk/Nz6lZ4moUeHMnnMLHpopjCO saFuy05KntH0+0op7Vdtv71gMxtm91pS4wYzqHp2YkAfCp4shSipjB5qJhpaT34tMRaaKrN3 dAHGxx+0ZWTILwoshXl3x7kpd/7F7pygP7utfsUQ70pXHk7U932WerlkEV3Va9ZzGQAdYG+f 3p4yANh7ex8ywGx0T/rCTgjON/XZgObFl/hblXuegy97A0qyx9WK4MVR3eM06somwClERrXi F4d/FxNmEFlXM+048m1TVnk6XpPdIzfo2zzECrYva6zYGq33V5SZw7TAt0HQRsl74oZ0HlmK 0zo5j6y3QScEt/z48iND9HxhwFLQrXtnvqkQZmh+hEITFqtHjt4Q/Bw9dD72PnccJ7558HO1 I0DGvXttLmukbnjqJl12E/AXBlgQjOvN3PudOpA7p1PDEDWaPdSIKEFURFRQjS1BPZ75b3nW 6V8/l434OM7jJhO3ZVKtjpcGSYzltW5mSTIe9e6f9tLgicdI+8SI50D0PWEEp6sEd0HsdRiD p5KueAxYV/X90elM6jg7z/sc2HsI3Lc9PrdeTf7TQJBz0D6uCC9nunPd+J/ow39H+RGn4uk+ omx9L6oy8f56FQ6qDjeOnsn1CneD0PHbudTAfA8p2pvFuIC6PHGWY5Y2hind7zrFzwMZJ2r4 2kEK3HA3agvrPqrQLFu1Ypz7dWFf82piryinSvBEG/0xoMSqBhbRH9eUO05ac2ATQ+DQQNro Qs7xNiG7vsHdexkmxKLFJ0EMBI9+V9RBPPeICz4Al80/FgcBKWbcrti2q8bZvieaDedUDyn+ vkGzQ9FykYqlhOMhxrrEkJc2gPG1osWimWQz/pRyeF9HbEFo99G6egu3SnhmNOjXZTWlckUx 7+3P54Ho76YzBJjcuFhqB6xD1xzUIFEL+BX2PnNnWEeEaJeRc5ImY076kuM/RySt3LXHSRti Ue3JtjZkqE8zCVma2vQ3WXDYidCBq0r+06Tk8DE7x4kUrtloPA4WFco9JQEp9O0+fHBxDxj2 fvFAnNU1gmg2IGMdzUzJY7ltsK1BMDFGOEeT8gLNid+nK31M2RI1HH2mWD5gFH4dZ/vmQBJ6 fnBUOvpjPUr56oIjbXPmR3jdPWOi89H3hx5GlXIaXbZZ/dD5QBG/QatfqNfrm58LEQ/mIxof qTqiWCnfDjdFZc67pd0RqD9cscCclf7F9RzOtIp7Q3YWmXVFwiVP3rH1+aFSCdciPIgUUtRe EAeF1ThoghhZAiPq6JqKcWlKecJSsZv0y0TiZgwXt25U41gRDLhFHv4rZtBC3Ay2ZvGgHtzr K2HXLhcdmmtFO+OnmT307r0O02BjYdyr5I5N3Wy+8ynuUoYzKPwslG09NIObEugBSHzSEEGg BFxYLv/Q3ifQGJ7vJT/COxbO9/tniOViWg0jdmoYuKyYvgX/6/d9bfdPdIfNa8cD0wrlQ/SO kS3/YUv8n3rkZ/gIFKAZk4AA990wuMy2oc5nw/aYdOZxZiWVHdgoOtQ4dHxDbLW/Te+C0/iF junqahjpDH+B9ib6X1Tr+QoNV19AOSRYkSk3UlYRJPe4RGpOrzG7Dd+W895215cTevFIaLvp h80/z2ScbcIDKd0ZQTLn5d33z2X9LQ83YwWGgZtqNomfjyjaU+J/+wMMMggU1M4hijxIzGLB 63hV7Km/5iFDDhO2at9B5O+en4X9k8Ap+zzuXDPJzOW/yk2lbZTWe5PSXgDeGeGklHgbprXZ xb91ttR1h58Ih2wrQ7mgjKmBBRpZLb1CUb87Ecj9i76QejseTSMP00fFj6h2EcYMnVwvFFNw QhmcF/np6mc/UqZwmbMKM1vpE3rvow9CZWTUMMyi54A3wOnCGzMKhhyOccaT+FEjWBiA4VOQ q7FjnnULwkSTug9lDE4QFrDOMY77qLIaS8Ds7a19NxoTw3XWR9+BngPYcfB/8zQ9pnJ2S36n Bhq4KPzjBl9SiM8x9WazhnI3rlKyjMKN+oXM4VgsHfs/9QlGmSUBVIJtISfJv+LhOsWqt7X9 ecjrYHyJ9Edh6WK/vkBYzODrI5U60VtpPTm2cz2oho9Ff1Bdj8OZi6IY1GPpmjET8hTyMBwF KFt0IiqMlBDN8Ld+KuDYMBuFYAN55Qy9jEbo8kcrYUlPnB0/W10V5qSct7iI0XTIE37ss8KW pLXIsmTlR54GwZsCfZ1GC7Toz8OmeKlFl17izIAgbkR51gp/bhH8da2Is0IK/9E07as7KNNZ fGTTqYRJtjt2kiYs1zJWtHZfnaXO2Qehclweasn1AxCyWQCq4FEDYjQqxv8KUupEhALOrWOX JKgMX+WY/OlrTu4enNwnIzDovBA8Cufw2kLxFu2lLbK45wGrPXUTVFyw6hdUIJ19GRIhI5Ba IJdQ2yMFC52J/3zuiuKqShvb/2dpj0WiwU3loJBxxy8wSp3FHBo0WzQab9Dr6JLfmxh+hshO n0ciCAgnLyKn0lDcxtalxbvTzed8vEaGamDiB7Ejr84F29BYYlfM8grRMY8DlZY4VXbwy/or LCRAt7cN+nH0KJ53dlU/LP/19uuuRzxjZK9GgM9rlZifXAngvEyF/Q+ZBZURNAGwBUzxIRWg xuJToAGDmvTIR9rK7lsPITpdIg5q6XQBrUfP0GrXBsQYhJzNkUiZhR96twvY4JH8HK5Id6aY ccWaexobnsK+mvVh/eF6onjceXDpbJ4TID/4ai9p4c7leBU9+i5yMA2/ly70ugLeNBjgQlVh Qk80/fwOYDObFrV8iaLCmOpEeJgQ4Io1hni+86+9XXTHwv8qlgw1rJ8jCuSSQFW8b0ocM/vp +mR90JMDczvxeOtp6E/BZSLGF+1O3Frg7AZ/MhXF8iidmn8E+kOZF4KFu8VJ5pECtiUB9Kdb wz7ciIy6dQHxRc1L6wyEsxD1yXuIhzmn0pDx7Pwn1XduFlhnURlJWakBXYL9qK0nAjilXTE2 MKuBZUSmvu6ao1WQK9L6Pjwmhe3harF5NMtjW/f9NNjiwZc8wuVXFEg24M6kp0ebVyC4+I6E CA10knEGxIkYbbVjVVL06xsDKYjf2r2lye6P4ciC9dGCeOrUweL87ybW6omPXgvqECU28ciM iX0ikmjD+BCiKcmqAEJoyx3T+xTGGZ+tL2thVc5cKaEBKo6bDENC390M5ETN8vkAX1JxBnEn zG3jQO22HEakGenpYx3w1h3YGLA2B6JGSlsM1MRqeXGmWB89FhbHYRQ+CfKb3jZZVBnOz75t y9PUUEHbdjmYoyj6xKvXMiUIX+kP8B+HOo98nR+5nFI2nApBhYMBII+cMXJmUReSxBH82nRE 0JL0ieObs7w+CqU8fQKMqrqMEAZ8agiIvv6YqeBMYissXX5zG0skmQJ0BWLJlTyw1f483P3S osBJCoSKlwIbQxA14NMNbRntJsyo5osyAzcH+JMabjqR6JSSSjEXQWEsSbLH41ELgoKqFeE5 UeHrRE0mkDpgAHh9TVcKiCf70jljhLMKjGjdqhsMQ5mfYBJPRkHtQg4bnyXSWHsMuFJmd7dO OZYbXrDHSMux7yHV2757OZ8DPiqLh/1XhdXnLjhLXad2zMOZIDetqvTCUNh8eQEMsjSpQy79 3cKgEXm4dtjeL/OWS5RmJfOSZKc2JNux2q6OfvrUlemg/3OOmw53Y9235eGGFK4VQEDNqFct AW2HS9BPHIhPxP75Ogpsc6GUwiOdrYK1FcQsDGzC6OGO0gWOcJD1tqT9UwR4VNHXM4sjE1hw 9N2uy+yUZ3aim3g9UB2LPsLYveN5ZCbVLoZsSfCQe3l2W5Q3ik4TH4LjRcpPZMjrCvqwoWQu xYFo8ryhto5Ba1Tjoguyg0x26p2rP6900dD4ZSLgF8vLo9kRHBjezuXhUIO97O0juWQBe9/8 oRsb4WO0aE93KJB3F6MKrXZOGm02EOmD2C0W2HHI6SrAPyB/5m7+jTkE883748gwuEOwY4k6 JOI/aug9QJMVZk8pB6KWtkqqABkBpsvWHV+KwkuqpYizEEcELbk8XzrjqmUX8r3RFQqsaHhh wNqCY5T3TgmF9LMasao2pjpujTr/5EOMoR1srSTHQuHqi2ww2oPX11FgwJ0TqQlrrad1X/fW ccurbPTrT+EaKO7KOnddpFAzyq3wNXjLDMYRbg2ajPIEwnOoZi4VK3v23z0FCHn+Pvr1Mzcy i965bIJVHb5vL9x7WhhcqrPS0B8TplaV2nCxNO5bXtdvGK30d28CpvAOdRytBQ9WUV9j8GLG p16Tbpdd9wFSPnJm/v+Mmcq2WhCMOQMt3DrwpA3IEO20mTVEcuPQECuPH+ccP5E9V+q7QTeD WOQhUjrTs1kFwgCQEiUdUqceiXDqGbe3EFDWP8T3ygpNKAZOnu+eMf8T8MKopB/v2tXyWci5 j3BshHW0yVNnQb/KG6lY2eHbqccHK6GUSl25zFfJ1Yx/lR6KxF8KIHWjPC2HsjURudIh6GQm g6aBy7lnuQPvGhLm6G0c8QJm1eGL2smn2264OcWDeujp9AHh38xhromh8XlyqxZ/8b1HWuqr I7Ap3/DoG7rv9GkeZ7TbUjvkGnBWcQ5yvcdlDRYniyU48Je2C75kKopO1K/Naj7b3p2zHYRF ZaTCGs1SUHaWti4XjkRpfO/4OgVWlk/jRP/rGb+noPVpR1CiaHwA5/BRTnatmz/HyGIEt9bc NvoDqjNIkEZqwZtU/dNfzNUtMfxmlBg9cKG1Nn0EvYL0M4kag8IPRSUcCRO5xEJfzQweZqO7 B2/ypj9uV21CjE3PyjMOsPEp/Ccx2AnRIu1PDElCFiipIhz4I07k1kNlZCfug6Keiywqpt8P 7YMa/liA7Vep6XKb7MXzXr7cb5GzTvJF3ntfyvEsLKzJIlQHSG8p+ZuWtueXD2Ww6TnaErCO diBPwtxYbvRmxOv6JSpHrHasnBYdtxl7R8u/E2GMUjTuYTBMNWSRKuqpYn4mVc0yUlAEIvtl qZLbSJEACDIQPtXKQJEp8jnFHZG++FHiNSTG0UNm4aVfvEcLkBlzPcpdTFmg+CYAJNjGEuZi YSOdzQU5DcCDPw9MXXn9+2DbUFfY1x9B61SFPrRV2QAxTRnhMVpGA8W+g4rlZ7RU10xY1x5z 59wvoQ1cDj5UIAc//RzBaoTUFOjHEzEc8LlsFlrCQZSKFC4u/ofGkDPs+slDdMOmuUqHVbAh x70OnktLm57e7g2BJNnW/dtj71/nQnZG6zrdbexGitohgYkJar03l6RWeYi4YD3Z7+qTv3iI Bd7RV2P1kiWfDg7d6fMYQznIR+Md0WlJE3Hsj850GJHgIGGDmJvm2xQ0DAtR3SxQps/YkD18 b0eTRzNEpW+zJ1aVfF83J3iubJzCC/EbgJsEfxH49Ahu6HDRSRvar0wtiWWU7XDuFsE4y3vE Q3UIPuog8O6HVfUkaEVNL3qjsxHSgeaQOo3iFIt6burwAbDfJPTxgLCawpPQ1E9vhQh+veDs SnhBJepENaRRW+uKxRWEF51jJRfwkTAKAJpJvFdCdyg3QFQGMxudvLmm3zITkDM14OTfVkuk yN/KIQJ4+BSbUqlyQaha3l9Xjdu8kcp0IBWM3HQ2uLjLkV+fkLumYcAAXFUwGLNjIpvhgfQD KizzGp7cDU2/5rs7j11aNhKxtoAs+wDDhHgwzppj1q0Wny6YVVZ1GQhfG5G8hwJuSoLX6cwF IJDp2wgu4HvIwqwmcYEOPTAn5dz1t+NYaq+ws2DPDSDfvyAWc7BYReqZWqdojP34tEZ/zUDQ vTREPyHhCAsHKvBEasUR1uVs2E4P1znJxvjyBkqLvXxjO0rZIcX/RynUUDLF5uAVhsw7DN0G EzNfmY62Q7J9x6iIAVrBZ6j6XVS4Lx+A5h5vQ7kbL7Ok3XGWtFKAhYY4CSpkKLKtGW9aMRUT dewHMKtqW3NRAAl2IyNuPBL6IWxy2iVAKdD2LiqhdN6ZxTMTafmeGIRKtBa6tQx1rqp2AuhG 13Eeo04fYl81vcHC+68vsengCxHelW/NpxzI/YM+pYvp+2EV88UdvXJuTbOyv9AWNKXb6iV+ 9uFP6KQvxhfgqHU+W7mOfRFdzpBicKFIU02hJMp230/IcGs8K678kMmlVoEYzWja8eLdz2qj thuzy07HAjqAeRaI0EMioY2sf4nE0tC75Q8WBgyuU44Bv7wHzlI/bLlLGhfZo7jLsOVkwJSB B2jCE8hB+HePB+YSTKzfBqYTtXT0JfvPcfWxHKs41v/ISUfjGSUdJn1/0Nt7uZJzMGn+s0/8 MyKF6ygOVlgMnfXcGyoRTlqpANbL+K8g73oDN/NpYp6Y/XaZgu4HskEumzDbZKNJ3F7M6nrN XrtCy3ieQOj8p25vG23xYXmt4GTc98aMhiPlDONIQour4ODgWv7JnWdTzcTMegx1A/Cx1lb4 ka6xEszzgXJ/s9we2KGx5utfGCPiFxDJ5GLEUYlp9PCkii1n+lwTGBsw0CYPIUa9ivh21C+p kRqcjAldrV5d4S7aO6khfs5Nq2Cr8JQitqZEijk7isyrPCouRDVDL+WNyVerbtpIPuRbn+Hs k1vj+dyPhl30uUWAigRd6bg7j6nu2ic/lTsPRTmFCU7PELAPqXcR+xes/pmUSrmwHub53Ft1 l187Aadzv404mHHkOqZmZu/FfhIT109WhtZalgEjl4QBzAduWXaYGkMuDLEn7y1dlBBuPsV6 QznG70WhYuGYCMLZCa5TKoCx6/GLjqD/6JT44jFnwfJG1hD3RmGLk1pjfLm852+EK70nKScz u16/r5ZMfOUsoVECUDtsGbIG5qmnnqLdEaWkQWze7HWr93h1iqf37HQKb11vbs8t6LMIsIKj jZSl3VfB3WIDAGFbzPXkAKbojp5h9IpC+zG93fp0eXhxxqb5iY9iV/TJl3i8/PZDreyPx6y2 oVB6x91eJ44rYFu+8nZShIzCnJADEU3X+p1MnkNDPOmMamEvg//RI9eVUU7syN4XdJauIG34 R2BqAS/DDxeOccHz7VRnBJi8sUHmEXJ2cx722jpia65NQsM498nDyW6zCBzJ15QoBIdMcUMx 0paJFUH//5kVUSegt3182y0JqNi1FFkWWTc0NqovQhEm/JRXai/D12pBzbH55LGHXZ/B5lMf jHpNavl6Ar8TV6I0NfNC425AxmLAOCS32ooR4DufwtS4plOKa5K92LZE/UDXSzjPvui9PVoi sUbJqMZKrTYy2Avdt1uPC3vpxrXHmtTUE0A+ESy4kODKK822pgsIIb1iaXucVkaCcInE5bMB 6o1MhRfmdTQMH1bk/eeNiyxOB1Jg6NcVBG2o5OJdUAm8ZuA7g3hVDnQwKm/Av9Y07x70sR4K nZ8KkeEfJZCV0of9s6afWdU7eZU4yYM3GbCTPr0Go/6/MeoTfw3DSVfskubo/8yMBQmpbFFi B21irBLix0w4pMHL9G2HIZe44YCbd4wKJb2i5dRvRLjM/Y9dl/oWFFTagxzIvadyBQ5yU9D1 cyRT+HJio2DMwvdga6wBKVzoG84R40Dc0pIjMKMB7HQknznupOhx8RVCgeuG3RWL+Q1itWC4 4JTYd/OLEMdMZXlQJFozfB95WZiZLzFrF7qk+W2Q4HeQWGWdr3abd1EMQ8M2qg2xc9MDv8ni KAdLXPg/iSEv7C2QHRTcK7Tr4I7cWlskOiBPkcHoIKOOo/FhJOZLlQbRmwEeABuHrFckiA5I ocD1OWbLjFcofk4z5ocrpEuDfOR0X4rnwTswMuxa0Ft5ZyiGqnMKZpg4kOQAhyVpd6ujvuba oto9CGTD/wF4aHatgndMOJ6BVkaAb1HoWdsMO9hNsWDzI3R+flRRXXFGeso6lEqHnz4ohIAz SdnjnUtFZ1vrFJUSDoU3aHXxdAunXUn+O6dCaV+gbaqXDumh5SBQ7yg3r83Wr15J15ZTW+Hw 7XpkE41KqSM0lzytvg9wOTlJfx4iR5B4BBbJ11BuvsQF+So6QA3mtG1mgcG3SSkGWJvpTxS+ 2XIO/7HGhs0lSMLFF8RqMxJn5xOGQj/pCVxU5/MIDbNedXMJhPClZGJ0hY9ewAZVm6hfPIHZ a6vhox/mPI64P3Vbfb8tB1zdKQmJjAe5ALTn0bhxuIEVN/25fESAWFaRGy0H7ITQXssL/kx6 u3w/5SnKzc2xXkJctaCkUZF4nGSahCs8wfQ/RRxApudGXzTaCkpH8Z6Cpfpzgi0eXTmEH8zQ TuNzEebZyPghZU9FfTSi93noK8mQuo1++OaPdRL727n6/bE80JZs//EoA4nLLirV+4z1tRqv KJnpV5hUHdyX5bIMycPdDE51r2se1qbWuuXJ0/Yc7oCgHq++pCh42UBZbJ1mJNaDOmkbZ5Xm azEkYkC+urcXJB0U7qERhCo/QkwEuYZWgj5ZRrqdudw8S/On8o645XK366wWh93+9vL14d1W Wvri2JB/KG7H4i7gdZUgZHIz79v4um5MhXA2b2yQjvDvv9peUQCh7TfH5kXgXQZ2N1D3o8uK vngh6YSgLe4NJjs4UYD+Jm0jcZlj3BU062G25D8MaQOcchnBeOs0ykUTZPKU8mMXu9FuwhN5 6Nhav6cKcYOQ1YgZcGdZFK+wsfJAz23+P7hCLLp0Lf6xCgTJBdF03A8AcNVdmuFc/3oqy/nT H1Q/bmmUYLFDZjCCBbL9x2vIsQU2osVrlAs3eGplpeM+y18cF7kSPMLKodtAKVBSWlhuAr6V ruw7PXjeLaCBgQtDnI6V1xbKVDvzZXltbCTTZfwmysRGS9hDPukfhrxQewSX47OIBZnXgPIl p8i2kGgIzZs4rdapMrWNmo41EgIKwgw2BbdBO4HSpQJ0WN3PnY99Yx+oFV47s8HISvW+Ivgn MBvUo7Zn7MBDpwFZ2T9ziNbqwws34rM7AVxfIWtT4RyVPoE29g4V2QejQs30uq1b5s1cMwY4 z9XOWehC3pPPQeyRlMvYU/U+cnwPLVnEDT9iAC8cQGvIY1oT92Z0qXmQaNhL/2Y8q8nYoXO/ ijlNOocBKj/7us2Zmpf5huVESfkPJ2QxVDBLN+PrIDOUdlOn3mLRD0RLG3c7fy5cuCI/sfgM 9fhseSeno88ZCW8U/Pkid3Z+rvkHY7132x6suUCzdAHEtT5zdB1sS5M72ppMxjgmhYeCpJh5 MNjaDEIld/qQma1kIWkvDuHHPu6cN6D3GPPcVnXc/Lti/Bylo/dI8edVwC1+aomY7+pIhe4n eexuKD2rzFaQzyub5nEoLK/oe1gLeNODUeAqPcTpUA4dWOvOvQYAzujdgbYd37dcwZqYwvGh hcxEhF94xjH/0i+vnMKPwdBixrheR2NGl5thHjE+wr9KlMnhV20Gbgsv+F4QOcYzBk6bh1Ve 8/0ZBoazT2qJ+Q6jIyUydlCYZ1Z0baddJD39fAaMwwMUomp3pifudqZxPeWYzNqnPJG3wQHH arHzqmdp8UVD00D44FSHMbRPcKRLvBQUUCQ5j/3zS4qdEdxiNE/EgReGTE1ODZ1Aq4CIAi3G HvTGxiU9tUyFBXej7HP5IrjXT4lHWfnInkFWrlfdFOIPxRJCwtNAhY7BMY7bvhxIw6flCG5M GZpQHSiuy+a1jIVPxqrUpOfCgPK7e8CPg+5zMkOd+KIQdboMX5S3041gJGPrICQCvvk8WtE0 v31stswrtqc4QWKITkGERNMU8EVLiLzLa5OY+l800AaI4LjbIiybvedKGgjhWBe2yZD3k1we kihZPm3HCCKelW6wvy/Sg0wvuV0EfjFkATEx0zy5p2qR8psyGI6sOzZYdjd9laat2daw/IuX k7xv6X8fAYVtQghYHHsZxOP6VtqCdwqtnqKaxtMcFV3UeyOSEytPzgpR8dkfPxh3mLcgRuLs PJ6n8ITtyB7M2FciKwzJfzhhrTQ2xkdLV7y1Bv5EkNxezf6HyBKOp3C9cxmgOBy6VVLUqnA7 LrxINJGqLLAzu6a4c7atWLCQLFQSpB3n5uwWalDDS65eTRWLsHNe6NISGwM4uMBj7o5sV+Iq B3YQcTG3GniRIp+8ycysz2dppvdnlsRwy7WEuGvl7A7gO5tPDXWaGMef0AmO3z/LzY0chty+ /LdKbiG8Chx8tcN5ZOFFRXLFTK0uizOsRjKjxMgNIhE2YL06b2ShEzGX5mAs859mhXqfBv30 uSimbg1lfadvEEQnkFg4QFCJYoZqley4jULDlnkHoW0ydN/vitI5pCkWC27v28hduNL47c6p DzViZX/Fx0JWukoH9CMbz/Fdbyp59c7ivcv7D/Nr3Ent+9KuCPjuBL1ziszKyifE6hZyVBKh SWmpG1k5RKDvUDqkMrZBGTVLpHpdhRPvaX62WN5Mzp4Oh19K9RC/KC5DOtps9tBTWIy7d7bx qEYdPMRZS2G/x+JIM0SOwMpY9rSmqGZ7D2eaeC66TSUDlGcAjXbI9/iee2WwWKd++D2WFQzB rXVlua19VeoLxwx43tS8SmJmDe5suHBgIOnN80TOql096ibh7PEIUW7UeCSmujYG8w51AIC3 WdaqXMwN56OAH8qbpFTdbr7+o5/mkZZdNN+/3xGXaIk8/S8mqxyuBHkdVHIF4UN9HWdgRn9o LRXOr9XaPKr1PKTOLmoH7lrXnoI5c38KUl7wKLTVJPeTmRfSGrq6TeQnt+xdgOAyuMF1mkWu 8XWZWTmgNAHCSB09rK5l8btuaHqx4+ruKwuWJ4hBH7r25JHpAymwAcH41yivwCxw+GqFg2Nv qv6j9OE8y2bIu6oIW4nkg8zbpugMRvNpIXnCkusTVnDyNcsUFDP+xkX5ItIsOlNa3XY1M/F1 ptiqIx0I5ZYUI9i+0YLH+XZnSAhNgxNKRVJAOIf9xT/rYWW/F+LE4oiOnxoYizjVlPflmJq9 zpJN0xi2zch4hiqaCOkz02oPtL2s0JVkgT/qlVDcHHwKoA/BubO/eNEQI+RGQ19YbFDyH1Ln omqB3iF6oYkcF+9281/dc1M8liAQc/hudUOZ8/pjfVeeDjbBNj5m0rCv3tUNimDqqdaJZh3o O6wa14haPoqzNCpjEKse66/rGlG/7quDYq2DWE6QdKPHc/31/YtH4f9fUzhH8PQe2/sA4Zsl EA21P4nW+qnVBzQGww/iGL9jcc5xmBLVDT1anIpUHQXm3i4Eb5syj6s5lWl2ANjuBVhjAElS KD9nR3Ht+qjJLnsL7fkeMtux1nzv3IZEuaoqAJUZq+UTNBYG+F+u3GLGq5AFKmcGOBjy7qbR KLSHx8qP+2in3d/9iKdokn1X2Hta/oUy/ZnGlHV0LUDrG0OaOMgUOFNMiPI+ydJwURVzUOJA wnIiqpF1nU7ALLzLZ5wnhBBS3DCXtee/Kn0/Zq3gmwzAMY+jZH3vHq2Gtrg9Ezr6Ddp8q+cA YvDd3/D67gGHZ3rIu82zT8PFsZ4W/Y9X7r5rQfZa/37+ALY7ZAR32260rhF3fuC91MEPEYcp 2VP8rUCV9PRtIvH2iRSAjWKzUUOCVHyBV+jWgg6PgwbqhKxBmqRKd/0YzPbmJxBcEtB+ZDOd Nz6WPcAJJOXgrl+Lk3oY40DlTS7a7mjzEXfcBWCcHizYN1ccjd6UkKSNF72/RNT0AcC8SvuY /v5+WfNHJWDWiFiJTYITtj8MIztqI7o2b7v+2+9DrSk4ORiQMXtjD8Q/f/zfwG3xFtsltUe8 UMEbzelruet8YDc5jeADqRkIH+tNK0ypt5Ad544T/ylWVR7zRUONkRsZKxdjCs/sRzfw9qXk DMDy8aHav8VvT234M6eVqZoyY+R+OpFrhnn7mpdK+K94xzlfdkdwY1fVp91ER3e9KcrGfmCH GRXpV7rap/VtZMuf7yjGJShrgcGYk89Nxxa03W1ExVkyo1D/LQn4KmJvQ+3fnSFBeRCJE1hc 1l1hISa82MdZVCtL3IY7UlRyxyzG0KKZz5cKqvE8ipjZ0bhDxBqPW501TuYD210k9z9PY5rp GEi/Cz9ry/JxUXWNsLebMPlVH9TGnJVtRRW10jrJq9Ea5EIrBB9jsxAuk0DhI9TcV2P+Cqjs IY3E3r8Vwz1Yi+gPbqqGueQLJNXDstxoMjkrSHPgW3G9slU2qJXilo2XQSi89IK9/Sd10UsG +Shi/p24N28AteKPu/IhKYa/Y5yfogPsdQSLwiwGxMhSuRtbjzrbxtDduNtUK021rBAMLDnm nMRb58jTftNZTpv/4zrEM+wkJ9Ask/BD1sLl1XyffWddteomcI0V5OwgDJWIR6RvxWlIJRjp 4p7TKfrc1aBrbVWVbHcjRbUMMPoDhkOBkAYhwTa5bWOn1OKv0RwzppTsuXn+jIT6hsN3Y+3S 5bYMLKxsqD3x57vJ3b1iLGWThAdX/CbJU5F56VoHWpQ3YlV5tbfS1Yu0HwVu7Hbp4eoWGhfO m+3QJuNkvF4LBmuvZn1SQRT0lTDpKFlDkblOEOPib6Dsy4nihJZJ9PT3S4N6Mop+nvw832kT bpco/4dpNkl7zYwxnavI8qxIaKaxOkTt6hv3JTUytA+TnmXxAl2+u346JrTkEzdc8ZvNESDQ q64+WLToSTD5uOXad3BqNN2wcUWj/qUOssa5A0wk+A6e2zSBgpq/wlOv/luOVysUhcniw9Rm 5CstkA8hlRTSjKLgzrfol9uTgW9mAisGQ6XT/mqyx9e8tCIsihzVBUdPbGlbaVdrJiybBVCT 75Ew+XWZ1RKm3aU5S/qiK1AE8dV4ckQYlxA2oQO8hVTUcVg531YlfXj8M2GoDvNjM9W/TIIG GsSUn8EkljPAQlg4R1e3AWzrV6WEjbiwPlmq5BqsJAsa1TF0llogldwWMzaSfOscuiQ9u0FC ZC9nj7iY4L0kQ1ybL4EJzOy5zt6zaI1AMYcP6fh4cifmQL6Ev6tSjHD03O8fGHihUErlA6gY 4LDPDLYFpUY9Y9m8CQEH4+8O/B+12U9oNfgQYIfPhkO7x7HV5bqZoGWzX91DnDs3Swjp7xOy Al583uCvjpszARfwOK4GgaYTadpaNsQvzKVXClKsAuyFttCoVWLJBEYvAU2jdqI48PcTr85i l3edKm4GsJbDtGxtu8bVm89AMtDYyRgcTNMBSre7X8iRaqRKCf0KuBqeZi+42m8X2hmPaQrE hObD1SlrBgP67Fa1ICbSCZJh52Zc9Rka+uShk3aDtnjW7d+F93Sqy+h6jaq5ehOw4tThB2wv Ckw02BRW7FeyjOM5vd21kQFsLyG4S1u/+6yQsP06raWQpYH8FgqSN8xHa/Yfd8uDkCyqD/rI pbUFXS9JT6R1BFXuplFWFjEGY58tICsKzti/VpJDe2cL6FlLHXhkgjQBjShVe28eIwCIPpFt 1yOMq2f6nxiJ0Jq5pJq06jDLGh841XySa0VE8XDObJPZ20xwaFspxtm6s+UIt0X5CUaZY25E DHE89hmnlRfKrKSYLGr+3xvys2yDmRliQAm68iHML/gS27x50E5sVi0TQLPvdGuMzScfG4Nl aJxGyCR0RA0eZLlbODKhgO5Kb5rTe1GTDzvQFeLCd+eEd1Zg6Pn4r3ECAT8oLbqI6Zy3twli ec7NZj38nt0z8VE0mrzhArRBpkbKxMFoiXu0rsG67geQzOm7ERCQEx90b80qx4loJTYGDigY dDnI5jDwVxRvP5X29rhDc5BGeSHLqYr4rUBLr8/q3GAgYRHKRhtTjpZKh8J166xL+auLU42i o55AZqG/b8o5xrcdBOErVF5MFKnOmuB+xe/6SDSgMGbd4Djqu3wuGbwHsvcI0HxogLMn0861 lgYxX+rdbnP7K3YKRt667X3rsgP4JLSXqVDqBYwzWwG1gKfZ8s2RLSJ3ZWjjVECRKKP9UMXI vAyah6aiYLYKWJHfyfJH+AFd2xQU/4TJeFzrS2W2myRl464koeUDEaxArys9ohSVDrRfuzIA ZgmwCt9GYuDEFUcaiendt+AfAr01L2VJL32lzkmK8F/bOXwcfP2Pq3D6YHWolStN4gaEvx5v ul5daVE6r3vtr7gZwgy2QHTVGpVU29ZCKbAgt9dMbeh97eeMxCS49IbUrmejixuwzErv2JDY 0iwIeONp5IQlUGEGTMn2x7kf0zpMPeN/3hGWsUa21CGTIwes/DzW499/Kfo6a0dveumTTOZV eH2gJWArXDJ1PeHr1LI74lJOmxqe6wjzErwJr4XoXIFbSjXW+LpCr7WOpdpIotw5feTvmf7d 9EMcTWJbunw2ZB1Tkt9zbZXB30mDOY9WKtwKAPsgRKhY+b6rlA7lbvDat5V3VGWtCaIcaRyM D9SE4ltTAHxDSEgTlKT8zYsZ8bicXiUTS/IvMEuVkNo77wCoNQY2Kt7ESj0xKXrBADAh23Jd 6NZmnTQowu6cB1qSq0ld+++l9kfR+XrQ0PIm8zoj1beyA6Q+ir+k/EaUuSABIKmDw+9dQqV+ TEBpqzu+CJ3Tt0zZBTXaesUGmyTLpgsD1EL8YYSzshiU9O4lrqNoxI7kLUkXbdFCj+h20fEJ JjoxvDbcaw970YHPw6teNxBVYJxOs7mJjV7EljlVxEsCXXCz7XVwYyMsEWBBJfiRIueZ5liz zDu5cbQKY/BtSE2Z90JL6I6ia2DntsdoRUmenxM9N53LPHzq59saZZFA+sHa8aFF8KwGGkIu +TICoI1WgOQmaPHvqGo/B44aZS+Y8yq/qx8F3yHD6bxntKFEfX+Y6YoRWuMqgxttBA9ZdaAj J6Z419M6dAZzgTNe9PZPokeirrQT7IjJxjv6h9apGWbVuNZWfFcxXgi8R98Q8e56Y2826IIp FmlOEkTtpAglKqgUJgznI9f2PNmfxLgK/vAkvDvIG9LHuyh64ZgtGB7v1YULVfnkOcF81kzH pW/KJUUejmJgngaTCSV7BXuIUFN5/KYA4l/qEDh5KQuat9UVABcurSA+khGZFdVt/1yjdvGY Eg+KANQ2qL5jmPm2zC61dd0V1P8SZVQ8BpYQRgBgIg1PGJea5sifmwXtK6MgFr0SwyI+L6ML Qzaq9h8InSC0Ukh6H/V+CQcXncDBYfsa1XzFDOAtPxLnZgqubjefYtVNLoo8z8kAXswXcXTb VdRmf9b1ahml2a82fr1HMNaVGTyRYCsMkLfj7M7a/WT7f5Vru9ACqdSmpxgC9hS4ViHej1UQ 3wVxkdllL5HHPx9P5YLOGSHbdqY62QtKwHkxiJlQKhb95Z4ErEZ45+CYNyktpPAw5NkL2kyz rSbVPMaF8zlaYCeg1FUzlAauW/mqo9gsf5qGJzKnBibOr0Gu5XpJ6ScqfD6dLYGaSq26HgTx 2uesI7NBlJbKQ76OoQXyNa5yzRG8cPwUjx9SSmFmMaBYcI88jU0Ee3sAnZvZNlk3md2S4w0l eqGgciQg9UmdxJbSsra+F9zYMgrSDZvCkSBx0YgqQ0hig9Oe1/wV1hPeWcjtJ2/PBNgQrGN9 aUFbC87+VcdjKi1wQUGpUK1t/u7mbN3ssG6CIOBjXtQnuEv+b0zJYpacRbMqQchiqD0d5SO2 HBgnNBgd6ogKXBSrQxy8U7KLLLVRUI7Kt8YnaDZQFh27yUHncsbzqULreA3yOiFDEsQTY0rQ SpewzKd7lAOeV47BP92hKEzb6MdQRqUr+nb1568emoBHKJ6V6onOTujb1Oc3blBz0c8dcivS 6DXTtP5ZVLpvHwz+HahFcylwBUrMpxhGSl3pbIjqzRctqGpr9anUzuqVDTRELDuUvw7Wa+iw ShoPtXTEe9l9gZII4wP4KOocNotRB7ejvI8Vw6acF5j2+u7LlSWZrjrWroI0nYapwaqHg2N2 ctSSdZ/2gsrQSiRom7x1a3xVQp8ZGk4hJXkeew/JAwl9+NMMkYhIzVaZ6OB+I/bYhPbGNcl3 2AG7Amz8AhkAMrE3XzgaIQqzj9j1aYjnrS4/NH7V9X02vb7x/OIhaZY4q6+xM6Jpg2LTXTXH SwN1O2Vu/x/1XCXQN/km24L+IBEnCp5QGdb0deUMm4jkDsoE+FiZstyDjoqCW6MemczkyVF4 RbgURrj6ZMzuco1oaRPifI8PQsKwBBj3gYihXz8Doz2aK+pbUd+Zy3fE5ZLmBYSxw4K93LY8 SAhPbFMYN4xhB9AwIdUIshhExk8QgsgbPII63wFArLBZ+/IcfsC0GcXxgf/726krjgVYUPWn nSilq6oFseJVx2y/c2JAYdmCQBpLr3AIeZC1x3egBqY8e4IIn5SZNiCPML6xoXPPeU8k9uY8 CPlxCxJN9VDqOxP8GWuhECAdQ7axIld9x/KB8FRYPCkNeEf0fjCIzSM0YbRlz1M7F9Mks72j 4VozXKSHiojUI5MXi9psCYAyZkGRbrerZqF2fB6H70h4BdcyNso6/UZa9d3KxUmS8FYakO20 2ju9McqErHJZoAIPnAjDZYQnpxIf9iJLUmlYzf1IxF/QvFx+L48RZcCx/E1cE+/qhTezkK3J hy9+hiNFwb5D7fz2OEKlgJCScA2XvLNbtIyU4N2s08bM2Q430MT0At3DvxO9qTHSk84vMWt5 jOBhG+pJEGHHVRDA7T7G+kO9mQWYN3bgIr1kIynzfPVbsgHZIhrSwPbGGu2utY1yVXE0JdOo QxZxw0POEuANW4s2/kjUCeQXoJSfqpRMt44x2O0bZNOcc66Bokhv9xppgwNfkAqGepQN9/c7 8olmQ48vUIBUV8E7vmIRI/fxzB3//kD1++a3mVaTDrGKD0DhOyohOiXJiEYOIPoDtm485IMW ESPlSkSLQSM/zIjCLdGWpt7aOa6ad1J1QI2oDmBQyH2hocs9aHh+qzQ3AjhNBZggvWdFOQAX Es21nJMV/QkIZ99MKjLZMH+gBZEUFaHUv90hTchevatn/ogIwRPiqWl0e9SR8rJvadirgdin 8YeJIBtUDcTUfvQc0lhqUiozXJyDNSUFZofi6nBsOq+TsC5r/nHSkdTE5z5+Ypc5JylYClZp F5nFI9qf7bOQ4s61WGOR1WUJ1qwVaWIXqHlRnkQtjgUw8vjLx4azOcsmV79Zj+r312TEHdTv ALjeTL7OhMrlqLuul5+SRMr0xtwr+vX3ROFSy2f9K/Z6kEj9D8FOwU5cpOCu+u4ijV75v9oA mWoOZczF44Vkl5BYqq8NtSLqUxCfdxoOOSpdDliKfSFXyf0mNM3gRVE1CcfRauk2uah0RKPp p2/0d1zas+ZmA7dgKsTaGpijNWnLgKEY0py8lkiZA41O1U8OPxu6gESEfbSwd4/ikHJB3Dp6 Sax2rRpbUe694vouGMVtyTecly8qm3s1cVstFK6bPFFoa1EpDSheMSKEk8zUYBn2lnaRx3i1 scya0xkm95lfzR1vVix1FPkorEAYSM5z6qQpV3HZcrrDB+rJ74NX5YIEsLDWYxQVsKK4Mg0w nrcb0dkSSoOhJ1ahWUH5J4KLkIsBBLwuNcyCDAHnwfRAILhO9sk5t8h4dZk6EK4qVfdeln70 NIqyyWTjlO/Gw/5LawmLL9/GZarRJe9/fEc7NZYVWRrivH15d8E3tJvw/D51Z0UoXZ+9IaHo 6EF1b9g4zrqtHzbRPQ79z75GcTsEf3OSzpokJ1sHjcJdRxStDYjnFcIHoZfbjLOao0e8LYPj D8SKg4blxlXJr2KPdGOknKjbt1QSld/ihpItQ/UR3EOHTLHRMCT4CWw6FCzB0HvDpprH7duX psHaLTn78W7OgKaRpGKnpltWlZTx7xsvvx7J1qrslH28S79lYTYEjVCLtY1q7M9pDaC8nYf5 amaPXkSLVizi6pSkYft0Vpg5IV8fiqYTVwKv9AThwbrN/hxlJV99UVw3M97TM71IKtB8Hefn Zz59qZ5BVU4KjwM18X8hF7UNVpTB+KfJJE28GhBrD95TV8yU5bpLeEU3cG4vohBitPFVHAfq eRtlmG7JVvLX6VKihun50Su7ojQnoRomPxZzu28KslvJIHlzXJ/J9RDXieUw3AmWSlG3zFv3 sHp6LRPzfjvPCDzhAlTF8lqCpREh0iHZfBs8IKef21QuhYvXxoTrMquDg+j3X81JNS/m0RuR WFhC9dM8cLscbSsGGtZ26B65mCcPJajyOKz07P/Oq3KvrF4uIRk2wQ4wy9LGmPs2p1P47YxE mR2mntkvsQK8aZYzBgDZinx2gUrk4MlGEWk2Fr3TSMJSuYB50S/MwMhQJgUGJc7erFKkOuuE OR4bt/2GPLVNPqLvkkZneIgT3mkRku61/w4d8cNCmu3DGmzLye93f1oBY3gag1cJOLwq2Wu8 7crccevB0Poac8fCjYBGveWRH9D6oWHfngu0U+DNQR/YVhZmwViPkx0GPI8dtcqs7L0NipDB aX68ydXnUBqqLZo2Nr3rIUUdcPXmDlgGtf7Al5AEt6BrxluaGG84+Ion3uB9NJ6GV3xdlO+Y 2V5S6IvHSFVDRvFZr+L3tdYZ9WB/EsGhkPA3NRa7A9+1994lsSDCIjig9BYRD6lq0NJa0GBp wqrdq4luzwtBZ9KHPeZWMznmqz//a9mnEzux4yaXJCyKGP/bOL1PMQe0d4tO1lOx8RNvRNDO aK/98yCVVWEtkTlJ6NZRszsR286ZtBKRUsvnPhH5y/p9hour0D30QZGEEd+PBFx62aONSZbC /ja0bmQuM1jhEs5snwAmEeae5+IoYjEjL62/ekEv8g0x+9aLk2HIu+5nJL3cQmav+aCD3AaX NRBxBsHv+ly4Rkzru6B71+k5awm9Dwfw8BzjYamarynx3Y0mLjcDDHFTgz7pye5rMWOvAdwo BOFQ7KSjGC5WtxRIzL0JVX1R6YECj6IiME+SbzC/pyvRzaDXeoQpdbhCTCSo67l7vn2O8+L7 tn/u881Yt6PvGD5iZEER5mzIQZxPiRNI1lrEhYnpizc728WAPTXgg3irFL5wAUIiucfJU7bT b3t6k4E/ibjYAtn9dTl/pk+EDV7EeMA3sxla1ydnJEHlYdSKCRqqoOLUN9WKjza6CqYeAdpd zL0sbl3zErFNaFPgFYpLDvPv+XK9JAK2WsJeXbfKGiIRHKw9WYv30yxUNF6yFqotAf7A1yyE AdFR2uCCXHfPcpBB4Eur4TqX8i0Vv5vCG5jisrSiJ2GAWVHpdT7gX4BueZGOodk+PwnZn9II g6hyfUtuf1MzIrtaWFLXct/tVq6HZqgHq6M1g2Dqw+jYJ74yxNSwWAlISn0atGtWHDNHV3ne HwR2N7uqn4w0tqWDfwCHGYEARclC6DVjlGanRvy4k7Urn3CVMDTD5AqEp6tn2Rs1bLaenizP 2JUbY/VtEoaZNtluUTcK1q5EM/5KwU96nshq8D1T/9mumQd/DvuXrgGgB0+awQNZVm1BJU5c pTzDPWVV/wHNMcAtXP+mowkZlK03Z05RElGmYKWHsN56vA6RcmOB5yuFHvdlvbAxFJmLEwPf pFfI4JDcshAtDMvNN19Dh5B1pkLRx6mX3BBTcGSpWi6NKhj//XJwWn37de6AZi1jGynW8GXO xfO5NxOQydrQ0Xg3WF/sdO1VNwbp2Ks9KdlIrl1MDqOr/hil2XcVSPeGzSv4DtNM6V6I9knY /wxt/B3TkdgosfDx5rDFHXGZ1eMQ7cvIDrQwtx1NcM2yF6Nv7wl8e1ySXwTsn1aPCDDreoSc yQa49QFvyjL2liBsJCLsAvz6fI30Nss8eqX/YdRf5hX4P1TtFQ3ePkN6L4nVAi7PLaiAcN1i 2j8c7I/Ok1VSiHWJ6C0zKP1kmv3soLFwgfO//6rkhPnhShn9Qjh+DcL9U2q58ORGxuJkDHQQ NlsjKOrpGWKlJSVsbGRLT20ElDiYNV9QMjLUpoN4sX6L9DVHlEgVxthY0YHqHDQncBIsSO0P wh0/ueJNMHtvjPida8lUty3/XYt33zxIaKZC+ourxiQeQPVXvDnSQKdlA/a+U2zMNvX2OBjs QaRCMY9N3vcIR683FJdmuF04Er8k4MHVJHPTfAhnk8tjrBvz9Sk0tep5G/Xy+RQ/aQZtDksI 4+LWlLlG9qjsdb8Ly1UULe32PeUmR/LWE+4p4PXR0LNA2V16xQVnmKHDeBVoX7EeuPbLALM0 TUrxcVZdqri5LOP1gInnRVIvFQ7KszkVAkOOtiuUreD4rkMzvow3NwrosEmDg+91jTAsZ436 uj9zx6vN7QDBmfC9wydTQwInIKvXEjxsp31/lSRlMT0NEn3UX7d4z5PxrfRZYaBsz2D3I34B +Q6bpkWkzfIPh4chL6yPg6Mp7PjUnjcScmkVtvpy+/5gYT8oAf67y5doZ9Y2IdvZ4c9qsuun BcYIAVzUgaEm7qnRKWEPExe6U/pjwua4qDUUJCgN15AywxqEVlnFJGgtyhTxZJwfi4XxZC1P JPvuo9znG+jd4o01NeVExXqaF+aMixqs7j0dOcaPLcxvbkOek9n3cJGHurhPk8+eIC/tk0b1 4ztca9RewDW4wSZ2VqwGpMqvBXJdyHGxXKSFOQfZLflvrgOzeuEr0yQVOYfmHpnlYDI5tJLT K1SYeubm9FWePuu/dZ8RORQRnmFqvDLGC1WY3bSDOc4/MzeZIuhL13V3ANZnIV2Oqz5vpCZ7 egRnJ6QFkZXHjfiJUl+FfPMQxKcz8k3aS6pHYOhfxnBQdCC9gRrB4D9jAi+YY0cb7igMONbK 1qd/yK10/2+wuLvy0bSWc61BOeFHdRv/LdlVEaeagsE9xL8yCbbM1iD+tZfZibWZ1UdacFOO dKMfGuAlypevqpMByDmqFzqqWysK+oZg3zVgqrOYkx8eubQvUOUTGDgByLv7j6xR/TLPHVWF FLE5xBGMULOohbpSb0bVWR2AyZ5i5zt9Hb0ELJnPjQd1Cd6Q++5yL5oSJCsUPokKd7Xm2Q+o RiRjhWEhUSgK9fYVWDdCWxkxAfGQV5AcOO5htfPgamQvPl7CiMBnCwFHGsuQMttEyQxquc9M KP4+R1EN2ECE7XZL1xCtIGLVVw1atp1613jE6D85Itshk0mQRQgXfoVVFFL3Tq1mC8VziNcG 65/RjwJ/2Nc4XsxSTDfkotwZWUUAcFqC++9b5Dg+dKWGSoKiMd3s+XldgFMMHFr5OCZWPgCs obmpQkWY5TbmofKZ2NLPmu1FFnUTcLBlOehV9nDwGxVqI9UyYZ+jkSqPlhwbsd1CWqO29sbJ jKAbloOG3+MA7eAWLMcndf/oPM/7r/Mgf9+fj0TB3C/NxQyBWk1XF2GG5nTAsPIw4x9RRey5 rxjGN9zmZsuh4uv7UMLU35li/pF0En9OYPDZ83wZUYkujz0CJLsDYigwxIqHUvROYlRHV5W5 Jv3mLi86goSwn7v57laePAPDobL51g/gxWeb5/Z8SPe78nfNUhiKNHM8YzxXyX/LPuowiUgH NXa0d0U/Z0vrpp2RqE6rHgEyTw2j8y+3San7tfTGUxGwkv7tMjCNk8oR3DVtVReBhJcStdNB U7izJc4S7RK2QrKaqX0vq/PQJrl9NV/4o9cMbEnUMuKMvDZTIm0yhjZIpDOvjYg0Lr3ebtJO sEz8WIIPSD+/w6XlN/ZZZewjbHNsWy0c0tV+cOdwnQIqJ5F8kZb3qTQBhZ0NL8JtmwKNCnkP M7B2YwwPy/WDIoEfDrB7rheQnMKovcRxbTBrmOJ+/XS3RzPvfPiD7Su16CH6iG+zaEnDLB4c Sa+vG+r3708EQTHNjR4jrt1M88COsdx89qe4aS1TDDi5tjym1QU1QaPgqyhgpDiQOHngD8x4 zZ7OwfISHmmYPmrbL0OGkwGeaF/ckiyJ+Z9YjYO8wKsFiQwM6HlianTlqXrSElmpAtpJ3hLV 7B9GHi6LuWeE1FX8QH3zU08I2zGtN2+aTcV1q7GUmH/T6Nr6xF7XAA4v+MpOYmgNKiR5xfvA KRgeVg+dyuJyLN0halWUvl9H1TWvSI2M1AeM9sp8XS3cyTOCJlT6CUbeUhY1qAxAoh9MNDfH dsvEa1SbGCkJcTLILCbE3Xz98PXeywa0f1O+qt25xurgVvkXu7VStjGIdLxizIhDQj/qls8Z U2V6ynNEVJbzUZDYqZHPoq8q48okiVDT1I6lyuEZRu7/PgZStMz3YOwJMDStLiVzU/oR1Ci1 Q5ndy5iGGCHy0DpZpS3n6ZTL8EogkaEDO5iHt86g49Qj+/0fa1xwhgyVX8LYuEFXlKEWtHqV IoiCfBCffV9RFVlDq9oD2f40n+9G5AigaoDJOT5kx+pSVqiYejAMc3ki2iymg326ldJNrKrj HUuiSZQGGXvnMpf/0hvpQK77wmq7+9MbSjelL0McAHDJujTreBfnIHO+R6QEKEXPV5Dq9a3b 8DWqypE9++T5W0Q7TqfrG4H5PEx3P4jz25IzWVn7/CDyS+v4HQQR0xi87XvVk0ny7a2d+Orw r1Js9CkqM56RQwHxB3lupT/srH/2KrwgpG6IiKpiDEF6jU8g5XfwdnqYVpQ3aVwn0hZq5cGJ TdP8MvYJWb09DUBq79WZnrG2C9vz2IJGv2qXbLQt1Y/qKMO2Kl0ga1E1RZpOGXAzT+ahZgpq sxALDgNOUWgAjK3XWXp9rvGosMRl9jVvgMfk0tj8Mflwn8FN/DsPMOFEQpN6yBj9amgdXnGv DOGpA0rGjgaEX0CmINmyItsq21rJw0pdGyjAIKUI7ZTLGbNzIgWBoIANzEw4jLhbq0pE2ojK H+/MKyDA4fD5gDC/FLIbFvGpK8FJqNO/kNa0heJPAdnzok2MVl6TqX4tXs9Ot6kkENQZIkVT O6MMf2bTp5sVDfKpeiVuSF+ih0fmf3r+qzucMvJkVyfP2niQX5fX+NDb7mbJe8IhuUbeWTTR iqeJVfAYdHprkPKzGHD9RH5YhXw6Qeefsmf13CV1E/UTfMByA45+YI1blC2hupZrB0D7XQHP AndQVwy09z5mhuHLOVxvYqwffApxNRGfUQicxD4i+KkI72G2Ucx8SWSDyvf4ak4OKD6pWZEu u32ArNskDm5Yb2WzonRC7CHovVU/oKkX+XhsywgTit5K54AeuYSg6h9niFNruAjAovzValXB 4pd8pq6Fh5WcGN8OgoHDhseNCTkRofmRKft4V2ZiVTmHcAY0qDbfxHQtK0KpRSCNAeFVbttO xejrTzYf0uk3w4Yenh3gkQDCuVTJZ2IJcq4/4e9AX71J4pH8Ho1G9QlSFwrWaFDi65zaWnu6 rGT4qcLEvT7uCbl+qRov9COFlsk0oks8Xo2OtvgLZbj1WfGRyJQ2zWv9oaXrngKDG1MqYVMZ X0f4KVvQE8jiLhxNlIJNPtakcnswiAybPIqU19xrknUB0K5quWij2J+ioZuQAPaSD9FV0dx9 XLVjv36X2T2FsJXeCxXHMHioD9d6ilhWiKuV2bKCChO1rY5o7d/JH2kzww7R59kKEIG3FJVp ywPhUOZQi4aajEsc70h+NKBixNq0On3GsEdbZ5XIN4V6+q9DyaYfvqZ+qpz5NqMhifBofMA5 wjwfLPRKb0wlp7DWbzVvllosMxvp0h1HhkZfPlj84RGJpOn3SlTn2hDsZhiYQCgeezPkDhZE c3b+KphxBlZDxj/vIFXbPL+L00pSYvj2CGp4FQIvfjE9NBOrXF897F4J/GRRQ17rQwj4hZdo mu3DTAHrh50nU+t1M1C+OFS3KolY2dK8HIYBE5oHN9AHHyVFEa6jwBzvkd40LU6mk9F4pE5K z7v4Y8AgEgGIEEeIRCihI4nWnnfhq26gx4TbUJ8grsf2CXqEcETPxLBMc4r6oWb/TEdDUB8q 14KlBlzmSE8xyQQn//yWvjlzpHpNpGTgZKYoQsHVC2Ul9SHFJpzc7sV1KqCGa7pS2mGDpW6l 6FXyIRejQa6nHI2MeNFw9NmWelXd/5dkmvqAIKe+oMfNBwUVefOw31/AacIdIgeztkLi9kuy qf/eUXr8sgM9gQ7AvZxYZM4Z/B7aKLBpersoPABRQDWfpzsALL7OhdznVN/6gRM3Sf4+LCRE UmCxuaoYZUNHlIqmKQL2w5ZKAEj/WpgLCREh4KlbqXWQwVX9OVrM5q/U/gfhOaSd/aSAFsN1 fruP5xgZJtguEUrXv5VAfd06yj50ijpC5eKHdZXApWBNNiefIQD0E9Q1f6B/qn1UNuCl55wq 9pXyAWZAeWHrJ85FPe1AszCIVtLPqoHFYlT2Ofsi559y6J5ZNm0Owvi98S/JW5lFKAea+ZTg Ny/f7ToCPZjnEd7q2uSTNnTzcNd8ifQb++pQsW/9TqwgTcrrI4rKjAINip/dLrrvVVvJFsJ0 o1qPBiV/qDXGJguih/BlrJAVewxoYjO+EWN+IzAYG73F5pg1Y5FmYxZTX4IesiEBDvVArT43 iGKsyzvMw5NUnEHVK7PQGquISBQTCd+6tl7cKR3A7VSGSoFebdKnRmfIG/hhJqIjEu+uYT1Y n2s8Ewloe8cPUuSgch4/k74wvqkQv7RI8m3FbM4TYnGN900UwjVJnSOpCIK6dTHX3yJyRwWW Iz9yohLcR15uRrS8GnczGDkThswafYI3I1o/OMiixJhNrm3SikesA6OAi6IXPSC69jYETzSc oLeMBPdL/LWppKIS2BdzPpfFk5PP8dl+6wad/ALaOcYsxhu8A/MbZ0Dj3oWvoinxOSyZSEG7 sK/Ku7Ww9gjn9GQCIH43xSDvl60Vgzzgsw378V3I4zZcS8lZQxEFbAgIaFu6uDxVhA5HyUqp XoEA623mbYb1VeY0kp5FRhfXbzXeLKWA5Yhe9yu/WoMSfz1qtrfuIg+CxAQkvz6AfyOawsee WUiF2SOC2se+6w5jFruf+hvW0cxZtRArdED49Mcr9zJuheW0kXYA7VTB7GD98SOssdotx5gg MP8f1QQu0PRLG3fa2DjxUObR/tladLxZftV6ANiqycGQbs/73gP7y30lbaabt7DuQhEIqfaY 6+FHNbRX+e0N88BHDS7Un2u9ASsIFWMxpHZONkeGJrgVxR7Ns5e2isKyZeLdPU/PaWXneEKI XfeMB0btrwQ5gCyKz/GIStIf/g8kVKWniDleKZXBDeZR7EC8ssy63kIinIKQkouBFg573AmO Ekf/RM8cpMsqp+wRDWd7CmQnz4VJ6QktuPS8Y0pCoCRZw99BYD7/1Cp2Fcquy/0W6EUimCBA QrtZccNgrQ2gwTfwEbS7yrCNckVciVam0HG3Aw2+WPL40+jTohPPyylnN2x8les/udwagaRe EtC+FetQOmRmIlbAf7vshhveGbx0s9lQ/d49HbI1oD8jOJ9qHl5k7iuWmiQ0BAM0iM0cQ1tv VkGUOKZM3oyKCa51o45meQV7rKx2EZGrwJLaD+kMPsaZI15CqkhgNMHz37OMCH+F0yhynAad uAo+4SeiVVlCTsU0szFPLjJ3RvcbMidpfaBgEjHGrmCnMRp0IZHNFQcE3IMPRQt2oFMv1YaV 7PL6uHnBOnahry1fnhI23LaKu+c025b48aps2M4ZTmyWZilRcMxjSeJA44Qm2PCLg+P6Kl+c klgQ9XB38oxREihKbdRh97LgE9laA2QNjW5RgPiAEMTkugdEmjRalnPbvdY7+ODO6IRo/otD s4ORCmvuYzOVwSe/2YiGk/UEhZTm5qYJ2g9gBxAbTyjkB5nUtu9Si2JtnFkSb1s+Y+1jLICG p2feB0wTGG07FV/kD83LJuLN8kpqOcPMz8uB64k+QHm0/nUO+MIO14EZQpfdnvIpuXUCWj9V j/ejVI6xRmTxJGmJFO4SfdbbehF62oyKcaZmhHozCvVJW7gcZsfz5jNt360rNLg5/zmWfymJ 1aH9RnmgfkrdM/GOiHUrbkkGl0hN0ctCEmfcjhFriUH8YbJXbnFJ6qyEZXErOtHrlfot3yR6 LsClpaWlAQAAOABAuH8L1Lh/DPgAAAQqAAB53QAAAHIACBlhAABYVAAAh0wAACGJAANweXRo b25jbQAAYAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAKWlpaUBAAA5AAC4fwz4 uH8M+AAAV/gAAFtoAABX+AAJDw0AABgEAAACtwAAAAAPAC5EU19TdG9yZQAAtzoAAAAAAAAA AEAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAELB1Oc8Q8QiY93kRVrGKehV8ZKbGejYOT9pQlxF znw8CgtDj83a1srYX8Ya34tdUt90l3P9vH1a7uTqVYdsyvt3nn9Z8SZhix77gBi1AMG905vQ dhORPoveg77OjsKdLk/WIH0DjWoPdlu1tJs0keTK5rm3emXyUQ23u7XneJZOgxeDGZQOmpWi 1uyTmTNyT9AX5YlM1g1AdU+h4SeeYYLLDaSpk780BGzeQRAmVTjcH8JcYb3aW3rW8xtb6ci/ sRQCGAx3OSzSJR0uf/7+rAGq41u3AO3s3NOWILmJHfioQOdwYMcXOzxWSNoGmWQ9DY4gfkEe x3HSBqQYNMxTc5h7XG5g89QregIxxsXzPoeqS0WIb+658XpxltFlAShsMwARU4Omj9RUNlSY Pw/vYNgGUxqCcdZMlGj/yyfYQe53c52CTNyOiq2WcIhZHG/+4xdtBXByQ9W9TsJS37VXscuO XKL0ApUX8be/1j3jYtDEas/vp/zgSiWLyllGZuYYeBCVh1RUFIhIGd5jkc4Seew61BMrLfCz rrcKib9ukPZf34Qw1gCjsYmsUgCeCA0b8fX9/2DAE8PEz2/ytdnZbC/E220/DFESCnE82f46 wde4DPQjFtEwt8PW/gVfwAuIbJk6HQVNM8FC9eNmKPxz4cJRVmh8SQEKZ/NN+Q3gVnkiBw5Y 4WxHAgvNmmxyluhitjsck0TQoOYOaZivp9UqgjQR9uaU9zaGORnU74qPn7FXB2/8poZWVEQE kiKtLz2+/BEB7c7qhjOR88KuiBsZ6eDkMbMdt5a7b69NAjO0P0D3YwY2zo7iSeZPNgCfvuBM jojvJZ9IBp8E2OyAUXqgzhVgoDbHCnVRnPRIpTo7KbUSyYy3qH3BO3QyJT+FmhqsDoVBvViz XpgCKpEApZ8BfqjBc1hmo0kApaWlpQEAADMAQLh21Tm4fwz4AABYVAAAaTcAAFf4AAPZNAAA W78AAC7aAAANeAADbGliAABgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAApaWl pQEAADkAALh9fuG4fX7hAABbaAAAX7MAAFtoAAk1IgAAGAQAAAOXAAAAAA8ALkRTX1N0b3Jl AABgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAQsHUsIFTokGYMplRZ/SH7SOt +KaiEBcYAULZ+DbCoDMlHiHeFGslrnoEhPHZEeLe0Z7xpa1M8a2ES+TpUSczsqJ4NAS0ICq2 HeA6QZJE98JjV6QOVHCBOiAmkemBusOxodpp2LIU5G91bpqfitLcmZG7kIrC8AirMgtpR2ne q3C80ZzDh5aSyxlSvMvIToYwiGHZ+v3OQN9IVNeWNJTkcqJpHvOjf/Zoyz3RuWoFOu2eyQ5f rtPEWr0NWyVrThlqhTAnOhoD6oemyy5DpVCUDAnOtFZ9k9URuWqttklcSDYaGM3RM6e8Hhy3 XBQiHK7gMzxryhiE7sj25ipJ5jfGkaoq9vZlEOFqRMYu0DMagUqgZjLovvDRJaDR9IVkdPBo Q93smbtFRWfL6wUo2V7JwB+2aAPxO9h6w2WJtVrWtvWOxCDifuOth2+nI2E5WNYaWSERwH4y ApMB+2tnTNkJNTPtaUe+z1kCMP++g+5GWtS04udKSDOYelHZkBPTK9Ka+wJVGEkMjbJ2ZBih PBV9eus+vym5kqcFCBxiH1EaFunUiOUXl3EGkJj6QuDMppwVsD3gWle7063GfLpxBTxx1AO9 AmUpQqTY0pFGgEMvDMQkO50AEeGbMd80sHBeWAbrbmvD70lYhOsNuTDXBo5HBmCEbY9gOuKj mHBLqdkbkrnWHLSYZiifuM2BiMqC55wE3Hte5/vlml3aSlc38vTi2gJuxsOgZxtSXECl+MVB ren4R0P+nnjLDJp42FrDF4bLrehqHaIF40euYRMzkAlNitdXCAJyD+nf2LOyGnbphrF29yE/ evQkvxsJuYnu1+nOAL/geBrhvNpLEbq0u7+V3FWbdWvKGzV0cBgyhyMkoYkMaWune/lVRfC/ QOHs+z/dvWclWNZULY4NQTlwN3UdoI1dk8M9srpJK5CZomxi+7NwQMw/E9jO2TCE5n/IElO0 Mc4L/7Urpo36FKtqPijrZRZWDjIqZRRlJbnLnaIFee12p6143RbE5UZNTh19qKEFFnCfulg2 5Vl2kkWDG2ekReqec+B21XBCMygUQoXclqBBNh+xr9ZB2biTGfQ0StXPeqHlMYH9aihHZHRo RxuBOavTkPCH9svS1GqchQBAOvpWmbyZfDx9lvBiRhwiC//FEw2P1IDLKqhP5TcQF3UQER/s /C+08LGaU9mMZkLAUhUiRTFvcauP6SVK5s7KjZiXy1mfkF1OAKWlpaUBAAA7ABC4fXsPuH7a 1AAAW78AAGOYAABbaAALrMEAAAdDAAADEQAAAAAPAHB5dGhvbkNNLnB5AAHWtVRFWFRDV0lF AAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAABmgAAAGcAAAAADwBCwdSlLyRlq6mAp77rvjZ1 NbZTKnhpZ2oZxSFFZZYDWuojeDH6zFy6Vyo9z5f0D9Zvaru6gpXEMBnrzeRx3atsXr9kKeGP k6DTXgzwC2DsJAKAU41Rsr09wlP3Ek8rHZ37yIGk+CxUQsHU5SluGReIxDKXZ5nwFcqrPdgE dhZW6c6IZ/P638W1LWxcrHf2Htb0x79EGrCRlAw5vPTblpdpcfd9fjvX25OZ3rNpAwPSESvN Wdg2W+5i3XD5iAerqkP18ScuoPsTDJ9N/jBGKE3H8OYbAusXvU8smRhLNXpTfOuTsIYOZ8eV tt4+I1j8JgCkXC/QzB6yuIaHgf1XoMBJep7ceINwVxHRoh2EhKLi3avZss1ch/qBbuTydHaK 4MdJH++XXmCb91AaKuEnHwJrVYG86V3POXCBCD9LFpEpiAUd/2fo6xuh6sS3sLIrNmSlNd4a 9/okZxONPUq+H/gIZkZCBscLvGC9cRgS6G6au/t4Ri6InC0g+BwLjAXTqi7DUbWusFEIWnyw WbpbN19p1hh4293r/ENyypXTuGBpAhXTJ6UgYNLvrTbna3bJfSa7eaIW8LcXVsgeCwo8Q6AH J/c/h4L996ZPalUU64Pd7JtOZtYbK8CXwpmWDPsXYJ0j8gjozGh3xfLDsD+z69x2TOX/IoUO c97N4yCM5eZ/7HFmUnG6t4LpabeZXKFzdPn+lfaZ4ymlYSyuN88K3a03fKsrhz5pFOfw9Fbd ynq9be2JqmIg5cOpzy8N42fVDH+G8gIFSu1DPvAnPSgl50J0//YcC3zZVUxb0f+gJmcKPjC9 /8fLcvKnsUjrqOQpsM625UNH+EKc9OUAsfY/ZBy1YERKPDc1pm/YEWcOu5oBRS2gtXxt9PQ+ Uw/0SEHZgSz3khW7Z42ZgB/X/J4kt7VUk9naLk9dKtayhp3oJvRDjUiQNoFfZ+fPbK8CRAyc MdmQ3+hyHssy5u6XkUaLMuv8HhCrcjCUGVaWJk53p5LajId5T8c+UZOasbRjzUBOHj0RzUiL S9Nc+vwBQr9qWd00m5rN71DrXPwEXEp36/LxpEzmx6Z2HQusoyZB1hsnlABk3AgHKE5dhaZ4 6QUOzxWXLHcf0sLVF4dqbpQFIyHIQM003v/CMahIuaYvuTp9VZpByuu1mxftXajJZsXP8EBf X/nSA/dEEQClpaWlAQAAQgAQuH17D7h9ew8AAF+zAABpBwAAW2gAEv+sAAAMXwAABJMAAAAA DwBweXRob25DTU1hbmFnZXIucHkAAdZKVEVYVENXSUUAAAAAAAAAAAAAAAAAAAAAgAAAAAAA AAAAAAGaAAAAaAAAAAAPAELB1IpzJrI4C0ajwWNzpBEC609KikKw8q0tQse0Dal+YYjznFEL SiR3AErFyupMNm4X2fd5TGyRrf0GshzOdjI14X8Lakya5xciboJawXumY0X4F7MIlfB0m04Z jcK59AaD2aupuutgQsHUuDqUJyiXs19X/iOMGgMNvOsUeNYW881WPFXWS/yL7d9QUUbM/9ef EdWVstDqn2ypU7Vp62WzWF7IHfMbpcRNPs5MgE1TGLr230kMwMsMkzP9Kcl72OladYOTV+sI 3JhfEG+sZX6z6x8NYNMrbjSJkWt3b8Feyh6F6IsGx96hq9WnwBX6yw6OJYV+3JgKsB2ELR61 C8yq3ikKHM/IPOHihN4ZZTxe9nguk00uOif7VzGhoBbAABtOsbkwbjYMfQITvwkJn1Vo+j2S rO42pdqbUfloACZvxR7oHcTCCJj78sD3AEepTh705/83kDmSYf+w5tHMbOpsb/9Zoh8pwffO NWNuB3OOHKg5whZXFwIBgF9/UjF1JSQtp2JzoQJ6302ZndB899xebePRu95xhdXaVOJgXDaX KXGDnS2wDKTx7Zsh2STMVtGTzbSEvwPzbbDPp2g9gzr8YwbGR8O8gEs9gPlmoJVeKwL0dzzt 0/XrwEtkKkk+lyth0V2c+i9gi0QL5qq7v7h10OFhhpsB5RI7q/zS2d4m7kKedYBAvPuAtsdu i9i0tmzU4tlg7d5Ikx2Aw/SgcBamHsxQKf4lc6s1x7ONo/je6AhcLFTepj/i8aiqI2Q0fitw jNDnIXGXDmK3+nmrukIucHGbWCGNg0IEXiFBhIjIVEKu0NUGbsuWrdCoB0tnonvOeuYnJn4C u7oop1DpNbpNPgZZTz7/y0CKPSKo3sV5ZwtkjOoGCXQ4iLi4UCAom8kgUICqLuna7hCRZYv5 Y0T4m0yos22HTb6tG8IqnNC9bJ9KRInSg+tZUUayvhaOIG4Yo7s541+p0ljFNbCo83oDpDhR hx95crTMBGJuy6dmA6RFMToTDvBb89mdd44jcjktWk9C22oCCjnr2PJdhqPnjIoX81qvaDfR O1xKkzjGOohexOTbe+dlVwaF6oDTi+Tvi0ajhsbOXZCK9m2woZNT65Zm/yyIkT6AmQV6wgMl e41XIHSsYYFBtz2GY1WsY3W8UCXN/R4KN+fm/fT2m1PzzOaS1PHdya2bHFzJY6kjqqXkw/DE 4ewDvbxto0E6yK73+TBX3gfgaAnl/OSb3MBf/0nUxqqGliW48fjQ/a7+jCevF4S2Xcnrgxu4 YmoNHgq4uEegMRLHNWauCwcxINWOwvg9b5d8BxFfsh5WwWWoZo13lCJoqcg+ajF7HGkjrT+F c4wLDcVfP21LIeHyroRd2XoCjIdGbDhztT+JrbIJ64VY6nqQincrT40lKibwdsI+bwOTYcy/ s1+BP7b7HuxHf8wcxme6rzOY5InLkB03F1j81emma48+/PeaM6MRtqEX4lSewgYyKINPLSL7 n5kay5j5lLLc048zUhI5IYQpPiJCSVPFwfwyX9G2tFadgJxbXOH0Rw8iU3I3NLj0DtvUCBpx ifM0OJXZnhzEwmHqTLGzQ7dfoaihBhIdxIJ2ugdc4y73tnlrvYeAHadxaSV+ZGnhEbkYv4Vu nBzTqbzVAg7t5aUTHphumampx49ynz8OrOdJV5NIrGnzzdKshUtdy2+eCAaq8iJupKWlpaUB AAAwAEAAAAAAAAAAAAAAY5gAAAAAAABbaAAAAT//////AAAAAAAAAAAAAKWlpaUBAAA3AEC4 dtU8uH6+JwAAW2gAAHmtAABX+AAHOR0AAGmSAABAbgAAEBsABHBsdWdpbnMAAGAIAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAClpaWlAQAAOQAAuH66m7h+upsAAGk3AABsQgAA aTcACTiaAAAYBAAAAlMAAAAADwAuRFNfU3RvcmUAAGAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAAAAAAABCwdTFu0/CepHabNcw/yfaOIMKDjhrH6Zuendl5li84QNV5aeT9qGptTEx ORiS1O/QJLJE5/xTRsLbHEq71kx+2fC7E1o6QH5YWIP5B6JPCkyEDnrc3JPVkcaWx4+AEMc4 VXPXikkn4a7q5J+qRTMr3sxXJXlmmoG+1pErNOTHm0DQBaTb2d2UaihbkpdBKHiglv71kRk9 9vkP5RPhGzaB0LB7Q6NRrhg/ou3Zfkd9x20/xDVhENgY0QJPpYzXUVSUGtNl4goa8AX8KJ8P a1NWFRwXeRZTZ6RIXCxITX8YaPZs/0w9l4LNX4P/VoTaMzu1Dm0D5Ho/bawD2IGUEySGOZ0/ rM6SjsOEsDdiqI8kxqrpkk0Tb0HDZRD6Dq+/qj4nUmPAD59rCr/b28AlFHzlrpzAw8z8Rj7M 9huDv7BAmNJ8JUQVyqKj9dhCMblFFZJcwnhmC5vHSP3/uIRmI2NyrkdpOPka2RxusPSh/R4F tBXuV6e3edGZ/Whlq/tdjy3pnbt5niU1e3gO/kTO2czzeJkFi7fuLFJgfq3obZZ4B8x6fln4 0oIsT2QdWTtRHumBz1b10Nv7vJxHI66Fhl7ryESICtCul0I5ZelIiE50ko47q1N39NtzzNDV ch/RTg+e6GHFLUZUMfnhAmvRQkC82QETPaUACSQZDvhSMp1IoUN5WYZyD+aWxbjtM6Tl6d4/ GGrRLGFNFAeNkJYCIrBrrnVDbpHrRlHea97iiUye1S8BSWVgtQIMhstUWm88mcP1huZq5ER+ FRVPdjwo8+BHB6gApaWlpQEAADcAELh9ew+4fsMsAABpkgAAcTsAAGk3AAewUgAAD+YAAAQo AAAAAA8AY3JsZi5weQAB1kpURVhUQ1dJRQAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAZoA AABoAAAAAA8AQsHUpS8kfCliyAqXWl2oyrFCZx16Gr7zggo+MCtDENADfELjIOEpwYhT5WCy ylDZPb3Nh9bRmvbO1iauC59nS9dZx75nOLMQZ8BAA4nEuYEh4fimtbo3AU9ioZASooyy2IO+ FbCsIABCwdToeg6a8bNxemGWGhZVc3phUfvd4R/jpn2CaJSyWRdDqeQEaSjrOpXNOVe2wVI9 j2L4EpJnnyLv4XK8XJvjibKLPQ5n+Qx9O3vpZD3b5A5uk6cSxwQIphbna9vDppSl9vNwKu/D ZPvgyWJNKE1f+qqCypncrKpSOf009CviY6k761iozWwKhxSgTQml0i1MCcPalj7/UpnUllWx 9g0/dU8f6om6GbSqCSafmq4uswvIHYGSBgjLRxvhGJvhE1oZnXEr3IftKWaPKTmhoZUIKSlT J81KMhSVKEIPYjxqXee8+GaP1hDcOX54lLXDjtOFdNIVIaFU0u+AYs8Hnv1oa/FXBgQrUnQR xJ+43lXCQFQnhhPhzUjPN+jbr4TbZP8gx2f1FyxrDBmmepEKex/p5lWiUGmEvb7aHS1n1d1E GLyFdd384iNCpPaOoxXI1sIzASXZ7Hn8kC8EeURu7NzL0/dHwbkJux16xHT2B/p7XJ7lnDi7 EBV5TPsgUzC3CYYoQdnoa2qPxJLiSYJRoGOoz412YRWaLonLn84P8H3Dw0oQ4wA5HIT0uPj+ WFqEIUqB/63dAXv+kaLNN2xTbvdn5i/IepDL/ZpcKRZB4TlhzsAby58l6fV1y31IyqasoT67 eyp9OveLizvCKAxycViJBYN/8JqDLDZT64x6mB/Rs1bQtmX8RZy/GfomG2YE9VFNvSaR4K1l non/Xlfn2b8guAY9HoFef9GxyqkPP+k6l5su3L4skWWaAGLSwYnEQFRrqYTD1a+31le4YzJW bUzAOr0CmoBeThIN/mpmf6Y3FTwG91O6bQnWeHJXS5DOkbq8id51ukiQj0Jyz5LkYYE35nxs Y7h1Ve55ddvYrEDbY8s8bEIG4WIPgECHYl+b/hhi2tA2UyEFJxWLVdfjubxL6jUTENQ8pVut BDq6TYKkWZjykjSclaqH9HIecXbso+s6jeBDeZyjbIllQMw0Phy2lDhzPj7S+8h0nugtuPWD 6GDUj9xI/swhPfZFiPF7RTxHQzZJmVDqntKMb1AAAo/H5maHs42dWnNpxzWkReepdIoKOZDJ qkc8vBRjHAd8ycGWj43uHzWxSgUWz1ipBbfTuwXUO4OsUfcDv0vzOlqbhCi+smCWmOTZIWpX o1UXTky4faNtN9WX1/LGo/XwEX4Rp8heelqBMlnkkbEnmbYflq1S8t/2Pe6Rl7tRl9hvqUzs xpT9kEyWdFy9uQsACDOJ7tGG+DSpGUddnNw+kLDW2VvYw6GCW2eTBNISaT+I5mqaJdtvZTrR Dw0RaHpfCWqLk5vE9r64PlBO34q+fAIduVR0JmYa+GMgiBjyD+aslIMPlKZMkRJfSt+MnM21 RZx/d+gVnB3gAg7GQsLPSfsSEQAsMPIcMCNGOBVlgmJWyxSNDsNaQ1yB4KWlpaUBAAA8ABC4 fXsPuH7bcwAAbEIAAHXcAABpNwAM6/8AAAzuAAADzAAAAAAPAGZpbGV1dGlscy5weQAB1rVU RVhUQ1dJRQAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAZoAAABnAAAAAA8AQsHUinMmsjgL RqPBY3OkEQA+VUqKQ/Ay/K6RmCw59SOoIAR/V7jylTpGxQDgGckv0qiMS/JqMUouttBoDSeq ZVzKzQ7WbE6ZRq9zIO5TtZHVnsKjPFkWt/1YQkQpTZIShRZz4iDgAELB1PG3nMJOj/a5ZkuK 8KPnhYrZgl7L5Y1hg3pVXvMnkhiarB+e/aN1Ij6SMqNP4qCuZvIOxu32MU2/HKXknuMVgpLq 1jAcW5qFOLV4hUFB7qZ32mMq/MJQEyY6INxhh/+tEjlNxHQ2D1VW2d3WvP4q00JCMcEnjmx3 0sneUJGAATwYfSsXO5rcE2myIcnzPfA9vvEVvwZGG+KKJmqY/ZA/2R3foxjAB9eqLZSIFNZZ YI5yoRiteIWnLf+I9HxeHIbinKn72h0EBjVCFOdy5gtdUe8GtfhY6wN+ntWBWhloqi1TyVuB KGgGFTso/UgZUi03uw+r7IXJ60QJhLWbjqL9kBs1NIsg6E5S92vaRo5DFtoTvcXz6qlftSV+ 3qGYQzPpVngZ9zXzw1a7fMjkJQs5HpoEnlS4/sDx1qP8TjkBhFR5T/zuY+jl1ttkEzahhmGq 5Crl/7FWz1cW5USOX8He+aW67dDkGD1fwWRDPSIm3Jez6BdpSyFfzAoBaUmpahGEyACN1U3M 1ZyYGqqBVPa16UmxaguDp0beJ5wtS+069kqwT+62jgx0ynJVje1Fv1ngmkFbcz7ZXM7EBKYf j8rMFn5u4TUq5LUfRSXk4E0fcdCao1zWdpxnOkGSAkTXWSVw6KaU2RDPx8AxvoN/a0rJofAK 28sA3SwH/ndLJd2HQJbEUFl0+0doCfvwZI7L0jp7GDz+tnYSA7JRWPr5mHfUDhIjoSJGp9OM CH/Mshazdnb2J6rjIJy1B7RhAWZhaVQEl1DeXZ8ZWgiRMlFCWwkaoBvENutSGSotP0dQfjzb vG/rbB4YMBjg4mKzZLSbos3PMNuyFsSgDEKRimOiBljbERZHvYxgtJ/e+zhQI+nG9Vj45iNQ 1Tcfr2iRvVJz553PWz6dWdsl0bSXGLeJqapkUZIsZ0IGIQJ4jlKtgFhWw8FoOG0pNR4sm6t4 GuXZ+szglHxP2HwW1VdUmUDFwjCodRuzEj6FO0vfVdNkvlKORJxaIyElg0shRM32yy9Do4G1 NCaw+7XlGMcnhdS/2iv9bMz+7RSOsAE/lRbS/dkaxed7/En/hxTF69hDjmuCVzKmXQGphCpQ IFjXvE9FfS+mS9M8se/5KR0H18yzHQ2QKZeEN0b8EE1gpX5W2GkYOfeQqWYV7SvbYyeGy7uu ioLNV/tcXWtAabmnLL6RwqZUr4B4e10kmoM1vfMADhQGm5crX2jQE6sj2On7AJ0CSHRy6Tv7 beULVEmc9ulQ1XODiZmAdwd4Q/M5uSFsC98HZZKOkvT2944gX0ojgKWlpaUBAAA5ABC4fXsP uH7DZgAAcTsAAHl9AABpNwAJ9TAAAAbIAAACzgAAAAAPAG1hY3NpZy5weQAB1kpURVhUQ1dJ RQAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAZoAAABoAAAAAA8AQsHUinMmsjgLRqPBY3Ok ETxXqaUxWe0qIudaN1X8/+yQpokcuBo6p+TizCAZyI1olybj2GDtrddY8HGKzLSiZS5JVCsE +oDbK+Fu02SeNh4Z/G5eq7OFy0mn+wSEB/gt2kGnHf//+kBCwdT2P0lPspNhVulAAD9MlOy1 iLC1gpEeFPC9oHwqSJhgVPhxO2GgTvzF6Ja9I65BWWKTNVioA32RNGgxYEfxpqcY+3Cj83Y0 116J3qWk++HFJLz2Qp/0m/yQ7eKC4AY3ONMYVrNOQblwklP7IiWcvBenfEn2nN2U09imORfD 7UjbT8fzjoVXLBfdke7Wfmu45yLyWJMc7C/7FL4gunqHwlCwqG8ACnecJcHPgsBbBHHuAjdA rD6F4T0zQhzU0NwlGuUMzz48Ye3wVUuzBpFpfiNx7x2xLon7UGV9HbT+FeqzY9H8zY+zbo/A XKDKESA8+GD53G09yn9zRqzGFPL35YjaLwg7d44d7lSwJoqvW+SYWC3wEJSh+PUIIOzLeubO xQt3VHzK/q9qdeTGblA4ziH57KL0fosClV9tyuRBTZDFrdw3xLVvKJmA3T4KD7oaUZqxyhMI 4g2WJQgLrbT2+LSip2/yQkH4QjqUDRiY6kNrI4hpBmCvu9jlTdJi+5jgYNMppfxuJyW0o6ax p745g4kKqqg/gCOKlpFMe3EgaPfh5auhrExqebi3jqBrouma7+S67VS3ltKVNO6UPnCFXLLx Z8cz+mNqHu6vHLsj5zENe/ify2yfyLIUVb8NmQ9Y7srtgWJSl+bA0lf1MA2klGBJbblv/xgN G/rhDjNii08F8+vRKS9gXuVi37JhLcHqLBpbJXB0YWW2K2kMAiZYkMpvXtlgDrOt3l1fIT2+ Qwja1IG0y58YtG5SV/EOVBDZNJtgeSba64g411f4drNE+PZoghZPa6XTSnKdZQ8m+bU6zPOi 7qpUSjUKxQ9KYE8Yb+Lwo/8MhVzkFp+jrO5w+zOZSnemlJffUYV7sa5nbXa4OChmD2Y+KS7p yOMiSdCubkLrp0DwS6Zr0fwONguuJ3PbTCmmsVd9eQJ4eP4sx/Rl1v+zWqQitW95mu7ApaWl pQEAADAAQAAAAAAAAAAAAAB13AAAAAAAAGk3AAD6pP////8AAAAAAAAAAAAApaWlpQEAADAA QAAAAAAAAAAAAABpNwAAAAAAAFf4AACq0/////8AAAAAAAAAAAAApaWlpQEAAD8AQLhwtRC4 fK5GAABX+AAAqNMAAAByAA9iBwAAekAAAKlOAAAukwACcHl0aG9uY20ucGx1Z2luAAALkQAA AAAAAAAAIAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAApaWlpQEAADkAAE86/bC4fwuMAAB53QAA fSEAAHndAAkU5gAAGAQAAAKEAAAAAA8ALkRTX1N0b3JlAABgCAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAIAAAAAAAAAAQsHVGLW84xUx7vIityFfARrRSZSkW32yhZpHxpi3BSHjtQHWU6Kp PpOQ0V6yYyHeKIjaG/1EtsspOWGJTNGIWWmTjmaXu3pS+tpVgnpg/B1GlWlshQh/D36qhBam YD7qfOibgzScPTNigP8hzveWHKaT3yd4O2PbfOmnxif5BZumDUA7hGStATWvD5KFwV7dKVKd HHtvkhUDuCpXBRgUA3RmRfd4DJzCXb2olkmzN1IcxjNtx+GQa/ZHK2E52pnewV92xfs4Zuoe DbCA79MxwEJGX/6FnFPECRuHpaUmunhQFRDszOOCXQ2b/+9oEU69Fvg46SPZbOcAJu0O6rWG W/RWLr+WKfzgTcXrTWi9JVm/6dWv1YuznhOoX8iWgx43hCUND1/1RztaFnq5hqTrduFaU4E/ qrD4GjJGpjx67CUUOVzUl4WzrsHbNJZDSQOvxvIwJvet4Zc/uj5jcV+Dcw7p6tMgPuisNSyC 3ahqzUOZihERGfGJJTxsp3xfnS653ygHWvDTiCADL+QRQjfQAPIQlR/0+36s2lU9gktl4/qS frLbOGYJjiAMrGfrg4K51JeQ/sDqLFV7TVH3am2lakkQjbJ3oRyAP8oic5/iob/s2+GQfVfG rfOQykHEy9fyKYoMpTMllYOSpD+XOeUsX5NXgbB9h20p5mR7HiH7NPr27YduqYWS7+86uN8L K1AvIXYB5R/EiBIj7jl2S6b1GrsRNOuw3vaD6jnpgyVmMGHLol7kBKpP/VYAF0iaOLzRrShb fINHQgZZaF9WqeJ5LJZJm3yxPv3Mon8hCaitnTZDXz77KAkipYt0J7taNJtT6ViIw6fHbbdu C7IgOgCX+LchmAClpaWlAQAAOABAAAAAALh/C4wAAHpAAACoowAAed0ACM7hAAB9fQAAkUoA ACsmAAVjb250ZW50cwAAYAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAKWlpaUB AAA5AABPOv2wuH8LjAAAfSEAAIA4AAB9IQAJ7A0AABgEAAACXgAAAAAPAC5EU19TdG9yZQAA YAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAELB1JqvhWeg9TxZl8l+jzytuRUc IfWhMgol/lWZwI6reXsVIjIpzB66RwaGGLLOO/mjmnTrSy4mLWy7h6f2tARBHhv7mDeO1Iui 1h2RFOTM5MnXG81yIIJNONhRyEn7rX7DFwJgomY8pW7XletjweNy6HfEvUHysMsCrfMySa3M NSRc7nwe0nvzSZYtcVmHHIzEMDqzCagjrL5an0ewRVHnJt5jf5BjCNU2Kyt0JArkLQGE5l8x MM0hExA8/WUWKgW+ZSnTOUM0SZnUcWbgoElSBMCJvWH7HkNQDMgK1AFBYfTTNg/Zt4X++QrP tHSC/NEVJyfbQTSSVXkMcC9exGKw23MPGMYgQmvhqzkxni5AVJ2LLTCdN3JatPS+HzGoWoah sLrOoLOitiax2Ystvg6mlS3qZClRNrWuQeoL0nzTHlZGnhscrzzTMIdqe7/ri4jQozKvRr33 SelLQzl1FR3VylPR2I1As86rTckoTn1ksHqpoT7GRLt8mIU8ycucXVe/mSH2I2/4ysC9DJhr n3fd4pa9MjKXVMuhQnnUTvhaH5tQMYV0P2i4k1Itq+vjbOtmbGAod+0IYg92R+SEJ9qvTRz2 wuB2ocf0nzS3WpsAvPFlhLdsmfo3b8XT7hxDm+8O++1tRwmWbVDSbdBvVt0auAK4dgXOGPu3 6qZLYaIGMal78oCyDPhBrlUYHP0wH58WBK0nXBZVLGRVh16jTXuLDvqrnNEDzSi1O3n4nMgT olvpnv/A6sEyPnWas4lIXqa6rJ127+7ZfuL62/zL5YuBjGCj7OZvkZ//z62gAKWlpaUBAAA6 ABBPOv2wuH8LjAAAfX0AAIKjAAB9IQAK56QAAAUpAAACDQAAAAAPAEluZm8ucGxpc3QAAC2b VEVYVD8/Pz8AAAAAAAAAAAAAAAAAAAAAgAAAAAAAAABCwdUh2RC9ndj86/Wg6cHvp82pfxMf IzgN+X42YGTAs7Y/XgYcQi57fmDxGseBlxL+Bw7nZKKkpW9vzYtHTBVPrqQS/WXk5kSpV4tG b5iOw/YImokS28b0zPQO8Y9DYeaIGvQI4FWs2t4uoBADhIC6LDQLNtJ35Xur25eySJrcn3R2 VRgtOVyE5b+KN7Q873bGYdyrvhQmrobHrDDsed2lihFnMi7CAXpBxonEi+fdbf5sE4yJQ4M1 7TOHHnzo13d9RimElUxGG5BLXSmSDu03M7Z1qqZFKhjjZNg3HEDx7xZwVT7s+IKHIwEx0EpW SMEm1ORqjsb4mFIiwaKkxAG/P7g41IlXKNKpA/pZvOBuQ0rqMGpUyZK6UTE0mAfy40dOIOiX 8LdYQ5YXdOZBtKiEQhPXp4Hd0gmdKmR15A25X1aI2nY+sZCz/ZAk1vEh5qjLv/DK3iUFJJ+L i2aI1TZBmn9BBddQJntps+4tPCGJvFm0DOiCBavagw1RprPqW8lU9kMp1ZmRaNBzaktD9eig 1uCvojeERi5f9YumAHCVZaJczvWZNsSTnotJz24wm2F3TNmALeZdZ+Et6ZhasekU0rB/wBhP 29CrON6FzBRgHK7MOY7Y3Hr08qBBPtt7it1xA3wsX7BCqdFsDJmo+r39X18eTsPDazbCjtIQ uTSKllxHJuaug0i0r9HIDfClpaWlAQAAPABAAAAAALh/C4wAAIA4AACjIAAAfSEADMF2AACD AwAAWN4AACAdAAJNYWNPU0NsYXNzaWMAAGAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAA AAAAAAClpaWlAQAAOQAATzr9sLh/C4wAAIKjAACFwAAAgqMACSPVAAAYBAAAAmAAAAAADwAu RFNfU3RvcmUAAGAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAABCwdTQpRXQETHu 8iKtxnXcM0Bvx+/PoUuag7AiJZzjGi8bLl54+Rwf7/N9CuwT+iWtqf9NYONDQDR4v6kiLyIw V0xMR+JXQ4N2ZL9OCeG9NasB8l69eWlPBlQYEJwkJQ41H+QLKIr2yX9yDBBCVg6IyhjYpW4x tunmeReW7qaHBcZ6FDH0QAw0ynbUmoi5yJUGI2BDfASnZSHDpRuFO7nwVu9Lvhqfn0j/A8Ja b9ivsTlSO2hJi3dwZvbyhfh4a2Cevk/PEzwiY83n5ZltecLBRuCDN38PSM/utOFz6bdTm96A U9RyVOxFv0g6vca3HiLcORm+7X50kykWM94xiEhiqn82ludzCR4ItFj2BbSO70PYYH6J1oNF rMvlq7BnfctIY/R9kwYKnyOI3Ha2ZLRaYfXIYS4+rQD2B2L+aAoq2AirbBhoYGZBDzgfvc3e PcL0Nq47etYnirlNzEwKUzEbJz412k4b9BzTm/FsLAYXrQ57k5uDRblhD2gWAQRw66l3A3yh TLtcXmSurKzqHc1522zo1BJ/eAhJ7JzHfIdeuaEByF3efZjNmsX3Unb/aPZ4mgL2aESxX+fo YMM//+JJHZ1KWCgoDlsLos994mWPQaRUTm/AmeL8bHmcHtyvIuIb9DD5LgyVyvh2U60V+kkm Eyr5xapbYDXcdoD4cHkOH+1xh9nTVzeofTa9p+4jqdw5508js2g2eNx6tV0kXvddZseMNocW WAtbYbWeyvqaKsTCymAjebN+QyqxMiOyBI7BaXfQBJ1ta9XXGvlh5LNcXS0ovPU4AgCGIZyc lMeGgKWlpaUBAAA4AABPOv2wuH8LjAAAgwMAAKLwAACCowAI3vwAAEDaAAAc1AAAAAAPAFB5 dGhvbkNNAACV6GNtcGljbW51AAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAQsHU8z/cBK5mjGEJ cKIR0r0MCKyUVqrCpZt5ycgMV8FXrcrT3L+aBQNShh1f/8nFWMVFAPOfgsnOm5JtcUIZJ+ma RA32uvcpNoYCqqI06Puj3fgxJqlY8rfsMKGcePGrUXl9hYZ2PqYb/K5XelJIxfocLtch1QBQ FGezBr7S7mhDvK7q3Gz8goTEqJ3h0M0pHSezsisEWMhngTOjAkB4e8DzEh62Y78WSn28c6OX XlIs0m3K+NqKmDlJCDSHj406UkDea/UsMMy5vmZMgHuL4Vw6KFYdVklPnjQ6pR2B6dNpbCDy 4hMst7qrfHu0meJvo7mKIY8WNv1zxQBd+8DSWzgnHPfqzd1iDisXwcXfBLNpIFgA0b1jei6s M2CGM2pBi/SsFKvUYo/QlQ+4TiLEa19w49tb7WC1l+Um9PIt71YA9xx1884oVI6Y6hwaCJJy J0d24DeSTRl8j1C7kzxn/bbDqmNlCQOys7CnFQX0gft3U54+Ol2U8F/xMKZPJVq29A7Dov1s CgCuLr8hjlNNwmPlNPO2q3SbhxBFp2CW78b7HT2fTRzxyZHWFlE9DZMqmUBu9dxK2jDXP/RT yr5NUm564aQuJRoyn/LkxnsCEJbCvmXBTKI/XTJuyGyQzl5qCjcqcghWC2sbZuJ7VVSwJcr3 vOlvd2e20QcMmiXevOq826N17eBiig82ew+Sph/x/Fkk+bsJkZ1W1x/6BbU1W/oe+5WEJ8yZ 9bKJCqE3YxqYbf8WpiVKmYAOMbeZEjdxwgpnhpyl9J2WOtvCDO54XFqD2+T2qRWNdg7xh27I 0wtNH+3Het80owasytAcTvgWYQGsSXAbVK2x3P2YlRC1DfIkNJBW4g1pigxdL0AqIeQuOG8Y uDyPvIp/jJ4yUEwiMXWZNA2mP1gVzFOwmjDVwxJp4Rj12TEyGz/06CjyqUiXS+P27e6uCu9E zISqXrD35O8vanakRvWtYymrPCiQjAvihtsmxSIWL7lG3E7cKoyKdDnIRPlNb+ReOn+EDIEM 1NPZSCdj9THSPD4tb65F42XuGlQ33kAv0l1ajt4/zYV+jMwYqMk3TpsXb0cQmUbAsDPQ/elu h6kP3VVUVZyCXDHyIY+AMJs937xPj4MM8rUO8jJNNlqj1ItvuSfAYFykWx4U0BPyxkCkNt6f dCHUqEDBF1VsiG5SLi8LvoALqVpgivzEWNJM1vHW9auT8KxdnUA4J93ywkmTdGr+oakKlaCT LLSG1e7QPaN8UhK//yIGr20Q7J+Fpr0gSlKUT5Ac/Lov9CjTmlbfiQZIdCYrtAWSx3cJ+Vts dFEPW8MvItr1wJ2N8hblBLjPHoLNc5w40Zvlv3xv2dV8cjNyPHAdXIbw2ievpi7tCHNmmas/ Ymk2h9uX08T6SYEdiPscrh50TvDZiJ3mb9iCH/0wcrgedJy7s1sb6csR4cb2/A/Y3vhdUymX NM7QmTcuAhz+LxE/G1IB0ltBXAVv/yops4a4Eq/OiVZAcxmLwNdZrynt+BAmz9MfmjdA0CvW mzgiIcPHIlkB2+QtCMn/e7He6NW9ZVT26XOGTFOZV01NuuYavspLCu8TY7zwpqk2rzibu5b6 bIcWNnunD7p5TmGWCz7Ow67IDd/T1LyA7vG/DEhAykU7RopdcPs+3nCXuvL58WwRmCKpuNf6 4fjBZabfTV2h82dnP77vzSGXG1aLS+o47uNHT40t5/dwdT/aPTzVLx2EGEBhJnQ/jVcSwARr cCsDJCwfAhq3gFvxGLBLdl051XCjXQLzJxSlmiPUJzkeVGumwNnm2xEqT9zJtfRtNLucWrLm VndDkkZ1OXtipNbni4XC+IlWuBdWhGYuz+Z8xdUJ7ZBcRCYz3cGq97HgRnyVkrQimLNvjVHH LtWVk0has8iQlkDa1xFKxgJRcUf9YTT1kW+DMqoZXnGHYixRCjCh37nHQiFhzVriAxdqVcPK fVgjZkwqzge3SJQcNlb9cOEsdS/I8V7XpRBSQtyRI3zddHiUUbMRUVI4ptdK+oOsz1w0bMfG x7V3qjRxuqP95u3v7WJUD9VKCt2vl9edKJNhMgLaMrOPtH1yaSZ3H8OQCOE0jkKvNOTuljV5 eA3kHUlTYCZNdIemEXOtOvckNNyeLrqNIqd9VkibWx3vRulPtZQUlN1Xk1MoBGz9PYuY/DxC KLCFxFJXFOqsDadNW5asAfD+3Rwyzx3timWdm2tzlR9kZzVk8KZ2+gHsKbOswxuhZNZD0pzA N7bsywvugd0kPcrjf1UVVHR7mKCEdvff/ML+TDLFa23cLIEXpmxltQjPmf7wsompodIWkt0/ lRmPLKMdiSnBCyaa3rkAI1CsZPpgunewcZ6CDnc3FXNddN9NZ7MaAb5dB7rGMhwynjL8jNA/ JgzQYd1oDn7Hiv8JMQsCwEueP/wWCUyjIxqayQsPfyb/SW7xv5Amq3C3dAqEXICxGp1cdUk/ qkLwxkSyJwGb3tM+exCnLmQ449/wYzPlhoiAU7qGU7q8TWxZxF2LYvySDRZHbh6Klrvr/hnv 9zwbMjyXj9wuw743kiPcMQT/8hQC/SmK/o0pVgTAwwAxWXYYZOMGiKKF6iVzoev5sHBmKwj7 1chNnAsr4/zqWqdLyTQpmP0CBF8eEKRYTwCskLKY6U5lvTJxCfgfAG73Qx5kSetGb8Zbeizz oTlUOBGEz3lUA87uFjh5aNkk9anceK+pB9p+dNfwO8wLmRHgfzjNkv38Jbkbf11JjjMOCGhP 6R1uMJOC7JiuyBdu/UdgU/9lHmeheP3G/MtS59B46Z8zeSCIfMPPKdASJ88+GhHtda173WLM hQ+mWyzLx82/7SYS1BFOuLfGPCeEy1j8aGYm2ZL2P8oX6jxD+HEoof3sMDz8hTVPWJxq6mc7 j2I18e/m18Rw1GtUNI+w4Qk0kIJmiwBxioIWbmTXS4oErGVjFLJ7FbveRgZZ1jRyzt6zjzqd kqSVD8QzmfjnkCHuF5CnO5jgqHMjwrU3oFxDkON6/liPi2cPRZcuDahHd51Rm25VN9wk181+ CnsKJFOwNskCdz1L8iCdrik4VQq3ctzMu5nGLKVShL57ntlJyCzVGiRh1S5I3m6FjbEYyDwK 0//8oru6uadJk/z5I3uVAXAAoMF9Z/U9bntu8Jf+neVZC97Z+rsQNkxC2aqsrsp64EY8mgfc OBpTCfFRmw09Ev4POkPDpZBTMU5hswH6vzbgdGYY1SfDS9YzADBI7SXsmvkD7HMsIL21gtTJ BqM4FOy1TUQyIq7picX3mWUdDd+c53kNI3M0F2anDzc2kM83hUvRgzOCsimI4eLRRF6myudx xSZeX7UlmCSDSV6NrqKo0xSPhu3tbmCDIpeUXDcXgyD3srw+5C5y5oBThKcKBopjlgGTbjyO S3g01yuiV7DR0ttIdQS9lCych65EAg4yQkcxHHj1/FpaCei1UjztVmNT9fkESnqKf6EEKMTR PGZFB+yIb7OMPFJAfu/bw9aPSJ9NjTCXLPAxWOoirSMkW4/fKlc3QwhYuZViJ/iKo1pn73Xq 7JulIOMGnqcHP3cnkUF5DuHNRvS/1z2zY5j/rpprEK9qz4uHJEVAPxqm1Z182wq06U4nHs5y Tx3qIYD3gmomfyr5B/EpJA8A0kq6arOLQCXJRCVxChY761bBEjgI/Xs9O4C5w8j6QP1ePFMq lEUkOB7KYVd2PojZV4eWfLm7rJciGUte8BuqG4kM8K3az64ZqKa34jokOjAGPcivIzGrRXbM QtSQnyAKvJSy5aDbtCLwKZhvIUCASRY63jYtpQWN/a8DUkRbtHwQ7hd+SYmGZyacqsage+Z8 RyLW/xY6lbLLH5DgLKY26MM0S+isbegNfbCVW1QrTAEY2zryv48kleanE62cbdk2AYYEtEF2 k114M33qzkyjo372tvSw6r5PYPej/NWyH39j2nyAl+tk7FV0ZCJRcB32pH0F13RS83X9B3Vq /CLGnIZYSaKo4VoOG/A1/mnIQjyDrwGghEVq2h09EEP9nVHh4X10RKEDX1YTL3JpMrGZBhII ZYs8ZZQ37OL0LX0lx+AcFO8IazbYuM0hf3mqcgUx0WHRlyqlKOC6vBaZf26kKwUkxGhpsf0k eQt7Gbug7egX0JeQ/9aQ9YQKiIDRgzlCc6efhbJ4bsCq0pCFh6CcKAh/t/Vcf8WLwvzGe4so LC33zT0K5MryUsHtuXB4WsAYW8qZFAthCWyI/cDjMejv/ivOIvHwZjYSqa+nZyEytkHaa23w PlyeGmDA5zqgxUQmKF/9flSFZRwIHYZDDTc4OWpQhXignTRZNqhw5IS2lZX4GgDCfU+tSmuG jGtgGez2f3JNR0HiaOS9DSvytNtZzsMxC0QlxghjEqezxbrWPtQ2qV+REyvS+Pdgu5JDC/mt uV2MYBXplI3GPyHjyZhD0FewyatXkdA34DLdQKmQpYdmGF0qy2bUpNWaKzCAjaIzezwkKEvi xX7Aa25UOwZO3YpqUqafbLGgyOb7Lj7LRkW7J1rOU3XzSMWle4NjiTwQw//q7Lc2kPoWpVLt u1PeK/sew/ypZU10LPzL4K4AAS2LECBwo9R7S3eGC3OUR7/3gIops02ncey6g+WH3At6tmMJ wNglBByV1oPGpuXNbcC/mXU9PHTSPdOw4FGH8K5v/lsgUVE0t2XRovklZTOmnVRlS0coPuCF SW2OZCrg664kUT0XisRCRb9S65KHhc1v+xogp7D0S6m3I+6kmzCc28VZRaR7vxuWaSD2kvFV Z/Gz9XWxenXO3Tqi0XW0MTqGBJDLVZyxlWXolkn1FzMR3QdHFVOGJTll3FmLLnu1zT6EjYNm SvIwnNIxJdZ88Gz7vacJpH8rFjw1lFeahzzA5+ewUzM32sQSJXQdtYGaZ0n0pw8W59bp2GzC HKhguubs4yH11zTY5uaOEdIpbmro4F8GI7I3bmaq49U1l65YMznRmFer/sNxjfLVwu+AjejZ VdCdHRqx8rhaEjeAo6mCGzHpubeJ43HGar3rn76FXQ5GwsjzvNLrfglRgZS0BQdUcpfM1VK8 B4bQ2xYX5GlJ8KJJdAI2+Wob0y+yVO9kId39IcBsU4K3XfBx6VgfzuJKH5kQQh8pGc9v4a3Q TAKSCH788pDPP1HcJ5eMiCO8EqhAs72o2XxMdiLxt72WqYTmff0FcL3wb8OEOhTJbZNf5YYA +6XlRGjZbyiyyNbsGa/P2kjBGIaXWG2nXaxjiHWR88UpWCn281EYptp2MAbTKzkeFeQY1+Gx D4rwKMta1BYa9WGTK6CKc2NkSVYclT7J1+FCNuWDC04xZo7mNS221SybA8PyYTiefow23MHt HRCgBP4wqgd/keA7NLTs35zUFi3O9uenlgN8njEu64dShbfAsm3voz3ZLNQG0JVw8DQ3g9gR SsmdrCoRastqMmxOJnjxQMg+kTxPu7ofwr4uUUEt66FwRdFSKS9Ymb7/DnCpmARk772zuHaH 8jS+o+sy6oVYOlaQTxgy0wEyqqx5XMvyJ3lxHZZK+WU+I7XEj0I3GOSDnzWlivoU2ZR/Dm1y H4DZjFucJXjMSedpAQTRf4NbRCVEbfb+s30U8tsoYebX+69l6arW9Y4Vf8Job4GXUH84BGPc ocLEzDqRVgBxE+1fmkokdU8BOYk5gCb2vz9srvFwE+/UxQbJ5Dw2EuDeN/Pvw0HUCnGly+n+ 8YF5E3kmvF7A2LABMFkb9138sPU2r61yoUWKlwm3w/s1L47kQaSGbxdCkpoZwJEDy0NBrloF Iu5Uzf89sK+Xje84iL6MqIMlvcybgAafsKSHtg7SrUgqzWr0oo3pE69/2v1BtANy96+fBm/U L6/2DTJXtjCgCndoyjDWelQRP5C3eTcphEBGkMBsY6ESS78I+vJSU17Q/M+0JFPcVAQrQpgs Q1odTFN2WcS7AdJG/RS98ab4ha+QWyRfjGh6tbzsT7RCdUlO3c89Vy1GyB9+YjN2Ea2qlM86 6MJu7+emQecwHdPjgYhP/e870MNXtVv09r0g/jFpWEMYmMu/MMK+Ipv5fZilqrDfrbEkE2he S2gcQUBBGm7Gib/mntfs2C9Z3tRgy8oHugokYUKFdgwGD6QxZN2o+AlgMBqVVWa+/wtG9M4f Yu1YWbJEbkArBg/4Ki/la68gpCGq5mLFefZJBI1X9x7mc7BeNPJY2OyLqQeY73ybxz5FG/8j V+VJJSAW5TEv+JFMmM1ostwKy5Se2L0tkVaz8bzsFeNMuzw+p0L9gu5U0N/ojN6gFpRTrsIR E3uShwcaBtu7wjD3Qm+bTbQYAB0uk8DtAlO6r04YL8unyvvaDI8Cd6wMcGEzF+0Czivos8fu Y0HdfYuT3yF+hgHD0PNjVVYJm/LPxetVDQFULp6oaDkHWntVtpgMXYTeV0B++U+QCS3xkqXt l2mAjBiwwaB9ftU4hRaLk8JK/hh1hoqmyV0ukNSK1JK8MaDOLFM4jRa/NUQ11LGdZv4swoFe DY4dd8qOQpv3/rIx55znzLLeqaQ9DKSaN1OTZFKfloy9djE9sb6O0Bt3+DDGfJr9Oy3ReooD U/U3qhwnM/Glr+GobgR9clLLvSZxWe5bdvraOQBb39cPDRTDfLH0gpOVmxQo/K0gnzIXofbW Nf323QsEQg1IJ0E6WLSH5zmYtaJ2CGtLdVizQ3wd89VqRlQTmPxJ+UrXDBiFmWiiQyQnKwAj 5dFSAtqOTju2tkbhMa1NxfiJgXBJ50uBrgvaXnF9dyWpbvwtLuAJbFpPclrxwrD72dcmxMWz l7zQMHVu51F64/ridJ1pLCu8eMnBoqzbZNJhy/2NNSXaCxB/l6IG6fJ2bHe2pH0ta7wdxgv9 X24g5HY1YcBuDhek9EawmH4pQmMlPvlegmAhkTqKJJmfGWf0vP2ltiPLVmkCcCeJxJcJtURx FSET1GXDQYO70C3YBB1YoxsX6T12v22S+u/ycWDFKYoz87G1CVRW2W6jdstKccejx71XgZE+ zmRutUBPkrrANluhAI0TmvafFv4t9alg/Y6eBztBmhkJU/J1qlgC+ZEYj3Wu4F0PS4oMbk78 rN4MxSwsJegPsd9iaDNAyHr2VtMG3w/eRSEqm1ETbwpB0XBNbXsJD1QVAtz1gZgOy0CqxkmF hl3NLR0uLC7a2UUqnWHwByV9DfLc6iJrJBM3wmIs1n/ZpoJFWIjz1nKMHziGE7FFpHKTmhPV qrhoKapZ1jxuXGxW6NlhwD+OficW5wM1K2MxSDVGKcXrYHbb+D2l6KiEIVe2zERAND0xF90e f9wZuYZHch2Av1CaeRU4Fa9CzGqne2PGKgCXlEMOLnzsd2BcniIYqiKDwgiiY94uqaPGj5jy XH16tWeL+AtIFiJD+/XC4ItoLGrLVP5dbBonNaJ9ebu2wMgy2R6j5ZKO1Psi2yZv3fmKeN40 sCVuXeIea4pnYg6mtT1UIWZEULWOnUIil+Q48cO6Rwc662biDh2RLq57cOz9IaiN1kMTcPSB yhVanMJANzu9yIlg4vLPG0GFhS3d8wEvq8TfKScKyRDXXhQrmAA041jKkdezNb+Qqcgkau70 WjN72vKqKKGrBozqyBuW+sPTQOFmWEZEYNHrLypwS6XAydpea/vXrJ5kyp9dLgQOf3GOVgsv gnqt3ZLN/MOyzCTYom6/wXCTf6Hln3v7PPFUHsymtE3aRzcuCaFqXxDFcMuLoSS0LLmrQ5in g7peHIzNxIec9vflcTc2MpzZ5u+uXrjrjrgk20un5I/du/KFeF3GkYKSEfqEMFn0+iE5gH5D xPyIzDAJuPhiONAxRWmdO/kjzrs8lcCkWgUrhuXDkgSqwowuxodHD3y2AAlJAEqsNCsiQ938 TW/7ht5q/OEoYDA72KAQFmdYs0R3I1hFy6TdD1UrmD9Ajf1GXU7QrT6EoxCxLEj8hUXoJTBk BMWuG75tRVlLFQjA7kCcA8zent+KVp+eI33lG5OgS/Gs2U61Yzja77K2GNu6PViHjoPuM3L+ VLzftiLJKZcNSg3WuArCVHAppznZ3l33yi+1bumQlF0uEH82mUaCUDL0UzzcxkDJ4auht6MR q1pnewRoGpQyfeR2xT1S3YUKiMvBsAC2rUOr/F7mTtD7rsQhops8pvvb5KzlftZv6Cps5aOC a3p5TcTOpBxglltEsCW6T9isupv5+NSa44kC2Phz6GOaJDiVmKTLBlt9CL6b/y3svXWVmjtS cugQYveGpf66XAe9TPyRJfq0lz/ADWXxLyC8+E7fO+c00LBMy48VPxeZeJkuhlK/lS0h3ol6 oeNGPAzI6XThsGhoafpLPSKbyAjXuge6xMARfmOCMOUjda0OHmILA6foSljn1MjDN7kBg6bh zN3mgQtmgUQuxEPM0nlFpsbM1mKQf6Il9G5kiXjfJNfiHICJd7/GsblqlZ/AsMrW1EMvb/76 cxLwXUNb4Tm6FtS0l/KGQzZ/Rm2Iv2VolEfcGkFUon0qgfwpQIyAT6PNhY+fRL8spNOSXfqc GuY8FTgZJMeNCa5kwOH8Hc/Rw0+8OWlQgrsbklnNxUNCTW4jv9oAlw3dOqXH4NEJ1Z4oY6IC Nz4wWVFJbVE/ohssbxyEfjWlHH9zylgDnmpGlHXm9n2LNaQokw0E6FazazgqTW5voudmBGjU esMW07RY1JPWOpivKX8YrHeRv0Hgx9i75+Znjm+VQc9N7OG/LTpUIZ6J2mI1Y/ZsL2/xCqdR BaQkFeGFPAvI+3TUsXwy2w9vWGv/vV7QttWPrvxWKKGSvV1OtWnRw2VtkuseiAfWrkcd+QqT 6KfdJ8gbTjCN2dJjQ4+tA+NoMqWDsN1fyi/vQo2/rS4EQN7DVYkPW4qA0YDz/C40aNQ0Mx4a iOiUfVExhBemu2wYyNm0J2vFkAL2Y6vRQFQv2t+N+8SPsvxh4wXvj2azqe2D1ZHj3UOiGbWs 7EGo63CyFVLoFW7eFsO8snp/yd/aOUyzW5gvZmUqFzZIAegxA2jOSs+si9uz2YA246QSiLyB 1SiAWgYVBo3MXedL0zFXXJHmBWq9wdGpNRxtlb3hDkfalW2xvwldA2Tw9HMA/WduVvPSt/L6 sQUq2qRPu8QluRnlGghcWRyt6IBggFbNIdftM106bcZjbm07NkF/YHnKGIejhh3nQbkpG/pn SdgTD9pxccPl86OYhgFkpLkTICEd/wqMUbeAJT1BY4uSilOnK6mZc4GylPsJ21aV4mbnBMQU cLNLbKWLgg8WG0wss6D8LOcobfL8SWp4mlZzCiJslkTmumanm3Gzesb9Jp1YqGIXZdG6fRo9 Ov4krFu9WVqApJPLRhbAPfpXHWRC1rA3+i6uGym2pNQvyRC5RC/yUY3ZD7XRgSqHja3mvrV5 /F4aWFFyfHb5CB0wttcRZ7q7FIoB78BQM1K7AgiZgCLLz9FJjDFlVPux9bWH1vho+p4oN8Gv 28vl2/lEil73qeoSH+zxI2sDWKMTz8O4JUob82fPsAxfKfZFtyb3EOTvgR3unFnseeWFZmVp t+swdKDJdX5677Cn0uJlBmhnk11Co9HrZQQtocM3xOsembfXIyT3dKUr3A5PDOaTaCgRzUAp 0INv7A+h2K1yn5bztXFqD0xViAbDA3ge1+rls79pIjqAUVatweTEkDStaRNM1qJh7XtFM9Q1 ORRQ4oVPymdzuTtbEalQ94LpyRm7AiZpOKGQJYWj4rAphmARuEPyt1W2z3WSHmrZpKxmF+LF aaoFdnxAJnE8ZLxKIgW3CRcg+kNUPtOZhxR/Uj1GkTtflrZ52s1jeLSF23ruFcVg8hGLPhEQ 0F27Z2qUuAGK1aodx2OMTABz9oH7qsVApaWlpQEAADAAQAAAAAAAAAAAAACFwAAAAAAAAIKj AACpxP////8AAAAAAAAAAAAApaWlpQEAADcAEE86/bC4fwuMAACCowAAo/IAAH0hAAfGSwAA AAgAAAAI3M8AAAAAUGtnSW5mbwAB1tNURVhUQ1dJRQAAAAAAAAAAAAAAAAAAAACAAAAAAAAA AAAAAZoAAABhAAAAAA8AQsHU0ZGe9a2qR9uguGBHnFjTmlTvS2u0a2Tk2swYXPT416+IX8mB mMG9kXAsyIaj53wTcYFZL2+uuikPZABCFvnV9SH2yPubGiCn9W49vpB14mvXevhpXz8Wp+Qd BicoAGNtcGljbW51paWlpQEAADkAQAAAAAC4fwuMAACjIAAAqHMAAH0hAAlO8AAApE8AABmd AAAEJAACUmVzb3VyY2VzAABgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAApaWl pQEAADkAAE86/bC4fwuMAACj8gAAp5cAAKPyAAlmugAAGAQAAALrAAAAAA8ALkRTX1N0b3Jl AABgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAQsHUwfBEwAwwzvIirdXlW2ez Tu2+w382Ee3Rcabb0jZ7ggkPGII0mrTUimk7fNZv5p3vVDdjNGP9yEnvFM1lBAsWlo/cWP/Z eWhyXKcOVaFD3HvNmMTu42iRPoce/S+OjxhkpLqZJZvhihJUdAHVyozdHYU82SNFhYmfm9zK o0Ik2jcM84ESoFEEjjK8sWleV+v3TWx2Ec90BIkQfz18wkyS8BUZyPT5wPXsg0l5fP2HNlpA l3WLBNrt4BOMHNU4MyhBaCuzcEAd0EQDiQURDbJRAtY7NIw3oFnx1URHvG3WL3cEOXydI7y/ Oqy66lhKmvJ99/wd3awGMghtuk6F9D3fKpO0La5hHxlkoVZSIa8sbCpEgIt/8nvI8dBZFWo0 s5wR2DcKqwTcJOtnB/Zjm2TxFkvRYr9TmhZJ4JVJLwvw9ZLz9vVr+dCghahXB0Ul+tA+s8Uk fIx0FQZArnNkpUSFyBEDO+w4RO6CaPhGrkIr+MU7m/S1ejoqEbpmp/5cDt5UReZT6b5XmREL T3dmHDSfphTIXoI4EE9Z5OEQ97upTTHdU+IjaCWw2DDFBCkzPuzTUl0GC9LIyvzJ0kKa3H7x At4mX4lbjjZBO4s5a2FGKiHPFy7nDty9qiYGY9DQSpUY6NAUNmX1qJMLeJNfg83a7qxbIV93 m0aQQXDZKjsJ60H4Zyq/XOxB4JXFCQblLPU1Fm39K0IsWsrpFQMufcprqQsD3R5P49VU0LJA JawtE+/s4zPj81STOtMrORgdCYoUUJZeC1lo/x1YW8LsINRei4X1GZ7pWG6F6RBW9qhb6nJW 8rUJ2JUpgn7VMTOF4/8mVEp+d9L8zZ2uymJm00+MHvyI0oXQY2cfntuaRh9Udg1HxC/nD4ll WCMS9fZ72F1EbsXLBab9qnZi99ptoo59PmdSRS4PvusJPyRJm7YVmYXYig8Bf/MZK4nqtM8K uTkLKOIJDbg+vPEGa/4RUO7TWiIh6sKly0gApaWlpQEAAD0AAE86/bC4fwuMAACkTwAAqEMA AKPyAA0e6AAAAZkAAABLAAAAAA8AUHl0aG9uQ00ucnNyYwAAtU9yc3JjUlNFRAAAAAAAAAAA AAAAAAAAAACAAAAAAAAAAELB1LKyTRM7GQrqtZZ3pYD6BZdCQw2+6okbfJXZAMjBSJ/0CN75 PRi1mV+WH6kjAQJouH5jKXgbQCp65ydw2C8AtDspJWUk7KG0sKWlpaUBAAAwAEAAAAAAAAAA AAAAp5cAAAAAAACj8gAAMzf/////AAAAAAAAAAAAAKWlpaUBAAAwAEAAAAAAAAAAAAAAo/IA AAAAAAB9IQAAoTr/////AAAAAAAAAAAAAKWlpaUBAAAwAEAAAAAAAAAAAAAAfSEAAAAAAAB5 3QAAiKH/////AAAAAAAAAAAAAKWlpaUBAAA6ABC4fXsPuH8OIAAAed0AAKslAAAAcgAKFY4A AAJdAAABfwAAAAAPAFJFQURNRS50eHQAAda1VEVYVENXSUUAAAAAAAAAAAAAAAAAAAAAgAAA AAAAAAAAAAGaAAAAZwAAAAAPAELB1KUvJH7xYSwKl1pdqMqxQmnD/hqcVr8w82n07eTkwFIf AUwW+i+EvO5mjUAhBfwGI2hUiJ6LrkBlbQaJjWDMxru4NhOFKJWBpN7gjloAu4wNrv4Oj7jg anSTebz2sutaaUclW7BCwdT796AeGRfssqHacT/SIHwLF2Sw4fbyE/jjQw7Ak9ljSFxvW5c2 WA1gIwKEwVsjWEdxpzmFVjPufCiCcxG0GcBMsXJ/VF3fZ7cnSPn4d6PZW8IUAF07HcRiN5VO V46E9kHPADvX/BSu4ehNL7v4LA4TxxCouQy7kA52eBiJxjRMnVAbFLLeEDXFUjZFjY9/Og3B e6Wif4jals2R68xCdfIxqMQRaEcOaPx3k4EMg3C4xg6omQhExd6ekmHvy+81UXGYlOUAnOB5 cGRx3JPyNvzcBsAWzOYeAu/gtbB5uvIUI85dipVcm9myD04642+iJVPrbzuRtpS5BIKM6hNQ jn55y5b7/ABgg4uFw87UnR+aEgFw1Fo9hhuO2CeedBQ1SsHu8RUxcXQhsINfraZZP/irU+yE bPPDT3m5IUciCsuezFCCag5HxxLDivji6XSft4cHga9I7I9T4OwcipuKTMCfJZS/ZLh6YUht hbPnu9xz5LO55ak+AEFcaeHDAKWlpaUBAAAwAEAAAAAAAAAAAAAAqNMAAAAAAAAAcgAA09n/ ////AAAAAAAAAAAAAA== --B_3095334526_5394163--