From david@meakins.lan.mcgill.ca Mon Sep 1 19:28:00 1997 From: david@meakins.lan.mcgill.ca (David Eidelman) Date: Mon, 01 Sep 1997 14:28:00 -0400 Subject: [PYTHONMAC-SIG] Numerical Python on the Mac Message-ID: <340B0930.66C2D02E@meakins.lan.mcgill.ca> Does anyone know if the numerical python extensions developed by the matrix-sig have been (are being?) ported to the Mac? The current web page suggests that this is going on but has not been updated in some months. If a port is not underway, could anyone provide me with pointers about how to go about doing a port? Thanks David Eidelman Meakins-Christie Laboratories McGill University _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Tue Sep 2 09:52:49 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 02 Sep 1997 10:52:49 +0200 Subject: [PYTHONMAC-SIG] Numerical Python on the Mac In-Reply-To: Message by David Eidelman , Mon, 01 Sep 1997 14:28:00 -0400 , <340B0930.66C2D02E@meakins.lan.mcgill.ca> Message-ID: > Does anyone know if the numerical python extensions developed by the > matrix-sig have been (are being?) ported to the Mac? It's available at . I'm pretty sure I told the numerics folks about this, but apparently they haven't updated their page. Starting with the 1.5 distribution NumPy and Pil will be optional items in the standard Mac distribution. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Thomas.Tiemann@ipk.fhg.de Wed Sep 3 12:39:53 1997 From: Thomas.Tiemann@ipk.fhg.de (Thomas Tiemann) Date: Wed, 03 Sep 1997 13:39:53 +0200 Subject: [PYTHONMAC-SIG] Python/AppleScript Message-ID: <340D4C85.5703@ipk.fhg.de> Hi, I'm Thomas and I have a question to Python and AppleScript. Is it possible to handle Data between Python-Scripts and Apple-Scripts. Thomas _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From just@knoware.nl Wed Sep 3 15:00:34 1997 From: just@knoware.nl (Just van Rossum) Date: Wed, 3 Sep 1997 15:00:34 +0100 Subject: [PYTHONMAC-SIG] Python/AppleScript In-Reply-To: <340D4C85.5703@ipk.fhg.de> Message-ID: At 1:39 PM +0200 9/3/97, Thomas Tiemann wrote: >Hi, I'm Thomas and I have a question to Python and AppleScript. Is it >possible to handle Data between Python-Scripts and Apple-Scripts. Yes it is. See AEServer.py and MiniApplication.py for a basic framework to build a simple AE server application. In Mac:Demo:cgi you'll find a little demo that uses them. Just _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From david@meakins.lan.mcgill.ca Wed Sep 3 14:10:58 1997 From: david@meakins.lan.mcgill.ca (David Eidelman) Date: Wed, 03 Sep 1997 09:10:58 -0400 Subject: [PYTHONMAC-SIG] NumPy release Message-ID: <340D61DC.CFEC3C7@meakins.lan.mcgill.ca> Thanks very much for the prompt reply regarding the Python Numeric package. I note however that there is a discrepancy between the binaries and the source Jack's FTP directory. The source is for 1.0b3, the binaries for one of the "a" releases. I briefly tried building the sources using CW Pro1 but encountered a number of not found errors when the project opened. Are the PPC binaries for 1.0b3 available? David -- David Eidelman, MD Associate Professor Meakins-Christie Laboratories McGill University 3626 rue St. Urbain Montreal, Quebec, Canada H2X 2P2 tel: (514) 398-3864 fax: (514) 398-7483 email: david@meakins.lan.mcgill.ca _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From A.M.INGRALDI@larc.nasa.gov Wed Sep 3 15:49:24 1997 From: A.M.INGRALDI@larc.nasa.gov (Anthony M. Ingraldi) Date: Wed, 3 Sep 1997 10:49:24 -0400 Subject: [PYTHONMAC-SIG] daemons on the Mac In-Reply-To: References: Message by "Anthony M. Ingraldi" , Fri, 29 Aug 1997 15:00:35 -0400 , Message-ID: At 10:34 PM +0200 8/31/97, Jack Jansen wrote: >Well, I tried your script under 1.5a3 (which'll be available to PSA >members sometime this week) and it works fine (even with the >listen(0)). My error... listen(0) works under 1.4 as well. I previously assumed that when the interface locked up, that the whole app was dead. -- Tony Ingraldi | e-mail: A.M.INGRALDI@LaRC.NASA.GOV NASA Langley Research Center | Mail Stop 267 | Phone : (757) 864-3039 Hampton, VA 23681-0001 | Fax : (757) 864-7892 _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From managan@llnl.gov Wed Sep 3 17:36:42 1997 From: managan@llnl.gov (Rob Managan) Date: Wed, 3 Sep 1997 09:36:42 -0700 Subject: [PYTHONMAC-SIG] NumPy release In-Reply-To: <340D61DC.CFEC3C7@meakins.lan.mcgill.ca> Message-ID: At 9:10 AM -0400 9/3/97, David Eidelman wrote: >Thanks very much for the prompt reply regarding the Python Numeric package. I >note however that there is a discrepancy between the binaries and the source >Jack's FTP directory. The source is for 1.0b3, the binaries for one of the >"a" releases. > >I briefly tried building the sources using CW Pro1 but encountered a number of >not found errors when the project opened. > >Are the PPC binaries for 1.0b3 available? > I just went through the exercise of compiling NumPy with CW 10. I can email the shared library to those who need it. Reply if you do. It is 300k when stuffed. *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan mailto://managan@llnl.gov LLNL ph: 510-423-0903 P.O. Box 808, L-183 FAX: 510-423-5804 Livermore, CA 94551-0808 _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Thu Sep 4 12:46:11 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 04 Sep 1997 13:46:11 +0200 Subject: [PYTHONMAC-SIG] Python 1.5a3 available for PSA members Message-ID: Folks, I just released (with a lot of help from Just) a 1.5a3 distribution to the PSA members. If you're not a PSA member but think you could contribute to the alpha testing send me a mail and try to convince me to send you a copy, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Thu Sep 11 23:17:59 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Thu, 11 Sep 1997 18:17:59 -0400 (EDT) Subject: [PYTHONMAC-SIG] MacPython 1.5 questions and suggestions Message-ID: Trying out an old plugin with Mac Python 1.5a3, I get an error from the import because the core library is named "PythonCore 1.5a3" instead of "PythonCorePPC" as previously. Is this name change intention because there are significant enough mods that 1.4 plugins *shouldn't* work with 1.5 Core ? (OR) Is the name change intentional so that you can fiddle with the new alphas and keep the old core around without any problems ? (OR) Is this name change intentional because nobody wanted to muck about and figure out how library versioning works on the Mac. If it's any other than the first, I may try to look into it and see if there is a better way. ( That's the point of shared libraries -- the ought to be drop replacable unless the interface has changed. ( And I keep running into things (MacSWIG was the latest), that won't run under MacOS 8 because they use a beta of Tk8.0. )) What do you think about splitting the Tk library out of the Core PPC Library ? Although, we might still distribute it in the Python binary distribution, so that folks aren't required to gather up different bits from around the net -- but they could also upgrade Tk, if an 8.01 appears, without rebuilding Python. ( assuming the Tck/Tk folks don't much with the names also. ) Also, it could be possible to use a weak import so that it will run without the Tk libraries present. ( This requires a minor change to the source to check that the library entry point is not Null before calling the init. ) ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Thu Sep 11 23:21:20 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Thu, 11 Sep 1997 18:21:20 -0400 Subject: [PYTHONMAC-SIG] Re: MacPython 1.5 questions and suggestions In-Reply-To: Your message of "Thu, 11 Sep 1997 18:17:59 EDT." References: Message-ID: <199709112221.SAA28477@eric.CNRI.Reston.Va.US> > What do you think about splitting the Tk library out of the Core PPC > Library ? Although, we might still distribute it in the Python > binary distribution, so that folks aren't required to gather up > different bits from around the net -- but they could also upgrade > Tk, if an 8.01 appears, without rebuilding Python. ( assuming > the Tck/Tk folks don't much with the names also. ) This sounds like a good idea. I do it this way for Windows -- _tkinter is built standard but as a shared library. --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Thu Sep 11 23:43:14 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Thu, 11 Sep 1997 18:43:14 -0400 (EDT) Subject: [PYTHONMAC-SIG] MacPython 1.5 questions and suggestions In-Reply-To: Message-ID: On Thu, 11 Sep 1997, I wrote before looking: > Also, it could be possible to use a weak import so that it will > run without the Tk libraries present. ( This requires a minor change > to the source to check that the library entry point is not Null > before calling the init. ) Well -- all things being equal, it ought to be that simple, however, on looking at the (1.4) _tkinter.c source, I see that you had to add some Mac specific stuff to the import already, to be able to find resources properly. I don't know if the "weak import" trick would have and interactions with that code, but I'll look into it if I can. ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Fri Sep 12 09:54:17 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 12 Sep 1997 10:54:17 +0200 Subject: [PYTHONMAC-SIG] Re: MacPython 1.5 questions and suggestions In-Reply-To: Message by "Steven D. Majewski" , Thu, 11 Sep 1997 18:17:59 -0400 (EDT) , Message-ID: It's actually not the file name that's important but the fragment name. I changed it around 1.4, so that you could have a 1.4 working distribution and a 1.5alfa distribution on the same machine without the two interfering with each other. In the case of 1.4 and 1.5a?? this is a good thing, as 1.4 used the plaugher C libraries and 1.5 uses MSL, so if a plugin ever did some I/O it would break spectacularly. Besides that I'm also strict in version-numbering the fragments: each fragment implements a single version. It is possible to change that with the fragment version numbering scheme: I could say something like "this PythonCore fragment implements interface version 100 but is still backwards-compatible with interfaces from version 90 onwards". However, since the interface to PythonCore is so complex (it is essentially comprised of all external symbols and their arguments) I cannot really guarantee that any single module that works with one version continues to work with the next. The only way this could really change is when Guido defines an external interface: a set of routines and addresses that plugin modules are allowed to use. We could then export only these symbols, and increment the version numbers whenever there is a change here (compatible changes like extra routines increment only the "most recent" version number, incompatible changes like removal of routines or changes in parameters increment the most recent version number and set the oldest-version-supported to the same value as the most recent). In practice I think that there's little to be gained here: so many things change between Python releases that you'll still be stuck with a complete new version probably. It *is* a nuisance that you have to recompile all your extension modules, even those for which you know that they can still function with newer Pythons because you use little or no functionality of the PythonCore, but I see no practical solution to it right away. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Fri Sep 12 09:56:30 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 12 Sep 1997 10:56:30 +0200 Subject: [PYTHONMAC-SIG] Re: MacPython 1.5 questions and suggestions In-Reply-To: Message by Guido van Rossum , Thu, 11 Sep 1997 18:21:20 -0400 , <199709112221.SAA28477@eric.CNRI.Reston.Va.US> Message-ID: > > What do you think about splitting the Tk library out of the Core PPC > > Library ? > > This sounds like a good idea. I do it this way for Windows -- > _tkinter is built standard but as a shared library. I had missed this bit of Steven's post, and I'm confused. Tk isn't in the core library, it is in the _tkinter plugin. So, it's already separated, and you can already update it if a new version becomes available... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Fri Sep 12 14:58:04 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Fri, 12 Sep 1997 09:58:04 -0400 (EDT) Subject: [PYTHONMAC-SIG] Re: MacPython 1.5 questions and suggestions In-Reply-To: Message-ID: On Fri, 12 Sep 1997, Jack Jansen wrote: > > > What do you think about splitting the Tk library out of the Core PPC > > > Library ? > > > > This sounds like a good idea. I do it this way for Windows -- > > _tkinter is built standard but as a shared library. > > I had missed this bit of Steven's post, and I'm confused. Tk isn't in the core > library, it is in the _tkinter plugin. So, it's already separated, and you can > already update it if a new version becomes available... Thanks for the clarification -- I didn't see a separate Tk shared library, and I made the wrong assumption. However, the same idea applies: linking _tkinter to a shared Tk lib would make it easier to drop in a new Tk. I know that's a build option -- I'm suggesting it for the standard dist. since the folks who don't want to or can't rebuild it are the ones who would most appreciate a drop-in upgrade. ( I don't know what the future release plans for Tk are -- for all I know, 8.0 may be stable - but you know: generals always fighting the last war ... we've been thru quite a stream of Tk releases. ) ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Mon Sep 15 19:38:28 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: 15 Sep 97 14:38:28 -0400 Subject: _Files vs __files (&1.4 vs 1.5a3) was: [PYTHONMAC-SIG] Mac SWIG & dynamic loading MacPython modules Message-ID: An old thread, so first, some history: Long, long ago, I wrote: >Has anyone gotten MacSWIG to work with dynamically loaded Python >modules ? I keep getting link problems with the global "__file" >variable, which I assume, should not be exported from PythonCorePPC, [...] On Thu, May 29, 1997 5:41 AM, Jack Jansen wrote: > >It should definitely be exported from PythonCorePPC, otherwise you can't use >stdio in your extension. The trick is that you should put PythonCorePPC >*before* the C library in your link sequence, so that the __file symbol (and >any other shared global data) is resolved from PythonCorePPC. > >This is documented somewhere, but the fact that I can't find it right now >suggests that it might be stated a bit more clearly:-) > I had found my own temporary hack (below), which I thought might have dangerous side effects, but did appear to work, and, as I wasn't yet trying to seriously use SWIG, I didn't pursue Jack's solution >added console.stubs.c to project. > >added two lines to my wrapper function: > > #include > FILE __files[FOPEN_MAX]; > >and the SWIG example code builds (with CW11), imports, dynamically >loads and appears to run without crashing. > However, on delving into this further I find: Jack's suggestion does not work with MacPython 1.4 -- There is a "_Files" among the exported symbols, but not a "__files" ( Checking both in the export file in the source distrib, and using DumpPEF to look at the symbol table from the PPC lib in the binary distribution. ) DumpPEF show that the symbol "__files" does appear in "PythonCore 1.5a3" Replacing the 1.4 PythonCorePPC with than one and rebuilding does link without any errors. Running Python 1.5a3 and importing the example module produces this warning ( however, the module does appear to work properly. ) Python 1.5a3 (#0, Aug 4 1997, 16:50:52) [CW PPC w/GUSI w/MSL] Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import example WARNING: Python C API version mismatch for module example: This Python has API version 1007, module example has version 1006. >>> dir() ['__builtins__', '__doc__', '__name__', 'example'] >>> dir(example) ['__doc__', '__file__', '__name__', 'cvar', 'fact', 'get_time', 'mod'] >>> example.__file__ 'example.ppc.slb' >>> example.cvar Global variables { My_variable } >>> example.fact >>> example.fact(7) 5040 >>> example.get_time() 'Mon Sep 15 14:01:31 1997\012' >>> example.mod(7,4 ) 3 >>> - Steve Majewski _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Mon Sep 15 23:34:11 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Mon, 15 Sep 1997 18:34:11 -0400 (EDT) Subject: _Files vs __files (&1.4 vs 1.5a3) was: [PYTHONMAC-SIG] Mac SWIG & dynamic loading MacPython modules In-Reply-To: Message-ID: On looking further at the dump output, I'm guessing that this symbol disagreement is a result of the CW10 Old Libraries vs. CW11/CWPro-1 MSL switch. On 15 Sep 1997, Steven D. Majewski wrote: > > Jack's suggestion does not work with MacPython 1.4 -- > There is a "_Files" among the exported symbols, but not a "__files" > ( Checking both in the export file in the source distrib, and using DumpPEF > to look at the symbol table from the PPC lib in the binary distribution. ) > > > DumpPEF show that the symbol "__files" does appear in "PythonCore 1.5a3" > Replacing the 1.4 PythonCorePPC with than one and rebuilding does link > without any errors. Running Python 1.5a3 and importing the example > module produces this warning ( however, the module does appear to work > properly. ) > ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Tue Sep 16 00:48:38 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Mon, 15 Sep 1997 19:48:38 -0400 (EDT) Subject: _Files vs __files (&1.4 vs 1.5a3) was: [PYTHONMAC-SIG] Mac SWIG & dynamic loading MacPython modules In-Reply-To: Message-ID: On delving even deeper, I find that this is indeed the result of the change from the old Plumb Hall "(Obsolete ANSI Libraries)" that was standard up to CW10, and the newer MSL in CW11 & CW-Pro. Python 1.4 was built with the old libraries. Python 1.5a3 was build with the new libraries. _Files is exported from the old libraries. __files is exported from the new libraries. Replacing MSL ShLibRuntime.Lib with ShLibRuntime.Lib from the "(Obsolete ANSI Libraries)" folder, changing the access paths to get the right includes from that folder, adding "::Objects:cobject.c" to the project, and putting the 1.4 PythonCorePPC lib back yields a project that properly builds a working example module from the MacSwig distribution. ( Re: a previous thread on pythonmac-sig@python.org, and privately with Jack & Guido: It looks like it will indeed me necessary -- at least going from 1.4 to 1.5, to recompile all extensions: if the Python C-API changes don't get you, then the C Runtime Lib changes will! ) [ Thank goodness I've got Elba Ramalho singing "Odile - Odila" on the Afro Brasil CD to console me. ] On 15 Sep 1997, Steven D. Majewski wrote: > However, on delving into this further I find: > > Jack's suggestion does not work with MacPython 1.4 -- > There is a "_Files" among the exported symbols, but not a "__files" > ( Checking both in the export file in the source distrib, and using DumpPEF > to look at the symbol table from the PPC lib in the binary distribution. ) > > > DumpPEF show that the symbol "__files" does appear in "PythonCore 1.5a3" > Replacing the 1.4 PythonCorePPC with than one and rebuilding does link > without any errors. Running Python 1.5a3 and importing the example > module produces this warning ( however, the module does appear to work > properly. ) > ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From ranch1@earthlink.net Tue Sep 16 03:20:23 1997 From: ranch1@earthlink.net (Tom Fetherston) Date: Mon, 15 Sep 1997 22:20:23 -0400 Subject: [PYTHONMAC-SIG] Pod Message-ID: Hi All, Is anyone familiar with the way perl code is being documented via .pod (plain old documentation)? Seems to me that this is a natural thing for python to adopt. POD documents are just like super simple html files and have translators for make real html, man, and latex files out of them. The way paython supports multi-line strings for use as code/routine comments should integrate well with pod. Should be easily usable by a smalltalk like set of code browsers, or a standalone code inspector like the MacPerl "shuck" app (which lets you format according to pod's tags, and toggle code/code&pod/pod visiblity) should be fairly easy to do in python. Such an approach would put you ahead in the documenting game. Any thought on this? Tom _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Tue Sep 16 09:40:59 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 16 Sep 1997 10:40:59 +0200 Subject: _Files vs __files (&1.4 vs 1.5a3) was: [PYTHONMAC-SIG] Mac SWIG & dynamic loading MacPython modules In-Reply-To: Message by "Steven D. Majewski" , 15 Sep 97 14:38:28 -0400 , Message-ID: > > Jack's suggestion does not work with MacPython 1.4 -- > There is a "_Files" among the exported symbols, but not a "__files" > > DumpPEF show that the symbol "__files" does appear in "PythonCore 1.5a3" That's right: __files is the symbol used by the new MSL C library (which Python 1.5 uses, and apparently MacSWIG uses too). _Files is the symbol used by the old Plaugher C library. Mixing the two in a program that uses stdio.h is impossible, as far as I know. > Replacing the 1.4 PythonCorePPC with than one and rebuilding does link > without any errors. Running Python 1.5a3 and importing the example > module produces this warning ( however, the module does appear to work > properly. ) > > Python 1.5a3 (#0, Aug 4 1997, 16:50:52) [CW PPC w/GUSI w/MSL] > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import example > WARNING: Python C API version mismatch for module example: > This Python has API version 1007, module example has version 1006. > >>> And if you load the 1.5a3 developers kit (from the same place where you found the 1.5a3 distribution) you should be able to compile your example again without this error. This is probably a prudent thing to do, because there are quite some changes in the Python API... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Steven D. Majewski" Message-ID: On Wed, 17 Sep 1997, Jeffrey P Shell wrote: > Jonathan Wight wrote: > > I've got python 1.2 and I see 1.4 is on the FTP server. Should I > > bother > > downloading? Are the differences that great? I'm thinking of for the > > MacOS > > in particular. > > I'd upgrade. 1.5 seems to be the big difference-bringer, but much of the > MacOS stuff is improved in 1.4 over 1.2. > > > Is 1.5 about to be released 5 minutes after I download 1.4??? > > >From my understanding, there is to be one more Alpha release of Python 1.5 > (available to PSA members only), and probably a beta or three, so there's > probably two-three more weeks at least. > It's hard to remember specifics from way back then, but I believe there were a lot of improvements to the Mac and Tkinter interfaces since 1.2. Il'd go with 1.4! -- A Final 1.5 won't be around for a while yet. The major visible changes are to the C-API: If you are going to be writing extensions right away, you might want to start with 1.5 and the new documentation. More specific to the Mac, there are some changes in 1.5 to event handling in the MacOS module. There was short thread on this on the pythonmac-sig mailing list a while ago, launched by Jack with the Subject: "[PYTHONMAC-SIG] Incompatible change" Lookin in my archive, I don't see the definitive summary of what Jack decided to do, however, I see a new function: 'SchedParams' in the MacOS module and I see it used in EasyDialogs. I had assumed, from what I remembered of that discussion, that that was replacing 'EnableAppswitch', however I see both of them in MacOS. What's the plan, Jack ? [ This note cc-ed to pythonmac-sig -- if there is going to be some discussion about MacOS interfaces, we can carry it there. ] [ For the uninitiated, MacOS.EnableAppswitch toggles whether your MacPython application code, or the MacPython interpreter/application is handling events. If you write an app the has it's own event loop, unless you change this from the default, your event loop will not get all of the events and will miss some mouse down and other events. If you just want to check for a specific event, you can pass the other ones on with 'MacOS.HandleEvent(event)', so that MacPython's menu's and listener window, etc. will all still work. ] ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Thu Sep 18 10:22:55 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 18 Sep 1997 11:22:55 +0200 Subject: [PYTHONMAC-SIG] Re: Mac Python In-Reply-To: Message by "Steven D. Majewski" , Wed, 17 Sep 1997 12:50:48 -0400 (EDT) , Message-ID: > More specific to the Mac, there are some changes in 1.5 to event > handling in the MacOS module. There was short thread on this on > the pythonmac-sig mailing list a while ago, launched by Jack with > the Subject: "[PYTHONMAC-SIG] Incompatible change" > > Lookin in my archive, I don't see the definitive summary of what > Jack decided to do, however, I see a new function: 'SchedParams' > in the MacOS module and I see it used in EasyDialogs. I had > assumed, from what I remembered of that discussion, that that was > replacing 'EnableAppswitch', however I see both of them in MacOS. > > What's the plan, Jack ? MacOS.SchedParams() has indeed replaced EnableAppSwitch, but the latter is retained for compatibility reasons. But hardly anyone uses it directly (except Just), it is mainly used by Tkinter and FrameWork and such, so I might take it out for the final 1.5 release. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From guzdial@cc.gatech.edu Thu Sep 18 14:39:42 1997 From: guzdial@cc.gatech.edu (Mark Guzdial) Date: Thu, 18 Sep 1997 09:39:42 -0400 Subject: [PYTHONMAC-SIG] Re: Mac Python 1.5 Message-ID: Is there a list somewhere of changes in 1.5, new features, etc.? For example, I'm interested to hear if threads will be in the 1.5 MacPython release. Thanks! Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From wtbridgman@radix.net Thu Sep 18 23:08:00 1997 From: wtbridgman@radix.net (W.T. Bridgman) Date: Thu, 18 Sep 1997 18:08:00 -0400 Subject: [PYTHONMAC-SIG] Basic plotting using Python on the Mac Message-ID: An individual where I work (Goddard Space Flight Center) got me exploring Python for scientific applications and I've been (fairly quietly) following the activity on this mailing list. I'm particularly interested in Python as a way of freeing myself from the tyranny of RSI's $1500 price tag on IDL which is so heavily used in astronomy but for which I don't have the $$ to purchase for my home system (PowerPC 7300/200). Python's cleaner design around object-oriented features is also a big selling point. I've started experimenting with Python and the NumPy extension and am impressed with how a GUI using Tkinter operates on my Mac and a Solaris system at the lab with *no changes whatsoever*. I'm exploring rebuilding many if not of all my science analysis routines in Python but for one serious deficiency - portable graphics routines. The contributions library has graphics extensions for specific systems but apparently none for the Mac. Two questions: 1) Does anyone on this list have some basic graphics modules (that will run on a PowerPC) they would be interested in sharing. My basic needs are xy plots, scatter plots, linear & log scales. 2) I understand there is talk of starting a plotting SIG. My hope is that this will be for a PORTABLE graphics library that can work across many platforms. Whom do I contact about becoming part of that SIG? Thanks for your input. Tom Tom Bridgman, Ph.D. wtbridgman@radix.net Physics & Astronomy "Just say NO to Microsoft." _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From a.m.ingraldi@larc.nasa.gov Fri Sep 19 03:41:20 1997 From: a.m.ingraldi@larc.nasa.gov (Anthony M. Ingraldi) Date: Thu, 18 Sep 1997 22:41:20 -0400 Subject: [PYTHONMAC-SIG] Basic plotting using Python on the Mac In-Reply-To: Message-ID: At 6:08 PM -0400 9/18/97, W.T. Bridgman wrote: > >Two questions: >1) Does anyone on this list have some basic graphics modules (that will run >on a PowerPC) they would be interested in sharing. My basic needs are xy >plots, scatter plots, linear & log scales. > If you don't mind using an external application to do the plotting via AppleEvents, you can use the Macintosh port of gnuplot. I have used this approach and it is quite workable. You can even use python to act as a console window for gnuplot and send it plot commands interactively as you would in the UNIX version. I can send you the python modules that I put together to interact with gnuplot if you would like. The application itself is available at http://www.ee.gatech.edu/users/schooley/gnuplot.html Since gnuplot is available on multiple platforms, it would be possible to write a high-level interface for it that would hide the actual mechanism of interapplication communication. I've not gone that far with my modules. -- Tony Ingraldi e-mail: A.M.INGRALDI@LaRC.NASA.GOV NASA Langley Research Center Mail Stop 267 Phone : (757) 864-3039 Hampton, VA 23681-0001 Fax : (757) 864-7892 _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From da@maigret.cog.brown.edu Fri Sep 19 04:19:44 1997 From: da@maigret.cog.brown.edu (David Ascher) Date: Thu, 18 Sep 1997 23:19:44 -0400 (EDT) Subject: [PYTHONMAC-SIG] Basic plotting using Python on the Mac In-Reply-To: Message-ID: On Thu, 18 Sep 1997, Anthony M. Ingraldi wrote: > If you don't mind using an external application to do the plotting via > AppleEvents, you can use the Macintosh port of gnuplot. I have used this > approach and it is quite workable. You can even use python to act as a > console window for gnuplot and send it plot commands interactively as you > would in the UNIX version. > > I can send you the python modules that I put together to interact with > gnuplot if you would like. The application itself is available at > > http://www.ee.gatech.edu/users/schooley/gnuplot.html > > Since gnuplot is available on multiple platforms, it would be possible to > write a high-level interface for it that would hide the actual mechanism of > interapplication communication. I've not gone that far with my modules. Konrad Hinsen has also written a Gnuplot module which I believe he'll mention at SPAM-6, and I had a similar module (not worth sharing). Good topic for the PLOT-SIG... --david _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Fri Sep 19 09:19:15 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 19 Sep 1997 10:19:15 +0200 Subject: [PYTHONMAC-SIG] Re: Mac Python 1.5 In-Reply-To: Message by guzdial@cc.gatech.edu (Mark Guzdial) , Thu, 18 Sep 1997 09:39:42 -0400 , Message-ID: This is a multipart MIME message. --===_0_Fri_Sep_19_10:18:13_MET_DST_1997 Content-Type: text/plain; charset=us-ascii > Is there a list somewhere of changes in 1.5, new features, etc.? For > example, I'm interested to hear if threads will be in the 1.5 MacPython > release. I've appended the 1.5a3 relnotes, a few more things have changed since then. Little new stuff will be added on the mac-specific side before 1.5, because I'll be very busy until the end of the year (and going on a 5-week trip to the middle-east besides:-). Threads will not be done before 1.5, unless someone contributes working code. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm --===_0_Fri_Sep_19_10:18:13_MET_DST_1997 Content-Type: text/plain; charset=us-ascii Content-Description: Relnotes Release notes for MacPython 1.5a3 --------------------------------- Here are the mac-specific changes since MacPython 1.4, with end-user-visible changes near the top and API changes and other things that are developer-only more to the bottom. Changes marked with a [*] are new changes, since 1.5a2. And, of course, all Guido's 1.5a3 changes are incorporated. - Installation is now through an installer [*] - mkapplet and MkPluginAliases have been renamed to BuildApplet and ConfigurePython [*] - Applescript classes and properties are now exported by suites. Very sketchy documentation added to applescript.html [*] - Tkinter now uses tcl/tk 8.0 [*] - imports should be faster due to caching path information [*] - Generated suites now live in Mac:Lib:scripting [*] - Added zlib module [*] - Tkinter setfilehandler() did not work for sockets, fixed [*] - "Delay console window" option didn't work, fixed. Also check out the quietconsole.py module [*] - Menu bar is restored (if needed) when keeping console open after exit [*] - Influencing command-. and event processing (formerly MacOS.SetYield and MacOS.SetScheduleTimes) has been changed, see the manual [*] - FrameWork (or your own windowing code) can use asynchronous callbacks to keep user interface responsive during long computations [*] - Module to interface to Internet Config added - Module calldll added that allows calling of arbitrary C routines from MacOS toolboxes - gdbm module added - ctb error handling fixed, and some memory leaks plugged - Various of the documentation files in Mac:Demo have been updated - MacOS.string_id_to_buffer is a new hack: the number you have to add to the id() of a string object to get the (data) memory address - MacOS.splash() double-free fixed - macfs.FSSpec.as_pathname() was incorrect for disk toplevel folders - QT.NewMovieFromFile has an extra parameter and an extra return value - EasyDialogs.ProgressBar has changed both in layout and interface - FrameWork.Application has a new cleanup() method which asks all windows to close themselves. - Loading of PYC resources from the application greatly speeded up, especially for CDROM based applications - interrupt check/eventloop only entered 10 times per second, giving big speedup - Allow any object (file, folder, disk) to be dropped on an applet - Twit resource number conflict with debuggee fixed - sys.path preference can now be longer than 255 chars - cfmfile module allows parsing and merging of CFRG resources - PythonFAT and PythonApplet are now fat (PPC/CFM68K) applications, so applets can be moved between architectures. - Twit resource number conflict with debuggee fixed - mkapplet now uses a progress bar in stead of print statements - unshar made a bit more mac-friendly (input output dialogs) - img: added png, xbm, bmp support - img: jpeg now uses IJG v6 library - img: import of imagefile support modules delayed until needed - img: better error handling for truncated images and such - img: imgop.unpack() can unpack formats with multiple pixels per byte - We now use CW Pro 1, with multitarget projects and such goodies [*] - fixed xx plugin project for cfm68k [*] - All files updated to new Py_ naming convention - Toolbox modules regenerated from new Universal Headers - nfullpath() merged into PyMac_GetFullPath() - Added support for Metrowerks profiler - Standard MW/MSL runtime libraries used in stead of homegrown version - Allow any object (file, folder, disk) to be dropped on an applet - Malloc now returns cache-line-aligned memory on PPC, which speeds things up, especially on a 604. Dictionaries put this to good use. - statically linked pythons won't inadvertantly load .slb modules - Removed dependencies on PLStringFuncs and/or StdCLib - Project "segment" structure changed to more-or-less follow folder structure - fullbuild redesigned - Added PyMac_Initialize() call, for use by embedding programs. --===_0_Fri_Sep_19_10:18:13_MET_DST_1997-- _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From wtbridgman@radix.net Sat Sep 20 23:48:10 1997 From: wtbridgman@radix.net (W.T. Bridgman) Date: Sat, 20 Sep 1997 18:48:10 -0400 Subject: [PYTHONMAC-SIG] Changes in 'Programming Python' demos? Message-ID: As I've begun building my background in Python, I've been working with some of the demos (particularly the GUIs) in Mark Lutz's "Programming Python". I've encountered some problems running some of the demos from the CD-ROM. One problem is the call to ScrolledText in guimixin.py. More recently, I've encountered a problem using formgui.py & formtest.py. Since I know there were some changes in Python from the 1.2-1.3 release to the 1.4 version I'm using on a Mac, I'm not sure if the problem is Mac-specific or due to changes in Python. If it's the latter, is there a location listing the changes required to get these codes running under Python 1.4? Thanks, Tom Tom Bridgman, Ph.D. wtbridgman@radix.net Physics & Astronomy "Just say NO to Microsoft." _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From lutz@rmi.net Mon Sep 22 17:45:00 1997 From: lutz@rmi.net (Mark Lutz) Date: Mon, 22 Sep 97 10:45 MDT Subject: [PYTHONMAC-SIG] Changes in 'Programming Python' demos? (fwd) Message-ID: Hello, Your mail abut changes in some of the GUI examples in Programming Python was forwarded my way. There were indeed some incompatible Tkinter changes in Python 1.4. A listing of all known example updates is available on the web, at "http://rmi.net/~lutz/progdiff.html". Alternatively, to get a tar file with the updated examples (4 files), go to "http://rmi.net/~lutz/progdiff.tar", fetch the file, untar on your machine, and copy the 4 files to the book examples directory. Detailed descriptions of these and other book updates appear on the book's errata page, at: "http://rmi.net/~lutz/errata.html". If you have trouble accessing any of these URLs, send me an email. These are all the result of changes to the Tkinter module in 1.4, which were minor, but enough to break these examples; I doubt it's an issue with the Mac platform itself. Mark Lutz > ---------- Forwarded message ---------- > Date: Sat, 20 Sep 1997 18:48:10 -0400 > From: "W.T. Bridgman" > To: pythonmac-sig@python.org > Subject: [PYTHONMAC-SIG] Changes in 'Programming Python' demos? > > As I've begun building my background in Python, I've been working with some > of the demos (particularly the GUIs) in Mark Lutz's "Programming Python". > I've encountered some problems running some of the demos from the CD-ROM. > > One problem is the call to ScrolledText in guimixin.py. More recently, > I've encountered a problem using formgui.py & formtest.py. > > Since I know there were some changes in Python from the 1.2-1.3 release to > the 1.4 version I'm using on a Mac, I'm not sure if the problem is > Mac-specific or due to changes in Python. > > If it's the latter, is there a location listing the changes required to get > these codes running under Python 1.4? > > Thanks, > Tom > > Tom Bridgman, Ph.D. wtbridgman@radix.net > Physics & Astronomy "Just say NO to > Microsoft." _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From vanandel@stout.atd.ucar.edu Mon Sep 22 20:26:52 1997 From: vanandel@stout.atd.ucar.edu (Joe Van Andel) Date: Mon, 22 Sep 1997 13:26:52 -0600 Subject: [PYTHONMAC-SIG] Network/System admin on Mac using Python Message-ID: <199709221926.NAA10269@atd.atd.ucar.EDU> Has anyone done any system admin scripts using Python? I'm looking for scripts that would aid in maintaining a group of Macs in a student lab, i.e: Software distribution/updates Cleaning out student folders Checking versions on software Thanks much. Joe VanAndel Internet: vanandel@ucar.edu National Center for http://www.atd.ucar.edu/~vanandel/home.html Atmospheric Research _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From wtbridgman@radix.net Mon Sep 22 23:04:31 1997 From: wtbridgman@radix.net (W.T. Bridgman) Date: Mon, 22 Sep 1997 18:04:31 -0400 Subject: [PYTHONMAC-SIG] Changes in 'Programming Python' demos? (fwd) Message-ID: Mark & Jack & others who might be interested: Mark: Thanks for the location. I will check it out. As for my original inquiry, late last night after sending out the inquiry and applying Jack's fix to my sys.path problem, I went back into the programs. This time when they failed, I took a close look in the text and lo' and behold, they were different. Usually, the electronic demos are more up-to-date than the text (more time for printing vs. time for cutting CDs?). However, I made the changes that appeared in the text and now FormGUI.py seems to work fine. I looked in GUImixin.py and noticed the call to ScrolledText is also different. I'll be trying out that fix this evening. I've gotta learn to pay attention... Thanks, Tom Tom Bridgman, Ph.D. wtbridgman@radix.net Physics & Astronomy _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Thomas.Tiemann@ipk.fhg.de Wed Sep 24 09:45:09 1997 From: Thomas.Tiemann@ipk.fhg.de (Thomas Tiemann) Date: Wed, 24 Sep 1997 10:45:09 +0200 Subject: [PYTHONMAC-SIG] urllib Message-ID: Hi, i have a little problem. Is it possible to get with urllib.urlretrieve(url) an image File. I write the following code on Macintosh: import urllib : url = 'http ://192.0.1.23/tommy/' geturl = urllib.urlopen(url) : furl = findImagePath() iurl = url + furl # ok,iurl = http ://192.0.1.23/tommy/images/family.gif # but : getfile = urllib.urlretrieve(iurl) # the tmp-file is not correct, it can't read form Photoshop or other programs. I thnik the file was transfers as text-file and not as binary-file. What is the answer? Thomas _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Wed Sep 24 12:20:22 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 24 Sep 1997 13:20:22 +0200 Subject: [PYTHONMAC-SIG] urllib In-Reply-To: Message by Thomas Tiemann , Wed, 24 Sep 1997 10:45:09 +0200 , Message-ID: > Hi, > > i have a little problem. Is it possible to get with urllib.urlretrieve(url) > an image File. The file is fetched and saved in text-mode in stead of binary mode. Edit urllib.py, look for all makefile() and open() calls and give them flag 'rb' or 'wb'. This isn't completely correct either, since text files arrive on your mac with the end-of-line convention of the remote system, but there's little to be done about it. At least your binary files will be ok. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Thomas.Tiemann@ipk.fhg.de Fri Sep 26 09:06:53 1997 From: Thomas.Tiemann@ipk.fhg.de (Thomas Tiemann) Date: Fri, 26 Sep 1997 10:06:53 +0200 Subject: [PYTHONMAC-SIG] Mac CGI Message-ID: Hi Jack, thank's for your help with urlretrieve. Sorry, but I have next problem. Now I want to write a CGI-Script on Mac and I follow the steps in the cgi.html. If I write a CGI-Script with AppleScript so the Script don't quit, but the Programs (Applets create with mkapplet) with Python don't stay open and Webstar can't execute the Program. Thomas _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From guzdial@cc.gatech.edu Fri Sep 26 15:54:02 1997 From: guzdial@cc.gatech.edu (Mark Guzdial) Date: Fri, 26 Sep 1997 10:54:02 -0400 Subject: [PYTHONMAC-SIG] Mac CGI Message-ID: Start the Python CGI applet *first*. The CGI Applet is written as an AppleEvent Server. It just stays open and processes the CGI requests as they come in. Quit the Applet from the menu when you're through with it. (I find that if you don't start the Applet first, you can still start it up from the URL reference, but the request will probably time out before everything is set up.) Mark At 10:06 AM 9/26/97, Thomas Tiemann wrote: >Hi Jack, > >thank's for your help with urlretrieve. > >Sorry, but I have next problem. Now I want to write a CGI-Script on Mac and >I follow the steps in the cgi.html. If I write a CGI-Script with >AppleScript so the Script don't quit, but the Programs (Applets create with >mkapplet) with Python don't stay open and Webstar can't execute the Program. > >Thomas > > > >_______________ >PYTHONMAC-SIG - SIG on Python for the Apple Macintosh > >send messages to: pythonmac-sig@python.org >administrivia to: pythonmac-sig-request@python.org >_______________ -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Mon Sep 29 10:46:40 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 29 Sep 1997 11:46:40 +0200 Subject: [PYTHONMAC-SIG] Mac CGI In-Reply-To: Message by guzdial@cc.gatech.edu (Mark Guzdial) , Fri, 26 Sep 1997 10:54:02 -0400 , Message-ID: Is anyone willing to have a look at the Mac CGI stuff, both implementation and documentation, to clean it up and make it a little more user-friendly? That has been on my to-do list for a long long time, but since I haven't got a serious application for mac cgi-scripting at the moment it'll probably never get done. I would really like a framework that could be used in a way that makes cgi-scripts portable with unix/windows cgi-scripting (which would involve executing the users cgi-code within some framework and grabbing stdout to send the results as the appleevent reply), and I would like a framework that would make the users code identical for cgi and acgi scripts (and possibly nsapi plugins, or whatever the standard is on the mac). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From jimmy@cs.cofc.edu Tue Sep 30 01:44:40 1997 From: jimmy@cs.cofc.edu (James B. Wilkinson) Date: Mon, 29 Sep 1997 20:44:40 -0400 Subject: [PYTHONMAC-SIG] Show/Hide Window? Message-ID: MacPython just laughs at me when I try to invoke Win.ShowWindow. Win.NewWindow works fine, and both NewWindow and ShowWindow are in the Window Manager section of Inside Macintosh vol 1 (old), so I thought that Win gets me to the Window Manager part of the toolbox. Is this routine just not implemented in MacPython, or is it in some other toolbox set? Well, I finally noticed that everything gets imported into the Framework twice, e.g. Win, Windows and QD, QuickDraw. I even found them. Windows and QuickDraw are .py files that seem to have only constants in them, and QD and Win have the puzzle-piece icons that mean extensions to me. I guess they have the executable code, but I have no idea how to find out what routines are actually there. Here's another puzzlement: I can't find any code in the Framework that either hides a window or disposes of it, yet the windows disappear when I click the close box. When I try to trace it in the source, all I find is bookkeeping stuff like setting the parent to None and getting the parent to remove the window from its list of children. I can't see how any of that would make the window actually go away. In the programming I did in C I always had to be careful to do a DisposeWindow on any window I had done a NewWindow for so that all the memory was given back to the heap. Is that being taken care of under the table here somehow? What I'm trying to do is create windows that are not visible until a menu item is selected. Here's the code. Is this the right way to do what I'm after (modulo the ShowWindow problem)? It seems to work (again, modulo the ShowWindow problem). I got this by stealing from ped and hacking on it. class TAWindow(Window): def __init__(self, parent, width = 200, height = 100, name = 'TAWindow'): Window.__init__(self, parent) self.name = name r = windowbounds(width, height) w = Win.NewWindow(r, name, true, documentProc, -1, true, 0x55555555) # ^ # ^ # I want a false here so the window is not visible right away. self.wid = w Qd.SetPort(w) Qd.TextFont(4) Qd.TextSize(12) self.root = self.MakeTree() def MakeTree(self): #application-dependent hook routine return root def open(self): Qd.SetPort(self.wid) # Is this necessary here? #Win.ShowWindow(self.wid)# Why doesn't Python know about ShowWindow? self.do_postopen() Thanks much. ------------------------------------------------------------- Jimmy Wilkinson | Perfessor of Computer Science jimmy@cs.cofc.edu | The College of Charleston (803) 953-8160 | Charleston SC 29424 If there is one word to describe me, that word would have to be "profectionist". _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Tue Sep 30 09:29:52 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 30 Sep 1997 10:29:52 +0200 Subject: [PYTHONMAC-SIG] Show/Hide Window? In-Reply-To: Message by "James B. Wilkinson" , Mon, 29 Sep 1997 20:44:40 -0400 , Message-ID: > MacPython just laughs at me when I try to invoke Win.ShowWindow. Python turns the procedural interface of the toolbox into an OO interface as much as possible. So, you should say: >>> import Win >>> w = Win.NewWindow((100,100,200,200), "title", 0, 0, -1, 1, 0) >>> w.ShowWindow() and it all works fine. For most toolboxes, if the first argument of a routine is the "natural" type of the toolbox the routine will be turned into a method. There are some exceptions: Qd.SetPort(), for instance, since there are so many things that can be passed to it as an argument. > Well, I finally noticed that everything gets imported into the Framework > twice, e.g. Win, Windows and QD, QuickDraw. I even found them. Windows > and QuickDraw are .py files that seem to have only constants in them, and > QD and Win have the puzzle-piece icons that mean extensions to me. I guess > they have the executable code, but I have no idea how to find out what > routines are actually there. The long-named modules Window, QuickDraw, etc. have the symbolic constants, the short-named modules are indeed dynamically loaded C modules with the real interface. Use "dir(Win)" to find out which functions are defined in the Win module. Use "w = NewWindow(....); dir(w)" to find out which methods the Window objects support. Use "print Win.NewWindow.__doc__" to print the argument list and return values of the Python implementation of the method or function. Use these three snippets of information plus a Mac programmers manual plus a lot of creativity to find out how to use the routine. I agree that this is all very tricky, but documenting all the calls is beyond me. > > Here's another puzzlement: I can't find any code in the Framework that > either hides a window or disposes of it, yet the windows disappear when I > click the close box. When a Window object's reference count drops to zero the window is disposed, which removes it from the screen, hence the DisposeWindow call is also missing as it is implicit in Python. There is one situation where you have to be aware of this: when a reference to your window is tucked away somewhere (usually in a stacktrace in sys.last_exc and friends). Then you close your FrameWork object and the window doesn't go away. The workaround is to raise a dummy exception and catch it, to clear the stacktrace. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________