From jakob.spies@spmtechnologies.com Sun Dec 2 19:00:25 2001 From: jakob.spies@spmtechnologies.com (Jakob Spies) Date: Sun, 2 Dec 2001 20:00:25 +0100 Subject: AW: [Pythonmac-SIG] copy() in macostools.py Message-ID: <75FE1C8FE217E945AFBF635BFB505D3106749F@fallback.spmtechnologies.com> I did the measurements: You are right, I was wrong. Sorry. I seem to = have misinterpreted my experiments of some months ago. By the way, I've got a question concerning the PythonInterpreter implementation: Why is file copying by orders of magnitude faster when = the program is run in the IDE rather than the interpreter? (I just made a = little test that copied 100 files from local hard disk to local hard disk = (total 30 MB, size ranging from 232 KB to 492 KB): 25 s vs. 45 min!) I guess that = some calls to ::WaitNextEvent() cannot explain this dramatic difference. Jakob=20 ++++ Stop the execution of Mumia Abu-Jamal! ++++ > -----Urspr=FCngliche Nachricht----- > Von: Jack Jansen [mailto:jack@oratrix.nl] > Gesendet: Freitag, 30. November 2001 11:42 > An: Jakob Spies > Cc: 'pythonmac-sig@python.org'; Daniel Sa=DF; Pieter Bloemendaal; > 'ubirkemeyer@gmx.de' > Betreff: Re: [Pythonmac-SIG] copy() in macostools.py=20 >=20 >=20 > If you're sure that the speed of macostools.copy() improves=20 > significantly by=20 > getting rid of the single read() call then there's something=20 > much more serious=20 > going on. >=20 > Even though a Python function call is not trivial the whole=20 > process of going=20 > into read(), calling stdio fread(), seeing that we're at=20 > end-of-file and=20 > returning "" should not take more than a microsecond or two. >=20 > Could you maybe do some measurements to see how expensive a=20 > read() call is=20 > while at end of file? >=20 > > The implementation of file copying in macostools.copy()=20 > looks like this > >=20 > > d =3D ifp.read(BUFSIZ) > > while d: > > ofp.write(d) > > d =3D ifp.read(BUFSIZ) > > =09 > > It should, however, look similar to this: > > =09 > > d =3D ifp.read(BUFFER_SIZE) > > while d: > > ofp.write(d) > > if (len(d) >=3D BUFFER_SIZE): > > # last read did not encounter EOF > > d =3D ifp.read(BUFFER_SIZE) > > else: > > # save useless but expensive read attempt > > break; > >=20 > > I think you get the point.=20 > > I have tried this in a Python program mainly concerned with=20 > copying files > > that are smaller than 512 KB (=3DBUFSIZ), and the speed=20 > improved significantly > > (because of half as much file input accesses). > >=20 > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > >=20 >=20 > -- > Jack Jansen | ++++ stop the execution of Mumia=20 > Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines=20 > to your sig ++++ > www.cwi.nl/~jack | see=20 > http://www.xs4all.nl/~tank/spg-l/sigaction.htm=20 >=20 >=20 From jack@oratrix.nl Sun Dec 2 20:55:10 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 02 Dec 2001 21:55:10 +0100 Subject: AW: [Pythonmac-SIG] copy() in macostools.py In-Reply-To: Message by Jakob Spies , Sun, 2 Dec 2001 20:00:25 +0100 , <75FE1C8FE217E945AFBF635BFB505D3106749F@fallback.spmtechnologies.com> Message-ID: <20011202205515.58172E2677@oratrix.oratrix.nl> Recently, Jakob Spies said: > I did the measurements: You are right, I was wrong. Sorry. I seem to = > have > misinterpreted my experiments of some months ago. Ok. > By the way, I've got a question concerning the PythonInterpreter > implementation: Why is file copying by orders of magnitude faster when = > the > program is run in the IDE rather than the interpreter? (I just made a = > little > test that copied 100 files from local hard disk to local hard disk = > (total 30 > MB, size ranging from 232 KB to 492 KB): 25 s vs. 45 min!) I guess that = > some > calls to ::WaitNextEvent() cannot explain this dramatic difference. Yes, those calls make the difference. But: a factor 100 is *way* over the top. I would expect a factor of 2, maybe less. Which Python version were you using? As of 2.2b2 the whole event code has changed rather significantly. Do you happen to have a test script that I could run to try this for myself? -- 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 Benjamin.Schollnick@usa.xerox.com Mon Dec 3 18:33:51 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Mon, 03 Dec 2001 13:33:51 -0500 Subject: [Pythonmac-SIG] Well....? Tkinter question.... Message-ID: Folks, I admit it, I'm not a very good person with Tkinter... Does anyone feel up to giving me a slight hand, with a Tkinter Dialog? I'm attempting to figure out how to create a "tri-list", with a "use" button... i.e. option1 option a option ! option2 option b option @ option3 option c option # option4 option d option $ >>use<< <> When use is clicked, the values are returned, a small routine is run, and it's returned back to the trilist function... I'm not sure of the easiest, or best way....to create this... I briefly examined PMW a while back on the PC.... But I'm not sure it's suitable for MacPython.... (And I never really did get the hang of PMW)... Anyone have something similiar that I can use as a starting point (well, learning example)....Or suggestions on a straight forward way to create this? - Benjamin From kelvin.chu@uvm.edu Mon Dec 3 22:41:19 2001 From: kelvin.chu@uvm.edu (Kelvin Chu) Date: Mon, 3 Dec 2001 17:41:19 -0500 Subject: [Pythonmac-SIG] Python, MacOSX and Gnuplot. Message-ID: <20011203174119.A75780@zoo.uvm.edu> Hello all. With multiple incarnations of Python (MacPython and python via fink) and Gnuplot (homepage.mac.com/gnuplot) and gnuplot via fink, I have a question: Is it possible to call the Aqua version of Gnuplot (as opposed to the Unix X-windowing fink version) from Python (either MacPython or fink)? How do I do this? Thanks, Kelvin Chu -- kelvin.chu@uvm.edu (802) 656-0064 http://www.uvm.edu/~kchu/ FAX: (802) 656-0817 From trace@reinventnow.com Tue Dec 4 00:41:50 2001 From: trace@reinventnow.com (tracy shaun ruggles) Date: Mon, 03 Dec 2001 18:41:50 -0600 Subject: [Pythonmac-SIG] Silly MacOS X question... Message-ID: Hi, Just installed MacOS X and trying to change file permissions within the folder where Apache CGI files are, *but* my own machine won't let me (that folder is owned by 'root'). How does one change files that are owned by root? This does apply to the list since I'm working on a Python-based project using Webware. :-) Which brings me to my next question, how does one install things like Webware and MySQL on MacOS X so that it is run as root and/or is accessible by all users of the machine? And, one more X-novice question: where/what is the file that specifies where to run applications from the terminal, i.e. "python thisScript.py" execute the script using python. Or, better yet, "./thisScript.py" where the first line would read something like "#!/usr/local/bin/python". I can't access most of the folders in /usr since I'm not 'root'. Any help would be appreciated... Thanks, Tracy From prastawa@cs.unc.edu Tue Dec 4 03:42:25 2001 From: prastawa@cs.unc.edu (Marcelinus Prastawa) Date: Mon, 3 Dec 2001 22:42:25 -0500 Subject: [Pythonmac-SIG] Silly MacOS X question... In-Reply-To: Message-ID: These are all UNIX-related questions. Does this really apply to the list? Maybe, maybe not. Since I am procrastinating anyway, I'll try to answer them... [To other members, sorry if I am breaking a rule or two. I am posting this to the list hoping that this will help others new to the UNIX side of Mac OS X] > How does one change files that are owned by root? You can only do this if you are root or have admin access. Try 'man su' and 'man sudo' on the terminal. > how does one > install things like Webware and MySQL on MacOS X so that it is run as root > and/or is accessible by all users of the machine? Try 'man chmod', look up the part about setting the user and group ID on execution. > And, one more X-novice question: where/what is the file that specifies > where > to run applications from the terminal, i.e. "python thisScript.py" execute > the script using python. It's not really a file. The terminal runs a shell (the command line interface). It looks up binaries based on a variable called $PATH.. 'man tcsh' will give you the gory details... > Or, better yet, "./thisScript.py" where the first line would read > something > like "#!/usr/local/bin/python". I can't access most of the folders in > /usr > since I'm not 'root'. Now this is odd, you should at least have read and execute permissions on files in /usr. Normally you are just not permitted to write on /usr. The best way to get your questions answered would be to get a UNIX tutorial. Try searching "unix tutorial" on google, this should help you get started (there are tons of them). Marcel From dan@biznesshosting.com Tue Dec 4 04:03:24 2001 From: dan@biznesshosting.com (Dan Grassi) Date: Mon, 3 Dec 2001 23:03:24 -0500 Subject: [Pythonmac-SIG] Silly MacOS X question... In-Reply-To: Message-ID: On Monday, December 3, 2001, at 07:41 PM, tracy shaun ruggles wrote: > Hi, > > Just installed MacOS X and trying to change file permissions within the > folder where Apache CGI files are, *but* my own machine won't let me > (that > folder is owned by 'root'). > > How does one change files that are owned by root? Yoy have to provide a password for root, it comes blank. The easiest way to do this is: sudo passwd and answer the prompts. I always use my password. The other way is to copy your password and past it into root's password in NetInfo Manager. Beware, do _not_ do thinks as root unless you have to, and then use sudo unless it is really inconvenient. Doing thinks as root is a big nubie concept and it will cause many problems. > ... how does one > install things like Webware and MySQL on MacOS X so that it is run as > root > and/or is accessible by all users of the machine? Get MySQL from http://www.entropy.ch/software/macosx/mysql/ Follow the installation instructions. Probably a larger problem is getting the binary for the python MySQL driver, I had to compile it from source and there are compile problems under OS 10.1. If you need this let me know and I will post it on the net. I also understand that the compile problem has been resolved in python 2.2b2. As for webware ask Chuck. :-) > And, one more X-novice question: where/what is the file that specifies > where > to run applications from the terminal, i.e. "python thisScript.py" > execute > the script using python. I'm not sure I understand the question but I think the answer is the $PATH environment variable. Just type $PATH in the terminal application to see the search directories. You can modify this interactively of in the .cshrc file in your home directory. > Or, better yet, "./thisScript.py" where the first line would read > something > like "#!/usr/local/bin/python". Again I don't fully understand the question. First, if you are running the command line python it will be in /usr/bin with the rest of python in /usr/lib/python2.1 If your python is in /usr/local/bin you probably have the GUI version and that is probably not the version you want to use with webware. [Jack?] I have a link in /usr/local/python to /usr/bin/python because there are some programs that assume that python is in /usr/local/bin. MySQL does the same thing, placing many links in /usr/local/bin to the real files in /usr/bin. > I can't access most of the folders in /usr since I'm not 'root'. First enter a password for root. In the GUI under the Go menu select Go to Folder and enter the folder name. Note, you can _not_ enter /usr but /usr/local works as do similar /usr directories, other directories do not have this peculiarity, /etc works. Then there is the terminal, if you are going to fiddle with the under laying unix get used to it. Dan From jgitomer@erols.com Tue Dec 4 04:14:56 2001 From: jgitomer@erols.com (Jerry Gitomer) Date: Mon, 3 Dec 2001 23:14:56 -0500 Subject: [Pythonmac-SIG] How do I install Tkinter on 7.5.3 Message-ID: <01120323145600.01182@localhost.localdomain> I have a Performa 6820CD with OS 7.5.3. I have installed Python 1.5.2c1 and now wish to install Tkinter. What do I have to download and where can I find it? Thank you in advance. -- Jerry Gitomer -- jgitomer@erols.com From jack@oratrix.nl Tue Dec 4 10:56:18 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 04 Dec 2001 11:56:18 +0100 Subject: [Pythonmac-SIG] Silly MacOS X question... In-Reply-To: Message by Dan Grassi , Mon, 3 Dec 2001 23:03:24 -0500 , Message-ID: <20011204105618.8177A303183@snelboot.oratrix.nl> > > Just installed MacOS X and trying to change file permissions within the > > folder where Apache CGI files are, *but* my own machine won't let me > > (that > > folder is owned by 'root'). > > > > How does one change files that are owned by root? > > Yoy have to provide a password for root, it comes blank. The easiest > way to do this is: > sudo passwd This is not a good idea for Mac OS X, Apple advices against it. The root account is disabled, the idea being that if you need to do something as root you use sudo (which accepts any administrator password) for that command only, and you never log in as root, or use su. There's also a suido (I think it's called) somewhere out on the net that allows you to run gui programs as root. -- 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 jack@oratrix.nl Tue Dec 4 10:59:17 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 04 Dec 2001 11:59:17 +0100 Subject: [Pythonmac-SIG] How do I install Tkinter on 7.5.3 In-Reply-To: Message by Jerry Gitomer , Mon, 3 Dec 2001 23:14:56 -0500 , <01120323145600.01182@localhost.localdomain> Message-ID: <20011204105918.0B4D2303183@snelboot.oratrix.nl> > I have a Performa 6820CD with OS 7.5.3. > > I have installed Python 1.5.2c1 and now wish to install Tkinter. What do I > have to download and where can I find it? Tkinter is included. But: I vaguely remember that 1.5.2 had some serious problems with Tkinter. You might want to check the archives for pythonmac-sig from late 1999 to mid 2000 looking for messages with "tk" in the subject. Or maybe someone else here has a better memory than me? -- 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 joerg@kantel.de Tue Dec 4 16:09:53 2001 From: joerg@kantel.de (=?iso-8859-1?Q?J=F6rg?= Kantel) Date: Tue, 4 Dec 2001 17:09:53 +0100 Subject: [Pythonmac-SIG] How do I install Tkinter on 7.5.3 In-Reply-To: <20011204105918.0B4D2303183@snelboot.oratrix.nl> Message-ID: <20011204170955-r01010800-b8f205aa-0920-010c@192.168.1.75> On 04.12.2001 at 11:59 Uhr, jack@oratrix.nl (Jack Jansen) wrote: >Tkinter is included. But: I vaguely remember that 1.5.2 had some serious >problems with Tkinter. You might want to check the archives for pythonmac-sig >from late 1999 to mid 2000 looking for messages with "tk" in the subject. > >Or maybe someone else here has a better memory than me? Look at my How To at (German) and (English) There you can find everything about MacPython 1.5.2 and Tkinter. ;o) HTH 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 jorjun@mac.com Wed Dec 5 01:26:08 2001 From: jorjun@mac.com (Pete Moore) Date: Wed, 5 Dec 2001 01:26:08 +0000 Subject: [Pythonmac-SIG] Newbie asks : Current state of play for Python on Mac OS X 10.1? In-Reply-To: Message-ID: <0F0DFD42-E91F-11D5-9699-00039345EC58@mac.com> Fellow lazy leveragers! I have meandered around Sourceforge, maybe all this is in there somewhere, I haven't found it yet. Can someone point me to resources or post a brief summary of for these questions:- 1. Python Cocoa integration a) is it worthwhile? b) how different is this from traditional development? c) would it be a mammoth effort? d) can interface builder be used for Python GUI app's? 2. Native TKinter a) with aqua? b) is it possible to allow full compatibility with existing apps.? 3. Building Python from source with Project Builder a) can it be done? b) should it be done? 4. Integrated development a) IDLE things to know? b) Python IDE things to know? "We were the first that ever burst into that silent sea." -Samuel Taylor Coleridge From just@letterror.com Wed Dec 5 08:21:54 2001 From: just@letterror.com (Just van Rossum) Date: Wed, 5 Dec 2001 09:21:54 +0100 Subject: [Pythonmac-SIG] Newbie asks : Current state of play for Python on Mac OS X 10.1? In-Reply-To: <0F0DFD42-E91F-11D5-9699-00039345EC58@mac.com> Message-ID: <20011205092201-r01010800-281aa92d-0920-010c@10.0.0.23> Pete Moore wrote: > Fellow lazy leveragers! > > I have meandered around Sourceforge, maybe all this is in there > somewhere, I haven't found it yet. > Can someone point me to resources or post a brief summary of for these > questions:- > > 1. Python Cocoa integration > a) is it worthwhile? > b) how different is this from traditional development? > c) would it be a mammoth effort? > d) can interface builder be used for Python GUI app's? > 2. Native TKinter > a) with aqua? > b) is it possible to allow full compatibility with existing apps.? > 3. Building Python from source with Project Builder > a) can it be done? > b) should it be done? > 4. Integrated development > a) IDLE things to know? > b) Python IDE things to know? Cocoa: I for one would like to play with it. Steve Majewski said he'll try to revive pyobjc(.sf.net) so that it'll work with Python 2.2. Over to you Steve... In the meantime I've done two things, neither of which are in CVS yet: - added (some) bundle support to calldll: call mach-o stuff from CFM apps. - started wrapping CoreGraphics (Aqua). This is fantastic stuff. Jason Harper has been doing some good things to the IDE sources: better support for Appearance as well as back-porting to 8.1. The IDE in 2.2b2 is much better under OSX than before, but it's not good enough: the object browser widget is still broken beyond recognition. I will fix that before 2.2 final. Just From gherman@darwin.in-berlin.de Wed Dec 5 09:21:31 2001 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 05 Dec 2001 10:21:31 +0100 (CET) Subject: [Pythonmac-SIG] Python twice on Apple's website Message-ID: <1007544091.3c0de71b6a56c@webmail.in-berlin.de> Hi, I see pointers to Python appearing on Apple's OS X downloads page: http://www.apple.com/downloads/macosx/unix_apps_utilities/ These are the two entries: 1 MacPython 2.1.1. (Jack Jansen, 1.1 MB) MacPython is the port of Guido van Rossum's Python high-level object-oriented language, including an IDE and access to native functionality. MacPython is the port of Guido van Rossum's Python high-level object-oriented language to the Mac. Python is freely distri- butable and available in source form too. Aside from the nu- merous extension modules available on most platforms (include the Tk windowing toolkit, sockets and many others) MacPython has a number of extension modules specifically for Mac OS. MacPython programmers have access to QuickDraw, QuickTime, the Sound manager and various third party toolkits like In- ternet Config and Waste, to name but a few. Also included is an integrated development environment by Just van Rossum, which includes an editor, debugger and class brow- ser all closely integrated. The full distributions below contain examples and some docu- mentation on Mac-specific aspects of using Python. Documenta- tion on the language and the standard library can be obtained at the Python website. 2 Python 2.1 2.1 (Tony Lownds, 5.9 MB) A straight port of the Python programming language. Python 2.1 pre-compiled for Mac OS X. This version features: - readline - expat XML parser - Python Imaging Library 1.1.2 - zlib Being not quite sure if someone helped Apple to enlist them I wonder if it is a good idea at all to have multiple Python entries there and if so, if they could be described in such a way as to make very clear what the difference between them really is? Especially Tcl/Tk is an (absent) issue. Would it be possible to unite the two entries under the same (web) hood (or cross-link them if they aren't already) and offer two (identical) packages for download, one compiled and one not? My feeling is that this would reduce the poten- tial for confusion, at least when looking to this particular Apple page... Dinu -- Dinu C. Gherman ................................................................ "They made a desert and called it peace." (Tacitus) From jack@oratrix.nl Wed Dec 5 10:11:41 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 05 Dec 2001 11:11:41 +0100 Subject: [Pythonmac-SIG] Python twice on Apple's website In-Reply-To: Message by Dinu Gherman , Wed, 05 Dec 2001 10:21:31 +0100 (CET) , <1007544091.3c0de71b6a56c@webmail.in-berlin.de> Message-ID: <20011205101142.EA2C8303183@snelboot.oratrix.nl> > Hi, > > I see pointers to Python appearing on Apple's OS X downloads > page: > > http://www.apple.com/downloads/macosx/unix_apps_utilities/ > > [...] > 1 MacPython 2.1.1. (Jack Jansen, 1.1 MB) > > [...] > > 2 Python 2.1 2.1 (Tony Lownds, 5.9 MB) > MacPython shouldn't be there. It is a wonderful thing, but it's definitely not a Unix Application or Utility. I'm sending Apple a note about this. As to the confusion of two Pythons: I think that'll be with us until at least Python 2.3. I hope that by that time we've integrated MacPython and MachO-Python enough that we can pretend that they're one thing. -- 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 jack@oratrix.nl Wed Dec 5 10:17:41 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 05 Dec 2001 11:17:41 +0100 Subject: [Pythonmac-SIG] Newbie asks : Current state of play for Python on Mac OS X 10.1? In-Reply-To: Message by Pete Moore , Wed, 5 Dec 2001 01:26:08 +0000 , <0F0DFD42-E91F-11D5-9699-00039345EC58@mac.com> Message-ID: <20011205101741.60435303183@snelboot.oratrix.nl> > 1. Python Cocoa integration > a) is it worthwhile? > b) how different is this from traditional development? > c) would it be a mammoth effort? > d) can interface builder be used for Python GUI app's? Steve? Are you still with us? Status, please? > 2. Native TKinter > a) with aqua? > b) is it possible to allow full compatibility with existing apps.? Tony? Are you still with us? Status, please? > 3. Building Python from source with Project Builder > a) can it be done? Probably. > b) should it be done? Probably not. The Makefiles are fine, and the whole autoconfig process and such runs really well and is not easily adapted to Project Builder. What might be an option is to build Python.app (which is currently a difficult manual build in mac/OSX) with Project Builder. But again I'm not sure that there would be a lot of benefits. > 4. Integrated development > a) IDLE things to know? > b) Python IDE things to know? Just answered these already. > "We were the first that ever burst into that silent sea." > -Samuel Taylor Coleridge "O land van mest en mist, van vuile koude regen, doorsijpeld stukje grond, vol kille kou en damp" - de Genestet -- 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 gherman@darwin.in-berlin.de Wed Dec 5 11:47:32 2001 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 05 Dec 2001 12:47:32 +0100 Subject: [Pythonmac-SIG] Python twice on Apple's website References: <20011205101142.EA2C8303183@snelboot.oratrix.nl> Message-ID: <3C0E0954.26F4751D@darwin.in-berlin.de> Jack Jansen wrote: > > MacPython shouldn't be there. It is a wonderful thing, but it's definitely not > a Unix Application or Utility. I'm sending Apple a note about this. > > As to the confusion of two Pythons: I think that'll be with us until at least > Python 2.3. I hope that by that time we've integrated MacPython and > MachO-Python enough that we can pretend that they're one thing. Ok, so maybe we could feed them at least with little notes whenever the final next release is out, like 2.2, 2.3 etc. and have the binaries somewhere? I think many people are watching these pages on a regular basis. Thanks, Dinu From jack@oratrix.nl Wed Dec 5 11:58:41 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 05 Dec 2001 12:58:41 +0100 Subject: [Pythonmac-SIG] Python twice on Apple's website In-Reply-To: Message by Dinu Gherman , Wed, 05 Dec 2001 12:47:32 +0100 , <3C0E0954.26F4751D@darwin.in-berlin.de> Message-ID: <20011205115842.F2497303183@snelboot.oratrix.nl> > Ok, so maybe we could feed them at least with little notes > whenever the final next release is out, like 2.2, 2.3 etc. > and have the binaries somewhere? I think many people are > watching these pages on a regular basis. Yes, that's what I plan to do. But: I don't know where they got the information. I do enter MacPython into the guide.apple.com database, but I think that this listing comes from elsewhere. For one thing they refer to the active installer, whereas I always refer to the full installer (except on the MacPython webpage). I've asked them how I should update the listing. -- 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 tony@metanet.com Wed Dec 5 16:40:27 2001 From: tony@metanet.com (Tony Lownds) Date: Wed, 5 Dec 2001 08:40:27 -0800 Subject: [Pythonmac-SIG] Newbie asks : Current state of play for Python on Mac OS X 10.1? In-Reply-To: <20011205101741.60435303183@snelboot.oratrix.nl> References: <20011205101741.60435303183@snelboot.oratrix.nl> Message-ID: > > 2. Native TKinter >> a) with aqua? >> b) is it possible to allow full compatibility with existing apps.? > >Tony? Are you still with us? Status, please? I am completely stuck on this. Does anyone with experience debugging Mac apps want to take over/help? Unix experience isn't helping me on this one. > > 3. Building Python from source with Project Builder >> a) can it be done? > >Probably. > >> b) should it be done? > >Probably not. The Makefiles are fine, and the whole autoconfig process and >such runs really well and is not easily adapted to Project Builder. What might >be an option is to build Python.app (which is currently a difficult manual >build in mac/OSX) with Project Builder. But again I'm not sure that there >would be a lot of benefits. Tcl on OSX builds with project builder; Jim Ingham made targets for "configure", "make", etc. that simply call those scripts. Tk on OSX also builds with Project Builder but without using the traditional UNIX build machinery underneath. Sticking to the traditional UNIX build scripts gives people more freedom and makes it easier to adjust to changes from the other platforms Python runs on. -Tony -- From tony@metanet.com Wed Dec 5 16:50:14 2001 From: tony@metanet.com (Tony Lownds) Date: Wed, 5 Dec 2001 08:50:14 -0800 Subject: [Pythonmac-SIG] Python twice on Apple's website In-Reply-To: <20011205115842.F2497303183@snelboot.oratrix.nl> References: <20011205115842.F2497303183@snelboot.oratrix.nl> Message-ID: For Mach-O Python 2.2: 1. Can it go on www.python.org? 2. Should it be built with a framework? 3. Should it include Python.app? Python.app requires toolbox glue; that has been reported to make command-line python fail when no GUI is available. I tried this last weekend and didn't have any problems. 4. With Dinu's package-maker script, the entire process could be scripted. Could such a script go into Mac/OSX? -Tony At 12:58 PM +0100 12/5/01, Jack Jansen wrote: > > Ok, so maybe we could feed them at least with little notes >> whenever the final next release is out, like 2.2, 2.3 etc. >> and have the binaries somewhere? I think many people are >> watching these pages on a regular basis. > >Yes, that's what I plan to do. But: I don't know where they got the >information. I do enter MacPython into the guide.apple.com database, but I >think that this listing comes from elsewhere. For one thing they refer to the >active installer, whereas I always refer to the full installer (except on the >MacPython webpage). I've asked them how I should update the listing. >-- >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 > > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- From gherman@darwin.in-berlin.de Wed Dec 5 18:05:53 2001 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 05 Dec 2001 19:05:53 +0100 (CET) Subject: [Pythonmac-SIG] Python twice on Apple's website In-Reply-To: References: <20011205115842.F2497303183@snelboot.oratrix.nl> Message-ID: <1007575553.3c0e62010b9cf@webmail.in-berlin.de> Tony Lownds : > 4. With Dinu's package-maker script, the entire process could be > scripted. > Could such a script go into Mac/OSX? I've had no time to make significant progress on that one, but I've put it in some more visible space now: http://starship.python.net/crew/gherman/#buildpkg Regards, Dinu From dan@grassi.org Wed Dec 5 18:34:50 2001 From: dan@grassi.org (Dan Grassi) Date: Wed, 5 Dec 2001 13:34:50 -0500 Subject: [Pythonmac-SIG] Python twice on Apple's website In-Reply-To: <1007575553.3c0e62010b9cf@webmail.in-berlin.de> Message-ID: I might be able to help here, I just did the packaging on a commercial project. What is the time frame that it is needed. Dan On Wednesday, December 5, 2001, at 01:05 PM, Dinu Gherman wrote: > Tony Lownds : > >> 4. With Dinu's package-maker script, the entire process could be >> scripted. >> Could such a script go into Mac/OSX? > > I've had no time to make significant progress on that one, > but I've put it in some more visible space now: > > http://starship.python.net/crew/gherman/#buildpkg > > Regards, > > Dinu > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From tony@metanet.com Wed Dec 5 19:02:55 2001 From: tony@metanet.com (Tony Lownds) Date: Wed, 5 Dec 2001 11:02:55 -0800 Subject: [Pythonmac-SIG] Python twice on Apple's website In-Reply-To: References: Message-ID: At 1:34 PM -0500 12/5/01, Dan Grassi wrote: >I might be able to help here, I just did the packaging on a >commercial project. What is the time frame that it is needed. Python 2.2. is scheduled* to go out on Dec 19th. Did you use .pkg files for the commercial project? -Tony * http://python.sourceforge.net/peps/pep-0251.html >Dan > > >On Wednesday, December 5, 2001, at 01:05 PM, Dinu Gherman wrote: > >>Tony Lownds : >> >>>4. With Dinu's package-maker script, the entire process could be >>>scripted. >>> Could such a script go into Mac/OSX? >> >>I've had no time to make significant progress on that one, >>but I've put it in some more visible space now: >> >> http://starship.python.net/crew/gherman/#buildpkg >> >>Regards, >> >>Dinu >> >>_______________________________________________ >>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 sdm7g@Virginia.EDU Wed Dec 5 20:02:13 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Wed, 5 Dec 2001 15:02:13 -0500 (EST) Subject: [Pythonmac-SIG] Re: several messages In-Reply-To: <20011205101741.60435303183@snelboot.oratrix.nl> Message-ID: On Wed, 5 Dec 2001, Just van Rossum wrote: > Pete Moore wrote: > > > 1. Python Cocoa integration > > a) is it worthwhile? > > b) how different is this from traditional development? > > c) would it be a mammoth effort? > > d) can interface builder be used for Python GUI app's? > > Cocoa: > I for one would like to play with it. Steve Majewski said he'll try to > revive pyobjc(.sf.net) so that it'll work with Python 2.2. Over to you Steve... > On Wed, 5 Dec 2001, Jack Jansen wrote: > > Steve? Are you still with us? Status, please? > Hi Guys! I've been inactive for a while, due both to a long Thanksgiving break down at the Outer Banks and problems getting upgraded to 10.1 : first a long wait for the CD from Apple, and then finding I couldn't install because my internal CD-ROM has been dead and the external USB drive I bought couldn't boot from CD. ( Luckily, after a fruitless search for advice, I found clicking directly on the .mpkg will work as long as you've got two partitions and a working OSX on one of them. ) I just finally got it installed over the weekend. pyobjc (the current version on SourceForge) *was* working for me under Python 2.1x and OSX 10.0.* . It would not build or work with Python 2.2x. It was possible to create limited GUI app using Cocoa classes from pyobjc, but what you could do was limited due to: [1] the old type/class split: cocoa objects were python objects but not python *classes*, so you could not inherit from and extend them with new python classes. [2] the one major unsolved bug in pyobjc was that it couldn't handle delegate objects correctly, which was the other obvious way around problem #1 above. I did manage to build a HelloWorld.py that put up a window, text, and a button, which quit on clicking the button, but it required an unnatural (to Cocoa) procedural style of code. The plan is to redesign and reimplement pyobjc using the new type/class system in Python 2.2. ( Unfortunately, I'm not very far along in implementing this plan. No -- it shouldn't be a mamoth effort -- I've just been having trouble squeezing it in between everything else.) This should allow programming Cocoa from Python in an O-O style the same as it's done from objc -- subclassing and extending NS* widgets. I did some experiments with reanimating Project Builder Nibs built for another program. This should also be possible. Full supporrt for Python in Project Builder would need to wait on Apple opening and documenting more of the PB API's (which is something they have a stated intention to do) But even without that full support, you should still be able to use PB as a GUI designer -- you just won't be able to "wire" the behaviours in from PB. If anyone else wants to help out in any capacity: design, coding, testing, documentation, etc. -- either send me a note, or join up on the sourceforge project There is a mailing list for the project (which has been completely dead lately while things have been idle) but any news will go out on that list as well as the pythonmac-sig list. -- Steve From sdm7g@Virginia.EDU Wed Dec 5 20:11:06 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Wed, 5 Dec 2001 15:11:06 -0500 (EST) Subject: [Pythonmac-SIG] Newbie asks : Current state of play for Python on Mac OS X 10.1? In-Reply-To: Message-ID: On Wed, 5 Dec 2001, Tony Lownds wrote: > >Tony? Are you still with us? Status, please? > > I am completely stuck on this. Does anyone with experience debugging > Mac apps want to take over/help? Unix experience isn't helping me on > this one. FYI: One of the recent technotes: TN2030: GDB for MacsBug Veterans has come in handy for me. I always knew just enough GDB to get by debugging unix command line programs -- debugging a GUI app for OSX seems to require a few more tricks. -- Steve From sdm7g@Virginia.EDU Wed Dec 5 20:40:45 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Wed, 5 Dec 2001 15:40:45 -0500 (EST) Subject: [Pythonmac-SIG] OSX IDE (Newbie asks : Current state of play for Python on Mac OS X 10.1?) In-Reply-To: <20011205101741.60435303183@snelboot.oratrix.nl> Message-ID: > > 4. Integrated development > > a) IDLE things to know? > > b) Python IDE things to know? With the unix plumbing in OSX, it may now be possible to separate the python in the IDE from the python being developed in the IDE by spawning a separate process to the code run from the IDE. But is there a downside to this? i.e. does the IDE require much introspection that would get broken by seperating the user code from the IDE code? (I've been writing some AppleEvents code lately that uses a DoScript event to XlispStat, so I've been thinking of this as a way of linking two Python images.) -- Steve From sdm7g@Virginia.EDU Wed Dec 5 20:53:40 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Wed, 5 Dec 2001 15:53:40 -0500 (EST) Subject: [Pythonmac-SIG] Rez and resources on OSX (vs. bundle/package) Message-ID: I was recently trying out some sample code -- looking at how the new Carbon Event model works -- and I tried building the same code from both Project Builder and the command line tools. Instead of building a package, I added the resources to the executable using command-line Rez tool. This allowed me to run it from the Terminal.app command line, instead of double clicking or using "open -a some.app" , and still have it come up a GUI app. I wonder if this might work with mach-o (mac) Python ? BTW: What's the current status of bundling mach-o Python ? Can EasyDialogs.test() run successfully from bundled Python.app yet ? ( As I noted in an earlier message: I've been without a functional development machine for a while, which is why I'm asking instead of just trying it out myself! ) -- Steve From jack@oratrix.nl Wed Dec 5 21:56:38 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 05 Dec 2001 22:56:38 +0100 Subject: [Pythonmac-SIG] Rez and resources on OSX (vs. bundle/package) In-Reply-To: Message by Steven Majewski , Wed, 5 Dec 2001 15:53:40 -0500 (EST) , Message-ID: <20011205215643.AA2BB11CA23@oratrix.oratrix.nl> Recently, Steven Majewski said: > Instead of building a package, I added the resources to the executable > using command-line Rez tool. > > This allowed me to run it from the Terminal.app command line, instead > of double clicking or using "open -a some.app" , and still have it > come up a GUI app. Hmm, interesting... But this has the disadvantage that you have a dual-fork file again. I'm not sure whether the advantages outway the drawbacks, but it might be worth investigating. > BTW: What's the current status of bundling mach-o Python ? > Can EasyDialogs.test() run successfully from bundled Python.app yet ? Yes, they should, after a bit of massaging (like getting dialogs.rsrc in your resource chain). Instructions are in Mac/OSX. -- 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 jack@oratrix.nl Wed Dec 5 22:25:32 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 05 Dec 2001 23:25:32 +0100 Subject: [Pythonmac-SIG] Python twice on Apple's website In-Reply-To: Message by Tony Lownds , Wed, 5 Dec 2001 08:50:14 -0800 , Message-ID: <20011205222537.DD40B11CA23@oratrix.oratrix.nl> Recently, Tony Lownds said: > For Mach-O Python 2.2: > > 1. Can it go on www.python.org? Yes, definitely. There's currently a link to the "fink" project, but they use a specialised Debian package to do the installs, I think. Something that is OSX-native would be preferred. > 2. Should it be built with a framework? > 3. Should it include Python.app? These go together: without 2 there's no 3, and if we do 2 we might as well include 3. But I'm unsure as to what the correct answer to this one is. I consider the framework-based installer still to be experimental, For one thing, it doesn't install a working /usr/local/bin/python. For another, it's still too easy to crash on OSX Server (by importing a Carbon module, for instance). I would suggest that there be at least a "normal" command line Python installer. Possibly there is an additional one, labelled "experimental", that is framework based. > Python.app requires toolbox glue; that has been reported to make > command-line python fail when no GUI is available. I tried this last > weekend and didn't have any problems. Yes, this should all be fixed now, except for the import problem above. If I find time to get away from mail:-) I'll try and do something about that tonight. > 4. With Dinu's package-maker script, the entire process could be scripted. > Could such a script go into Mac/OSX? This is probably something for 2.3, or at least for after the 2.2 final is done. One of the reasons is that I really want to get rid of Mac/OSX, it's mainly a stopgap until we get the whole Python.app stufff included in the normal build process. Of course there's a very good chance that the actual directory Mac/OSX remains to have a function, but I don't want to overload it just yet. Hmm, and Dinu's script itself still doesn't have a place to live yet. -- 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 pfroehli@ics.uci.edu Wed Dec 5 22:37:16 2001 From: pfroehli@ics.uci.edu (Peter H. Froehlich) Date: Wed, 5 Dec 2001 14:37:16 -0800 Subject: [Pythonmac-SIG] Python twice on Apple's website In-Reply-To: <20011205222537.DD40B11CA23@oratrix.oratrix.nl> Message-ID: Hi! On Wednesday, December 5, 2001, at 02:25 PM, Jack Jansen wrote: > Recently, Tony Lownds said: >> 1. Can it go on www.python.org? > > Yes, definitely. There's currently a link to the "fink" project, but > they use a specialised Debian package to do the installs, I > think. Something that is OSX-native would be preferred. Sorry, gotta put in my $0.02. The fink/debian package system is actually pretty smart, and having this version available helps when the rest of your developers use various Unix Pythons. I asked Tony about this a couple of hours ago, and he mentioned that the whole debian stuff could be very well utilized for more version control when installing "extra Python packages" if I understood him correctly. To sum up: Add whatever links, but please don't remove the fink link from python.org. -- Peter H. Froehlich @ http://www.ics.uci.edu/~pfroehli/ From jack@oratrix.nl Wed Dec 5 22:41:22 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 05 Dec 2001 23:41:22 +0100 Subject: [Pythonmac-SIG] Python twice on Apple's website In-Reply-To: Message by "Peter H. Froehlich" , Wed, 5 Dec 2001 14:37:16 -0800 , Message-ID: <20011205224127.1F84711CA23@oratrix.oratrix.nl> Recently, "Peter H. Froehlich" said: > Sorry, gotta put in my $0.02. The fink/debian package system is > actually pretty smart, and having this version available helps when > the rest of your developers use various Unix Pythons. I asked Tony > about this a couple of hours ago, and he mentioned that the whole > debian stuff could be very well utilized for more version control > when installing "extra Python packages" if I understood him > correctly. To sum up: Add whatever links, but please don't remove > the fink link from python.org. Ok, great! Who is this fink targeted at, mainly at Mac users transitioning, or at unix users transitioning? I had never heard of it, but I get the vague impression that that's because I'm probably the last unix user on the world who has used unix for an average of, oh, four hours per day for the last 25 years and still never had any real experience with Linux:-) -- 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 pfroehli@ics.uci.edu Wed Dec 5 23:18:37 2001 From: pfroehli@ics.uci.edu (Peter H. Froehlich) Date: Wed, 5 Dec 2001 15:18:37 -0800 Subject: Fink (was: Re: [Pythonmac-SIG] Python twice on Apple's website) In-Reply-To: <20011205224127.1F84711CA23@oratrix.oratrix.nl> Message-ID: <694AC0AC-E9D6-11D5-B1D5-003065F6D8BE@ics.uci.edu> Hi! On Wednesday, December 5, 2001, at 02:41 PM, Jack Jansen wrote: > Who is this fink targeted at, mainly at Mac users transitioning, or at > unix users transitioning? I had never heard of it, but I get the vague > impression that that's because I'm probably the last unix user on the > world who has used unix for an average of, oh, four hours per day for > the last 25 years and still never had any real experience with Linux:-) I'd guess that is is mainly for Unix users who like the idea of having an "as Unixish as possible" experience in the Terminal.app of OS X. Fink is reusing the "famous" debian package system (which has a pretty good reputation) to bring a variety of Unix/GNU applications and tools to OS X. Another good thing is that fink does not install things into system paths such as "/usr/local/bin". Instead it uses it's own toplevel path "/sw". That keeps things nicely separated. I hope that this project stays alive, but of course you never know. What might be interesting to people here is that they also provide X for OS X that integrates with their Python AFAIK. So any X-based GUIs should actually work (haven't tested that though, no big need for graphics when you hack compilers). -- Peter H. Froehlich @ http://www.ics.uci.edu/~pfroehli/ From bobsavage@mac.com Thu Dec 6 04:02:56 2001 From: bobsavage@mac.com (Bob Savage) Date: Wed, 05 Dec 2001 22:02:56 -0600 Subject: Fink (was: Re: [Pythonmac-SIG] Python twice on Apple's website) In-Reply-To: <694AC0AC-E9D6-11D5-B1D5-003065F6D8BE@ics.uci.edu> Message-ID: on 12/5/01 5:18 PM, Peter H. Froehlich wrote: > I hope that this project stays alive, but of course you never know. > What might be interesting to people here is that they also provide > X for OS X that integrates with their Python AFAIK. So any X-based > GUIs should actually work (haven't tested that though, no big need > for graphics when you hack compilers). I haven't experimented with fink, but I got the Grass CD, which also installs X, and tried launching the GUI version of Grass (which is TK-based) and it worked surprisingly well. I haven't had time to play with it very much (mostly just curious, no good reason to be looking at it), so I can't really comment further. Bob From tony@metanet.com Thu Dec 6 06:35:05 2001 From: tony@metanet.com (Tony Lownds) Date: Wed, 5 Dec 2001 22:35:05 -0800 Subject: [Pythonmac-SIG] Newbie asks : Current state of play for Python on Mac OS X 10.1? In-Reply-To: References: Message-ID: That technote was really really useful!! After some much-more-productive-than-before debugging, I have a working Tkinter/Aqua. Well, at least the hello.py demo works. The patch and Setup.local file are below. -Tony Index: _tkinter.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v retrieving revision 1.120 diff -u -r1.120 _tkinter.c --- _tkinter.c 2001/11/28 20:27:42 1.120 +++ _tkinter.c 2001/12/06 06:17:36 @@ -41,8 +41,13 @@ #define MAC_TCL #endif +#ifdef TK_FRAMEWORK +#include +#include +#else #include #include +#endif #define TKMAJORMINOR (TK_MAJOR_VERSION*1000 + TK_MINOR_VERSION) @@ -454,6 +459,7 @@ ClearMenuBar(); TkMacInitMenus(v->interp); #endif + /* Delete the 'exit' command, which can screw things up */ Tcl_DeleteCommand(v->interp, "exit"); @@ -1579,8 +1585,8 @@ TkttObject *v = (TkttObject *)self; char buf[100]; - PyOS_snprintf(buf, sizeof(buf), "", v, - v->func == NULL ? ", handler deleted" : ""); + sprintf(buf, "", v, + v->func == NULL ? ", handler deleted" : ""); return PyString_FromString(buf); } @@ -2136,6 +2142,22 @@ Tktt_Type.ob_type = &PyType_Type; PyDict_SetItemString(d, "TkttType", (PyObject *)&Tktt_Type); + + +#ifdef TK_AQUA + /* Tk_MacOSXSetupTkNotifier must be called before Tcl's subsystems + * start waking up. Note that Tcl_FindExecutable will do this, this + * code must be above it! The original warning from + * tkMacOSXAppInit.c is copied below. + * + * NB - You have to swap in the Tk Notifier BEFORE you start up the + * Tcl interpreter for now. It probably should work to do this + * in the other order, but for now it doesn't seem to. + * + */ + Tk_MacOSXSetupTkNotifier(); +#endif + /* This helps the dynamic loader; in Unicode aware Tcl versions it also helps Tcl find its encodings. */ Index: tkappinit.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/tkappinit.c,v retrieving revision 1.9 diff -u -r1.9 tkappinit.c --- tkappinit.c 2000/08/04 15:53:06 1.9 +++ tkappinit.c 2001/12/06 06:17:36 @@ -15,17 +15,68 @@ #include #include +#define MAX_PATH_LEN 1000 + int Tcl_AppInit(Tcl_Interp *interp) { Tk_Window main_window; +#ifdef TK_AQUA + char tclLibPath[MAX_PATH_LEN], tkLibPath[MAX_PATH_LEN]; + Tcl_Obj* pathPtr; + + /* pre- Tcl_Init code copied from tkMacOSXAppInit.c */ + Tk_MacOSXOpenBundleResources (interp, "com.tcltk.tcllibrary", + tclLibPath, MAX_PATH_LEN, 0); + + + if (tclLibPath[0] != '\0') { + Tcl_SetVar(interp, "tcl_library", tclLibPath, TCL_GLOBAL_ONLY); + Tcl_SetVar(interp, "tclDefaultLibrary", tclLibPath, TCL_GLOBAL_ONLY); + Tcl_SetVar(interp, "tcl_pkgPath", tclLibPath, TCL_GLOBAL_ONLY); + } + + if (tclLibPath[0] != '\0') { + Tcl_SetVar(interp, "tcl_library", tclLibPath, TCL_GLOBAL_ONLY); + Tcl_SetVar(interp, "tclDefaultLibrary", tclLibPath, TCL_GLOBAL_ONLY); + Tcl_SetVar(interp, "tcl_pkgPath", tclLibPath, TCL_GLOBAL_ONLY); + } +#endif if (Tcl_Init (interp) == TCL_ERROR) return TCL_ERROR; - if (Tk_Init (interp) == TCL_ERROR) - return TCL_ERROR; +#ifdef TK_AQUA + /* pre- Tk_Init code copied from tkMacOSXAppInit.c */ + Tk_MacOSXOpenBundleResources (interp, "com.tcltk.tklibrary", + tkLibPath, MAX_PATH_LEN, 1); + + if (tclLibPath[0] != '\0') { + pathPtr = Tcl_NewStringObj(tclLibPath, -1); + } else { + Tcl_Obj *pathPtr = TclGetLibraryPath(); + } + + if (tkLibPath[0] != '\0') { + Tcl_Obj *objPtr; + + Tcl_SetVar(interp, "tk_library", tkLibPath, TCL_GLOBAL_ONLY); + objPtr = Tcl_NewStringObj(tkLibPath, -1); + Tcl_ListObjAppendElement(NULL, pathPtr, objPtr); + } + + TclSetLibraryPath(pathPtr); +#endif + + if (Tk_Init (interp) == TCL_ERROR) + return TCL_ERROR; + main_window = Tk_MainWindow(interp); + +#ifdef TK_AQUA + TkMacOSXInitAppleEvents(interp); + TkMacOSXInitMenus(interp); +#endif #ifdef WITH_MOREBUTTONS { --------------------- Setup.local --------------------- # Edit this file for local setup changes *shared* _tkinter _tkinter.c tkappinit.c -DWITH_APPINIT -DTK_AQUA \ -I/Library/Frameworks/Tcl.framework/Headers/ \ -I/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders/ \ -I/Library/Frameworks/Tk.framework/Headers/ \ -I/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders/ \ -I/usr/X11R6/include/ \ -framework Tcl -framework Tk At 3:11 PM -0500 12/5/01, Steven Majewski wrote: >On Wed, 5 Dec 2001, Tony Lownds wrote: > >> >Tony? Are you still with us? Status, please? >> >> I am completely stuck on this. Does anyone with experience debugging >> Mac apps want to take over/help? Unix experience isn't helping me on >> this one. > >FYI: One of the recent technotes: > TN2030: GDB for MacsBug Veterans > >has come in handy for me. I always knew just enough GDB to >get by debugging unix command line programs -- debugging a >GUI app for OSX seems to require a few more tricks. > >-- Steve > > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- From jack@oratrix.nl Thu Dec 6 13:49:25 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 06 Dec 2001 14:49:25 +0100 Subject: [Pythonmac-SIG] Newbie asks : Current state of play for Python on Mac OS X 10.1? In-Reply-To: Message by Tony Lownds , Wed, 5 Dec 2001 22:35:05 -0800 , Message-ID: <20011206134930.97CBFD52D8@oratrix.oratrix.nl> Recently, Tony Lownds said: > That technote was really really useful!! After some > much-more-productive-than-before debugging, I have a working > Tkinter/Aqua. Well, at least the hello.py demo works. The patch and > Setup.local file are below. Tony: brilliant, brilliant! Now the question: can we still incorporate this in 2.2? And should we, i.e. would it still allow people to build with the "normal" X/Tkinter too, if they so choose? -- 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 jack@oratrix.nl Thu Dec 6 14:53:50 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 06 Dec 2001 15:53:50 +0100 Subject: [Pythonmac-SIG] Newbie asks : Current state of play for Python on Mac OS X 10.1? In-Reply-To: Message by Tony Lownds , Wed, 5 Dec 2001 22:35:05 -0800 , Message-ID: <20011206145355.08F4511CA22@oratrix.oratrix.nl> Tony, after applying your diffs (manually, grmpf! I hate unified diffs, they always seem to fail for me:-( ) I can't compile Tkinter. It complains about not being able to find X11/Xlib.h, included from tk.h. And, indeed, I don't seem to have that on my system. I downloaded the snapshot binary release of Aqua-tk, should I have downloaded something else? -- 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 tony@metanet.com Thu Dec 6 18:05:44 2001 From: tony@metanet.com (Tony Lownds) Date: Thu, 6 Dec 2001 10:05:44 -0800 Subject: [Pythonmac-SIG] Newbie asks : Current state of play for Python on Mac OS X 10.1? In-Reply-To: <20011206134930.97CBFD52D8@oratrix.oratrix.nl> References: <20011206134930.97CBFD52D8@oratrix.oratrix.nl> Message-ID: >Now the question: can we still incorporate this in 2.2? And should we, >i.e. would it still allow people to build with the "normal" X/Tkinter >too, if they so choose? All the changes are protected by a TK_AQUA define, it does not key off of the platform for just that reason. However I'm not set up to test the "normal" X/Tkinter. Let me work up the patch a bit more and post it to SourceForge. I don't think this should go into 2.2 because 1. Time is tight 2. Tkinter/Aqua is alpha, -Tony -- From ryanwilcox@mac.com Thu Dec 6 23:54:37 2001 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Thu, 6 Dec 2001 18:54:37 -0500 Subject: [Pythonmac-SIG] Getting the selection in the IDE? In-Reply-To: <20010806151819.89BF8303181@snelboot.oratrix.nl> Message-ID: <20011206185439-r01010800-fcc2a092-0922-010c@129.21.190.170> I want to write a script (that I put in the Scripts Menu of the IDE) that acts on the selection in the IDE. Can anybody point me in the right direction? I didn't see any documentation that would help... Thanks a bunch!, -Ryan Wilcox PGP key available on keyserver.pgg.com PGP fingerprint: 2B1D 8B69 318C F876 A6ED FE0B 6D83 B4A8 2F4E 9C31 From TattooMabonzoK. Fri Dec 7 08:54:03 2001 From: TattooMabonzoK. (TattooMabonzoK.) Date: Fri, 7 Dec 2001 09:54:03 +0100 Subject: [Pythonmac-SIG] Newbie asks : Current state of play for Python on Mac OS X 10.1? In-Reply-To: <20011205092201-r01010800-281aa92d-0920-010c@10.0.0.23> Message-ID: On Wednesday, December 5, 2001, at 09:21 AM, Just van Rossum wrote: > Pete Moore wrote: > >> Fellow lazy leveragers! >> >> I have meandered around Sourceforge, maybe all this is in there >> somewhere, I haven't found it yet. >> Can someone point me to resources or post a brief summary of for >> these >> questions:- >> >> [snip] > Cocoa: > I for one would like to play with it. Steve Majewski said he'll try to Same here. I've started to learn Cocoa and programming it with Objective-C and I LOVE it. I've also played a little with F-Script after reading the article on oreilly which and the integration of that scripting language with cocoa is nothing short of amazing. And now I've just received AppleScript Studio, which totally rocks. I can't wqit to be able to program Cocoa apps using Python, the two would make for the coolest development enviroment. > revive pyobjc(.sf.net) so that it'll work with Python 2.2. Over to > you Steve... > > In the meantime I've done two things, neither of which are in CVS yet: > - added (some) bundle support to calldll: call mach-o stuff from CFM > apps. > - started wrapping CoreGraphics (Aqua). This is fantastic stuff. Just, now that you've kickstarted this, if you need any kind of help I'd be very glad to oblige. I've running Mac OS X only since September last year, now which means that unfortunately, I can only help with Python in that environment. > Jason Harper has been doing some good things to the IDE sources: better > support for Appearance as well as back-porting to 8.1. The IDE in 2.2b2 > is much better under OSX than before, but it's not good enough: > the object > browser widget is still broken beyond recognition. I will fix that > before > 2.2 final. Same goes here. I've switched to using Mach-O-Python (the Unix-based one) due to the fact that for me the IDE on Mac OS X is FUBAR. But again if I can help with bringing the IDE to MOSX, please count me in. = tmk = > > Just > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From TattooMabonzoK. Fri Dec 7 08:58:35 2001 From: TattooMabonzoK. (TattooMabonzoK.) Date: Fri, 7 Dec 2001 09:58:35 +0100 Subject: [Pythonmac-SIG] Silly MacOS X question... In-Reply-To: <20011204105618.8177A303183@snelboot.oratrix.nl> Message-ID: <992796DA-EAF0-11D5-9249-003065C18BA0@easynet.be> Yo, You may want to check Pseudo which allows you to run GUI app as Root from you normal (non-root) user account. HTH = tmk = On Tuesday, December 4, 2001, at 11:56 AM, Jack Jansen wrote: >>> Just installed MacOS X and trying to change file permissions >>> within the >>> folder where Apache CGI files are, *but* my own machine won't let me >>> (that >>> folder is owned by 'root'). >>> >>> How does one change files that are owned by root? >> >> Yoy have to provide a password for root, it comes blank. The easiest >> way to do this is: >> sudo passwd > > This is not a good idea for Mac OS X, Apple advices against it. > The root > account is disabled, the idea being that if you need to do > something as root > you use sudo (which accepts any administrator password) for that > command only, > and you never log in as root, or use su. > > There's also a suido (I think it's called) somewhere out on the > net that > allows you to run gui programs as root. > -- > 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 > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Benjamin.Schollnick@usa.xerox.com Fri Dec 7 16:00:47 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 07 Dec 2001 11:00:47 -0500 Subject: [Pythonmac-SIG] Silly question? Database server (Mac OS 9 / Mac OS x / PC-Win) Message-ID: Guys, I'm running into a situation where I'd like to interface with a database (preferably SQL based).... But since I'm planning this to be multiplatform, I'm not sure what's available for both Mac OS (9 & X) & the wintel platforms... MySQL doesn't seem to have a Mac version, that I could find? Does anyone know of a Macintosh database that is Python accessible, preferably with a SQL style interface? (i.e. I pass a SQL statement to the database engine) If necessary, I'll make a translation layer, for the PC version... But I really haven't looked into any of Mac Database packages (except Filemaker Pro v4)... Preferably this should be free, since however runs this would need it... - Benjamin From jakob.spies@spmtechnologies.com Fri Dec 7 16:58:28 2001 From: jakob.spies@spmtechnologies.com (Jakob Spies) Date: Fri, 7 Dec 2001 17:58:28 +0100 Subject: [Pythonmac-SIG] Silly question? Database server (Mac OS 9 / Mac OS x / PC-Win) Message-ID: <75FE1C8FE217E945AFBF635BFB505D310674DF@fallback.spmtechnologies.com> It is possible to run MySQL on Mac OS X. I tried it. If I remember correctly, the source distribution for Unix could be built right out of = the box. I switched to Lutris InstantDB however, because this RDBMS was = more convenient for my pure Java (not Python) application. Jakob ++++ stop the execution of Mumia Abu-Jamal ++++ > -----Urspr=FCngliche Nachricht----- > Von: Schollnick, Benjamin [mailto:Benjamin.Schollnick@usa.xerox.com] > Gesendet: Freitag, 7. Dezember 2001 17:01 > An: pythonmac-sig@python.org > Betreff: [Pythonmac-SIG] Silly question? Database server (Mac=20 > OS 9 / Mac > OS x / PC-Win) >=20 >=20 > Guys, >=20 > I'm running into a situation where I'd like to interface with=20 > a database > (preferably SQL based).... But since I'm planning this to be=20 > multiplatform, > I'm not sure what's available for both Mac OS (9 & X) & the wintel > platforms... >=20 > MySQL doesn't seem to have a Mac version, that I could find? >=20 > Does anyone know of a Macintosh database that is Python accessible, > preferably > with a SQL style interface? (i.e. I pass a SQL statement to=20 > the database > engine) >=20 > If necessary, I'll make a translation layer, for the PC=20 > version... But I > really > haven't looked into any of Mac Database packages (except Filemaker = Pro > v4)... > Preferably this should be free, since however runs this would=20 > need it... >=20 > - Benjamin >=20 > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig >=20 From richard@richardgordon.net Fri Dec 7 17:16:19 2001 From: richard@richardgordon.net (Richard Gordon) Date: Fri, 7 Dec 2001 12:16:19 -0500 Subject: [Pythonmac-SIG] Silly question? Database server (Mac OS 9 / Mac OS x / PC-Win) In-Reply-To: References: Message-ID: At 11:00 AM -0500 12/7/01, Schollnick, Benjamin wrote: >MySQL doesn't seem to have a Mac version, that I could find? Not unless something has been made available for OS X. >Does anyone know of a Macintosh database that is Python accessible, >preferably >with a SQL style interface? (i.e. I pass a SQL statement to the database >engine) > >If necessary, I'll make a translation layer, for the PC version... But I >really >haven't looked into any of Mac Database packages (except Filemaker Pro >v4)... >Preferably this should be free, since however runs this would need it... I think that the only thing that meets all of your criteria is Gadfly SQL which is pure python and available for free at http://www.chordate.com/gadfly.html. It's interesting to play with, but I personally ran into a problem regarding query results exceeding some internal limits even tho they were not especially large and Gadfly is in any case not intended to be used in heavy production environments. The biggest problem is that as far as I know, it hasn't been updated in quite a while. You will have to convert the line endings of its components to get it to run on a Mac and then edit a couple of files to make it work with Python 2.x regardless of platform: gfserve.py line 335: #change from #sock.bind(self.HOST, self.port) #to tupleName = self.HOST, self.port sock.bind(tupleName) gfclient.py line 141: #change from #sock.connect(self.machine, self.port) #to tupleName = self.machine, self.port sock.connect(tupleName) Depending on what you need to do, you might also consider the shelve module if you really just need a persistent dictionary-like object. It's very simple to use and has been quite fast when I've used it in cgi hit counters and stuff like that. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From jhrsn@pitt.edu Fri Dec 7 19:17:44 2001 From: jhrsn@pitt.edu (Jim Harrison) Date: Fri, 07 Dec 2001 14:17:44 -0500 Subject: [Pythonmac-SIG] Silly question? Database server (Mac OS 9 / Mac OS x / PC-Win) In-Reply-To: Message-ID: on 12/7/01 12:16 PM, Richard Gordon at richard@richardgordon.net wrote: >> MySQL doesn't seem to have a Mac version, that I could find? > > Not unless something has been made available for OS X. MacOSX precompiled packages are available for both MySQL and PostGreSQL at http://www.entropy.ch/software/macosx/. I believe they are also part of the fink project (see http://fink.sourceforge.net). Gadfly might be an option for experimentation or prototyping, but I wouldn't try to build a multi-user production system on it. The Lutris Java DB would be an interesting choice for pre-OSX Macs if it will run within their Java implementation. For pre-OSX Macs, you might also look at dtf/SQL (http://www.slab.de/us/home/) and Valentina (commercial, http://www.paradigmasoft.com/). Also in the commercial arena, we used to use Butler, which was distributed by Everyware before they got involved in Tango, but I don't know whether it's still available. It's probably pretty close to what you want, unfortunately. There's probably also a module to allow ODBC/SQL access to 4th Dimension. Jim Harrison Univ. of Pittsburgh From Benjamin.Schollnick@usa.xerox.com Fri Dec 7 18:15:02 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 07 Dec 2001 13:15:02 -0500 Subject: [Pythonmac-SIG] Building Apps in Os X? (previously Silly Ques tion....) Message-ID: Richard, The problem is that I'm considering rewriting some of my older "Message Base", etc (BBS related software) for the web & telnet/irc..... And while Shelve will work, I'm concerned on performance for lookups.... As well as considering messing around while a python newsgroup / usenet server prototype that I found, and updating it to use a proper database, instead of shelve.... I'll have to (at least) examine MySQL, as per the earlier recommendation.... Does anyone have any pointers for building apps in OS X? I really haven't done any UNIX builds.... - Benjamin -----Original Message----- From: Richard Gordon [mailto:richard@richardgordon.net] Sent: Friday, December 07, 2001 12:16 PM To: Schollnick, Benjamin Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Silly question? Database server (Mac OS 9 / Mac OS x / PC-Win) At 11:00 AM -0500 12/7/01, Schollnick, Benjamin wrote: >MySQL doesn't seem to have a Mac version, that I could find? Not unless something has been made available for OS X. >Does anyone know of a Macintosh database that is Python accessible, >preferably >with a SQL style interface? (i.e. I pass a SQL statement to the database >engine) > >If necessary, I'll make a translation layer, for the PC version... But I >really >haven't looked into any of Mac Database packages (except Filemaker Pro >v4)... >Preferably this should be free, since however runs this would need it... I think that the only thing that meets all of your criteria is Gadfly SQL which is pure python and available for free at http://www.chordate.com/gadfly.html. It's interesting to play with, but I personally ran into a problem regarding query results exceeding some internal limits even tho they were not especially large and Gadfly is in any case not intended to be used in heavy production environments. The biggest problem is that as far as I know, it hasn't been updated in quite a while. You will have to convert the line endings of its components to get it to run on a Mac and then edit a couple of files to make it work with Python 2.x regardless of platform: gfserve.py line 335: #change from #sock.bind(self.HOST, self.port) #to tupleName = self.HOST, self.port sock.bind(tupleName) gfclient.py line 141: #change from #sock.connect(self.machine, self.port) #to tupleName = self.machine, self.port sock.connect(tupleName) Depending on what you need to do, you might also consider the shelve module if you really just need a persistent dictionary-like object. It's very simple to use and has been quite fast when I've used it in cgi hit counters and stuff like that. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From bobsavage@mac.com Fri Dec 7 21:17:41 2001 From: bobsavage@mac.com (Bob Savage) Date: Fri, 07 Dec 2001 15:17:41 -0600 Subject: [Pythonmac-SIG] Silly question? Database server (Mac OS 9 / Mac OS x / PC-Win) In-Reply-To: Message-ID: on 12/7/01 10:00 AM, Schollnick, Benjamin wrote: > Guys, > > I'm running into a situation where I'd like to interface with a database > (preferably SQL based).... But since I'm planning this to be multiplatform, > I'm not sure what's available for both Mac OS (9 & X) & the wintel > platforms... This was a big weakness that OS 9 had. MacOSX has at least 4 more SQL-based databases that I know of: MySQL -- free PostGresQL -- free OpenBase -- commercial FrontBase -- commercial I recently installed PostGresQL on my iBook and it works great, but you have to do a few mysterious things to get it setup. Both PostGresQL and MySQL are available already compiled. Also there was an article on Apple's website that I found very useful for setting things up: http://developer.apple.com/internet/index.html There is a tutorial on setting up MySQL linked from this page (as "Open Source Databases"). Both MySQL and PostGresQL have Python bindings (here is one I found for PostGres: http://sourceforge.net/projects/pypgsql/ ) As far as I know both PostGresQL and MySQL have support for Unix, MacOSX, and Windows. I don't know about the commercial databases because I am too cheap :) Best of luck! Bob From mmiller@adobe.com Fri Dec 7 22:11:52 2001 From: mmiller@adobe.com (Martin Miller) Date: Fri, 07 Dec 2001 14:11:52 -0800 Subject: [Pythonmac-SIG] Using Tkinter with 2.1.1 Message-ID: <3C113EA8.EAB2B35F@adobe.com> Hello, I am a Python/PythonMac newbie and have encountered a problem re-running scripts in the Python IDE that use the Tkinter module. They will work the first time I click the "run all" button (assuming there were no programming mistakes made ;-) but not the second time I do it. Instead I get the following error message: > Menu ID 256 is already in use!Fatal Python error: Tcl/Tk panic and the IDE locks up. All I can do at that point is option-cmd-esc and click the "Force Quit" button. Here's a script that exhibits the problem: > import Tkinter > widget = Tkinter.Label(None, text="Hello World!") > widget.pack() > widget.mainloop() I tried adding a "del Tkinter" statement at the end but that did not help the problem. Is there something I must do to allow such a script to be rerun without Quitting, restarting the IDE, and then reopening the script? Thanks in advance. Martin From just@xs4all.nl Fri Dec 7 22:16:48 2001 From: just@xs4all.nl (Just van Rossum) Date: Fri, 7 Dec 2001 23:16:48 +0100 Subject: [Pythonmac-SIG] Using Tkinter with 2.1.1 In-Reply-To: <3C113EA8.EAB2B35F@adobe.com> Message-ID: <20011207231649-r01010800-a6189489-0922-010c@10.0.0.23> Martin Miller wrote: > Is there something I must do to allow such a script to be rerun without > Quitting, restarting the IDE, and then reopening the script? Running Tkinter apps in the IDE is not supported. You must run your script in the interpreter. Maybe later in OSX, when it'll be easier to start a script as a new process. Just From richard@richardgordon.net Sat Dec 8 00:49:30 2001 From: richard@richardgordon.net (Richard Gordon) Date: Fri, 7 Dec 2001 19:49:30 -0500 Subject: [Pythonmac-SIG] Silly question? Database server (Mac OS 9 / Mac OS x / PC-Win) In-Reply-To: References: Message-ID: At 2:17 PM -0500 12/7/01, Jim Harrison wrote: >Gadfly might be an option >for experimentation or prototyping, but I wouldn't try to build a multi-user >production system on it. Me either, Jim. I probably didn't make it very clear, but my assumption was that Benjamin wanted to used something in a distributed system on a standalone basis, not as multi-user. > The Lutris Java DB would be an interesting choice >for pre-OSX Macs if it will run within their Java implementation. I don't know if it would run on conventional MacOS or not, but it isn't free for deployment and thereby failed that preference criterion. >For pre-OSX Macs, you might also look at dtf/SQL >(http://www.slab.de/us/home/) and Valentina (commercial, >http://www.paradigmasoft.com/). I like Valentina, but none of this stuff is free for deployment purposes. >Also in the commercial arena, we used to use Butler, which was distributed >by Everyware before they got involved in Tango, but I don't know whether >it's still available. It's probably pretty close to what you want, >unfortunately. Unless they sold the code to somebody else, Butler has been dead for a long time now. I also liked it, but again didn't see this as a client/server implementation. > There's probably also a module to allow ODBC/SQL access to >4th Dimension. Now you really are talking about some $$$. I tried to get interested in 4D and will say that the company is great, but they will nickel & dime you to death and members of the developer community charge each other for all kinds of stuff that is free for all in an open source environment. Aside from that, I've never found ODBC to be very satisfactory, but it does open up some possibilities on occasion. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From richard@richardgordon.net Sat Dec 8 01:02:33 2001 From: richard@richardgordon.net (Richard Gordon) Date: Fri, 7 Dec 2001 20:02:33 -0500 Subject: [Pythonmac-SIG] Building Apps in Os X? (previously Silly Ques tion....) In-Reply-To: References: Message-ID: At 1:15 PM -0500 12/7/01, Schollnick, Benjamin wrote: > I'll have to (at least) examine MySQL, as per the earlier >recommendation.... MySQL is ok, but I tend to think of it more in terms of what it can't do than what it can do. >Does anyone have any pointers for building apps in OS X? I really haven't >done any >UNIX builds.... Sorry but I've never built anything under OS X, just linux and the various other BSDs. Assuming that Apple hasn't screwed things up too badly, I would generally say that the ease of any unix build is directly related to how much care has gone into the source package that you are working with. I've never had any trouble with things like Apache, Python and Perl that offer really nice makefiles. Other stuff has been dubious and has thrown lots of apparently spurious errors during compile or in a few cases, just refused to build at all. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From richard@richardgordon.net Sat Dec 8 01:17:10 2001 From: richard@richardgordon.net (Richard Gordon) Date: Fri, 7 Dec 2001 20:17:10 -0500 Subject: [Pythonmac-SIG] Silly question? Database server (Mac OS 9 / Mac OS x / PC-Win) In-Reply-To: References: Message-ID: At 3:17 PM -0600 12/7/01, Bob Savage wrote: >I recently installed PostGresQL on my iBook and it works great, but you have >to do a few mysterious things to get it setup. Both PostGresQL and MySQL are >available already compiled. The only word that can describe PostgreSQL is "splendid." I run it on a LAN using mkLinux and an Apache interface using mod_snake with Python. Very cool. Oops, that's two more words. >Both MySQL and PostGresQL have Python bindings (here is one I found for >PostGres: http://sourceforge.net/projects/pypgsql/ ) MySQLdb works well too and is very similar. I am using it for "The Devil's Dictionary" at http://internet-voyager.com/dictionary.html (just click the "Browse All" button if you are not that familiar with Ambrose Bierce's writing) and the source code for the CGI is available at http://internet-voyager.com/source.html if anyone wants to get a general idea of how the interface can be used. >As far as I know both PostGresQL and MySQL have support for Unix, MacOSX, >and Windows. I haven't looked lately, but the last I heard PostgreSQL will only run on windoze from within Cygwin, so it's effectively limited to unix. MySQL does work directly in windoze and actually runs rather well. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From khk@uiah.fi Sat Dec 8 14:42:25 2001 From: khk@uiah.fi (Kari-Hans Kommonen) Date: Sat, 8 Dec 2001 16:42:25 +0200 Subject: [Pythonmac-SIG] Standalone localhost OSX configuration; w/ Zope, wo/ network Message-ID: hi! Does someone know what it takes to successfully run MacOSX without live network connection and be able to point the browser to http://localhost (which runs Zope)? I have not been able to do this with a machine that does not get any TCP/IP services (eg. live ethernet and DHCP address) from the outside. I have given it a manual TCP/IP address in the TCP/IP control panel. The Zope installation should be ok, and works when I am on the network, and I can access it from elsewhere as well. Because I know practically nothing about Unix, I have no idea how to start looking for the reason and what to try out. I am asking about this on this list, because I see Zope as a nice and powerful local object server for any MacOSX Python application, but if you can't trust that you can always find your objects from localhost even if you are not on the net, the prospect is lost. Kari-Hans Kommonen From steve@spvi.com Sat Dec 8 14:47:44 2001 From: steve@spvi.com (Steve Spicklemire) Date: Sat, 08 Dec 2001 09:47:44 -0500 Subject: [Pythonmac-SIG] Standalone localhost OSX configuration; w/ Zope, wo/ network References: Message-ID: <3C12280F.F74EBF83@spvi.com> Hi Kari-Hans, Try: http://127.0.0.1:8080/ -steve Kari-Hans Kommonen wrote: > > hi! > > Does someone know what it takes to successfully run MacOSX without > live network connection and be able to point the browser to > http://localhost (which runs Zope)? > > I have not been able to do this with a machine that does not get any > TCP/IP services (eg. live ethernet and DHCP address) from the > outside. I have given it a manual TCP/IP address in the TCP/IP > control panel. > > The Zope installation should be ok, and works when I am on the > network, and I can access it from elsewhere as well. > > Because I know practically nothing about Unix, I have no idea how to > start looking for the reason and what to try out. > > I am asking about this on this list, because I see Zope as a nice and > powerful local object server for any MacOSX Python application, but > if you can't trust that you can always find your objects from > localhost even if you are not on the net, the prospect is lost. > > Kari-Hans Kommonen > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From trace@reinventnow.com Sun Dec 9 22:11:40 2001 From: trace@reinventnow.com (Tracy Ruggles) Date: Sun, 9 Dec 2001 16:11:40 -0600 Subject: [Pythonmac-SIG] Python on OS X In-Reply-To: Message-ID: Hi, I've been able to install Python on OS X with the pre-compiled version and can use it interactively via the Terminal, but when I try to call it from a CGI, I get a message I haven't seen before: > Could not find platform independent libraries > Could not find platform dependent libraries > Consider setting $PYTHONHOME to [:] > 'import site' failed; use -v for traceback > Traceback (most recent call last): > File "/Library/WebServer/CGI-Executables/test.py", line 5, in ? > import string > ImportError: No module named string > [Sun Dec 9 16:10:47 2001] [error] [client 127.0.0.1] Premature end of script headers: /Library/WebServer/CGI-Executables/test.py The first 4 lines of this error message happen every time. The module, 'string', doesn't seem to want to load. 'sys' and 'os' are there, but I haven't tested for other ones. The code calling it is: > #!/usr/local/bin/python > > import string > print "Content-type: text/html\n\n" > print dir(string) Does anybody have any idea what's happening? Thanks, Tracy -- tracy s. ruggles -- trace@reinventnow.com From tony@metanet.com Sun Dec 9 22:24:23 2001 From: tony@metanet.com (Tony Lownds) Date: Sun, 9 Dec 2001 14:24:23 -0800 Subject: [Pythonmac-SIG] Python on OS X In-Reply-To: References: Message-ID: Hi Tracy, Can you try changing the first line of your script to #!/usr/local/bin/python -v That will cause Python to output details about it's importing process. -Tony At 4:11 PM -0600 12/9/01, Tracy Ruggles wrote: >Hi, > >I've been able to install Python on OS X with the pre-compiled >version and can use it interactively via the Terminal, but when I >try to call it from a CGI, I get a message I haven't seen before: > >> Could not find platform independent libraries >> Could not find platform dependent libraries >> Consider setting $PYTHONHOME to [:] >> 'import site' failed; use -v for traceback >> Traceback (most recent call last): >> File "/Library/WebServer/CGI-Executables/test.py", line 5, in ? >> import string >> ImportError: No module named string >> [Sun Dec 9 16:10:47 2001] [error] [client 127.0.0.1] Premature >>end of script headers: /Library/WebServer/CGI-Executables/test.py > >The first 4 lines of this error message happen every time. The >module, 'string', doesn't seem to want to load. 'sys' and 'os' are >there, but I haven't tested for other ones. > >The code calling it is: > >> #!/usr/local/bin/python >> >> import string >> print "Content-type: text/html\n\n" >> print dir(string) > >Does anybody have any idea what's happening? > >Thanks, >Tracy > > >-- >tracy s. ruggles -- trace@reinventnow.com > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- From trace@reinventnow.com Sun Dec 9 22:35:51 2001 From: trace@reinventnow.com (Tracy Ruggles) Date: Sun, 9 Dec 2001 16:35:51 -0600 Subject: [Pythonmac-SIG] Python on OS X In-Reply-To: Message-ID: <19356FB0-ECF5-11D5-8D45-003065637774@reinventnow.com> Below is the traceback with '-v' option on... Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; traceback: ImportError: No module named site Python 2.1 (#4, 05/17/01, 18:34:21) [GCC Apple DevKit-based CPP 6.0alpha] on darwin1 Type "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/Library/WebServer/CGI-Executables/test.py", line 3, in ? import string ImportError: No module named string # clear __builtin__._ # clear sys.path # clear sys.argv # clear sys.ps1 # clear sys.ps2 # clear sys.exitfunc # clear sys.exc_type # clear sys.exc_value # clear sys.exc_traceback # clear sys.last_type # clear sys.last_value # clear sys.last_traceback # restore sys.stdin # restore sys.stdout # restore sys.stderr # cleanup __main__ # cleanup[1] signal # cleanup[1] exceptions # cleanup sys # cleanup __builtin__ # cleanup ints: 1 unfreed int in 1 out of 1 block # cleanup floats [Sun Dec 9 16:34:01 2001] [error] [client 127.0.0.1] Premature end of script headers: /Library/WebServer/CGI-Executables/test.py On Sunday, December 9, 2001, at 04:24 PM, Tony Lownds wrote: > Hi Tracy, > > Can you try changing the first line of your script to > > #!/usr/local/bin/python -v > > That will cause Python to output details about it's importing process. > > -Tony > > > At 4:11 PM -0600 12/9/01, Tracy Ruggles wrote: >> Hi, >> >> I've been able to install Python on OS X with the pre-compiled version >> and can use it interactively via the Terminal, but when I try to call it >> from a CGI, I get a message I haven't seen before: >> >>> Could not find platform independent libraries >>> Could not find platform dependent libraries >>> Consider setting $PYTHONHOME to [:] >>> 'import site' failed; use -v for traceback >>> Traceback (most recent call last): >>> File "/Library/WebServer/CGI-Executables/test.py", line 5, in ? >>> import string >>> ImportError: No module named string >>> [Sun Dec 9 16:10:47 2001] [error] [client 127.0.0.1] Premature end of >>> script headers: /Library/WebServer/CGI-Executables/test.py >> >> The first 4 lines of this error message happen every time. The module, >> 'string', doesn't seem to want to load. 'sys' and 'os' are there, but I >> haven't tested for other ones. >> >> The code calling it is: >> >>> #!/usr/local/bin/python >>> >>> import string >>> print "Content-type: text/html\n\n" >>> print dir(string) >> >> Does anybody have any idea what's happening? >> >> Thanks, >> Tracy >> >> >> -- >> tracy s. ruggles -- trace@reinventnow.com >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > > -- From jack@oratrix.nl Mon Dec 10 10:44:32 2001 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 10 Dec 2001 11:44:32 +0100 Subject: [Pythonmac-SIG] Python on OS X In-Reply-To: Message by Tracy Ruggles , Sun, 9 Dec 2001 16:35:51 -0600 , <19356FB0-ECF5-11D5-8D45-003065637774@reinventnow.com> Message-ID: <20011210104433.0BF65303183@snelboot.oratrix.nl> > Below is the traceback with '-v' option on... > > Could not find platform independent libraries > Could not find platform dependent libraries > Consider setting $PYTHONHOME to [:] The problem lies earlier than what -v can find: Python can't find it's home folder, and therefore it can't set sys.path correctly. This usually means that Python has been moved, or that it has been installed in a different location than what it was built for. Try printing sys.prefix and sys.execprefix in your CGI script to see what they are. Then try whether you can access them from your CGI script. I.e. Add something like the following to your script (at the top): import sys print 'sys.prefix=', sys.prefix print 'sys.exec_prefix=', sys.exec_prefix print 'listdir(sys.prefix)=', posix.listdir(sys.prefix) print 'listdir(sys.exec_prefix)=', posix.listdir(sys.exec_prefix) print 'sys.path=', sys.path One of the things I'm thinking of is that it could be that the webserver runs your script in a chroot()ed jail. This is a unix method to make sure that CGI scripts can never ever damage most of your system, by taking a subtree of the whole filesystem and calling that "/" for the CGI script. -- 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 Benjamin.Schollnick@usa.xerox.com Mon Dec 10 12:54:35 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Mon, 10 Dec 2001 07:54:35 -0500 Subject: [Pythonmac-SIG] Using Tkinter with 2.1.1 Message-ID: Martin, Unfornately, this problem is the same one I was having... It's a Tkinter issue, and as far as I know, I doubt we will see a resolution to it... Basically, from the MacTCL list, what happening is that the Tkinter library can't be loaded twice.... The people on the MacTCL list say that this is proper behavior, so the only likely fix, is that somehow MacPython is patched around this behavior.... - Benjamin -----Original Message----- From: Martin Miller [mailto:mmiller@adobe.com] Sent: Friday, December 07, 2001 5:12 PM To: pythonmac-sig Subject: [Pythonmac-SIG] Using Tkinter with 2.1.1 Hello, I am a Python/PythonMac newbie and have encountered a problem re-running scripts in the Python IDE that use the Tkinter module. They will work the first time I click the "run all" button (assuming there were no programming mistakes made ;-) but not the second time I do it. Instead I get the following error message: > Menu ID 256 is already in use!Fatal Python error: Tcl/Tk panic and the IDE locks up. All I can do at that point is option-cmd-esc and click the "Force Quit" button. Here's a script that exhibits the problem: > import Tkinter > widget = Tkinter.Label(None, text="Hello World!") > widget.pack() > widget.mainloop() I tried adding a "del Tkinter" statement at the end but that did not help the problem. Is there something I must do to allow such a script to be rerun without Quitting, restarting the IDE, and then reopening the script? Thanks in advance. Martin _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From mmiller@adobe.com Mon Dec 10 20:59:27 2001 From: mmiller@adobe.com (Martin Miller) Date: Mon, 10 Dec 2001 12:59:27 -0800 Subject: [Pythonmac-SIG] Using Tkinter with 2.1.1 References: Message-ID: <3C15222F.99F20CC9@adobe.com> Benjamin, What you say about the error occurring because Tkinter is being load twice surprises me, because I have read that module "import" statements only happen once*, the first time one is encountered for a particular module -- which is why the built-in "reload()" function must be used. Perhaps it has something to do with how scripts are executed from within the Mac Python IDE. Just van Rossum told me in a separate email (see far below) that running Tkinter apps in the IDE is not currently supported. I have been able to run them multiple times by dragging-and-dropping them directly on the PythonInterpreter app. Regards, -Martin *page 132-133, "Learning Python" by Lutz and Ascher. ======================================================== On Mon, 10 Dec 2001 07:54:35, Benjamin Schollnick wrote: > > Martin, > > Unfornately, this problem is the same one I was having... > > It's a Tkinter issue, and as far as I know, I doubt we will > see a resolution to it... > > Basically, from the MacTCL list, what happening is that the > Tkinter library can't be loaded twice.... > > The people on the MacTCL list say that this is proper behavior, > so the only likely fix, is that somehow MacPython is patched > around this behavior.... > > - Benjamin > > -----Original Message----- > From: Martin Miller [mailto:mmiller@adobe.com] > Sent: Friday, December 07, 2001 5:12 PM > To: pythonmac-sig > Subject: [Pythonmac-SIG] Using Tkinter with 2.1.1 > > Hello, I am a Python/PythonMac newbie and have encountered a problem > re-running scripts in the Python IDE that use the Tkinter module. They > will work the first time I click the "run all" button (assuming there > were no programming mistakes made ;-) but not the second time I do it. > Instead I get the following error message: > > > Menu ID 256 is already in use!Fatal Python error: Tcl/Tk panic > > and the IDE locks up. All I can do at that point is option-cmd-esc and > click the "Force Quit" button. > > Here's a script that exhibits the problem: > > > import Tkinter > > widget = Tkinter.Label(None, text="Hello World!") > > widget.pack() > > widget.mainloop() > > I tried adding a "del Tkinter" statement at the end but that did not > help the problem. > > Is there something I must do to allow such a script to be rerun without > Quitting, restarting the IDE, and then reopening the script? > > Thanks in advance. > > Martin > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig =================================================== On Fri, 7 Dec 2001 23:16:48, Just van Rossum wrote: > > Martin Miller wrote: > > > Is there something I must do to allow such a script to be rerun without > > Quitting, restarting the IDE, and then reopening the script? > > Running Tkinter apps in the IDE is not supported. You must run your script in > the interpreter. Maybe later in OSX, when it'll be easier to start a script as a > new process. > > Just From Benjamin.Schollnick@usa.xerox.com Tue Dec 11 12:51:03 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Tue, 11 Dec 2001 07:51:03 -0500 Subject: [Pythonmac-SIG] RE: [MACTCL] Re: TkPutImage crash on very wide images Message-ID: Now, please keep in mind, I haven't gone through the MacPython source code, but I've seen the identical symptoms... Here's my summary: Is there any reason that Tkinter (Tkinter.Tk()) Initialization might fail, if it already exists? i.e. Test = Tkinter.Tk() Test2 = Tkinter.Tk() What was happening was that I initialized Tk, and then I didn't pass the Root to the Wizard GUI package... Which then initialized it again... But, as I am apt to do, this does not cause an issue on the PC Python (Cpython).... I already posted a inquiry on the mac-tcl list, but will follow that up.... But, I assume this is a Tcl core issue? And what version of Tcl did Python v2.11 ship with? Right from the source...(From the MacTCL list): > From: Jim Ingham [mailto:jingham@apple.com] > Sent: Wednesday, November 07, 2001 2:39 PM > To: Schollnick, Benjamin > Cc: 'tcl-mac@lists.sourceforge.net' > Subject: Re: [MACTCL] RE: Problems with Mac TCL? > > > Benjamin, > > First off, Tcl/Tk is not designed to allow you to load two independent > copies of Tk into an application. There is global state in the > libraries that will cause conflicts. So you have to make sure that you > unload the first copy completely before you try to load the second > copy. You can create two tcl interpreters, both running Tk, but the way > you are supposed to do that is to create one interpreter, and then load > Tk into the second interpreter by running "package require Tk" in the > second interpreter. This is, for example, how the console window in > MacTk works. But we never intended you to be able to actually load the > Tk library twice. > > Theoretically, you could load Tk, then unload it. However, I never > worked very hard to make sure that you could unload Tcl/Tk from an app, > and then reload it again cleanly. There are finalization routines for > all the subsystems, but I would have no problem believing they don't > clean up everything. The only things I really cared about was > non-shared state, and resources that the system would not reap when the > process exited. You could probably fix this - since the mechanism to > handle finalization is present. What I suspect is happening is, since the IDE never unloads, the TK/Tcl library's are still initialized.... The second time you run the program, the library attempts to initialize, can't grab/generate the "Window ID#256" and fails.... (This is the assumption) The IDE imports the library's into it's own name space, since in Classic there no way to make a "truly" separate process.... (In Mac OS X, probably that would spawn another process.) Sorry if I was not clear enough, previously.... I still think this is a problem, especially since the PC (aka Cpython) version doesn't have this problem.... But when I (briefly) examined Tkinter.py I didn't see anyway to work around this issue, without causing significant code issues between the PC & Mac versions of python.... - Benjamin -----Original Message----- From: Jim Ingham [mailto:jingham@apple.com] Sent: Monday, December 10, 2001 1:23 PM To: Daniel A. Steffen Cc: tcl-mac@lists.sourceforge.net; scassidy@laurel.ocs.mq.edu.au Subject: [MACTCL] Re: TkPutImage crash on very wide images Daniel, On Sunday, December 9, 2001, at 11:31 PM, Daniel A. Steffen wrote: > Dear All, > > tkMacDraw.c's TkPutImage crashes in CopyBits when using very wide > images. > > I have a case here where a Tk app (which is working fine on unix & win) > uses an image 4846 pixels wide (and 32 bits deep), which results in a > bytes_per_line value of 0x4BB8. However, according to IM, PixMap's > maximal value for rowBytes is 0x3FFF (c.f. [1]) and indeed CopyBits > crashes on the PixMap constructed by TkPutImage with > pixmap.rowBytes = image->bytes_per_line | 0x8000; > (rowBytes is a short whose high 2 bits are used as QD flags, thus the > 0x3FFF limit) > > In practical terms this means that Tk will crash when using any 32bit > image wider than 4095 pixels. > > Not sure what the best solution is here, I've now added a panic before > the CopyBits to at least exit gracefully, a better solution would be to > split the image into blocks that are maximally 0x4000 bytes wide and do > CopyBits on each block... The question is how common is the use of > images this wide, is it worth putting in time to get this to work? > This depends on how much free time you have. Not many screens can display an image this big, so I wouldn't imagine this is all that common. > BTW, this problem almost certainly also exist on TkAqua, as TkPutImage > is essentially unchanged in tkMacOSXDraw.c (and Carbon CopyBits still > uses Bit 15 as a flag) > Yes, but I would solve this problem on X not by breaking the image up, as you would have to on 9, but by replacing CopyBits with a CoreGraphics problem at some point, since that would also open the possibility of compositing with alpha channels as well. So I don't think this is a motivation to do this work on 9 (of course, who knows when I will get around to this...) Jim -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer _______________________________________________ Tcl-mac mailing list Tcl-mac@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tcl-mac From Benjamin.Schollnick@usa.xerox.com Tue Dec 11 14:27:46 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Tue, 11 Dec 2001 09:27:46 -0500 Subject: [Pythonmac-SIG] Using Tkinter with 2.1.1 Message-ID: Now, please keep in mind, I haven't gone through the MacPython source code, but I've seen the identical symptoms... Here's my summary: Is there any reason that Tkinter (Tkinter.Tk()) Initialization might fail, if it already exists? i.e. Test = Tkinter.Tk() Test2 = Tkinter.Tk() What was happening was that I initialized Tk, and then I didn't pass the Root to the Wizard GUI package... Which then initialized it again... But, as I am apt to do, this does not cause an issue on the PC Python (Cpython).... I already posted a inquiry on the mac-tcl list, but will follow that up.... But, I assume this is a Tcl core issue? And what version of Tcl did Python v2.11 ship with? Right from the source...(From the MacTCL list): > From: Jim Ingham [mailto:jingham@apple.com] > Sent: Wednesday, November 07, 2001 2:39 PM > To: Schollnick, Benjamin > Cc: 'tcl-mac@lists.sourceforge.net' > Subject: Re: [MACTCL] RE: Problems with Mac TCL? > > > Benjamin, > > First off, Tcl/Tk is not designed to allow you to load two independent > copies of Tk into an application. There is global state in the > libraries that will cause conflicts. So you have to make sure that you > unload the first copy completely before you try to load the second > copy. You can create two tcl interpreters, both running Tk, but the way > you are supposed to do that is to create one interpreter, and then load > Tk into the second interpreter by running "package require Tk" in the > second interpreter. This is, for example, how the console window in > MacTk works. But we never intended you to be able to actually load the > Tk library twice. > > Theoretically, you could load Tk, then unload it. However, I never > worked very hard to make sure that you could unload Tcl/Tk from an app, > and then reload it again cleanly. There are finalization routines for > all the subsystems, but I would have no problem believing they don't > clean up everything. The only things I really cared about was > non-shared state, and resources that the system would not reap when the > process exited. You could probably fix this - since the mechanism to > handle finalization is present. What I suspect is happening is, since the IDE never unloads, the TK/Tcl library's are still initialized.... The second time you run the program, the library attempts to initialize, can't grab/generate the "Window ID#256" and fails.... (This is the assumption) The IDE imports the library's into it's own name space, since in Classic there no way to make a "truly" separate process.... (In Mac OS X, probably that would spawn another process.) Sorry if I was not clear enough, previously.... I still think this is a problem, especially since the PC (aka Cpython) version doesn't have this problem.... But when I (briefly) examined Tkinter.py I didn't see anyway to work around this issue, without causing significant code issues between the PC & Mac versions of python.... - Benjamin -----Original Message----- From: Martin Miller [mailto:mmiller@adobe.com] Sent: Monday, December 10, 2001 3:59 PM To: Schollnick, Benjamin Cc: pythonmac-sig Subject: Re: [Pythonmac-SIG] Using Tkinter with 2.1.1 Benjamin, What you say about the error occurring because Tkinter is being load twice surprises me, because I have read that module "import" statements only happen once*, the first time one is encountered for a particular module -- which is why the built-in "reload()" function must be used. Perhaps it has something to do with how scripts are executed from within the Mac Python IDE. Just van Rossum told me in a separate email (see far below) that running Tkinter apps in the IDE is not currently supported. I have been able to run them multiple times by dragging-and-dropping them directly on the PythonInterpreter app. Regards, -Martin *page 132-133, "Learning Python" by Lutz and Ascher. ======================================================== On Mon, 10 Dec 2001 07:54:35, Benjamin Schollnick wrote: > > Martin, > > Unfornately, this problem is the same one I was having... > > It's a Tkinter issue, and as far as I know, I doubt we will > see a resolution to it... > > Basically, from the MacTCL list, what happening is that the > Tkinter library can't be loaded twice.... > > The people on the MacTCL list say that this is proper behavior, > so the only likely fix, is that somehow MacPython is patched > around this behavior.... > > - Benjamin > > -----Original Message----- > From: Martin Miller [mailto:mmiller@adobe.com] > Sent: Friday, December 07, 2001 5:12 PM > To: pythonmac-sig > Subject: [Pythonmac-SIG] Using Tkinter with 2.1.1 > > Hello, I am a Python/PythonMac newbie and have encountered a problem > re-running scripts in the Python IDE that use the Tkinter module. They > will work the first time I click the "run all" button (assuming there > were no programming mistakes made ;-) but not the second time I do it. > Instead I get the following error message: > > > Menu ID 256 is already in use!Fatal Python error: Tcl/Tk panic > > and the IDE locks up. All I can do at that point is option-cmd-esc and > click the "Force Quit" button. > > Here's a script that exhibits the problem: > > > import Tkinter > > widget = Tkinter.Label(None, text="Hello World!") > > widget.pack() > > widget.mainloop() > > I tried adding a "del Tkinter" statement at the end but that did not > help the problem. > > Is there something I must do to allow such a script to be rerun without > Quitting, restarting the IDE, and then reopening the script? > > Thanks in advance. > > Martin > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig =================================================== On Fri, 7 Dec 2001 23:16:48, Just van Rossum wrote: > > Martin Miller wrote: > > > Is there something I must do to allow such a script to be rerun without > > Quitting, restarting the IDE, and then reopening the script? > > Running Tkinter apps in the IDE is not supported. You must run your script in > the interpreter. Maybe later in OSX, when it'll be easier to start a script as a > new process. > > Just From Benjamin.Schollnick@usa.xerox.com Tue Dec 11 15:37:19 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Tue, 11 Dec 2001 10:37:19 -0500 Subject: [Pythonmac-SIG] Problems with Findertools in OS x v.10.1.1? (Move) Message-ID: I haven't heard anything back regarding this? Traceback (most recent call last): File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 104, in ? move_file ( pathname, new_dir, filename ) File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 53, in move_file findertools.move (old_path + filename, new_path) File "OS v9.1:Applications (Mac OS 9):Python2.1.1:Mac:Lib:findertools.py", line 74, in move return finder.move(src_fss, to=dst_fss) File "OS v9.1:Applications (Mac OS 9):Python2.1.1:Mac:Lib:lib-scriptpackages:Finder:Standard_Suite.py", line 293, in move raise aetools.Error, aetools.decodeerror(_arguments) aetools.Error: (0, 'component result = no error', None) This is in MacPython in "Classic" mode running in a classic window from Mac Os v10.1.1. I'm trying to switch Macpython to "Carbon" mode, but it's taking forever (30 minutes +) to run all the reconfigures.... (It hasn't finished yet). So I'm not sure if there's a work around... - Benjamin (See below for more details). -----Original Message----- From: Schollnick, Benjamin [mailto:Benjamin.Schollnick@usa.xerox.com] Sent: Wednesday, November 21, 2001 11:27 AM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] Problems with Findertools in OS x v.10.1.1? (Move) I'm using a file copy routine that I just finished, and started to notice some oddities... Namely the findertools.move () command appears to work, but is returning an exception....... This may have just started with OS X v10.1.1, but I'm not positive... I just booted back to OS v9.21 and do *NOT* see this problem occuring there... So it's certainly an Mac OS X issue... Since the file copy does appear to work, I may have missed it when I added the exception coding.... (It appears to work so maybe I just wasn't observant enough). Anyone else notice this? - Benjamin def move_file ( old_path, new_path, filename ): try: if os.path.exists (new_path + os.sep + filename): Ask = EasyDialogs.AskYesNoCancel("Duplicate File Detected (%s), Overwrite?" % filename, default = 1, yes=None, no=None, cancel=None, id=262) if Ask == 1: if mac_mode: # Overwrite, by removing the old file # os.remove(new_path + os.sep + filename) elif Ask == 0: # # Do not overwrite, end routine, by returning # return 0 elif Ask == -1: # # Abort program, return error code # return -1 if mac_mode: findertools.move (old_path + filename, new_path) print old_path + filename, " --> Moved.." except: print "error" return None # of Files found : 6 filename : WAITING.JPG filename : WALL filename : WALL_1.JPG ------------------------------------- old: OS v9.1:Desktop Folder:python work:test: new: OS v9.1:Desktop Folder:python work:test:Wall filename: WALL_1.JPG old + file: OS v9.1:Desktop Folder:python work:test:WALL_1.JPG Traceback (most recent call last): File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 104, in ? move_file ( pathname, new_dir, filename ) File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 53, in move_file findertools.move (old_path + filename, new_path) File "OS v9.1:Applications (Mac OS 9):Python 2.1.1:Mac:Lib:findertools.py", line 74, in move return finder.move(src_fss, to=dst_fss) File "OS v9.1:Applications (Mac OS 9):Python 2.1.1:Mac:Lib:lib-scriptpackages:Finder:Standard_Suite.py", line 293, in move raise aetools.Error, aetools.decodeerror(_arguments) aetools.Error: (0, 'component result = no error', None) _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From mis@creazone.com Tue Dec 11 17:30:21 2001 From: mis@creazone.com (Michal Seta) Date: Tue, 11 Dec 2001 12:30:21 -0500 Subject: [Pythonmac-SIG] calldll? Message-ID: Hello. Could someone, please, point me to some documentation on using calldll or show an example? Or, is there any other way of using shared libraries in my Python code that are not python modules? I think I'm missing something... thanks. Mike From just@letterror.com Tue Dec 11 17:49:50 2001 From: just@letterror.com (Just van Rossum) Date: Tue, 11 Dec 2001 18:49:50 +0100 Subject: [Pythonmac-SIG] calldll? In-Reply-To: Message-ID: <20011211184952-r01010800-9ca174b3-0922-010c@10.0.0.23> Michal Seta wrote: > Could someone, please, point me to some documentation on > using calldll or show an example? Or, is there any other way > of using shared libraries in my Python code that are not > python modules? > > I think I'm missing something... Did you look at the stuff in :Mac:Demo:calldll: ? Just From mis@creazone.com Tue Dec 11 18:32:09 2001 From: mis@creazone.com (Michal Seta) Date: Tue, 11 Dec 2001 13:32:09 -0500 Subject: [Pythonmac-SIG] calldll? Message-ID: > > Did you look at the stuff in :Mac:Demo:calldll: ? Ha! Thanks. that'll do. Mike From nathan@vividworks.com Tue Dec 11 20:29:43 2001 From: nathan@vividworks.com (Nathan Heagy) Date: Tue, 11 Dec 2001 14:29:43 -0600 (CST) Subject: [Pythonmac-SIG] 2.2 compile problem Message-ID: I'm getting the following error when trying to compile the latest beta of Python 2.2 on OS X 10.0: dyld: ./python.exe multiple definitions of symbol _COLS /Users/nathan/Documents/Downloads/Python-2.2b2/build/lib.darwin-1.3.3-Power Macintosh-2.2/readline.so definition of _COLS /Users/nathan/Documents/Downloads/Python-2.2b2/build/lib.darwin-1.3.3-Power Macintosh-2.2/_curses.so definition of _COLS An acceptable solution for me is to not build curses support at all - I don't need it in python. However it isn't enabled in Module.Setup so I think one of the Makefiles has snuck behind my back to build it without my consent. Any ideas? Nathan From sdm7g@Virginia.EDU Tue Dec 11 20:48:07 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Tue, 11 Dec 2001 15:48:07 -0500 (EST) Subject: [Pythonmac-SIG] 2.2 compile problem In-Reply-To: Message-ID: On Tue, 11 Dec 2001, Nathan Heagy wrote: > I'm getting the following error when trying to compile the latest beta of > Python 2.2 on OS X 10.0: > > dyld: ./python.exe multiple definitions of symbol _COLS > /Users/nathan/Documents/Downloads/Python-2.2b2/build/lib.darwin-1.3.3-Power > Macintosh-2.2/readline.so definition of _COLS > /Users/nathan/Documents/Downloads/Python-2.2b2/build/lib.darwin-1.3.3-Power > Macintosh-2.2/_curses.so definition of _COLS > > An acceptable solution for me is to not build curses support at all - I > don't need it in python. However it isn't enabled in Module.Setup so I > think one of the Makefiles has snuck behind my back to build it without my > consent. > > Any ideas? > I didn't get any error and my version didn't build with _curses: Python 2.2b2 (#1, Dec 2 2001, 12:13:01) [GCC 2.95.2 19991024 (release)] on darwin5 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/curses/__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses But I also don't have readline enabled -- I haven't reinstalled some libraries since I installed 10.1 . I'll put it back and see what happens. -- Steve Majewski From nathan@vividworks.com Tue Dec 11 20:54:56 2001 From: nathan@vividworks.com (Nathan Heagy) Date: Tue, 11 Dec 2001 14:54:56 -0600 (CST) Subject: [Pythonmac-SIG] 2.2 compile problem In-Reply-To: Message-ID: > I didn't get any error and my version didn't build with _curses: > > But I also don't have readline enabled -- I haven't reinstalled > some libraries since I installed 10.1 . I'll put it back and see > what happens. Ya I love readline though. Nathan From nathan@vividworks.com Tue Dec 11 23:27:35 2001 From: nathan@vividworks.com (Nathan Heagy) Date: Tue, 11 Dec 2001 17:27:35 -0600 (CST) Subject: [Pythonmac-SIG] 2.2 compile problem In-Reply-To: Message-ID: This seems to be a bug in the assumptions in setup.py for OS X. Please correct me if I'm wrong, but line 461, "# OSX has an old Berkeley curses, not good enough for the _curses module." hints that perhaps the possibility that OS X may have been upgraded to gnu ncurses is not considered. This would then be a bug. For example, this is exactly what I have done. I am still no closer to locating what is telling make to build the curses module. And help to this is greatly appreciated. It seems ridiculous that no one on this list knows where this is being done. Nathan On Tue, 11 Dec 2001, Nathan Heagy wrote: > I'm getting the following error when trying to compile the latest beta of > Python 2.2 on OS X 10.0: > > dyld: ./python.exe multiple definitions of symbol _COLS > /Users/nathan/Documents/Downloads/Python-2.2b2/build/lib.darwin-1.3.3-Power > Macintosh-2.2/readline.so definition of _COLS > /Users/nathan/Documents/Downloads/Python-2.2b2/build/lib.darwin-1.3.3-Power > Macintosh-2.2/_curses.so definition of _COLS > > An acceptable solution for me is to not build curses support at all - I > don't need it in python. However it isn't enabled in Module.Setup so I > think one of the Makefiles has snuck behind my back to build it without my > consent. > > Any ideas? > > Nathan > > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From jack@oratrix.nl Wed Dec 12 12:57:28 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 12 Dec 2001 13:57:28 +0100 Subject: [Pythonmac-SIG] 2.2 compile problem In-Reply-To: Message by Nathan Heagy , Tue, 11 Dec 2001 17:27:35 -0600 (CST) , Message-ID: <20011212125729.31A8A303183@snelboot.oratrix.nl> > This seems to be a bug in the assumptions in setup.py for OS X. Please > correct me if I'm wrong, but line 461, "# OSX has an old Berkeley curses, > not good enough for the _curses module." hints that perhaps the > possibility that OS X may have been upgraded to gnu ncurses is not > considered. This would then be a bug. For example, this is exactly what I > have done. > > I am still no closer to locating what is telling make to build the curses > module. And help to this is greatly appreciated. It seems ridiculous that > no one on this list knows where this is being done. Nathan, you're on fresh ground here. I don't think anyone every tried building curses or readline on OSX. The included curses on OSX isn't good enough for the Python curses module, but of course if you install a more recent one that is good enough. If you know how to distinguish between the two: could you create a patch for setup.py and submit it to sourceforge? If you do so within the next few days, and assign the patch to me, and provide instructions as to where I can download the needed curses, etc. I can probably test this patch and check it in before 2.2 goes out the door. The _COLS collision between readline and curses is not easy to solve, this is a general OSX problem. It is solved in 10.1 if you use a hierarchical namespace in your binaries, but unfortunately that means your program won't run on 10.0 anymore. But: this collision should only bother you if you try to import curses and readline at the same time. So if you can get setup to not import the just-created module you should be fine. -- 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 just@letterror.com Wed Dec 12 13:43:15 2001 From: just@letterror.com (Just van Rossum) Date: Wed, 12 Dec 2001 14:43:15 +0100 Subject: [Pythonmac-SIG] 2.2 compile problem In-Reply-To: <20011212125729.31A8A303183@snelboot.oratrix.nl> Message-ID: <20011212144317-r01010800-57d9caec-0922-010c@10.0.0.23> Jack Jansen wrote: > you're on fresh ground here. I don't think anyone every tried building curses > or readline on OSX. FWIW: readline 4.2 builds just fine, and seems to work nicely with Python. Just From nathan@vividworks.com Wed Dec 12 15:53:25 2001 From: nathan@vividworks.com (Nathan Heagy) Date: Wed, 12 Dec 2001 09:53:25 -0600 (CST) Subject: [Pythonmac-SIG] 2.2 compile problem In-Reply-To: <20011212125729.31A8A303183@snelboot.oratrix.nl> Message-ID: > The included curses on OSX isn't good enough for the Python curses module, but > of course if you install a more recent one that is good enough. If you know > how to distinguish between the two: could you create a patch for setup.py and > submit it to sourceforge? If you do so within the next few days, and assign > the patch to me, and provide instructions as to where I can download the > needed curses, etc. I can probably test this patch and check it in before 2.2 > goes out the door. K, I'll see what I can do. No guarantees though. Nathan From sburr@home.com Wed Dec 12 20:57:26 2001 From: sburr@home.com (Steven Burr) Date: Wed, 12 Dec 2001 13:57:26 -0700 Subject: [Pythonmac-SIG] 2.2 compile problem In-Reply-To: <20011212125729.31A8A303183@snelboot.oratrix.nl> Message-ID: On Wednesday, December 12, 2001, at 05:57 AM, Jack Jansen wrote: >> This seems to be a bug in the assumptions in setup.py for OS X. Please >> correct me if I'm wrong, but line 461, "# OSX has an old Berkeley >> curses, >> not good enough for the _curses module." hints that perhaps the >> possibility that OS X may have been upgraded to gnu ncurses is not >> considered. This would then be a bug. For example, this is exactly >> what I >> have done. >> >> I am still no closer to locating what is telling make to build the >> curses >> module. And help to this is greatly appreciated. It seems ridiculous >> that >> no one on this list knows where this is being done. > > Nathan, > you're on fresh ground here. I don't think anyone every tried building > curses > or readline on OSX. FWIW, the fink distribution of python includes readline and curses support. When I run the interpreter in Terminal or in an XDarwin terminal, I have command history and editing and am able to import curses with no errors. The info file for python 2.2b2 lists readline as a dependency; it doesn't list the ncurses library, but I think that's because it's included in the fink base system. If it would be helpful, I'd be happy to e-mail the fink patch file for python. If on the other hand I've completely missed the point of this discussion, I apologize. From jack@oratrix.nl Wed Dec 12 23:29:13 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 13 Dec 2001 00:29:13 +0100 Subject: [Pythonmac-SIG] 2.2 compile problem In-Reply-To: Message by Steven Burr , Wed, 12 Dec 2001 13:57:26 -0700 , Message-ID: <20011212232918.41A8211D107@oratrix.oratrix.nl> Recently, Steven Burr said: > If it would be helpful, I'd be happy to e-mail the fink patch file for > python. If on the other hand I've completely missed the point of this > discussion, I apologize. Please put them in the sourceforge patchmanager and assign them to me. -- 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 jack@oratrix.nl Wed Dec 12 23:32:33 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 13 Dec 2001 00:32:33 +0100 Subject: [Pythonmac-SIG] Re: CarbonEvents -> MacPython In-Reply-To: Message by Donovan Preston , Mon, 12 Nov 2001 15:21:42 -0800 , <081E921B-D7C4-11D5-89BA-003065B33450@intersight.com> Message-ID: <20011212233238.49F5611D107@oratrix.oratrix.nl> Recently, Donovan Preston said: > I also have a few changes to the module on my local hard drive at home > which make the module build properly under OS X. I have been unable to > figure out how to create a diff and this is the reason why I haven't > submitted the changes to Jack (they are quite trivial, however.) If > someone could tell me how I could generate a diff from the terminal on > OS X, on a CVS checkout which I have modified locally, I would > appreciate it. Perhaps then this module can become part of the standard > build process and I can stop worrying about making sure it is there > separately. I'll only answer this now (the rest of the message needs actual brainpower, and I'm low on that, so about to go and replenish it with some alcoholic beverages and loud music:-): do a "cvs diff -c" and put it in the sourceforge patch manager. Assign it to me or (better) Just. I'm jackjansen, Just is jvr. -- 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 sburr@home.com Thu Dec 13 01:22:13 2001 From: sburr@home.com (Steven Burr) Date: Wed, 12 Dec 2001 18:22:13 -0700 Subject: [Pythonmac-SIG] 2.2 compile problem In-Reply-To: <20011212232918.41A8211D107@oratrix.oratrix.nl> Message-ID: On Wednesday, December 12, 2001, at 04:29 PM, Jack Jansen wrote: > > Recently, Steven Burr said: >> If it would be helpful, I'd be happy to e-mail the fink patch file for >> python. If on the other hand I've completely missed the point of this >> discussion, I apologize. > > Please put them in the sourceforge patchmanager and assign them to me. Done. I hope it's helpful. From sdm7g@Virginia.EDU Thu Dec 13 02:42:49 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Wed, 12 Dec 2001 21:42:49 -0500 (EST) Subject: [Pythonmac-SIG] Re: CarbonEvents -> MacPython In-Reply-To: <081E921B-D7C4-11D5-89BA-003065B33450@intersight.com> Message-ID: Somebody said: ( I've stripped out the attributions, because, since I didn't see the earlier messages in the thread, I'll probably get confused and get it wrong. ) > > ... but > > there is at least one issue that's beyond me: this MP stuff in the > > event handler > > code and in RunApplicationEventLoop(). I see USE_MAC_MP_MULTITHREADING > > is > > manually defined. However, if it _is_ defined, at least > > RunApplicationEventLoop() doesn't work under OS 9.x (it throws a > > SystemError Only OSX has multiprocessor support, not OS9, so I assume it's throwing that SystemError on purpose. > > exception, which is bad all by itself...). So for now I've simply > > disabled it. And because of the global interpreter lock in the interpreter, I don't think it makes any sense to try to run Python on dual processors. > Here's the issue I had with RunApplicationEventLoop which I tried to > solve with the code between USE_MAC_MP_MULTITHREADING: (I put it between > that define specifically so someone could turn it off if it was > problematic) > > When python calls a C function, it assumes that C function COULD be > calling the C Python api to manipulate python objects, call functions, > etc. Therefore it hands the global interpreter lock to the C function > and waits until the function returns before executing any more python > code. Simple enough for doing most things in C like calculating the > value of 2 + 2, building a python object out of the result, and > returning it to python. > > But when you call RunApplicationEventLoop, you are entering into a black > hole from which control will not be returned until your app exits. > > Also, if you have registered any event handlers before calling > RunApplicationEventLoop (your app would be pretty boring if you hadn't), > the OS will call your code from within the black hole of > RunApplicationEventLoop and the python interpreter will be kicked off > again. > > Problem is, the OS sometimes likes to call an event handler __while__ > another event is still being handled. This causes two threads of > execution to try to execute python code in the same interpreter at the > same time. Bad news. First: you don't really need to call the RunApplicationEventLoop to use AppleEvents -- you can do it entirely with WaitNextEvent. See "Carbon Events Versus WaitNextEvent" in chapter 2 of the "Inside Carbon: Handling Carbon Events" doc: on my disk as: Second: If we wanted to reorganize the event code in (Carbon) MacPython, I would suggest making the whole interpreter loop event driven: ( This is partly inspired by the fact that, while I've been reading the CarbonEvent docs, I've been working on using AppleEvents to XlispStat, which supports a DoScript event that will evaluate any lisp expression.) Define Events for some parts of the Python C API, especially PyRun_* functions. Python sends itself those events. ( Although doing this also makes it scriptable. ) The fact that *Run_Interactive* has to be getting keyboard events, etc. for input is using those parallel events you mention above that are a problem you your advantage. ( At least that's how I *think* it works -- I haven't tried to trace out the execution yet. Maybe I can do some simple test code. ) When the RunInteractive event is dispatched, it can't return until it collects interactive input, so it calls WaitNextEvent, which dispatches the registered events. ( We don't really expect to have any low level events returned by WNE -- they should be handled by their registered handlers. ) Is that confusing enough for you? [ BTW: You can *send* AppleEvents from a unix command line program running from Terminal.app. I don't know yet if you can receive them -- there must be a way, because if I set the Wait-for-reply, I do get a reply back with the data I'm expecting, but A command line program doesn't typically have an event loop, so I'm not quite sure how to catch other events! This may be a way to link the unix app world with the OSX bundled app world. ] > I'm very excited about helping make MacPython kick ass, and sorry that I > don't take more time out to give a progress report on what I'm doing to > the list. -- Steve From ryanwilcox@mac.com Thu Dec 13 05:53:59 2001 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Thu, 13 Dec 2001 00:53:59 -0500 Subject: [Pythonmac-SIG] PythonSlave and X -- new developments! In-Reply-To: <20011212232918.41A8211D107@oratrix.oratrix.nl> Message-ID: <20011213005400-r01010800-086d909b-0922-010c@129.21.139.101> Anybody remember that old PythonSlave BBEdit plugin/PythonInterpreter script Just made several years ago? Well, I've made a set of Applescripts that duplicate the functionality of that BBEdit Plugin. Actually, I wrote -two- applescripts. One will have PythonInterpreter execute the whole document, and the other will execute only the SELECTED text. Note: The first time you run either of these scripts you will be promoted to locate PythonInterpreter. I wish it didn't have to be this way, but I couldn't think of a way around it. ------------------------------------- Installation instructions: #1: Place the scripts in your {BBEdit}:BBEdit Support:Scripts folder #2: Launch PythonSlave (see instructions that came with PythonSlave) #3: Launch BBEdit and test it out!! ------------------------------------- Since these are just Applescripts (and really easy scripts at that), this could easily be done for other editors... or even for the Finder. URL for scripts: http://www.autographsystems.com/Wilcox/OSX/RunAsPython.sit Hope this helps some people!, -Ryan Wilcox ------------------------------------- Who feels happy now that he can run all his python scripts from BBEdit, where they can happily live with my shell scripts and other utility Applescripts OHHH!!! Looky this!!!! ( What's also cool is that I can trigger PythonSlave from the terminal too: [prompt] rpw% open -a PythonInterpreter testscript.py ) ------------------------------------ Ryan Wilcox PGP: 0x2F4E9C31 From lmeyn@mail.arc.nasa.gov Thu Dec 13 16:03:07 2001 From: lmeyn@mail.arc.nasa.gov (Larry Meyn) Date: Thu, 13 Dec 2001 08:03:07 -0800 Subject: [Pythonmac-SIG] Numeric Problem & Carbon Problem Message-ID: In version 2.2b2 I get an error when importing RandomArray from the Numeric package. This worked fine in previous versions. The tracebacks for classic and carbon versions are given below. An additional problem found is that I could not copy text from the interpreter window when running PythonCarbon. The copy menu was not enabled. PythonClassic Traceback: Traceback (most recent call last): File "Macintosh HD:Projects:Active Projects:ATM Projects:Probabilistic Forecasting:Software:arrival_load.py", line 2, in ? from RandomArray import * File "Macintosh HD:Programming:Python:Python 2.2b2:lib:site-packages:Numeric:RandomArray.py", line 30, in ? seed() File "Macintosh HD:Programming:Python:Python 2.2b2:lib:site-packages:Numeric:RandomArray.py", line 24, in seed ndigits = int(math.log10(t)) ValueError: math domain error ================================================= PythonCarbon Traceback: Traceback (most recent call last): File "Macintosh HD:Projects:Active Projects:ATM Projects:Probabilistic Forecasting:Software:arrival_load.py", line 2, in ? from RandomArray import * File "Macintosh HD:Programming:Python:Python 2.2b2:lib:site-packages:Numeric:RandomArray.py", line 30, in ? seed() File "Macintosh HD:Programming:Python:Python 2.2b2:lib:site-packages:Numeric:RandomArray.py", line 24, in seed ndigits = int(math.log10(t)) OverflowError: float too large to convert -- ---------------------------------------------------------------------- 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 prastawa@cs.unc.edu Thu Dec 13 19:00:13 2001 From: prastawa@cs.unc.edu (Marcelinus Prastawa) Date: Thu, 13 Dec 2001 14:00:13 -0500 Subject: [Pythonmac-SIG] Numeric Problem & Carbon Problem In-Reply-To: Message-ID: This may not help at all... Could you check the value returned by time()? import time time.time() Marcel From lmeyn@mail.arc.nasa.gov Thu Dec 13 19:40:21 2001 From: lmeyn@mail.arc.nasa.gov (Larry Meyn) Date: Thu, 13 Dec 2001 11:40:21 -0800 Subject: [Pythonmac-SIG] Numeric Problem & Carbon Problem In-Reply-To: References: Message-ID: At 2:00 PM -0500 12/13/01, Marcelinus Prastawa wrote: >This may not help at all... > >Could you check the value returned by time()? >import time >time.time() > >Marcel > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig I think you hit upon the cause of the Numeric problem. MacPython 2.2b2 is returning a negative time. Outputs of your test for 2.2.2 and 2.2b2 are given below. Python 2.1.1 (#97, Aug 2 2001, 21:56:33) [CW CARBON GUSI2 THREADS] on mac Type "copyright", "credits" or "license" for more information. >>> import time >>> time.time() 3091088189.0 Python 2.2b2 (#116, Nov 27 2001, 23:37:30) [CW PPC GUSI2 THREADS GC] on mac Type "copyright", "credits" or "license" for more information. >>> import time >>> time.time() -1203879081.0 -- ---------------------------------------------------------------------- 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 jack@oratrix.nl Thu Dec 13 21:21:32 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 13 Dec 2001 22:21:32 +0100 Subject: [Pythonmac-SIG] Numeric Problem & Carbon Problem In-Reply-To: Message by Larry Meyn , Thu, 13 Dec 2001 11:40:21 -0800 , Message-ID: <20011213212137.CE4F7D720C@oratrix.oratrix.nl> Recently, Larry Meyn said: > I think you hit upon the cause of the Numeric problem. MacPython 2.2b2 is re > turning a negative time. Outputs of your test for 2.2.2 and 2.2b2 are given > below. Oops, this is probably caused by the new GUSI. Could you please file a bug report (for Python) at sourceforge? And give it a high (>7) priority, this should be fixed before 2.2. -- 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 lmeyn@mail.arc.nasa.gov Thu Dec 13 21:51:57 2001 From: lmeyn@mail.arc.nasa.gov (Larry Meyn) Date: Thu, 13 Dec 2001 13:51:57 -0800 Subject: [Pythonmac-SIG] Numeric Problem & Carbon Problem In-Reply-To: <20011213212137.CE4F7D720C@oratrix.oratrix.nl> References: <20011213212137.CE4F7D720C@oratrix.oratrix.nl> Message-ID: The bug has been submitted. As a follow up on the other problem (not being able to copy from the interpreter window,) I can't seem to repeat the problem, so it might not be an issue. At 10:21 PM +0100 12/13/01, Jack Jansen wrote: >Recently, Larry Meyn said: >> I think you hit upon the cause of the Numeric problem. MacPython 2.2b2 is re >> turning a negative time. Outputs of your test for 2.2.2 and 2.2b2 are given >> below. > >Oops, this is probably caused by the new GUSI. Could you please file a >bug report (for Python) at sourceforge? And give it a high (>7) >priority, this should be fixed before 2.2. >-- >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 > >_______________________________________________ >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 jack@oratrix.nl Fri Dec 14 21:32:47 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 14 Dec 2001 22:32:47 +0100 Subject: [Pythonmac-SIG] test_locale failing on Mac OS X - for everyone? Message-ID: <20011214213247.CF84EE8449@oratrix.oratrix.nl> Folks, in command-line Python, if I do "make test" test_locale is one of the tests that always fails. And, indeed, I have no /usr/shares/locales/en or en_US. Does this test fail for everyone, or are there people that see it succeed, and is this failing somehow related to my setup? -- 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 paul@fxtech.com Fri Dec 14 21:41:13 2001 From: paul@fxtech.com (Paul Miller) Date: Fri, 14 Dec 2001 15:41:13 -0600 Subject: [Pythonmac-SIG] EMBEDDED MacPython (Carbon) + OSX - should this work? In-Reply-To: <20011214213247.CF84EE8449@oratrix.oratrix.nl> Message-ID: <5.1.0.14.2.20011214153929.02ea5118@cedar.he.net> I have an app (a shared-lib actually) which links against PythonCoreCarbon that worked fine in Classic mode. But when trying to use this on OSX native it crashes (and I'm not sure why yet). Are there issues with embedded MacPython and OSX? Should I be preferring the native OSX version of Python for use in OSX? -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From jack@oratrix.nl Fri Dec 14 21:47:22 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 14 Dec 2001 22:47:22 +0100 Subject: [Pythonmac-SIG] EMBEDDED MacPython (Carbon) + OSX - should this work? In-Reply-To: Message by Paul Miller , Fri, 14 Dec 2001 15:41:13 -0600 , <5.1.0.14.2.20011214153929.02ea5118@cedar.he.net> Message-ID: <20011214214728.210A5E844B@oratrix.oratrix.nl> Recently, Paul Miller said: > I have an app (a shared-lib actually) which links against PythonCoreCarbon > that worked fine in Classic mode. But when trying to use this on OSX native > it crashes (and I'm not sure why yet). Are there issues with embedded > MacPython and OSX? Should I be preferring the native OSX version of Python > for use in OSX? It depends (doesn't it always:-). If your app (or shared library) is CFM-based then MacPython is the best choice, but if it is Mach-O based then unix-Python is better. As to why your app crashes: without further information there could be so many reasons that it's difficult to even guess. Start by looking in the console whether you see any messages. Then try running from the command line with a couple of dyld debugging environment variables defined (man dyld gives quite a few). Then try running under either the CodeWarrior debugger or gdb (but the lattter is tricky, see the notes in the developer docs on debugging CFM apps with gdb). -- 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 paul@fxtech.com Fri Dec 14 21:51:07 2001 From: paul@fxtech.com (Paul Miller) Date: Fri, 14 Dec 2001 15:51:07 -0600 Subject: [Pythonmac-SIG] EMBEDDED MacPython (Carbon) + OSX - should this work? In-Reply-To: <20011214214728.210A5E844B@oratrix.oratrix.nl> References: <5.1.0.14.2.20011214153929.02ea5118@cedar.he.net> Message-ID: <5.1.0.14.2.20011214154851.02ec2288@cedar.he.net> >It depends (doesn't it always:-). If your app (or shared library) is >CFM-based then MacPython is the best choice, but if it is Mach-O based >then unix-Python is better. Okay, you will have to forgive my ignorance - I'm new to OSX and not much of a "Mac guy" in the first place. What is CFM? If this means that the host app is OS9/OSX compliant (ie. Carbonized and OSX compatible), then yes. >As to why your app crashes: without further information there could be >so many reasons that it's difficult to even guess. Start by looking in I was able to run in CodeWarrior, and the crash seems to happen when my shared lib (which is really a plug-in into an OSX-compatible app) is dynamically loaded. At least, the crash stack seems to be down in some dl code. Does that help? -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From jack@oratrix.nl Fri Dec 14 22:07:22 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 14 Dec 2001 23:07:22 +0100 Subject: [Pythonmac-SIG] EMBEDDED MacPython (Carbon) + OSX - should this work? In-Reply-To: Message by Paul Miller , Fri, 14 Dec 2001 15:51:07 -0600 , <5.1.0.14.2.20011214154851.02ec2288@cedar.he.net> Message-ID: <20011214220727.A7C9AE844B@oratrix.oratrix.nl> Recently, Paul Miller said: > > >It depends (doesn't it always:-). If your app (or shared library) is > >CFM-based then MacPython is the best choice, but if it is Mach-O based > >then unix-Python is better. > > Okay, you will have to forgive my ignorance - I'm new to OSX and not much > of a "Mac guy" in the first place. What is CFM? If this means that the host > app is OS9/OSX compliant (ie. Carbonized and OSX compatible), then yes. Yep, that's CFM. OSX has two executable formats, CFM (which is OS9-compatible) and Mach-O (which is the native OSX format). > I was able to run in CodeWarrior, and the crash seems to happen when my > shared lib (which is really a plug-in into an OSX-compatible app) is > dynamically loaded. At least, the crash stack seems to be down in some dl cod > e. Hmm... If you can compile your plugin with debugging enabled and get a stacktrace with symbols that would probably help. I think the choices are now narrowed down to - There's something wrong with your init code - The CFM loader somehow can't find PythonCoreCarbon - The PythonCoreCarbon init code has a problem when loaded in your plugin on OSX. -- 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 sdm7g@Virginia.EDU Fri Dec 14 22:24:00 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Fri, 14 Dec 2001 17:24:00 -0500 (EST) Subject: [Pythonmac-SIG] EMBEDDED MacPython (Carbon) + OSX - should this work? In-Reply-To: <5.1.0.14.2.20011214154851.02ec2288@cedar.he.net> Message-ID: On Fri, 14 Dec 2001, Paul Miller wrote: > >It depends (doesn't it always:-). If your app (or shared library) is > >CFM-based then MacPython is the best choice, but if it is Mach-O based > >then unix-Python is better. > > Okay, you will have to forgive my ignorance - I'm new to OSX and not much > of a "Mac guy" in the first place. What is CFM? If this means that the host > app is OS9/OSX compliant (ie. Carbonized and OSX compatible), then yes. CFM is short for Code Fragment Manager, although I think PEF (which stands for Preferred Execution Format, I think.) might be more accurate: PEF is the object code format which CFM uses for PPC code. But CFM is usually used for shorthand to refer to the whole classic PPC runtime architecture: PEF & the API used for loading dynamic libs ( and sometimes things like the Mixed-Mode manager, for supporting both 68K and PPC code -- which didn't make it into Carbon. ). The other choice on OSX is mach-o, which is the native object format used for OSX's Darwin (BSD+mach) core. Also sometimes used as shorthand for the whole architecture it drags along with it (especially another set of API for dynamic libs, and tools like gcc and gdb. ) Classic apps are always CFM. Carbon apps can be CFM based (in which case they can also run on OS9), or mach-o (in which case they are OSX only.) Just like you could make Fat binaries for earlier systems, you can also build apps with both CFM and mach-o code (I think!) I think Cocoa apps are always built mach-o format because that the only format supported for the Cocoa libs (which don't have to be OS9 compatible.) Another orthogonal issue is how apps are packaged: Resource/Data forked files or Bundles. -- Steve Majewski From jorjun@mac.com Sat Dec 15 12:20:51 2001 From: jorjun@mac.com (Pete Moore) Date: Sat, 15 Dec 2001 12:20:51 +0000 Subject: [Pythonmac-SIG] Pygame on OS X : Anyone had success? In-Reply-To: Message-ID: <2DE872CF-F156-11D5-91CA-00039345EC58@mac.com> Been not too techy outside of my normal IBM midrange habitat, I am having trouble (yet again) getting it all together, I'll get there in the end with help :) I have the osx package :: http://www.libsdl.org/download-1.2.html But there is no pygame dist. for os x :: http://www.pygame.org/download.shtml From tony@metanet.com Sat Dec 15 18:52:22 2001 From: tony@metanet.com (Tony Lownds) Date: Sat, 15 Dec 2001 10:52:22 -0800 Subject: [Pythonmac-SIG] test_locale failing on Mac OS X - for everyone? In-Reply-To: <20011214213247.CF84EE8449@oratrix.oratrix.nl> References: <20011214213247.CF84EE8449@oratrix.oratrix.nl> Message-ID: It fails for me as well. I believe OSX doesn't have the necessary files to set any locales - there are no LC_NUMERIC or LC_CTYPE files in any subdir of /usr/share/locales/ -Tony At 10:32 PM +0100 12/14/01, Jack Jansen wrote: >Folks, >in command-line Python, if I do "make test" test_locale is one of the >tests that always fails. And, indeed, I have no /usr/shares/locales/en >or en_US. > >Does this test fail for everyone, or are there people that see it >succeed, and is this failing somehow related to my setup? >-- >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 asymmetrik@yahoo.com Sun Dec 16 16:45:55 2001 From: asymmetrik@yahoo.com (erik ryerson) Date: Sun, 16 Dec 2001 08:45:55 -0800 (PST) Subject: [Pythonmac-SIG] Scrap.GetScrap() no more? Message-ID: <20011216164555.92219.qmail@web13608.mail.yahoo.com> Hi. I was wondering what happened to GetScrap()? AttributeError: 'Scrap' module has no attribute 'GetScrap' I can PutScrap() and all other kinds of scrappyness... just need to know how to get content from my clipboard.. thanks. -e ===== ... . ... . ... . ... . ... . ... . erik ryerson asymmetrik@yahoo.com http://www.36invisible.com/ __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From jsw@cdc.noaa.gov Sun Dec 16 17:52:45 2001 From: jsw@cdc.noaa.gov (Jeff Whitaker) Date: Sun, 16 Dec 2001 10:52:45 -0700 (MST) Subject: [Pythonmac-SIG] 2.2c1 configure bug Message-ID: Hi: Found a small bug in the configure script for 2.2c1 that manifests itself on case-insensitive filesystems (like HFS+) when --with-suffix= is given, and is not set to ".exe". EXEEXT is set to (in my case "x") and BUILDEXEEXT is set to ".exe", leading to the following error during the install: /usr/bin/install -c python.exe /sw/src/root-python-unstable-2.2c1-1/sw/bin/python2.2x if test -f libpython2.2.so; then \ /usr/bin/install -c -m 644 libpython2.2.so /sw/src/root-python-unstable-2.2c1-1/sw/lib; \ else true; \ fi if test -f ""; then \ /usr/bin/install -c -m 555 /sw/src/root-python-unstable-2.2c1-1/sw/bin; \ else true; \ fi mkdir ./Lib/plat-darwin cp ./Lib/plat-generic/regen ./Lib/plat-darwin/regen export PATH; PATH="`pwd`:$PATH"; \ export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \ export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \ export EXE; EXE="x"; \ cd ./Lib/plat-darwin; ./regen python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h Traceback (most recent call last): File "../../Tools/scripts/h2py.py", line 24, in ? import sys, re, getopt, os File "/sw/src/python-unstable-2.2c1-1/Python-2.2c1/Lib/re.py", line 27, in ? from sre import * File "/sw/src/python-unstable-2.2c1-1/Python-2.2c1/Lib/sre.py", line 97, in ? import sre_compile File "/sw/src/python-unstable-2.2c1-1/Python-2.2c1/Lib/sre_compile.py", line 17, in ? assert _sre.MAGIC == MAGIC, "SRE module mismatch" AssertionError: SRE module mismatch make: *** [Lib/plat-darwin] Error 1 ### make failed, exit code 2 Failed: installing python-unstable-2.2c1-1 failed The only way to make it build correctly is to use --with-suffix=.exe, leaving --with-suffix out entirely doesn't work since EXEEXT is then null, and BUILDEXEEXT is still .exe. Seems like BUILDEXEEXT and EXEEXT need to be the same. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/CDC R/CDC1 Email : jsw@cdc.noaa.gov 325 Broadway Web : www.cdc.noaa.gov/~jsw Boulder, CO, USA 80303-3328 Office : Skaggs Research Cntr 1D-124 From sdm7g@Virginia.EDU Sun Dec 16 22:03:48 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Sun, 16 Dec 2001 17:03:48 -0500 (EST) Subject: [Pythonmac-SIG] 2.2c1 configure bug In-Reply-To: Message-ID: I assume this is on OSX your asking about. When I configured --with-suffix=.x, as I usually do, I saw that the executable got installed as 'python.exe'. ( I think the copy in the source directory was named 'python.x' ). I tried configure again without the --with-suffix switch, and it build it as 'python.exe', but installed it as '/usr/bin/python' . 2.2c1 seems to build and install properly without any switches -- it doesn't seem to need --with-dyld anymore either. The error message you're getting at the end looks like it's unconnected to the name or case sensitivity. ( But I'm not sure what it IS connected to! ) -- Steve Majewski From jsw@cdc.noaa.gov Sun Dec 16 22:38:24 2001 From: jsw@cdc.noaa.gov (Jeff Whitaker) Date: Sun, 16 Dec 2001 15:38:24 -0700 (MST) Subject: [Pythonmac-SIG] 2.2c1 configure bug In-Reply-To: Message-ID: On Sun, 16 Dec 2001, Steven Majewski wrote: > > I assume this is on OSX your asking about. Yep. > > When I configured --with-suffix=.x, as I usually do, I saw that the > executable got installed as 'python.exe'. ( I think the copy in the > source directory was named 'python.x' ). I tried configure again > without the --with-suffix switch, and it build it as 'python.exe', > but installed it as '/usr/bin/python' . I used suffix=x. python.exe got built, but there is no pythonx. Note in the output I attached the following lines: export EXE; EXE="x"; \ cd ./Lib/plat-darwin; ./regen python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' It's trying to uses pythonx, which doesn't exist in the build directory, but does exist is my old installation. So, it's using python2.1, hence the module mismatch error. If I use suffix=.exe it works fine. If I leave out --with-suffix altogether, same story - no python in build directory, so it uses the symlink I have already installed, which points to the python2.1 executable. So, I really do think it is a configure bug. BUILDEXEEXT and EXEEXT must be the same, but BUILDEXEEXT now always gets set to .exe on HFS+ systems, and EXEEXT is set to whatever --with-suffix provides. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/CDC R/CDC1 Email : jsw@cdc.noaa.gov 325 Broadway Web : www.cdc.noaa.gov/~jsw Boulder, CO, USA 80303-3328 Office : Skaggs Research Cntr 1D-124 From jeff.harmon@adobe.com Mon Dec 17 17:22:10 2001 From: jeff.harmon@adobe.com (Jeff Harmon) Date: Mon, 17 Dec 2001 09:22:10 -0800 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #925 - 9 msgs In-Reply-To: Message-ID: on 12/15/01 09:01 AM, pythonmac-sig-request@python.org wrote: > I was able to run in CodeWarrior, and the crash seems to happen when my > shared lib (which is really a plug-in into an OSX-compatible app) is > dynamically loaded. At least, the crash stack seems to be down in some dl > code. That smells like an exception triggered by a ctor triggered by a global instance of some class. Just a thought, JR From jeff.harmon@adobe.com Tue Dec 18 17:26:17 2001 From: jeff.harmon@adobe.com (Jeff Harmon) Date: Tue, 18 Dec 2001 09:26:17 -0800 Subject: [Pythonmac-SIG] ConfigurePythonCarbon pukes on OS X.1 Message-ID: Anyone know what these symptoms from ConfigurePythonCarbon are trying to tell me? 1) Download and run the Python 2.1.1 or 2.2b2 carbon kits on OS X.1; 2) Watch as the Installer mentions that "the config tool will likely die when I sublaunch it on OS X" (it does); 3) Jump back to Finder and manually launch the (carbon) config tool; 4) Watch as the tool stops responding while "Creating PythonCore aliases..." The Console receives a number of... GUSI: (fLocked > 0) -- assertion failed. ...messages just prior to the config tool's death. I've tried both MacPython distributions (211/22b2) under my admin accouunt and root without success. Now I'm officially stuck awaiting your esteemed assistance. Happy Holidays, JR PS - 211 runs fine if I boot into with 9.x (although I haven't managed to get the build environment/dependencies settled down enough to directly build it). From aparente@adobe.com Tue Dec 18 17:57:54 2001 From: aparente@adobe.com (Alexandre Parenteau) Date: Tue, 18 Dec 2001 09:57:54 -0800 Subject: [Pythonmac-SIG] Re: ConfigurePythonCarbon pukes on OS X.1 In-Reply-To: Message-ID: > Anyone know what these symptoms from ConfigurePythonCarbon are trying to > tell me? > > 1) Download and run the Python 2.1.1 or 2.2b2 carbon kits on OS X.1; > 2) Watch as the Installer mentions that "the config tool will likely die > when I sublaunch it on OS X" (it does); > 3) Jump back to Finder and manually launch the (carbon) config tool; > 4) Watch as the tool stops responding while "Creating PythonCore aliases..." > > The Console receives a number of... > > GUSI: (fLocked > 0) -- assertion failed. This is a known bug of GUSI on OSX. Jack and I have tried to push for Matthias Neeracher to help us out with this problem. Jack, did you have news from Matthias on that subject ? I would think this needs to be fixed for 2.2 RC, because MacPython is not usable on OSX because of that. If only I knew where to put the critical section needed by GUSI... Sigh... Alex. > > ...messages just prior to the config tool's death. > > I've tried both MacPython distributions (211/22b2) under my admin accouunt > and root without success. Now I'm officially stuck awaiting your esteemed > assistance. > > Happy Holidays, > JR > > PS - 211 runs fine if I boot into with 9.x (although I haven't managed to > get the build environment/dependencies settled down enough to directly build > it). > -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From jeff.harmon@adobe.com Tue Dec 18 21:49:51 2001 From: jeff.harmon@adobe.com (Jeff Harmon) Date: Tue, 18 Dec 2001 13:49:51 -0800 Subject: [Pythonmac-SIG] Is it just me or...? Message-ID: Uncle! Uncle! Uncle! I've spent the better part of two days now trying to get MacPython (the CFM app distribution not the command line interpreter) to install and run natively on OS X (I'm running 10.1.1). Is it just something I'm not doing or is this a futile process (i.e., it is know not to run)? I have the PPC command line interpreter Python running fine but need to know in a conclusive fashion (for reasons I can't explain here) if MacPython will work in OS X too. It (MacPython) runs fine in OS 9. Please advise, JR From cjl@physics.otago.ac.nz Wed Dec 19 04:16:46 2001 From: cjl@physics.otago.ac.nz (Chris Lee) Date: Wed, 19 Dec 2001 17:16:46 +1300 Subject: [Pythonmac-SIG] Large number sets on MacPython (Carbon) Message-ID: <7D1C13.11102E.13E6AB.Nisus.ID@physics.otago.ac.nz> Hi All, I have just installed MacPython on OS X and converted my unix scripts over. = These scripts deal with large matrix calculations. Unfortunately I find = that when I drop one of these scripts on the interpreter I get a Math range = error but I don't seem to get that when running from the IDE. What I really want to do is drop several of these scripts on the = interpreter and leave them to run in background will the interpreter do = this? Sorry if I am covering well covered ground Cheers Chris= From cjl@physics.otago.ac.nz Wed Dec 19 04:16:51 2001 From: cjl@physics.otago.ac.nz (Chris Lee) Date: Wed, 19 Dec 2001 17:16:51 +1300 Subject: [Pythonmac-SIG] Large number sets on MacPython (Carbon) Message-ID: <7D1C13.111033.13E7B8.Nisus.ID@physics.otago.ac.nz> Hi All, I have just installed MacPython on OS X and converted my unix scripts over. = These scripts deal with large matrix calculations. Unfortunately I find = that when I drop one of these scripts on the interpreter I get a Math range = error but I don't seem to get that when running from the IDE. What I really want to do is drop several of these scripts on the = interpreter and leave them to run in background will the interpreter do = this? Sorry if I am covering well covered ground Cheers Chris= From jack@oratrix.nl Wed Dec 19 09:20:13 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 19 Dec 2001 10:20:13 +0100 Subject: [Pythonmac-SIG] Is it just me or...? In-Reply-To: Message by Jeff Harmon , Tue, 18 Dec 2001 13:49:51 -0800 , Message-ID: <20011219092013.CF769303183@snelboot.oratrix.nl> > I've spent the better part of two days now trying to get MacPython (the CFM > app distribution not the command line interpreter) to install and run > natively on OS X (I'm running 10.1.1). Is it just something I'm not doing > or is this a futile process (i.e., it is know not to run)? There are some problems with MacPython on MacOS X. For one thing, it does not currently work on a MacOSX multiprocessor. And, since 10.1, it does not work on all single-processors anymore either. For some people (like myself) ti works fine, for others it doesn't. We are working hard to resolve this issue, but it now looks that it won't be solved before 2.2 :-( I will probably do a 2.2.1 release when it is solved. But, just to make sure that you're not seeing a different issue: could you post the symptoms you see when you try to use MacPython on OSX? -- 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 jack@oratrix.nl Wed Dec 19 09:30:33 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 19 Dec 2001 10:30:33 +0100 Subject: [Pythonmac-SIG] Large number sets on MacPython (Carbon) In-Reply-To: Message by "Chris Lee" , Wed, 19 Dec 2001 17:16:46 +1300 , <7D1C13.11102E.13E6AB.Nisus.ID@physics.otago.ac.nz> Message-ID: <20011219093033.3801D303183@snelboot.oratrix.nl> > = > Hi All, > = > I have just installed MacPython on OS X and converted my unix scripts o= ver. > These scripts deal with large matrix calculations. Unfortunately I fi= nd that > when I drop one of these scripts on the interpreter I get a Math range = error > but I don't seem to get that when running from the IDE. This is definitely not well-covered ground, I can think of absolutely no = reason why math behaviour would be different under the raw interpreter th= an = under the IDE. If this behaviour is easy to reproduce, could you send me a script that s= hows = it? Oh yes: you are indeed dropping your script on the PythonInterpreter, you= 're = not running it with the commandline python interpreter? (Because that is = a = completely different beast inside than the IDE, so there I could well ima= gine = differrent behaviour for math boundary cases). -- 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 just@letterror.com Wed Dec 19 08:56:25 2001 From: just@letterror.com (Just van Rossum) Date: Wed, 19 Dec 2001 09:56:25 +0100 Subject: [Pythonmac-SIG] Is it just me or...? In-Reply-To: <20011219092013.CF769303183@snelboot.oratrix.nl> Message-ID: <20011219095629-r01010800-9ecea7d5-0922-010c@10.0.0.23> Jack Jansen wrote: > > > I've spent the better part of two days now trying to get MacPython (the CFM > > app distribution not the command line interpreter) to install and run > > natively on OS X (I'm running 10.1.1). Is it just something I'm not doing > > or is this a futile process (i.e., it is know not to run)? > > There are some problems with MacPython on MacOS X. For one thing, it does not > currently work on a MacOSX multiprocessor. And, since 10.1, it does not work > on all single-processors anymore either. For some people (like myself) ti > works fine, for others it doesn't. > > We are working hard to resolve this issue, but it now looks that it won't be > solved before 2.2 :-( I will probably do a 2.2.1 release when it is solved. > > But, just to make sure that you're not seeing a different issue: could you > post the symptoms you see when you try to use MacPython on OSX? Is the problem more this installer, or MacPython itself? I haven't used the installer under 10.1, yet I use MacPython every day. Ok, this is not quite fair, I built it from the source, with lots of help from Jack. Maybe the installer screws things up? Just From jack@oratrix.nl Wed Dec 19 10:15:12 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 19 Dec 2001 11:15:12 +0100 Subject: [Pythonmac-SIG] Is it just me or...? In-Reply-To: Message by Just van Rossum , Wed, 19 Dec 2001 09:56:25 +0100 , <20011219095629-r01010800-9ecea7d5-0922-010c@10.0.0.23> Message-ID: <20011219101512.27BDB303183@snelboot.oratrix.nl> > > There are some problems with MacPython on MacOS X. For one thing, it does not > > currently work on a MacOSX multiprocessor. And, since 10.1, it does not work > > on all single-processors anymore either. For some people (like myself) ti > > works fine, for others it doesn't. > > > > We are working hard to resolve this issue, but it now looks that it won't be > > solved before 2.2 :-( I will probably do a 2.2.1 release when it is solved. > > > > But, just to make sure that you're not seeing a different issue: could you > > post the symptoms you see when you try to use MacPython on OSX? > > Is the problem more this installer, or MacPython itself? I haven't used the > installer under 10.1, yet I use MacPython every day. Ok, this is not quite fair, > I built it from the source, with lots of help from Jack. Maybe the installer > screws things up? Hmm, that's also a possibility. I was thinking that it was a problem to do with machine type. Maybe we can have a heads-up on who has problems with OSX and who doesn't, and what their hardware is? Here goes: Deskside G4, 450Mhz, 10.1.1 - No problems iBook (old), 350Mhz, 10.1.1 - No problems -- 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 just@letterror.com Wed Dec 19 10:20:41 2001 From: just@letterror.com (Just van Rossum) Date: Wed, 19 Dec 2001 11:20:41 +0100 Subject: [Pythonmac-SIG] Is it just me or...? In-Reply-To: <20011219101512.27BDB303183@snelboot.oratrix.nl> Message-ID: <20011219112044-r01010800-5b429e08-0922-010c@10.0.0.23> Jack Jansen wrote: > Here goes: > Deskside G4, 450Mhz, 10.1.1 - No problems > iBook (old), 350Mhz, 10.1.1 - No problems PB G4, 400 Mhz, 10.1.1 - No problems (But I do see some GUSI blurb showing up in the console every now and then.) Just From tbrumley@mac.com Wed Dec 19 13:04:42 2001 From: tbrumley@mac.com (Troy Brumley) Date: Wed, 19 Dec 2001 08:04:42 -0500 Subject: [Pythonmac-SIG] Is it just me or...? In-Reply-To: <20011219112044-r01010800-5b429e08-0922-010c@10.0.0.23> Message-ID: On Wednesday, December 19, 2001, at 05:20 AM, Just van Rossum wrote: > Jack Jansen wrote: > >> Here goes: >> Deskside G4, 450Mhz, 10.1.1 - No problems >> iBook (old), 350Mhz, 10.1.1 - No problems > > PB G4, 400 Mhz, 10.1.1 - No problems iMac DV SE 500Mhz, 10.1.1 - No problems that I know of, I can run most of the tests but haven't tried much else. Debugger comes up fine when I tried to see what was wrong in the socket test. > > (But I do see some GUSI blurb showing up in the console every now and > then.) > > Just > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From paul@fxtech.com Wed Dec 19 14:41:10 2001 From: paul@fxtech.com (Paul Miller) Date: Wed, 19 Dec 2001 08:41:10 -0600 Subject: [Pythonmac-SIG] Is it just me or...? In-Reply-To: <20011219092013.CF769303183@snelboot.oratrix.nl> References: Message-ID: <5.1.0.14.2.20011219083930.02738480@cedar.he.net> >But, just to make sure that you're not seeing a different issue: could you >post the symptoms you see when you try to use MacPython on OSX? The interpreter works for me on OSX (10.1), but when I try to load a shared lib that is linked against PythonCoreCarbon, I get a fatal error. Also, I can't run the Python Prefs utility. Jeff - is this similar to the problem you're having? Since you're here, I'm seeing it when my AE plug-in (which is linked against Python) is dynamically loaded by AE. -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From trace@reinventnow.com Wed Dec 19 17:23:08 2001 From: trace@reinventnow.com (tracy shaun ruggles) Date: Wed, 19 Dec 2001 11:23:08 -0600 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs In-Reply-To: Message-ID: on 01.12.19 11:01 AM, Jack Jansen wrote: >> Is the problem more this installer, or MacPython itself? I haven't used the >> installer under 10.1, yet I use MacPython every day. Ok, this is not quite >> fair, >> I built it from the source, with lots of help from Jack. Maybe the installer >> screws things up? > > Hmm, that's also a possibility. I was thinking that it was a problem to do > with machine type. > > Maybe we can have a heads-up on who has problems with OSX and who doesn't, and > what their hardware is? > > Here goes: > Deskside G4, 450Mhz, 10.1.1 - No problems > iBook (old), 350Mhz, 10.1.1 - No problems For me: ibook (old), 366MHz, 10.1.1 - No problems --Tracy -- Tracy S. Ruggles :: tracy @ reinventnow.com From jorjun@mac.com Wed Dec 19 17:33:21 2001 From: jorjun@mac.com (Pete Moore) Date: Wed, 19 Dec 2001 17:33:21 +0000 Subject: [Pythonmac-SIG] 2.2b2 Mac OS X 10.1.1, iBook, worked no prob. Message-ID: <7F81EBF5-F4A6-11D5-8238-00039345EC58@mac.com> From bobsavage@mac.com Wed Dec 19 21:34:37 2001 From: bobsavage@mac.com (Bob Savage) Date: Wed, 19 Dec 2001 15:34:37 -0600 Subject: [Pythonmac-SIG] heads-up In-Reply-To: Message-ID: > Maybe we can have a heads-up on who has problems with OSX and who doesn't, and > what their hardware is? iBook (newish), 500MHZ, 10.1.1 - No problems here Bob From jeff.harmon@adobe.com Wed Dec 19 22:32:26 2001 From: jeff.harmon@adobe.com (Jeff Harmon) Date: Wed, 19 Dec 2001 14:32:26 -0800 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs In-Reply-To: Message-ID: on 12/19/01 09:01 AM, pythonmac-sig-request@python.org wrote: > But, just to make sure that you're not seeing a different issue: could you > post the symptoms you see when you try to use MacPython on OSX? Here is a summary of what I've encountered. The machine in question is a dual500 (g4) (with gobs o' RAM and perty much all the fix'ns). It's running a fully current (as of yesterday) 10.1.1 that started from an "consumer boxed" 10. I work for Adobe, btw. I'm sure you've seen a lot of traffic from some of us later since were thinking of adopting Python for some internal use. The jury is still out... I've downloaded both "full" distributions (2.1x and 2.2x), run the installer, got the the "I'll bet the cofg tool will puke" message, watched the config tool puke, quit the installer, launch the config tool directly, watch as the config tool stops dead in its tracks at the point mentioned in a previous email (GUSI fLocked > 0). Failing that I drug my know good MacPython (carbon of course) 211 dist from my 9.1 TiBook to the dual. The interpreter launches (and more or less appears to run) but has bogus (as wrong bad not corrupt) data in sys.path. As a result it can't find anything and bitches when it tries to load, err... import site and macfsn. If I hack sys.path at runtime it seems to work but I still don't know enough about the "world of python" (only been doing this for a week so far) to know if there are other init things that never went off when it bailed after failing to find macfsn. The questions I'm trying to track down at present is where does MacPython acquire the data it writes into sys.path. (what file, etc.), what (specifically) does the config tool do (so I can attempt to replicate it's effect manually) and what does MacPython do at launch (execution sequence, first files, etc.)? An alternative thought I have to work on is "how hard will it be to glue the OS X CL interpreter (not MacPython) to PEF a gaggle of libs?" It looks doable but I've never traveled this road before. Any expertise you can add or light you can shed would be VERY, VERY welcome. Cheers! JR From jeff.harmon@adobe.com Wed Dec 19 22:44:23 2001 From: jeff.harmon@adobe.com (Jeff Harmon) Date: Wed, 19 Dec 2001 14:44:23 -0800 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs In-Reply-To: Message-ID: on 12/19/01 09:01 AM, pythonmac-sig-request@python.org wrote: > The interpreter works for me on OSX (10.1), but when I try to load a shared > lib that is linked against PythonCoreCarbon, I get a fatal error. Also, I > can't run the Python Prefs utility. I haven't gotten to a point of stability where I can see if I can use any glued DLLs. OBTW - Jack!!! Both the MacPython IDE and Interpreter fail for the same reasons but the IDE leaves me without access to a prompt so I can't hack/recover after I "die" there. The interpreter shows me a command prompt (if I return) at the point of failure so I can hack that one and get macfsn to import, etc. after editing sys.path[]. > Jeff - is this similar to the problem you're having? Since you're here, I'm > seeing it when my AE plug-in (which is linked against Python) is > dynamically loaded by AE. Sounds very similar. JR From jack@oratrix.nl Wed Dec 19 22:54:59 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 19 Dec 2001 23:54:59 +0100 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs In-Reply-To: Message by Jeff Harmon , Wed, 19 Dec 2001 14:32:26 -0800 , Message-ID: <20011219225504.D8914E844A@oratrix.oratrix.nl> Recently, Jeff Harmon said: > on 12/19/01 09:01 AM, pythonmac-sig-request@python.org wrote: > > > But, just to make sure that you're not seeing a different issue: could you > > post the symptoms you see when you try to use MacPython on OSX? > > Here is a summary of what I've encountered. The machine in question is a > dual500 (g4) (with gobs o' RAM and perty much all the fix'ns). It's running > a fully current (as of yesterday) 10.1.1 [...] This is the known problem I was referring to. Sorry, but MacPython does not currently run on OSX multiprocessors, it will hang almost immedeately. This will most likely not be fixed before 2.2, but a maintainance release will be forthcoming as soon as the problem is fixed. We more-or-less know where the problem lies, but unfortunately the only person who can fix it appears to be very busy. In the mean time you can either use MacPython in classic mode or use (for some applications) unix-Python from the commandline. -- 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 sdm7g@Virginia.EDU Thu Dec 20 02:29:06 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Wed, 19 Dec 2001 21:29:06 -0500 (EST) Subject: [Pythonmac-SIG] Is it just me or...? In-Reply-To: Message-ID: On Wed, 19 Dec 2001, Troy Brumley wrote: > > On Wednesday, December 19, 2001, at 05:20 AM, Just van Rossum wrote: > > > Jack Jansen wrote: > > > >> Here goes: > >> Deskside G4, 450Mhz, 10.1.1 - No problems > >> iBook (old), 350Mhz, 10.1.1 - No problems > > > > PB G4, 400 Mhz, 10.1.1 - No problems > > iMac DV SE 500Mhz, 10.1.1 - No problems that I know of, I can run most > of the tests but haven't tried much else. Debugger comes up fine when I > tried to see what was wrong in the socket test. > 500 mHz Blue&White G3 OSX 10.1.1 installed MacPython2.2b2.full, ran EasyDialogs.test() and test.testall from PythonInterpreter and ran Module Browser from Python IDE with no problems. 300 mHz iBook OSX 10.1.1 When I double clicked on the installer, not much of anything happened. Maybe there was a problem with the download? I copied the installed from the other machine and it worked. (all the same tests) -- Steve From dp@ulaluma.com Thu Dec 20 07:08:30 2001 From: dp@ulaluma.com (Donovan Preston) Date: Wed, 19 Dec 2001 23:08:30 -0800 Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! Message-ID: <5F87C316-F518-11D5-A672-000502EE274C@ulaluma.com> Well, since I noticed Jack had gotten the WASTE module compiling and linking under command-line Mach-O Python in the CVS, I decided to take another stab at getting the IDE up and running as a Mach-O bundle. After downloading WASTE, putting it in the right place (as mentioned in the comment in setup.py in CVS) and running ranlib on the libWASTE.a file, I was able to get the WASTE module to compile and link. So far so good. Then, I dropped PythonIDEMain.py on the Python.app. Error on MacOS.EnableAppSwitch. No problem, just comment it out. I was able to get as far as macresource.need before having tough problems. It turns out that while os.path.join and the like create '/asdf/zxcv/wqr' slash delimited strings, the code that converts a python string into a C FSRef (? or FSSpec?) needs ':' delimited strings. Or the Carbon library itself needs colon delimited strings. I didn't look into it too much except to determine that slash delimited path strings were the problem. Anyway, I wrote an awful hack in macresource.py that converts any slash delimited paths to colon delimited and allows the IDE to get up and running!!! There are caveats, however. I had to comment out quite a few more MacOS.EnableAppSwitch calls as well as the call that installs the Console and Output windows in the IDE. But I only worked on it for about an hour, and already, I can create new python files, execute them (output goes to the Console application), use the module browser, see nice traceback windows, and bring up a post-mortem debugger! Awesome. Screenshots are available at http://www.ulaluma.com/pyx/ Just, here's the ugly, ugly hack to macresource.py that got me going down the path towards things working (Lots more commentings-out were required, however): [localhost:src/Mac/Lib] dsp% cvs diff -c macresource.py Index: macresource.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Lib/macresource.py,v retrieving revision 1.3 diff -c -r1.3 macresource.py *** macresource.py 2001/08/30 21:19:42 1.3 --- macresource.py 2001/12/20 07:02:30 *************** *** 54,67 **** searchdirs = sys.path # And look for the file for dir in searchdirs: ! pathname = os.path.join(dir, filename) if os.path.exists(pathname): break else: ! raise ResourceFileNotFoundError, filename ! refno = Res.FSpOpenResFile(pathname, 1) # And check that the resource exists now if type(resid) is type(1): --- 54,80 ---- searchdirs = sys.path # And look for the file + import string + print "filename:",filename + splt = filename.split(':') + splt = [x for x in splt if x] + fn = string.join(splt, '/') for dir in searchdirs: ! print "yo:", dir, fn ! pathname = os.path.join(dir, fn) if os.path.exists(pathname): + print "exist",pathname break else: ! print pathname ! raise ResourceFileNotFoundError, fn ! print pathname ! foo = pathname.split('/') ! foo[0] = 'MacOSX' # my root hard drive name ! newpth = string.join(foo, ':') ! print newpth ! refno = Res.FSpOpenResFile(newpth, 1) # And check that the resource exists now if type(resid) is type(1): From jack@oratrix.nl Thu Dec 20 10:49:15 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 20 Dec 2001 11:49:15 +0100 Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! In-Reply-To: Message by Donovan Preston , Wed, 19 Dec 2001 23:08:30 -0800 , <5F87C316-F518-11D5-A672-000502EE274C@ulaluma.com> Message-ID: <20011220104915.81CCA303183@snelboot.oratrix.nl> Donovan, hats off!! Especially for just hacking your way along and showing that everything at least works in principle. I had also commented out the EnableAppSwitches, or actually replace them with if hasattr(MacOS, 'EnableAppSwitch'): MacOS.EnableAppSwitch(....) and then I got bogged down in macresource.py. After an hour or so I had to leave the project because 2.2 is due (and IDE won't make it, I'm afraid). A couple of random thoughts: - Should I add a dummy EnableAppSwitch() to MachoPython, or is the hasattr construction good enough? - macresource.py needs work, any takers? What I have in mind is that it allows you to open resource files in both MacPython and MachoPython. There are two problems it needs to solve. One is the pathname problem, for which there's also a solution that is less hacky than what Donovan has done (if the pathname is the wrong type convert to URL and then back to the other type pathname). The other problem is that if you have a Unix Python distribution the .rsrc files are not actually resource files but MacBinary encoded resource files. My idea was to unpack these on the fly, something like if exists(name.df.rsrc) and timestamp(name.df.rsrc) > timestamp(name.rsrc): open-datafork-resource-file(name.df.rsrc) elif has_resource_fork(name.rsrc): open-resource-file(name.rsrc) else: macbinary.decode(name.rsrc, name.df.rsrc, resource_only=1) open-datafork-resource-file(name.df.rsrc) - I think the macfs pathname calls should use native pathnames (i.e. unix-style pathnames in MachoPython). What do other people think? Should I add an optional parameter with which you can override the pathname style, as in fsr = macfs.FSRef('mac:style:pathname', 'mac') fsr = macfs.FSRef('/unix/style/pathname', 'unix') -- 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 jack@oratrix.nl Thu Dec 20 11:09:42 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 20 Dec 2001 12:09:42 +0100 Subject: [Pythonmac-SIG] MacPython 2.2c1 available Message-ID: <20011220110942.E07B2303183@snelboot.oratrix.nl> Folks, MacPython 2.2c1 is available via http://www.cwi.nl/~jack/macpython.html . This is a final candidate for MacPython 2.2, which is due this weekend, so please send any feedback to pythonmac-sig@python.org as soon as possible. The main differences with the last beta release are that this MacPython should now run on old systems again (from MacOS 8.1 onwards), and that the MacOS toolbox interface modules have been updated to Universal Headers 3.4. While neither of these should pose compatibility problems there's always the chance that something silly happened, so please give this release a try. As usual, it won't interfere with your normal Python: different pathnames, prefs files, etc, so there shouldn't be much trouble trying this and then going back to your usual MacPython release. -- 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 paul@fxtech.com Thu Dec 20 18:35:17 2001 From: paul@fxtech.com (Paul Miller) Date: Thu, 20 Dec 2001 12:35:17 -0600 Subject: [Pythonmac-SIG] more on MacPython/OSX/shared lib In-Reply-To: References: Message-ID: <5.1.0.14.2.20011220123049.0221e520@cedar.he.net> > > Jeff - is this similar to the problem you're having? Since you're here, I'm > > seeing it when my AE plug-in (which is linked against Python) is > > dynamically loaded by AE. > >Sounds very similar. This is what happens in the debugger when I try to load my plug-in (which is linked against PythonCoreCarbon): I get an "access fault" error. The stack trace has a bunch of CarbonCore entries, then several [unknown] entries, then CoreFoundation, then libSystem.b.dylib, and that's it. My next step is to remove all my Python code and see if I get the error without linking against Python. All this works in Classic and OS9 of course. -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From paul@fxtech.com Thu Dec 20 19:28:38 2001 From: paul@fxtech.com (Paul Miller) Date: Thu, 20 Dec 2001 13:28:38 -0600 Subject: [Pythonmac-SIG] more on MacPython/OSX/shared lib In-Reply-To: <5.1.0.14.2.20011220123049.0221e520@cedar.he.net> References: Message-ID: <5.1.0.14.2.20011220132600.02149470@cedar.he.net> >This is what happens in the debugger when I try to load my plug-in (which >is linked against PythonCoreCarbon): >My next step is to remove all my Python code and see if I get the error >without linking against Python. Back to square 1 for me. I removed the Python lib and all my Python code and I have the same problem. It must be something in global initialization in my own code. For yucks I disabled the __initialize and __terminate entry points in the linker options and I ended up with an assert in my code (which was expecting the static initializations to happen). Does anyone have any idea why static initializations would cause my shared lib to die in OSX when it works fine in OS9.2? Can anyone tell me how to set a breakpoint in __initialize so I can step around and see what it is doing? Cheers! -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From jack@oratrix.nl Thu Dec 20 20:27:36 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 20 Dec 2001 21:27:36 +0100 Subject: [Pythonmac-SIG] more on MacPython/OSX/shared lib In-Reply-To: Message by Paul Miller , Thu, 20 Dec 2001 13:28:38 -0600 , <5.1.0.14.2.20011220132600.02149470@cedar.he.net> Message-ID: <20011220202741.CD989E8453@oratrix.oratrix.nl> Recently, Paul Miller said: > >My next step is to remove all my Python code and see if I get the error > >without linking against Python. > > Back to square 1 for me. I removed the Python lib and all my Python code > and I have the same problem. It must be something in global initialization > in my own code. For yucks I disabled the __initialize and __terminate entry > points in the linker options and I ended up with an assert in my code > (which was expecting the static initializations to happen). Hmm, my guess would be either a bug in CodeWarrior, or (probably more likely) you using the wrong runtime library. Especially if you use C++ you have to be careful with which runtime library you use where, because the zero-overhead exception handling will fail otherwise. And you shouldn't use Python as an example, because it doesn't follow the rules (but gets away with it being a C program). You might want to spell out the MW Targeting MacOS manual. -- 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 paul@fxtech.com Thu Dec 20 20:31:41 2001 From: paul@fxtech.com (Paul Miller) Date: Thu, 20 Dec 2001 14:31:41 -0600 Subject: [Pythonmac-SIG] more on MacPython/OSX/shared lib In-Reply-To: <20011220202741.CD989E8453@oratrix.oratrix.nl> References: <5.1.0.14.2.20011220132600.02149470@cedar.he.net> Message-ID: <5.1.0.14.2.20011220143046.0230c608@cedar.he.net> >Hmm, my guess would be either a bug in CodeWarrior, or (probably more >likely) you using the wrong runtime library. Especially if you use C++ >you have to be careful with which runtime library you use where, >because the zero-overhead exception handling will fail otherwise. And >you shouldn't use Python as an example, because it doesn't follow the >rules (but gets away with it being a C program). You might want to >spell out the MW Targeting MacOS manual. That's what I thought, but how much harder does it get than to link with MSL_All_Carbon and CarbonLib? -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From dp@ulaluma.com Thu Dec 20 20:34:05 2001 From: dp@ulaluma.com (Donovan Preston) Date: Thu, 20 Dec 2001 12:34:05 -0800 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs In-Reply-To: Message-ID: --Apple-Mail-1-508474735 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Wednesday, December 19, 2001, at 02:32 PM, Jeff Harmon wrote: Here is a summary of what I've encountered. The machine in question is a dual500 (g4) (with gobs o' RAM and perty much all the fix'ns). It's running a fully current (as of yesterday) 10.1.1 that started from an "consumer boxed" 10. I work for Adobe, btw. I'm sure you've seen a lot of traffic from some of us later since were thinking of adopting Python for some internal use. The jury is still out... I've held off on contributing to this discussion, but I'm going to try to shed some more light into the dark corners of MacPython and hopefully help you out. On OS 9 and before, the mac os had no built-in facility for handling stdio and therefore replacement libraries needed to be written to gain this functionality. The library in question is GUSI, the Grand Unified Socket Interface, which replaced much of the socket-based I/O behavior needed to port stdio-using apps to the Mac. Unfortunately, GUSI was programmed with some assumptions about the innards of the OS taken for granted. One of those assumptions was that once an I/O completion callback was called at interrupt time, it would not be interrupted until the routine had finished. On OS X, however, this assumption no longer holds true. Any time an I/O completion callback is called (which tries to set a flag to let the main macpython thread know that some IO happened), MacPython enters a race condition hoping that function doesn't get preempted until it finishes. On single processor machines, it's not as much of an issue (it seems to have been exaggerated by 10.1, however) but on dual processor machines, it seems the exceptional condition is almost always reached. So what can be done about it? OS X already has an implementation of socket-based IO -- it's called BSD. :-) And OS X already has a Python which will compile to use it -- command line Python. What OS X Python is missing, therefore, is the IDE running on top of the command-line Python binary. Stay tuned, hopefully we'll have it soon. See my message about Mach-O MacPython IDE if you're interested in knowing more. first files, etc.)? An alternative thought I have to work on is "how hard will it be to glue the OS X CL interpreter (not MacPython) to PEF a gaggle of libs?" It looks doable but I've never traveled this road before. That will definitely be the route you will be taking. There should be docs and sample code on Apple's dev web site about how to call a CFM (PEF) library from a Mach-O binary. It's possible. I unfortunately can't tell you exactly how to do it. Good luck. If you decide to try to execute code stored in a CFM library from Mach-O Python, I'd be interested. This will probably be something I will need to do in order to use CFM VST plugins in the Mach-O based app I am writing. Donovan --Apple-Mail-1-508474735 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII On Wednesday, December 19, 2001, at 02:32 PM, Jeff Harmon wrote: 0000,0000,DEDE Here is a summary of what I've encountered. The machine in question is a dual500 (g4) (with gobs o' RAM and perty much all the fix'ns). It's running a fully current (as of yesterday) 10.1.1 that started from an "consumer boxed" 10. I work for Adobe, btw. I'm sure you've seen a lot of traffic from some of us later since were thinking of adopting Python for some internal use. The jury is still out... I've held off on contributing to this discussion, but I'm going to try to shed some more light into the dark corners of MacPython and hopefully help you out. On OS 9 and before, the mac os had no built-in facility for handling stdio and therefore replacement libraries needed to be written to gain this functionality. The library in question is GUSI, the Grand Unified Socket Interface, which replaced much of the socket-based I/O behavior needed to port stdio-using apps to the Mac. Unfortunately, GUSI was programmed with some assumptions about the innards of the OS taken for granted. One of those assumptions was that once an I/O completion callback was called at interrupt time, it would not be interrupted until the routine had finished. On OS X, however, this assumption no longer holds true. Any time an I/O completion callback is called (which tries to set a flag to let the main macpython thread know that some IO happened), MacPython enters a race condition hoping that function doesn't get preempted until it finishes. On single processor machines, it's not as much of an issue (it seems to have been exaggerated by 10.1, however) but on dual processor machines, it seems the exceptional condition is almost always reached. So what can be done about it? OS X already has an implementation of socket-based IO -- it's called BSD. :-) And OS X already has a Python which will compile to use it -- command line Python. What OS X Python is missing, therefore, is the IDE running on top of the command-line Python binary. Stay tuned, hopefully we'll have it soon. See my message about Mach-O MacPython IDE if you're interested in knowing more. 0000,0000,DEDEfirst files, etc.)? An alternative thought I have to work on is "how hard will it be to glue the OS X CL interpreter (not MacPython) to PEF a gaggle of libs?" It looks doable but I've never traveled this road before. That will definitely be the route you will be taking. There should be docs and sample code on Apple's dev web site about how to call a CFM (PEF) library from a Mach-O binary. It's possible. I unfortunately can't tell you exactly how to do it. Good luck. If you decide to try to execute code stored in a CFM library from Mach-O Python, I'd be interested. This will probably be something I will need to do in order to use CFM VST plugins in the Mach-O based app I am writing. Donovan --Apple-Mail-1-508474735-- From jack@oratrix.nl Thu Dec 20 20:59:39 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 20 Dec 2001 21:59:39 +0100 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs In-Reply-To: Message by Donovan Preston , Thu, 20 Dec 2001 12:34:05 -0800 , Message-ID: <20011220205944.3389DE8453@oratrix.oratrix.nl> Recently, Donovan Preston said: > OS X already has an implementation of socket-based IO -- it's called > BSD. :-) And OS X already has a Python which will compile to use it -- > command line Python. What OS X Python is missing, therefore, is the IDE > running on top of the command-line Python binary. Stay tuned, hopefully > we'll have it soon. See my message about Mach-O MacPython IDE if you're > interested in knowing more. > > first files, etc.)? An alternative thought I have to work on is "how > hard > will it be to glue the OS X CL interpreter (not MacPython) to PEF a > gaggle > of libs?" It looks doable but I've never traveled this road before. This isn't worth it. We discussed it about a year ago (both here and on the GUSI list) and by getting the BSD sockets you would also get (unless you do major surgery) all the rest of glibc, so you would get Unix filenames, Sioux would go down the drain, etc. And you'd end up with something almost identical to MachoPython, but with a funny (and slower) CFM component. It's better then to do away with MacPython altogether and base something on MachoPython. And that's also what is being worked on, with porting all the modules, etc. (No doubt we'll call it MacPython when it's finished, but for the time being it's better to make a distinction between MacPython (CW-based Python with PythonInterpreter and IDE which runs on 9 and X) and MachoPython (basically unix command line Python with frameworks and Carbon modules and the rough Python.app added)). -- 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 tony@metanet.com Thu Dec 20 21:18:20 2001 From: tony@metanet.com (Tony Lownds) Date: Thu, 20 Dec 2001 13:18:20 -0800 Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! In-Reply-To: <5F87C316-F518-11D5-A672-000502EE274C@ulaluma.com> References: <5F87C316-F518-11D5-A672-000502EE274C@ulaluma.com> Message-ID: Awesome! So, if like me you don't have CodeWarrior, where do you get libWASTE? > >It turns out that while os.path.join and the like create >'/asdf/zxcv/wqr' slash delimited strings, the code that converts a >python string into a C FSRef Tk on Mac OS X has a similar problem; the file open and save dialogs expect Mac paths, but the Tcl libraries generate unix paths. According to Jim Ingham (the guy behind Tk on Mac OS X), FSRef's, unlike FSSpecs, and can be built with UNIX paths; this is how Tk on Mac OS X, which is Carbon software, will be able to accept UNIX paths. >(? or FSSpec?) needs ':' delimited strings. Or the Carbon library >itself needs colon delimited strings. I didn't look into it too much >except to determine that slash delimited path strings were the >problem. Anyway, I wrote an awful hack in macresource.py that >converts any slash delimited paths to colon delimited and allows the >IDE to get up and running!!! Very exciting! I think we'll end up with two nice IDE's on MacOSX.... Yep, that's right, IDLE will run on MachoPython! I've been playing in IDLE for a couple of days now, and there are definite usability issues (like, you can't save files... or open files... tooltips grab the focus....) Here is some more Mac/Unix path wierdness: >>> macpath.abspath('') ':/Users/tlownds/Desktop' -Tony -- From sdm7g@Virginia.EDU Thu Dec 20 22:07:33 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Thu, 20 Dec 2001 17:07:33 -0500 (EST) Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs In-Reply-To: <20011220205944.3389DE8453@oratrix.oratrix.nl> Message-ID: On Thu, 20 Dec 2001, Jack Jansen wrote: > It's better then to do away with MacPython altogether and base > something on MachoPython. And that's also what is being worked on, > with porting all the modules, etc. (No doubt we'll call it MacPython > when it's finished, but for the time being it's better to make a > distinction between MacPython (CW-based Python with PythonInterpreter > and IDE which runs on 9 and X) and MachoPython (basically unix command > line Python with frameworks and Carbon modules and the rough > Python.app added)). Jack: I love your spelling of "mach-o Python" as "MachoPython" ! I wonder if we can get the Village People to record a theme song for mach-o MachoPython! :-) [ But will Guido dress up in Indian feathers or a hardhat for the video ? ] Maybe there's inspiration for a new icon there somewhere. -- Steve From jack@oratrix.nl Thu Dec 20 22:19:36 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 20 Dec 2001 23:19:36 +0100 Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! In-Reply-To: Message by Tony Lownds , Thu, 20 Dec 2001 13:18:20 -0800 , Message-ID: <20011220221941.71C4EE8453@oratrix.oratrix.nl> Recently, Tony Lownds said: > So, if like me you don't have CodeWarrior, where do you get libWASTE? It's in the standard WASTE distribution. > Here is some more Mac/Unix path wierdness: > > >>> macpath.abspath('') > ':/Users/tlownds/Desktop' Ah, this needs to be fixed. Could you file a bug report? (note that in general using xyzzypath.abspath() on anything but the xyzzy platform is a no-no, but for Mac OS X I think we should try to get macpath and posixpath working for both MachoPython and MacPython). -- 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 jack@oratrix.nl Thu Dec 20 22:22:35 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 20 Dec 2001 23:22:35 +0100 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs In-Reply-To: Message by Steven Majewski , Thu, 20 Dec 2001 17:07:33 -0500 (EST) , Message-ID: <20011220222240.E6F33E8453@oratrix.oratrix.nl> Recently, Steven Majewski said: > Jack: > I love your spelling of "mach-o Python" as "MachoPython" ! > I wonder if we can get the Village People to record a theme song > for mach-o MachoPython! :-) > [ But will Guido dress up in Indian feathers or a hardhat for > the video ? ] Any special reason for mentioning the Indian? He's supposedly the only one in the Village People who's really gay:-) > Maybe there's inspiration for a new icon there somewhere. Ah yes, icons! I did a couple of quick-and-dirty icons for MachoPython (they're in the Mac/OSXResources directory), does anyone want to do some decent ones to replace them? -- 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 jorjun@mac.com Thu Dec 20 23:12:39 2001 From: jorjun@mac.com (Pete Moore) Date: Thu, 20 Dec 2001 23:12:39 +0000 Subject: [Pythonmac-SIG] Pygame on OS X : Anyone had success? In-Reply-To: Message-ID: <1058B678-F59F-11D5-BBE7-00039345EC58@mac.com> Bob! You don't know how pleased that makes me, I started coding when I was about 11 years old, my interest was in doing graphicsy stuff, weird animations, simple games, etc. and I am looking forward to doing it again (with much more elegance, hopefully, thanks to Python) now I'm 30 something!! I'll be checking the Pygame site for updates, SDL installed nicely as a packaged OS X framework...but after digging around in Distutils, I realised I was out of my depth as far as the issues that need resolving there. Big thanks Pete On Thursday, December 20, 2001, at 10:05 PM, Bob Ippolito wrote: > I'm pretty close to having pygame 1.3 ported to OS X. I have the > latest python 2.2c1, Numeric, SDL and _all_ of its dependencies working > great, and I have pygame compiling (with some trickery), but there are > some OS X specific implementation details that will probably take > another few days because pygame doesn't link with SDLmain > > I'll make an installer available from the pygame.org website when I'm > done, hopefully this week > > (feel free to fwd this to pythonmac-sig, I'm not subscribed there at > the moment) > > -bob > From dp@ulaluma.com Thu Dec 20 23:14:16 2001 From: dp@ulaluma.com (Donovan Preston) Date: Thu, 20 Dec 2001 15:14:16 -0800 Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! In-Reply-To: Message-ID: <49B99D5C-F59F-11D5-BB9C-000502EE274C@ulaluma.com> On Thursday, December 20, 2001, at 01:18 PM, Tony Lownds wrote: > Awesome! > > So, if like me you don't have CodeWarrior, where do you get libWASTE? As Jack mentioned, it's in the standard WASTE distribution. For any point and clickers who'd like to follow along, that's: http://www.merzwaren.com/bin/waste/waste-21a4.sit Unpack the sit, rename the folder 'waste', and place it at the same level as your python 'src' directory (ie if you've done a checkout from cvs, in 'python/dist') Go into the Static Libraries folder with the terminal and run 'ranlib libWASTE.a' Now you should be able to 'make sharedinstall', run python, and 'import waste'. >> >> It turns out that while os.path.join and the like create >> '/asdf/zxcv/wqr' slash delimited strings, the code that converts a >> python string into a C FSRef > > Tk on Mac OS X has a similar problem; the file open and save dialogs > expect Mac paths, but the Tcl libraries generate unix paths. > > According to Jim Ingham (the guy behind Tk on Mac OS X), FSRef's, > unlike FSSpecs, and can be built with UNIX paths; this is how Tk on Mac > OS X, which is Carbon software, will be able to accept UNIX paths. Ah. I had read some discussion about FSRefs vs FSSpecs on Carbon-dev, but never had to deal with it so didn't pay much attention; can an FSRef be used wherever an FSSpec is called for in a Carbon call? Or do you have to create an FSRef and convert it to an FSSpec? I suppose the problems with slash delimited paths could therefore be solved by changing the FSSpec_New code to first create an FSRef and then convert it to an FSSpec. Then the only problem remaining is all of the hardcoded colon delimited strings littered throughout the MacPython IDE code. They should all be replaced with calls to os.path.join. That way it works on either 9 or X. >> (? or FSSpec?) needs ':' delimited strings. Or the Carbon library >> itself needs colon delimited strings. I didn't look into it too much >> except to determine that slash delimited path strings were the >> problem. Anyway, I wrote an awful hack in macresource.py that converts >> any slash delimited paths to colon delimited and allows the IDE to get >> up and running!!! > > Very exciting! I think we'll end up with two nice IDE's on MacOSX.... > Yep, that's right, IDLE will run on MachoPython! I've been playing in > IDLE for a couple of days now, and there are definite usability issues > (like, you can't save files... or open files... tooltips grab the > focus....) I downloaded your Python with Tk distribution the other day, and just for laughs dropped idle.py on it. I was pleasantly surprised :-) Thanks, Tony, for getting Tk up and running with MachoPython. Do you have any diffs to the CVS for the changes you made to your distribution? Are they going to make it in to the official distribution? Personally, though, I have no idea why Guido ever went with Tk. I hate it. I wish he had stuck with his STDWIN code. (How long did that last? I just read about it in the History of Python as recorded by the Google Groups usenet archive...) Ah, well, to each his own ;-) Donovan From dp@ulaluma.com Thu Dec 20 23:27:48 2001 From: dp@ulaluma.com (Donovan Preston) Date: Thu, 20 Dec 2001 15:27:48 -0800 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs In-Reply-To: <20011220205944.3389DE8453@oratrix.oratrix.nl> Message-ID: <2DF185B8-F5A1-11D5-BB9C-000502EE274C@ulaluma.com> On Thursday, December 20, 2001, at 12:59 PM, Jack Jansen wrote: > > Recently, Donovan Preston said: > [ discussion of loading code in CFM/PEF libraries from MachoPython ] > This isn't worth it. We discussed it about a year ago (both here and > on the GUSI list) and by getting the BSD sockets you would also get > (unless you do major surgery) all the rest of glibc, so you would get > Unix filenames, Sioux would go down the drain, etc. I think there's a bit of confusion as to why one would still want to load code from a CFM library EVEN on MachoPython. Of course, if a Mach-O library is available it should be used. However, there will be occasions where a Mach-O library will not be available. Probably the most obvious example would be closed-source VST plugins. If the plugin author even bothers to relink the plugin with Carbon, it will most definitely be as a CFM library, not a Mach-O library. Thus the necessity of loading and running code in a CFM library from a Mach-O binary. It sounds like Jeff Harmon is also in a similar situation where he already has a bunch of CFM libraries that he doesn't want to have to recompile as Mach-O to get working with MachoPython. As I was saying, it is technically possible and has been discussed on the Carbon-dev mailing list. Just thought I'd try to clear things up a little bit. p.s. MachoPython -- heh heh. Village people references aside, It'll do as a temporary name until CFM MacPython on OS X dies a horrible death. Donovan From tony@metanet.com Fri Dec 21 04:46:27 2001 From: tony@metanet.com (Tony Lownds) Date: Thu, 20 Dec 2001 20:46:27 -0800 Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! In-Reply-To: <49B99D5C-F59F-11D5-BB9C-000502EE274C@ulaluma.com> References: <49B99D5C-F59F-11D5-BB9C-000502EE274C@ulaluma.com> Message-ID: >As Jack mentioned, it's in the standard WASTE distribution. For any >point and clickers who'd like to follow along, that's: > >http://www.merzwaren.com/bin/waste/waste-21a4.sit > >Unpack the sit, rename the folder 'waste', and place it at the same >level as your python 'src' directory (ie if you've done a checkout >from cvs, in 'python/dist') > >Go into the Static Libraries folder with the terminal and run >'ranlib libWASTE.a' > >Now you should be able to 'make sharedinstall', run python, and >'import waste'. Thanks! > >Ah. I had read some discussion about FSRefs vs FSSpecs on >Carbon-dev, but never had to deal with it so didn't pay much >attention; can an FSRef be used wherever an FSSpec is called for in >a Carbon call? Or do you have to create an FSRef and convert it to >an FSSpec? The second; there are conversion functions. FSRef and FSSpec are not interchangeable. I really don't know what would be best, but there are plenty of smart folks here. >I suppose the problems with slash delimited paths could therefore be >solved by changing the FSSpec_New code to first create an FSRef and >then convert it to an FSSpec. > How would FSSpec_New know if you are passing a unix path or a mac path? The API for those two is different. And all possible unix paths are possible mac paths; on the mac / is legal in filenames and : is the path delimiter, and on unix vice versa. So guessing that "/hello/world" is a unix path would be hasty. > >I downloaded your Python with Tk distribution the other day, and >just for laughs dropped idle.py on it. I was pleasantly surprised >:-) Thanks, Tony, for getting Tk up and running with MachoPython. Do >you have any diffs to the CVS for the changes you made to your >distribution? Are they going to make it in to the official >distribution? Yes and yes. Tk is still in alpha 1. Its VERY stable to use, considering that fact, but the process of embedding is still rough around the edges. So, why rush it? A patch to let you link against Tk alpha 1 is already in Python 2.2. -Tony -- From dp@ulaluma.com Fri Dec 21 05:24:33 2001 From: dp@ulaluma.com (Donovan Preston) Date: Thu, 20 Dec 2001 21:24:33 -0800 Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! In-Reply-To: Message-ID: <043CB9F8-F5D3-11D5-BB9C-000502EE274C@ulaluma.com> On Thursday, December 20, 2001, at 08:46 PM, Tony Lownds wrote: > Donovan wrote: >> I suppose the problems with slash delimited paths could therefore be >> solved by changing the FSSpec_New code to first create an FSRef and >> then convert it to an FSSpec. >> > > How would FSSpec_New know if you are passing a unix path or a mac path? > The API for those two is different. And all possible unix paths are > possible mac paths; on the mac / is legal in filenames and : is the > path delimiter, and on unix vice versa. So guessing that "/hello/world" > is a unix path would be hasty. Hmm. Well, I suppose the only way to get around this is to explicitly state which type of path is being used as Jack suggested, or to always assume slash-delimited paths on X and colon-delimited paths on 9. Since os.path.join creates slash-delimited strings on X, all of the places in the IDE where there is code that looks like os.path.join(rootdir, 'my:subdir:etc') are going to have to be replaced anyway. I suggest replacing them with os.path.join(*[rootdir, 'my', 'subdir', 'etc']) which works no matter what OS you are running under. Then, assuming all paths on X are slash delimited, we can insert the code to convert from a slash-delimited string to a colon-delimited string in FSSpec_New only if MacPython is being compiled as Mach-O. Maybe I'll get around to doing it and submitting a patch. Donovan From jack@oratrix.nl Fri Dec 21 12:36:08 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 21 Dec 2001 13:36:08 +0100 Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! In-Reply-To: Message by Donovan Preston , Thu, 20 Dec 2001 15:14:16 -0800 , <49B99D5C-F59F-11D5-BB9C-000502EE274C@ulaluma.com> Message-ID: <20011221123613.F2587E8453@oratrix.oratrix.nl> Recently, Donovan Preston said: > Ah. I had read some discussion about FSRefs vs FSSpecs on Carbon-dev, > but never had to deal with it so didn't pay much attention; can an FSRef > be used wherever an FSSpec is called for in a Carbon call? Or do you > have to create an FSRef and convert it to an FSSpec? In C you have to do the conversion yourself. In Python you don't: anywhere an FSRef is required you can also pass either an FSSpec or a pathname, and anywhere an FSSpec is required you can also pass an FSRef or a pathname. Lovely language, Python :-) > I suppose the problems with slash delimited paths could therefore be > solved by changing the FSSpec_New code to first create an FSRef and then > convert it to an FSSpec. > > Then the only problem remaining is all of the hardcoded colon delimited > strings littered throughout the MacPython IDE code. They should all be > replaced with calls to os.path.join. That way it works on either 9 or X. How about the following (I think I suggested this before but didn't get any answer): macfs.FSSpec() and macfs.FSRef() get an optional second parameter, which can be either "mac" or "unix". If you pass a string first parameter then the second parameter governs how the pathname is interpreted. Also, fsspec.as_pathname() and fsref.as_pathname() get an optional parameter "mac" or "unix" which give the type of pathname you want. Default is "mac" for MacPython, "unix" for MachoPython. Hmm, we could even add "url" as a third choice, although that's probably feeping creaturism. -- 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 nathan@vividworks.com Fri Dec 21 15:46:56 2001 From: nathan@vividworks.com (Nathan Heagy) Date: Fri, 21 Dec 2001 09:46:56 -0600 (CST) Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! In-Reply-To: <043CB9F8-F5D3-11D5-BB9C-000502EE274C@ulaluma.com> Message-ID: > >> I suppose the problems with slash delimited paths could therefore be > >> solved by changing the FSSpec_New code to first create an FSRef and > >> then convert it to an FSSpec. > >> > > > > How would FSSpec_New know if you are passing a unix path or a mac path? > > The API for those two is different. And all possible unix paths are > > possible mac paths; on the mac / is legal in filenames and : is the > > path delimiter, and on unix vice versa. So guessing that "/hello/world" > > is a unix path would be hasty. This is a problem that Carbon/Cocoa has as well. Carbon expects ':' delimited paths and Cocoa '/', as I understand it. Carbon does ':'->'/' translation automagically. Is there any reason for python to behave any differently? Nathan From mmiller@adobe.com Fri Dec 21 19:16:54 2001 From: mmiller@adobe.com (Martin Miller) Date: Fri, 21 Dec 2001 11:16:54 -0800 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs References: Message-ID: <3C238AA6.D9FC9C8B@adobe.com> On Thu, 20 Dec 2001 15:27:48 Donovan Preston wrote: > >On Thursday, December 20, 2001, at 12:59 PM, Jack Jansen wrote: > > > > Recently, Donovan Preston said: > > [ discussion of loading code in CFM/PEF libraries from MachoPython ] > > > This isn't worth it. We discussed it about a year ago (both here and > > on the GUSI list) and by getting the BSD sockets you would also get > > (unless you do major surgery) all the rest of glibc, so you would get > > Unix filenames, Sioux would go down the drain, etc. > > I think there's a bit of confusion as to why one would still want to > load code from a CFM library EVEN on MachoPython. Of course, if a Mach-O > library is available it should be used. However, there will be occasions > where a Mach-O library will not be available. > > Probably the most obvious example would be closed-source VST plugins. If > the plugin author even bothers to relink the plugin with Carbon, it will > most definitely be as a CFM library, not a Mach-O library. Thus the > necessity of loading and running code in a CFM library from a Mach-O > binary. > > It sounds like Jeff Harmon is also in a similar situation where he > already has a bunch of CFM libraries that he doesn't want to have to > recompile as Mach-O to get working with MachoPython. As I was saying, it > is technically possible and has been discussed on the Carbon-dev mailing > list. > > Just thought I'd try to clear things up a little bit. > > p.s. MachoPython -- heh heh. Village people references aside, It'll do > as a temporary name until CFM MacPython on OS X dies a horrible death. > > Donovan (Sorry about the subject line, but I hesitate to change it now.) Hi, my name is Martin and I work with Jeff at Adobe. I would like to try clarify the situation we are in. Donovan is right on target with his comments above with respect to how we would like to use Python on the Mac. I cannot be specific, but essentially we have a body of CFM libraries, which must stay in that format, that we would like to access as Python extensions on OS X (from both single and multi-processor equipped systems). Being unable to do this could force us to abandon the use of Python altogether for this particular use and project -- which would make a number of us, shall we say, unhappy. Unfortunately, we just don't have the resources needed available to try fix it ourselves at this point. Donovan wrote: > ...until CFM MacPython on OS X dies a horrible death. This especially concerns me because it sounds like the problem will never be solved, even if we could wait a while for the GUSI multi-tasking problem be worked out. Guess there really is "no such thing as a free lunch." ;-) Best regards, Martin From jack@oratrix.nl Fri Dec 21 21:44:09 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 21 Dec 2001 22:44:09 +0100 Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! In-Reply-To: Message by Donovan Preston , Thu, 20 Dec 2001 21:24:33 -0800 , <043CB9F8-F5D3-11D5-BB9C-000502EE274C@ulaluma.com> Message-ID: <20011221214414.57A15E8453@oratrix.oratrix.nl> Recently, Donovan Preston said: > Hmm. Well, I suppose the only way to get around this is to explicitly > state which type of path is being used as Jack suggested, or to always > assume slash-delimited paths on X and colon-delimited paths on 9. I assume you mean "MacPython" where you say 9 and "MachoPython" where you say X, right? Pathname interpretation is more a function of the runtime library than of the OS, in the case of Python. > Since os.path.join creates slash-delimited strings on X, all of the > places in the IDE where there is code that looks like > os.path.join(rootdir, 'my:subdir:etc') are going to have to be replaced > anyway. I suggest replacing them with os.path.join(*[rootdir, 'my', > 'subdir', 'etc']) which works no matter what OS you are running under. Or, alternatively, use macpath. Os.path is great to get rid of platform dependencies, but only if you add single components. If you're using my:subdir:etc you have a Mac dependency anyway, so there's little to be gained from using os.path. While the *[rootdir, 'my', 'subdir'] construct is really really nifty (applause!) methinks it's almost obfuscated enough to make it into Perl:-) -- 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 jack@oratrix.nl Fri Dec 21 21:53:14 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 21 Dec 2001 22:53:14 +0100 Subject: [Pythonmac-SIG] Mach-O MacPython IDE!!! In-Reply-To: Message by Jack Jansen , Fri, 21 Dec 2001 13:36:08 +0100 , <20011221123613.F2587E8453@oratrix.oratrix.nl> Message-ID: <20011221215320.0BE09E8453@oratrix.oratrix.nl> Recently, Jack Jansen said: > > Recently, Donovan Preston said: > > I suppose the problems with slash delimited paths could therefore be > > solved by changing the FSSpec_New code to first create an FSRef and then > > convert it to an FSSpec. Sorry, in my previous mail I went off on a tangent. What I should have said in answer to this suggestion is: "Good idea! Let's do it!". So, here's the current design: - FSSpec expected: if arg-is-fsspec: fine elif arg-is-3-tuple: turn-into-fsspec elif arg-is-string and (arg2 == 'mac' or (arg2==None and MacPython)): Turn from : separated path into fsspec else: try to turn into FSref if it isn't one turn FSRef into fsspec - FSRef expected: if arg-is-fsref: fine #ifdef MACHO_PYTHON elif arg-is-string and (arg2 == 'unix' or arg2==None): Turn into FSref from / separated path #endif else: Try to turn into FSSpec if it isn't one turn fsspec into fsref. -- 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 jack@oratrix.nl Fri Dec 21 22:20:12 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 21 Dec 2001 23:20:12 +0100 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs In-Reply-To: Message by Martin Miller , Fri, 21 Dec 2001 11:16:54 -0800 , <3C238AA6.D9FC9C8B@adobe.com> Message-ID: <20011221222017.9151CE8453@oratrix.oratrix.nl> > > > This isn't worth it. We discussed it about a year ago (both here and > > > on the GUSI list) and by getting the BSD sockets you would also get > > > (unless you do major surgery) all the rest of glibc, so you would get > > > Unix filenames, Sioux would go down the drain, etc. > > > > I think there's a bit of confusion as to why one would still want to > > load code from a CFM library EVEN on MachoPython. Of course, if a Mach-O > > library is available it should be used. However, there will be occasions > > where a Mach-O library will not be available. > > > > Probably the most obvious example would be closed-source VST plugins. If > > the plugin author even bothers to relink the plugin with Carbon, it will > > most definitely be as a CFM library, not a Mach-O library. Thus the > > necessity of loading and running code in a CFM library from a Mach-O > > binary. Ok, this is indeed a completely different situation. Depending on the API the plugin is provided with it could be either easy or impossible to put Python in between. If the plugin is in complete control it's easy, the only problem to solve is the CFM-MachO bridge. Although someone will have to take care to convert pathnames, if any go across the API. If the plugin API provided by the host application is sufficiently rich (as an Adobe plugin API I've glanced at happens to be, IIRC) there's a bit of a problem, but not too much, as you really have to only build a Python interpreter that refrains from doing its own I/O calls incorrectly. Linking against a cfm-bridged glibc should go a long way. If the API is just a couple of start/stop calls plus a long list of do's and don'ts (like the Netscape plugin API) there is a problem. > Donovan wrote: > > ...until CFM MacPython on OS X dies a horrible death. > > This especially concerns me because it sounds like the problem will > never be solved, even if we could wait a while for the GUSI > multi-tasking problem be worked out. I think that's too negative. First, it'll be a while until CFM MacPython dies (and why something that has served us so well for so long deserves a "horrible death".... well.... :-). Second, this problem isn't really Python-related. Every product that has a plugin architecture with a sufficient marketshare will have to face this problem when they decide to move the product to Mach-O. And I'm pretty sure everyone will move to Mach-O at some point... -- 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 jack@oratrix.nl Fri Dec 21 23:56:36 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 22 Dec 2001 00:56:36 +0100 Subject: [Pythonmac-SIG] Please test the 2.2 installer Message-ID: <20011221235636.C8206E8453@oratrix.oratrix.nl> Folks, I think MacPython 2.2 is ready. The first installer is in http://www.cwi.nl/ftp/jack/python/mac/MacPython22full.bin . All the other ones (hqx, active installer, source) will follow later. I'm announcing this one here early mainly for Jason or anyone else with access to MacOS 8.1: does this release work? But that shouldn't stop anyone else from trying it: I've only tried it on my own dev machine, not even on OSX. So: give it a go and let me know ehterh it works (I'm 99% sure it will). I'll post another note with much wider audience when the other installers are uploaded and I get a green light on 8.1. Or I'll refrain from doing so if I get a red light on any otherissue, of course:-) -- 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 dp@ulaluma.com Sat Dec 22 01:56:45 2001 From: dp@ulaluma.com (Donovan Preston) Date: Fri, 21 Dec 2001 17:56:45 -0800 Subject: [Pythonmac-SIG] Using slash-seperated paths for creating FSSpecs (was: Mach-O MacPython IDE!!!) Message-ID: <43E994F3-F687-11D5-AB28-000502EE274C@ulaluma.com> On Friday, December 21, 2001, at 01:44 PM, Jack Jansen wrote: > > Recently, Donovan Preston said: >> Hmm. Well, I suppose the only way to get around this is to explicitly >> state which type of path is being used as Jack suggested, or to always >> assume slash-delimited paths on X and colon-delimited paths on 9. > > I assume you mean "MacPython" where you say 9 and "MachoPython" where > you say X, right? Pathname interpretation is more a function of the > runtime library than of the OS, in the case of Python. Yes, correct, sorry. So I should have said "Always assume slash-delimited paths on Mach-O Python and colon-delimited paths on CFM MacPython." >> Since os.path.join creates slash-delimited strings on X, all of the >> places in the IDE where there is code that looks like >> os.path.join(rootdir, 'my:subdir:etc') are going to have to be replaced >> anyway. I suggest replacing them with os.path.join(*[rootdir, 'my', >> 'subdir', 'etc']) which works no matter what OS you are running under. > > Or, alternatively, use macpath. Os.path is great to get rid of > platform dependencies, but only if you add single components. If > you're using my:subdir:etc you have a Mac dependency anyway, so > there's little to be gained from using os.path. Ah. I wasn't aware there was a macpath module which would do colon-delimiting even on X. Hmm. At first glance I thought that might work, but upon further inspection I recall why sticking to colon-delimited paths won't work on Mach-O MacPython: There are constructions throughout the IDE that look like this: widgetresfile = os.path.join(sys.exec_prefix, ":Mac:Tools:IDE:Widgets.rsrc") Since sys.exec_prefix is specified as a slash-delimited string, even macpath won't help here. And I am strongly opposed to making sys.exec_prefix return a colon-delimited string :-) And rather than convert any slash-delimited string such as sys.exec_prefix to a colon-delimited string prior to using macpath.join, I still contest that it's better to use os.path.join and construct your path segments in a platform agnostic way. Maybe this syntax will be a little more to your (non-obfuscated) liking ;-) pathsegments = [sys.exec_prefix, 'Mac', 'Tools', 'IDE'] path = os.path.join(*pathsegments) Then, the resulting path can be passed to the new FSSpec_New, after it's been updated to conform to your pseudocode, no matter what runtime you are running under and it will work. Donovan From stefan.witzgall@online.de Sat Dec 22 13:21:20 2001 From: stefan.witzgall@online.de (Stefan Witzgall) Date: Sat, 22 Dec 2001 14:21:20 +0100 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: <20011221235636.C8206E8453@oratrix.oratrix.nl> Message-ID: Hello Jack, >I think MacPython 2.2 is ready. The first installer is in >http://www.cwi.nl/ftp/jack/python/mac/MacPython22full.bin . All the great to see your efforts to keep on track. I did download the binaries this morning (Europe). >with much wider audience when the other installers are uploaded and I >get a green light on 8.1. Or I'll refrain from doing so if I get a red >light on any otherissue, of course:-) When I start the IDE by doubleclicking on its icon it starts up and one moment it shows the well known MacPython logo, then I get a traceback and the IDE stalls. I am able to make screenshoot, but I'm not able to copy the traceback to the clipboard. If you want, I will do some typing ... Ok, at least the last lines: [cut some traceback] File "archive_1_red:Python 2.2:Mac:Tools:IDE:Splash.py", line 51, in UpdateSplash splash.GetDialogWindow().ValidWindowRect(splash.GetDialogPort().portRect) NotImplementedError: Not available in this shared library/OS version Btw: Previous versions of MacPython are running here fine. When I gave the line import test.regrtest ; test.regrtest.main() to the interpreter it did the following tests, then stalled (I waited about half an hour): test_grammar test_opcodes test_operations test_builtin test_exceptions test_types test_MimeWriter test_StringIO test___all__ A ctrl-cmd-esd raise the usual dialog, where I did confirm and, surprise, was back at the interpreter. That are my experiences with MacPyzhon 2.2. Stefan From richard@richardgordon.net Sat Dec 22 18:19:52 2001 From: richard@richardgordon.net (Richard Gordon) Date: Sat, 22 Dec 2001 13:19:52 -0500 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: References: Message-ID: At 2:21 PM +0100 12/22/01, Stefan Witzgall wrote: >When I gave the line > import test.regrtest ; test.regrtest.main() >to the interpreter it did the following tests, then stalled (I waited about >half an hour): > >test_grammar >test_opcodes >test_operations >test_builtin >test_exceptions >test_types >test_MimeWriter >test_StringIO >test___all__ > >A ctrl-cmd-esd raise the usual dialog, where I did confirm and, surprise, >was back at the interpreter. > >That are my experiences with MacPyzhon 2.2. When I was playing with the c1 version, I ran into the same problem but wound up with a nasty system hang. I got past this by bumping memory up to 60 megs. With the final version of 2.2 running under 8.6, I got thru all of the tests in about 1.5 hrs by setting the interpreter's memory at 100 megs. Four tests failed: test_email test_frozen test_socket test_time I did have a problem of sorts with the installer - it thought it should use Carbon instead of Classic for some reason tho I've never run into this problem with previous versions, so I had to reconfigure manually. It also seems to me that the IDE is much slower about loading up but it does manage to do so. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From sdm7g@Virginia.EDU Sat Dec 22 18:33:19 2001 From: sdm7g@Virginia.EDU (Steven Majewski) Date: Sat, 22 Dec 2001 13:33:19 -0500 (EST) Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: <20011221235636.C8206E8453@oratrix.oratrix.nl> Message-ID: On my iBook, OSX 10.1.2, the install script went ok. When I did ConfigurePythonCarbon, it seemed to get stuck at building applets. I gave up after a while, killed it, and restarted it, and everything seemed fine. Interpreter and IDE both worked: did testall and EasyDialogs.test from Interp. EasyDialogs.test, and Module Browser from IDE. When the Configure script got stuck the first time, I was running pine in Terminal.app window, deleting and emptying trash from former Python installs, and had IE idle in the background -- so maybe it was being in the background while there was a lot of other activity that the configure script didn't like. I think that's a "green light"! If you would like me to try it again, either with or without the extra load, just let me know. -- Steve From richard@richardgordon.net Sat Dec 22 19:15:00 2001 From: richard@richardgordon.net (Richard Gordon) Date: Sat, 22 Dec 2001 14:15:00 -0500 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: References: Message-ID: At 1:19 PM -0500 12/22/01, Richard Gordon wrote: >I did have a problem of sorts with the installer - it thought it >should use Carbon instead of Classic for some reason tho I've never >run into this problem with previous versions, so I had to >reconfigure manually. It also seems to me that the IDE is much >slower about loading up but it does manage to do so. hmmm, I now see that while the IDE version is PPC, the module browser reveals that it is importing Carbon stuff (i.e., Carbon._AE, Carbon._App, Carbon._Ctl, Carbon._Dlg, etc.). How do I untangle this? Thanks. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From dp@ulaluma.com Sat Dec 22 21:20:04 2001 From: dp@ulaluma.com (Donovan Preston) Date: Sat, 22 Dec 2001 13:20:04 -0800 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: Message-ID: On Saturday, December 22, 2001, at 11:15 AM, Richard Gordon wrote: > At 1:19 PM -0500 12/22/01, Richard Gordon wrote: > >> I did have a problem of sorts with the installer - it thought it >> should use Carbon instead of Classic for some reason tho I've never >> run into this problem with previous versions, so I had to reconfigure >> manually. It also seems to me that the IDE is much slower about >> loading up but it does manage to do so. > > hmmm, I now see that while the IDE version is PPC, the module browser > reveals that it is importing Carbon stuff (i.e., Carbon._AE, > Carbon._App, Carbon._Ctl, Carbon._Dlg, etc.). How do I untangle this? Even though it says the modules are inside the Carbon module, they are really not -- they are just in a module (folder) called Carbon to keep them together. If you've run ConfigurePythonClassic, the c-compiled modules (_AE, _App, _Ctl) that are being used are the ones that are linked against the normal mac libs and not Carbon. Confusing, but the Carbon module is just a way to keep the Mac modules neat and tidy together. Maybe it should have been called Mac instead. (Mac.AE, Mac.App, Mac.Ctl)... Donovan From richard@richardgordon.net Sat Dec 22 23:57:55 2001 From: richard@richardgordon.net (Richard Gordon) Date: Sat, 22 Dec 2001 18:57:55 -0500 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: References: Message-ID: At 1:20 PM -0800 12/22/01, Donovan Preston wrote: >Even though it says the modules are inside the Carbon module, they >are really not -- they are just in a module (folder) called Carbon >to keep them together. If you've run ConfigurePythonClassic, the >c-compiled modules (_AE, _App, _Ctl) that are being used are the >ones that are linked against the normal mac libs and not Carbon. >Confusing, but the Carbon module is just a way to keep the Mac >modules neat and tidy together. Maybe it should have been called Mac >instead. (Mac.AE, Mac.App, Mac.Ctl)... Thanks. I noticed this when I decided to reinstall everything and bothered to read the readme. 8 -( Oddly enough, the installer got confused again when I reinstalled even tho I had deleted all older stuff and all preference files, so I still had to configure for Classic manually. I also still think that the IDE is taking longer to load than it used to, but perhaps I'm just being impatient. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From mday@mac.com Sun Dec 23 04:53:47 2001 From: mday@mac.com (Mark Day) Date: Sat, 22 Dec 2001 20:53:47 -0800 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: <20011221235636.C8206E8453@oratrix.oratrix.nl> Message-ID: on 12/21/01 3:56 PM, Jack Jansen at jack@oratrix.nl wrote: > I think MacPython 2.2 is ready. The first installer is in > http://www.cwi.nl/ftp/jack/python/mac/MacPython22full.bin I tried installing it on 9.2.2. It seemed to install fine until it got to the point of launching the configure program. It launched ConfigurePythonCarbon instead of ConfigurePythonClassic. At that point, the machine was hung, and I rebooted. After the reboot, I tried launching ConfigurePythonClassic. That hung, too, but I was able to force quit it. When I ran ConfigurePythonClassic again, it seemed to run and set things up OK. -Mark From hiss999@dircon.co.uk Sun Dec 23 18:10:24 2001 From: hiss999@dircon.co.uk (sandro) Date: Sun, 23 Dec 2001 18:10:24 +0000 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: <20011221235636.C8206E8453@oratrix.oratrix.nl> Message-ID: on 21/12/01 11:56 pm GMT, Jack Jansen at jack@oratrix.nl apparently typed: > Folks, > I think MacPython 2.2 is ready. The first installer is in > http://www.cwi.nl/ftp/jack/python/mac/MacPython22full.bin . All the > other ones (hqx, active installer, source) will follow later. Hi there Both 2.2 Classic and Carbon run smooth here under OS 9.04/CarbonLib 1.4. All went well when I realised that I've got to reassign loads of memory to the interpreter every time I switch between configurations... I just didn't know the memory settings are initialised every time you configure Carbon/Classic. Best Sandro -- LUThER From jack@oratrix.nl Sun Dec 23 21:40:58 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 23 Dec 2001 22:40:58 +0100 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: Message by Richard Gordon , Sat, 22 Dec 2001 18:57:55 -0500 , Message-ID: <20011223214103.62392E8453@oratrix.oratrix.nl> Recently, Richard Gordon said: > Oddly enough, the installer got confused again when I reinstalled > even tho I had deleted all older stuff and all preference files, so I > still had to configure for Classic manually. Are you sure you don't have CarbonLib installed? There's quite a few packages nowadays that install it, and if you have Carbon then the installer will pick that as the preferred configuration.... -- 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 jack@oratrix.nl Sun Dec 23 21:45:37 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 23 Dec 2001 22:45:37 +0100 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: Message by Mark Day , Sat, 22 Dec 2001 20:53:47 -0800 , Message-ID: <20011223214542.DFF5DE8453@oratrix.oratrix.nl> Recently, Mark Day said: > I tried installing it on 9.2.2. It seemed to install fine until it got to > the point of launching the configure program. It launched > ConfigurePythonCarbon instead of ConfigurePythonClassic. That's normal: on 9.2.2 you have CarbonLib, so Carbon is the preferred configuration. > At that point, the > machine was hung, and I rebooted. After the reboot, I tried launching > ConfigurePythonClassic. That hung, too, but I was able to force quit it. That's not normal:-) > When I ran ConfigurePythonClassic again, it seemed to run and set things up > OK. Are other people seeing unexpected hangs? I've been having a similar one, where I installed 2.2 on a fresh system, which went fine, but the first time I ran the IDE it hung and I had to force-quit it. Next time: no problem. Re-installed: worked fine the first time. -- 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 jack@oratrix.nl Sun Dec 23 21:51:42 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 23 Dec 2001 22:51:42 +0100 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: Message by Stefan Witzgall , Sat, 22 Dec 2001 14:21:20 +0100 , Message-ID: <20011223215147.0D0A1E8453@oratrix.oratrix.nl> Recently, Stefan Witzgall said: > [cut some traceback] > File "archive_1_red:Python 2.2:Mac:Tools:IDE:Splash.py", line 51, in > UpdateSplash > splash.GetDialogWindow().ValidWindowRect(splash.GetDialogPort().portRect) > NotImplementedError: Not available in this shared library/OS version After some mailing back and forth with Jason I'm afraid this is unfixable. The current (Universal 3.4) version of CarbonAccessors.o does not have the ValidWindowRect call anymore (which the previous 3.3.2 version did have). I could hack something together with two versions of CarbonAccessors.o, but this would be a nightmare to people who want to build from source. I'm currently thinking that I'll release 2.2 as "partially MacOS 8.1 compatible" (the interpreter works, the IDE doesn't). We (me + the people who have access to 8.1) should then put together a patch set that can be overlayed onto a MacPython installation and that replaces all calls to ValidWindowRect() with GetPort()/SetPort()/ValidRect()/SetPort() sequences. -- 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 sdm7g@mac.com Mon Dec 24 00:51:29 2001 From: sdm7g@mac.com (Steven Majewski) Date: Sun, 23 Dec 2001 19:51:29 -0500 Subject: [Pythonmac-SIG] OSX Tips for Christmas... Message-ID: <5E06582A-F808-11D5-BD18-003065A7CFBA@mac.com> [1] Maybe there's a less roundabout method, but I did: /Developer/Tools/DeRez dialogs.rsrc >dialogs.r using the dialogs.rsrc from the MacPython2.2b sources -- the ones in the Mac/Resources directory of the standard source release seem to be corrupted -- at least the tools complain about it when you try to use those files -- maybe they are getting EOL converted when they go to the CVS server? Then: /Developer/Tools/Rez dialogs.r -o /usr/local/bin/python Now I can run MachoPython and EasyDialogs.test() works -- more or less. You need to manually bring the dialogs to the front from behind the Terminal.app window. [2] In case you didn't know, you can send and receive AppleEvents from a unix commandline program. This capability is not likely to go away, as it's used for the osascript commands, etc. I compiled and linked with switches: -I/Developer/Headers/FlatCarbon -framework ApplicationServices -framework Carbon This should also work from MachoPython, although I only did a partial test. (I was trying to debug communication with AppleEvents between two classic apps, and I found it easy to simulate one of the programs with a simple cli program so that I could step thru the calls with gdb. ) And BTW, have you seen: [3] How to enable Translucent Terminal Windows: http://forums.macnn.com/cgi- bin/ultimatebb.cgi?ubb=get_topic&f=39&t=001777 ( I don't know if this is actually USEFUL, but it looks kind of cool! ) [4] And the thread on how to Enable Window Backing Store Compression: http://forums.macnn.com/cgi- bin/ultimatebb.cgi?ubb=get_topic&f=46&t=000100 (I don't know if the 10.1.2 upgrade enables this -- I did the hack before I did the latest upgrade.) [5] And if you haven't checked out: yet, you should. Merry Christmas and Happy Hacking! -- Steve Majewski (trying to send this from Mail.app, so I hope it doesn't get mangled as HTML or RTF! ) From stefan.witzgall@online.de Mon Dec 24 02:51:37 2001 From: stefan.witzgall@online.de (Stefan Witzgall) Date: Mon, 24 Dec 2001 03:51:37 +0100 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: <20011223215147.0D0A1E8453@oratrix.oratrix.nl> References: Message by Stefan Witzgall , Sat, 22 Dec 2001 14:21:20 +0100 , Message-ID: Hi Jack, >Recently, Stefan Witzgall said: >> [cut some traceback] >> File "archive_1_red:Python 2.2:Mac:Tools:IDE:Splash.py", line 51, in >> UpdateSplash >> splash.GetDialogWindow().ValidWindowRect(splash.GetDialogPort().portRect) >> NotImplementedError: Not available in this shared library/OS version > >After some mailing back and forth with Jason I'm afraid this is >unfixable. The current (Universal 3.4) version of CarbonAccessors.o >does not have the ValidWindowRect call anymore (which the previous >3.3.2 version did have). I could hack something together with two >versions of CarbonAccessors.o, but this would be a nightmare to people >who want to build from source. ok, I see that the time of of systems thus old are goimg down the drain... >I'm currently thinking that I'll release 2.2 as "partially MacOS 8.1 >compatible" (the interpreter works, the IDE doesn't). We (me + the >people who have access to 8.1) should then put together a patch set >that can be overlayed onto a MacPython installation and that replaces >all calls to ValidWindowRect() with >GetPort()/SetPort()/ValidRect()/SetPort() sequences. Perhaps you could think about taking one of the last versions of MacPython that runs smooth with MacOS 8.1 and hack the most important changes into it, fix bugs... make an "old style", reliable "MacPython classic". Most important is fixing bugs, not new features, in my oppinion. I would not be angry to see the development of MacPython for MacOS 8.1 is frozen... perhaps I never will update my currently running version of OzTeX... Stefan From richard@richardgordon.net Mon Dec 24 04:27:30 2001 From: richard@richardgordon.net (Richard Gordon) Date: Sun, 23 Dec 2001 23:27:30 -0500 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: <20011223214103.62392E8453@oratrix.oratrix.nl> References: <20011223214103.62392E8453@oratrix.oratrix.nl> Message-ID: At 10:40 PM +0100 12/23/01, Jack Jansen wrote: >Are you sure you don't have CarbonLib installed? There's quite a few >packages nowadays that install it, and if you have Carbon then the >installer will pick that as the preferred configuration.... Now that you ask, yes I do. I'm not sure exactly how I wound up with it, but it almost certainly was there when I installed the c1 version a few days ago and probably for some time before that and c1 sorted things out ok, as did 2.1. Out of curiosity, why doesn't the installer just get the system level instead (I've forgotten, but it seems like that's a gestalt thing)? Thanks. Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net From stefan.witzgall@online.de Mon Dec 24 06:14:17 2001 From: stefan.witzgall@online.de (Stefan Witzgall) Date: Mon, 24 Dec 2001 07:14:17 +0100 Subject: [Pythonmac-SIG] MacPython 2.2, MacOS 8.1, test_regtest.py: What works, what fails. Message-ID: Hi all, as one could read in the parallel thread concerning the MacPython 2.2 installer the IDE doesn't work with MacOS 8.1 but the interpreter does. Ok, I let it do a test. Am I right, that so following results are quite nomral? What about the failing tests? Stefan interpreter output: =================== test_grammar [the first output line; cut many lines in the following] test test_al skipped -- No module named al test test_bsddb skipped -- No module named bsddb test test_cd skipped -- No module named cd test test_cl skipped -- No module named cl test test_commands skipped -- Not posix; skipping test_commands test test_crypt skipped -- No module named crypt test test_curses skipped -- No module named _curses test test_dbm skipped -- No module named dbm test test_dl skipped -- No module named dl test test_fcntl skipped -- No module named fcntl test test_fork1 skipped -- os.fork not defined -- skipping test_fork1 test test_frozen failed -- import __phello__.foo should have failed test test_gl skipped -- No module named gl test test_grp skipped -- No module named grp test test_imgfile skipped -- No module named imgfile test test_largefile skipped -- filesystem does not have largefile support test test_linuxaudiodev skipped -- No module named fcntl test test_locale skipped -- test locale en_US not supported test test_longexp crashed -- exceptions.MemoryError: test test_mmap skipped -- No module named mmap test test_nis skipped -- No module named nis test test_ntpath skipped -- No module named nt test test_openpty skipped -- No openpty() available. test test_poll skipped -- select.poll not defined -- skipping test_poll test test_popen2 skipped -- cannot import name fork test test_pty skipped -- No module named termios test test_pwd skipped -- No module named pwd test test_signal skipped -- No module named signal test test_socket_ssl skipped -- Use of the `network' resource not enabled test test_socketserver skipped -- Use of the `network' resource not enabled test test_sunaudiodev skipped -- No module named sunaudiodev test test_time failed -- Traceback (most recent call last): File "archive_1_red:Python 2.2:Lib:test:test_time.py", line 46, in test_mktime time.mktime, (999999, 999999, 999999, 999999, File "archive_1_red:Python 2.2:Lib:unittest.py", line 279, in failUnlessRaises raise self.failureException, excName AssertionError: OverflowError test test_timing skipped -- No module named timing test test_unicode_file skipped -- No Unicode filesystem semantics on this platform. test test_winreg skipped -- No module named _winreg test test_winsound skipped -- No module named winsound test test_zlib crashed -- exceptions.MemoryError: 149 tests OK. 4 tests failed: test_frozen test_longexp test_time test_zlib 33 tests skipped: test_al test_bsddb test_cd test_cl test_commands test_crypt test_curses test_dbm test_dl test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile test_linuxaudiodev test_locale test_mmap test_nis test_ntpath test_openpty test_poll test_popen2 test_pty test_pwd test_signal test_socket_ssl test_socketserver test_sunaudiodev test_timing test_unicode_file test_winreg test_winsound Those skips are all expected on mac. From jwblist@olympus.net Mon Dec 24 08:05:25 2001 From: jwblist@olympus.net (John W Baxter) Date: Mon, 24 Dec 2001 00:05:25 -0800 Subject: [Pythonmac-SIG] Is it just me or...? In-Reply-To: <20011219092013.CF769303183@snelboot.oratrix.nl> References: <20011219092013.CF769303183@snelboot.oratrix.nl> Message-ID: At 10:20 +0100 12/19/01, Jack Jansen wrote: >I will probably do a 2.2.1 release when it is solved. Er...may I suggest some other numbering? There may eventually be a mainline Python 2.2.1 --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jack@oratrix.nl Mon Dec 24 12:21:25 2001 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 24 Dec 2001 13:21:25 +0100 Subject: [Pythonmac-SIG] MacPython 2.2, MacOS 8.1, test_regtest.py: What works, what fails. In-Reply-To: Message by Stefan Witzgall , Mon, 24 Dec 2001 07:14:17 +0100 , Message-ID: <20011224122131.22DB1E8448@oratrix.oratrix.nl> Recently, Stefan Witzgall said: > 149 tests OK. > 4 tests failed: > test_frozen test_longexp test_time test_zlib > 33 tests skipped: > test_al test_bsddb test_cd test_cl test_commands test_crypt > test_curses test_dbm test_dl test_fcntl test_fork1 test_gl > test_grp test_imgfile test_largefile test_linuxaudiodev > test_locale test_mmap test_nis test_ntpath test_openpty test_poll > test_popen2 test_pty test_pwd test_signal test_socket_ssl > test_socketserver test_sunaudiodev test_timing test_unicode_file > test_winreg test_winsound > Those skips are all expected on mac. Yes, this is the expected outcome. README explains why those four tests fail. -- 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 jack@oratrix.nl Mon Dec 24 12:22:40 2001 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 24 Dec 2001 13:22:40 +0100 Subject: [Pythonmac-SIG] Is it just me or...? In-Reply-To: Message by John W Baxter , Mon, 24 Dec 2001 00:05:25 -0800 , Message-ID: <20011224122245.4AC22E8448@oratrix.oratrix.nl> Recently, John W Baxter said: > At 10:20 +0100 12/19/01, Jack Jansen wrote: > >I will probably do a 2.2.1 release when it is solved. > > Er...may I suggest some other numbering? There may eventually be a > mainline Python 2.2.1 I'll try to usurp the 2.2.1 number. If I can't then it'll be called something else, but I hate versions like "2.2 build 125", unless it can't be helped. -- 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 dan@grassi.org Mon Dec 24 19:17:39 2001 From: dan@grassi.org (Dan Grassi) Date: Mon, 24 Dec 2001 14:17:39 -0500 Subject: [Pythonmac-SIG] bsddb availability In-Reply-To: Message-ID: Hi, I am wondering if bsddb is available for Mac classic. Thanks, Dan From hiss999@dircon.co.uk Tue Dec 25 16:22:54 2001 From: hiss999@dircon.co.uk (sandro s.) Date: Tue, 25 Dec 2001 16:22:54 +0000 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: <20011223215147.0D0A1E8453@oratrix.oratrix.nl> Message-ID: on 23/12/01 9:51 pm GMT, Jack Jansen at jack@oratrix.nl apparently typed: > I'm currently thinking that I'll release 2.2 as "partially MacOS 8.1 > compatible" (the interpreter works, the IDE doesn't). After playing with 2.2 for a couple of days, I've found the interpreter much more "reliable" than IDE on OS 9.04 too. Actually, I don't really mind it for I tend to run Python from BBedit/Alpha for many different reasons... Generally speaking, I think using the interpreter and a good editor still is the best solution. Yes, I'm having fun crashing my machine on Xmas day. How sad:( Best -- LUThER (I use this when I'm travelling) From hiss999@dircon.co.uk Tue Dec 25 19:21:15 2001 From: hiss999@dircon.co.uk (sandro s.) Date: Tue, 25 Dec 2001 19:21:15 +0000 Subject: [Pythonmac-SIG] MPW Message-ID: Hi bunch Is anyone building Python Modules successfully with MPW? Any documentation apart from the useful link on Jack's page? Ta -- LUThER (I use this when I'm travelling) From jack@oratrix.nl Tue Dec 25 22:41:05 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 25 Dec 2001 23:41:05 +0100 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: Message by "sandro s." , Tue, 25 Dec 2001 16:22:54 +0000 , Message-ID: <20011225224110.C251AE8448@oratrix.oratrix.nl> Recently, "sandro s." said: > After playing with 2.2 for a couple of days, I've found the interpreter much > more "reliable" than IDE on OS 9.04 too. Please send bug reports on this, either send "vague" reports here, so other people can tell whether they have similar problems, or submit firm bug reports to the sourceforge bugreporter and assign them to me or Just (jvr). The only problem I'm aware of with the IDE is that the multicolumn browser with reveal triangles looks absolutely wierd on OSX. -- 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 Benjamin.Schollnick@usa.xerox.com Wed Dec 26 13:37:53 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Wed, 26 Dec 2001 08:37:53 -0500 Subject: [Pythonmac-SIG] Using slash-seperated paths for creating FSSp ecs (was: Mach-O MacPython IDE!!!) Message-ID: Donovan, I like the idea....(personally).... It's a interesting use of the overloaded parameters.... I think, this is similiar to what you intend... (In a more formalized, function), and suggestions for improvement? import os def create_platform_path ( list_of_directories, *overflow): """ """ if (list_of_directories <> None): return os.path.join ( list_of_directories, *overflow ) else: return "" print "path: ", create_platform_path (None) print "path: ", create_platform_path ( *["develope"] ) print "path: ", create_platform_path ( *["develope", "bas_common"] ) print "path: ", create_platform_path ( *["temp", "delete", "me"] ) test = ["this", "is", "the", "path"] print "path: ", create_platform_path (*test) - Benjamin -----Original Message----- From: Donovan Preston [mailto:dp@ulaluma.com] Sent: Friday, December 21, 2001 8:57 PM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] Using slash-seperated paths for creating FSSpecs (was: Mach-O MacPython IDE!!!) On Friday, December 21, 2001, at 01:44 PM, Jack Jansen wrote: > > Recently, Donovan Preston said: >> Hmm. Well, I suppose the only way to get around this is to explicitly >> state which type of path is being used as Jack suggested, or to always >> assume slash-delimited paths on X and colon-delimited paths on 9. > > I assume you mean "MacPython" where you say 9 and "MachoPython" where > you say X, right? Pathname interpretation is more a function of the > runtime library than of the OS, in the case of Python. Yes, correct, sorry. So I should have said "Always assume slash-delimited paths on Mach-O Python and colon-delimited paths on CFM MacPython." >> Since os.path.join creates slash-delimited strings on X, all of the >> places in the IDE where there is code that looks like >> os.path.join(rootdir, 'my:subdir:etc') are going to have to be replaced >> anyway. I suggest replacing them with os.path.join(*[rootdir, 'my', >> 'subdir', 'etc']) which works no matter what OS you are running under. > > Or, alternatively, use macpath. Os.path is great to get rid of > platform dependencies, but only if you add single components. If > you're using my:subdir:etc you have a Mac dependency anyway, so > there's little to be gained from using os.path. Ah. I wasn't aware there was a macpath module which would do colon-delimiting even on X. Hmm. At first glance I thought that might work, but upon further inspection I recall why sticking to colon-delimited paths won't work on Mach-O MacPython: There are constructions throughout the IDE that look like this: widgetresfile = os.path.join(sys.exec_prefix, ":Mac:Tools:IDE:Widgets.rsrc") Since sys.exec_prefix is specified as a slash-delimited string, even macpath won't help here. And I am strongly opposed to making sys.exec_prefix return a colon-delimited string :-) And rather than convert any slash-delimited string such as sys.exec_prefix to a colon-delimited string prior to using macpath.join, I still contest that it's better to use os.path.join and construct your path segments in a platform agnostic way. Maybe this syntax will be a little more to your (non-obfuscated) liking ;-) pathsegments = [sys.exec_prefix, 'Mac', 'Tools', 'IDE'] path = os.path.join(*pathsegments) Then, the resulting path can be passed to the new FSSpec_New, after it's been updated to conform to your pseudocode, no matter what runtime you are running under and it will work. Donovan _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From fukazawa@134net.com Wed Dec 26 14:40:35 2001 From: fukazawa@134net.com (fukazawa@134net.com) Date: Wed, 26 Dec 2001 23:40:35 +0900 Subject: [Pythonmac-SIG] =?ISO-2022-JP?B?GyRCSlQ9OEl0JGgkaiEiJCo0aiQkGyhC?= Message-ID: <20011226150454241.00000.0.net134@XP.md.scn-net.ne.jp> お忙しいところ申し訳ございません。 「湘南パラダイスマガジン」編集部深沢と言います。 このメールは、風俗、アダルトサイト、ナイト情報を 運営している管理者様へ、送信させて頂いております。 ７万部発行のナイト情報誌を発行していますが、 この度、「人気ＷＥＢサイト紹介」 などの編集記事を企画しております。アダルトサイト含 そこで今回、情報収集も含めまして、相互リンク形式のランキングシステムを導入しましたので、登録をよろしくお願いいたします。 登録して頂いた情報を元に、本紙面で紹介させていただく場合は、 改めて、こちらから御連絡させていただきます。 登録は http://www.134net.com/ra/html/regist.html 上記より、アカウントを発行しておりますので、ご登録くださいませ。 お時間がありましたら、拝見していただければと思います。 http://www.134net.com ------------------------- 湘南パラダイスマガジン 編集部　深沢 0463-51-5722 fukazawa@134net.com http://www.134net.com/ ------------------------- From just@letterror.com Wed Dec 26 19:29:20 2001 From: just@letterror.com (Just van Rossum) Date: Wed, 26 Dec 2001 20:29:20 +0100 Subject: [Pythonmac-SIG] Please test the 2.2 installer In-Reply-To: <20011225224110.C251AE8448@oratrix.oratrix.nl> Message-ID: <20011226202922-r01010800-ef2ba092-0922-010c@10.0.0.23> Jack Jansen wrote: > The only problem I'm aware of with the IDE is that the multicolumn > browser with reveal triangles looks absolutely wierd on OSX. That's something I hope I could fix before the release, but then I had to go on holiday instead ;-) I'll try and fix this soon. (It's not just the appearance that's broken, the browser logic should also be adapted to 2.2...) Just From jack@oratrix.nl Wed Dec 26 21:14:08 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 26 Dec 2001 22:14:08 +0100 Subject: [Pythonmac-SIG] Using slash-seperated paths for creating FSSp ecs (was: Mach-O MacPython IDE!!!) In-Reply-To: Message by "Schollnick, Benjamin" , Wed, 26 Dec 2001 08:37:53 -0500 , Message-ID: <20011226211413.36073E8448@oratrix.oratrix.nl> Recently, "Schollnick, Benjamin" said: > print "path: ", create_platform_path (None) > print "path: ", create_platform_path ( *["develope"] ) > print "path: ", create_platform_path ( *["develope", "bas_common"] ) > print "path: ", create_platform_path ( *["temp", "delete", "me"] ) > test = ["this", "is", "the", "path"] > print "path: ", create_platform_path (*test) I was going to say that I like it too, and I was going to suggest we drop the idea with the python-dev people for inclusion in all platforms, but then I started thinking about it a little more and I realised two things. 1. Something like this will never fly for Windows, where the first component, the disk name, is magic. Actually, it's also uncertain whether it will fly for Mac OS X: the colon-paths start with a disk name (which is somewhat magic) while the / path is a standard unix path. If you're not on the system disk a path like diskname:dirname:filename will become /Volumes/diskname/dirname/filename. 2. We already have a perfectly well-defined way to specify pathnames and their conversion between platform syntaxes: URLs. An url2pathname() followed by basejoin() followed by pathname2url() should always do the trick. -- 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 Benjamin.Schollnick@usa.xerox.com Thu Dec 27 13:01:07 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Thu, 27 Dec 2001 08:01:07 -0500 Subject: [Pythonmac-SIG] Using slash-seperated paths for creating FSSp ecs (was: Mach-O MacPython IDE!!!) Message-ID: Jack, > 2. We already have a perfectly well-defined way to specify pathnames > and their conversion between platform syntaxes: URLs. An > url2pathname() followed by basejoin() followed by pathname2url() > should always do the trick. It appears I've missed some feature creap in Python... When was url2pathname / pathname2url added? I'm assuming it's in URLLIB? And while I recognize that file://blah/blah/blah.exe is certainly a path, isn't that forcing us to go through some extra hoops? I'm not sure (especially since v2.1 Docs don't seem to document url2pathname, etc) where the url2pathname is simplier. Don't you still have the same issues? > component, the disk name, is magic. Actually, it's also uncertain > whether it will fly for Mac OS X: the colon-paths start with a disk > name (which is somewhat magic) while the / path is a standard unix > path. If you're not on the system disk a path like > diskname:dirname:filename will become > /Volumes/diskname/dirname/filename. That really really is OS dependant (Win2000) ...Oh.... You mean the *drive letter*. If your constructing from scratch, that might be a issue... But I rarely construct programs that require me to "assign" a drive. What I usually do is something along this line: program_path = os.getcwd() file_handle = os.join(program_path, "working_directory") Plus, I usually use some form of relative path instead of absolute paths. I think I've started to ramble slightly... Let me sum up. 1) I think I may have missed part of your viewpoint... Because #4 is obvious to me.... but... >g< 2) Platform Agnostic good... ... It let's us move our programs without having to customize... (So either way, url2path or using os.join, but I think we need to make note of a working method and do our best to wrap it in a convience function) 3) I'm afraid that if we move away from a obvious os.join, that we will be obscuring our code too much. (KISS principal at work) 4) I honestly don't think that the programs can make the absolute paths, unless they are "custom" programs (or it's in a config file that is read). Yes the code needs to be able to manipulate one, but that doesn't mean it has to validate it. For example: c:\windows\system32\drivers\etc\hosts isn't going to automatically be mapped to: guyver:system:hosts That would require me to examine the code/configuration file, or whatever and manually change it. - Benjamin -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Wednesday, December 26, 2001 4:14 PM To: Schollnick, Benjamin Cc: 'Donovan Preston'; pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Using slash-seperated paths for creating FSSp ecs (was: Mach-O MacPython IDE!!!) Recently, "Schollnick, Benjamin" said: > print "path: ", create_platform_path (None) > print "path: ", create_platform_path ( *["develope"] ) > print "path: ", create_platform_path ( *["develope", "bas_common"] ) > print "path: ", create_platform_path ( *["temp", "delete", "me"] ) > test = ["this", "is", "the", "path"] > print "path: ", create_platform_path (*test) I was going to say that I like it too, and I was going to suggest we drop the idea with the python-dev people for inclusion in all platforms, but then I started thinking about it a little more and I realised two things. 1. Something like this will never fly for Windows, where the first component, the disk name, is magic. Actually, it's also uncertain whether it will fly for Mac OS X: the colon-paths start with a disk name (which is somewhat magic) while the / path is a standard unix path. If you're not on the system disk a path like diskname:dirname:filename will become /Volumes/diskname/dirname/filename. 2. We already have a perfectly well-defined way to specify pathnames and their conversion between platform syntaxes: URLs. An url2pathname() followed by basejoin() followed by pathname2url() should always do the trick. -- 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 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From Benjamin.Schollnick@usa.xerox.com Thu Dec 27 19:12:38 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Thu, 27 Dec 2001 14:12:38 -0500 Subject: [Pythonmac-SIG] url2pathname...pathname2url? Message-ID: Jack & company, I just went through the python.org doc's, and the v2.2 changes docs, and can't find any mention of url2pathname..... (I didn't search bu Jack, were you suggesting the creation of those functions? Or are they contained in a non-core module, that I'm not aware of? - Benjamin From jack@oratrix.nl Thu Dec 27 21:36:59 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 27 Dec 2001 22:36:59 +0100 Subject: [Pythonmac-SIG] Re: url2pathname...pathname2url? In-Reply-To: Message by "Schollnick, Benjamin" , Thu, 27 Dec 2001 14:12:38 -0500 , Message-ID: <20011227213704.C59E2E8448@oratrix.oratrix.nl> Recently, "Schollnick, Benjamin" said: > Jack & company, > > I just went through the python.org doc's, and the v2.2 changes > docs, and can't find any mention of url2pathname..... (I didn't search bu Hmm, is it undocumented? They're defined in macurl2path (and nturl2path, rourl2path, etc), and I think they're included from there into urllib. -- 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 adam@switchedonsoftware.com Sat Dec 29 11:27:52 2001 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Sat, 29 Dec 2001 22:27:52 +1100 Subject: [Pythonmac-SIG] Python 2.2 Framework _REENTRANT Message-ID: <19190A84-FC4F-11D5-80CA-0030656E8732@switchedonsoftware.com> Hi, I'm developing a Mach-O Carbon application that embeds Python and I'm getting a few funny warnings when I try to compile it. I've installed the Unix version of Python with the commands "./configure --enable-framework && make && make framework" install as per documentation and that all seems to work fine. But when I compile my application with: cc *.c -framework Carbon -framework Python I get the following warnings: (widget.h is one of my files, line 6 #includes ) widget.h:6: warning: could not use precompiled header '/System/Library/Frameworks/Carbon.framework/Headers/Carbon.p', because: widget.h:6: warning: #ifdef '_REENTRANT' not defined when precompiled, but now defined: widget.h:6: warning: at /Library/Frameworks/Python.framework/Headers/pyconfig.h:208 Lines 207 and 208 in pyconfig.h are: /* Define to force use of thread-safe errno, h_errno, and other functions */ #define _REENTRANT 1 Commenting out this line removes all warnings. Everything seems to work fine, but could commenting this line out cause any problems? Kind regards, Adam Eijdenberg Switched on Software adam@switchedonsoftware.com From blacktrash@gmx.net Sat Dec 29 13:09:46 2001 From: blacktrash@gmx.net (Christian Ebert) Date: Sat, 29 Dec 2001 14:09:46 +0100 Subject: [Pythonmac-SIG] Newbie-Q: test & applets Message-ID: <20011229141029-r01010800-958cece6-0922-0108@212.184.142.103> Hi there, I am completely new to Python and more or less to programming too. So bear with me or point me in the right direction if this has already been covered somewhere else. 1. After installing 2.2 I ran test.regrtest - everything went fine when I typed the commands directly in the interpreter. However if I run test.regrtest from IDE or if I run import test.autotest I get: [...] test_threaded_import test test_threaded_import skipped -- can't run when import lock is held [...] 1 skip unexpected on mac: test_threaded_import Is this the regular behaviour? 2. If I save a little "Hello world" script as applet and try to run it I get the message: "PythonCore not found". After I run ConfigurePythonClassic (the script imports Tkinter) everything works fine - till I restart my computer, then I have to run ConfigurePythonClassic again to make it work. More or less the same little script, but with import W, can only be run from within IDE. Saved and run as applet it returns: Traceback (most recent call last): File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Scripts:Hello_world.py", line 1, in ? import W File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Mac:Tools:IDE:W.py", line 5, in ? from Wbase import * File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Mac:Tools:IDE:Wbase.py", line 698, in ? _cursors = { MacOS.Error: (-192, 'Resource not found') I added $(PYTHON):Mac:Tools and $(PYTHON):Mac:Tools:IDE in preferences. What am I missing? Some QuickDraw module? (Mac OS D1-9.2.2) TIA Christian From jack@oratrix.nl Sat Dec 29 16:21:05 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 29 Dec 2001 17:21:05 +0100 Subject: [Pythonmac-SIG] Python 2.2 Framework _REENTRANT In-Reply-To: Message by Adam Eijdenberg , Sat, 29 Dec 2001 22:27:52 +1100 , <19190A84-FC4F-11D5-80CA-0030656E8732@switchedonsoftware.com> Message-ID: <20011229162110.44F99E8448@oratrix.oratrix.nl> You should probably compile without preprocessed headers (sorry, not behind my OSX machine right now so I don't know the exact command line switch). The problem is that Python needs the _REENTRANT macro defined (for the reason stated in pyconfig.h, so that you get thread-safe errno and such), but that the set of precompile headers supplied by Apple was generated with it undefined. This is a general problem with precompiled headers: they only work if you don't use any special switches. Recently, Adam Eijdenberg said: > Hi, > > I'm developing a Mach-O Carbon application that embeds Python and I'm > getting a few funny warnings when I try to compile it. > > I've installed the Unix version of Python with the commands "./configure > --enable-framework && make && make framework" install as per > documentation and that all seems to work fine. > > But when I compile my application with: > cc *.c -framework Carbon -framework Python > > I get the following warnings: (widget.h is one of my files, line 6 > #includes ) > > widget.h:6: warning: could not use precompiled header > '/System/Library/Frameworks/Carbon.framework/Headers/Carbon.p', because: > widget.h:6: warning: #ifdef '_REENTRANT' not defined when precompiled, > but now defined: > widget.h:6: warning: at > /Library/Frameworks/Python.framework/Headers/pyconfig.h:208 > > Lines 207 and 208 in pyconfig.h are: > > /* Define to force use of thread-safe errno, h_errno, and other > functions */ > #define _REENTRANT 1 > > Commenting out this line removes all warnings. > > Everything seems to work fine, but could commenting this line out cause > any problems? > > Kind regards, > Adam Eijdenberg > > Switched on Software > adam@switchedonsoftware.com > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- 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 adam@switchedonsoftware.com Sun Dec 30 01:50:32 2001 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Sun, 30 Dec 2001 12:50:32 +1100 Subject: [Pythonmac-SIG] Python 2.2 Framework _REENTRANT In-Reply-To: <20011229162110.44F99E8448@oratrix.oratrix.nl> Message-ID: <9BFCC316-FCC7-11D5-80CA-0030656E8732@switchedonsoftware.com> Jack, Firstly, thanks for your response. > You should probably compile without preprocessed headers (sorry, not > behind my OSX machine right now so I don't know the exact command line > switch). No switch necessary, it just shoots out about a billion warnings telling me that it can't use the precompiled headers. > The problem is that Python needs the _REENTRANT macro defined (for the > reason stated in pyconfig.h, so that you get thread-safe errno and > such), but that the set of precompile headers supplied by Apple was > generated with it undefined. This is a general problem with > precompiled headers: they only work if you don't use any special > switches. Fair enough. Is it feasible to recompile the precompiled headers so that this will work? 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@oratrix.nl Sun Dec 30 12:15:52 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 30 Dec 2001 13:15:52 +0100 Subject: [Pythonmac-SIG] Python 2.2 Framework _REENTRANT In-Reply-To: Message by Adam Eijdenberg , Sun, 30 Dec 2001 12:50:32 +1100 , <9BFCC316-FCC7-11D5-80CA-0030656E8732@switchedonsoftware.com> Message-ID: <20011230121557.ADDF6E8448@oratrix.oratrix.nl> Recently, Adam Eijdenberg said: > > You should probably compile without preprocessed headers (sorry, not > > behind my OSX machine right now so I don't know the exact command line > > switch). > > No switch necessary, it just shoots out about a billion warnings telling > me that it can't use the precompiled headers. That's right, but if you add the switch to the commandline it won't even try the precompiled headers and you won't get the warnings. > > The problem is that Python needs the _REENTRANT macro defined (for the > > reason stated in pyconfig.h, so that you get thread-safe errno and > > such), but that the set of precompile headers supplied by Apple was > > generated with it undefined. This is a general problem with > > precompiled headers: they only work if you don't use any special > > switches. > > Fair enough. Is it feasible to recompile the precompiled headers so that > this will work? That has the disadvantage that all other compilations, which expect _REENTRANT to be undefined, will give the reverse warnings:-( But if you really want to do this: yes, there's a commandline tool that regenrates them. "man -k precompiled" or looking up precompiled headers in Developer section of Apple Help should give you the invocation. The way Apple does precompiled headers (automatically using the precompiled header if applicable) breaks down when defines on which the header depends are different. Incidentally, the way MetroWerks does precompiled headers, where you have to manually precompile them into a .pch file and then #incluyde the .pch in stead of the .h file, is also far from ideal. I don't know of any precompiled header implementation that does it right... (At least the Apple implementation notices the fact that the symbol has a different value from what was used to generate the preprocessed header, so it can fallback to using non-preprocessed header files). -- 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 adam@switchedonsoftware.com Sun Dec 30 13:21:18 2001 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Mon, 31 Dec 2001 00:21:18 +1100 Subject: [Pythonmac-SIG] Python 2.2 Framework linking and distributing (was: _REENTRANT) In-Reply-To: <20011230121557.ADDF6E8448@oratrix.oratrix.nl> Message-ID: <1C1B8F38-FD28-11D5-89C6-0030656E8732@switchedonsoftware.com> > That's right, but if you add the switch to the commandline it won't > even try the precompiled headers and you won't get the warnings. Thanks again for your detailed reply. If anyone's interested the switch is: -Wno-precomp resulting in: cc -Wno-precomp *.c -framework Carbon -framework Python > That has the disadvantage that all other compilations, which expect > _REENTRANT to be undefined, will give the reverse warnings:-( But if > you really want to do this: yes, there's a commandline tool that > regenrates them. "man -k precompiled" or looking up precompiled > headers in Developer section of Apple Help should give you the > invocation. No worries, just found the docs. That solved, this brings me up to query number 2. After compiling I get the following linkage warnings: /usr/bin/ld: warning unused multiple definitions of symbol __objcInit "link editor" definition of __objcInit in section (__DATA,__common) /usr/lib/libobjc.A.dylib(objc-runtime.o) unused definition of __objcInit If I configure Python with --disable-toolbox-glue then I don't get these. Will those cause any problems or can I safely ignore them? (not that I'm too fussed as I don't need any of the Carbon stuff) And, if I compile as per above, does this mean that all I have to do is copy my executable and the Python.framework to another machine and it will all... just work? 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 adam@switchedonsoftware.com Sun Dec 30 13:44:38 2001 From: adam@switchedonsoftware.com (Adam Eijdenberg) Date: Mon, 31 Dec 2001 00:44:38 +1100 Subject: [Pythonmac-SIG] Python 2.2 Framework _REENTRANT followup In-Reply-To: <20011230121557.ADDF6E8448@oratrix.oratrix.nl> Message-ID: <5E0CF4FA-FD2B-11D5-89C6-0030656E8732@switchedonsoftware.com> > That's right, but if you add the switch to the commandline it won't > even try the precompiled headers and you won't get the warnings. Or, if you don't want to spend five minutes waiting to compile, move one line in your sources file to change: #include #include #include so it reads: #include #include #include and ta da, no more precompiled header warnings. (and then feel like a real idiot for wasting everyone's time! :) 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@oratrix.nl Sun Dec 30 16:09:23 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 30 Dec 2001 17:09:23 +0100 Subject: [Pythonmac-SIG] Python 2.2 Framework _REENTRANT followup In-Reply-To: Message by Adam Eijdenberg , Mon, 31 Dec 2001 00:44:38 +1100 , <5E0CF4FA-FD2B-11D5-89C6-0030656E8732@switchedonsoftware.com> Message-ID: <20011230160928.DC149E8448@oratrix.oratrix.nl> Recently, Adam Eijdenberg said: > Or, if you don't want to spend five minutes waiting to compile, move one > line in your sources file to change: > > #include > #include > #include > > so it reads: > > #include > #include > #include > > and ta da, no more precompiled header warnings. I'm not sure that this is safe. Python, by defining _REENTRANT, may have changed how the C runtime system works. And if the Python core expects it to work one way and your code expects it to work another way you may run in to problems. But if the~ _REENTRANT stuff only has to do with the way you access errno in multithreaded programs you might well be safe doing this. -- 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 halazar@media.mit.edu Sun Dec 30 16:36:21 2001 From: halazar@media.mit.edu (Michael Halle) Date: Sun, 30 Dec 2001 16:36:21 +0000 Subject: [Pythonmac-SIG] strange Tkinter event behavior Message-ID: <200112302136.QAA01586@ml.media.mit.edu> Hello, I've been developing my first Mac Python/Tkinter application, and I've come across strange event processing behavior that perhaps someone else has seen before. I'm running MacOS 9.2.1 and Python 2.1.1 and now 2.2. First, the initial mouse click to the application seem to be lost in some cases. For example, try Demos:tkinter:matt:dialog-box.py . The window has focus, but the first mouse click doesn't do anything. A second click works. This behavior is annoying, but not fatal. On the other hand, I would also like it if I could make my MacPython application be more friendly in dealing with other running applications. I understand that tk-based apps don't give lots of time back to the system (as a side note, are there convenient pointers for tuning these params?) but I'm seeing something stranger in some applications. When I run NiftyTelnet at the same time, for instance, its event queue gets screwed up: the printing of output characters is one character behind the processing of typed input characters. Some other applications seem to have the same kinds of problems. Generally, but not always, everything clears up when the python-based app terminates. In my Mac-challenged Unix-trained mind, these "lost or delayed" event problems seem potentially related, so I raise them here in the same message. It also looks like the problem's outside of Tk itself, as Wish 8.3.3 doesn't produce the same problems. I would appreciate any help anyone else can give me. The project is especially frustrating because this code is a full and fast rewrite of a Java app that would crash deep in the VM when accessing the serial port and the network at the same time. I can't say that this Mac development stuff it giving me the warm fuzzies.... Thanks. Michael Halle mhalle@media.mit.edu From Jack.Jansen@cwi.nl Mon Dec 31 13:39:09 2001 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 31 Dec 2001 14:39:09 +0100 Subject: [Pythonmac-SIG] Offline for a while Message-ID: <200112311339.fBVDd9O16531@spruit.ins.cwi.nl> Folks, I will probably be unreacable by mail for the next few days, the backup we put in for our move seems to be non-functional. So don't worry about bounceds to the oratrix.nl address, all should be well again on wednseday or thusrday (and backspace also doesn't work on this machine:-) Jack From ariza@flexatone.com Mon Dec 31 19:13:23 2001 From: ariza@flexatone.com (christopher ariza) Date: Mon, 31 Dec 2001 14:13:23 -0500 (EST) Subject: [Pythonmac-SIG] strange Tkinter event behavior In-Reply-To: Message-ID: it has been mentioned many times before, but Tkinter on MacOS Classic (pre OSX) almost always has strange behavior. for instance, in my experience, key-repeating is always broken in every application (BBEdit, for example) when a Python/Tkinter app is running. but there is a better way (and paricularily for those "mac-challenged unix-trained" people). this in no way helps you if you have to run MacOS 9x, but this works so well and easily it needs repeated mentioning: 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 hassel. did i say it was easy? of course, we will someday have Tk in Aqua, but in the meantime... christopher ariza