From jack@oratrix.nl Wed Nov 1 09:55:35 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 01 Nov 2000 10:55:35 +0100 Subject: [Pythonmac-SIG] Re: API_MAC_CARBON In-Reply-To: Message by "Steven D. Majewski" , Tue, 31 Oct 2000 18:09:08 -0500 (EST) , Message-ID: <20001101095536.F33F131C49C@snelboot.oratrix.nl> > Well -- if the MacOS Plugin Modules are Carbon, then they should also > work for MacOSX Python. The would need to be recompiled to mach-o > format for the current MacOSX python to load them. An alternative > appears to be to add the CFM import code from MacPython to the OSX > version so that it could import CFM modules. The interesting modules are the toolbox modules, and I'm not sure whether these are supported under non-carbon MacOSX. There are quite a few differences between the carbon and non-carbon programming model (think of pathnames, for instance). But: why don't you try to take the MacPython source of an interesting module (AppleScript or QuickTime comes to mind) and try to get it to compile and run under MacOSX Python? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From sdm7g@virginia.edu Wed Nov 1 13:21:50 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Wed, 1 Nov 2000 08:21:50 -0500 (EST) Subject: [Pythonmac-SIG] Re: API_MAC_CARBON In-Reply-To: <20001101095536.F33F131C49C@snelboot.oratrix.nl> Message-ID: On Wed, 1 Nov 2000, Jack Jansen wrote: > The interesting modules are the toolbox modules, and I'm not sure whether > these are supported under non-carbon MacOSX. There are quite a few differences > between the carbon and non-carbon programming model (think of pathnames, for > instance). I'm not sure what you mean by "non-carbon MacOSX" : carbon is supported for all MacOSX. If you mean the programming model, calls can (and are) mixed -- they are just different libraries (frameworks), although clearly for something like events you can't mix and match between two models without expecting real trouble. ( But Cocoa is a REAL O-O framework and it expects to be dispatching events. ) There are some problems with mixing CFM and mach-o code, but this is an orthogonal problem ( you can compile Carbon to mach-o, but it will only run on OSX, not OS 8 or 9. ) and you can shim around it. > But: why don't you try to take the MacPython source of an interesting module > (AppleScript or QuickTime comes to mind) and try to get it to compile and run > under MacOSX Python? Well - I did take a stab at the Win module. There are differences between the Carbon headers in the Carbon.framework and the carbon supporting headers in Univeral Interfaces -- mostly for backwards support. For example, MacWindows.h is the preferred file now. In UI, there's a Windows.h file that is just a shim that includes MacWindows.h. That's not in C.F. I've been trying to compile with U.I, but there's lots of layers of stuff that's included that not needed: it looks like I'll have to do some surgery to some of the mac support modules to make ones that will do a carbon-only compile. ( in particular, take out all of the GUSI specific stuff. ) That's one reason I was asking about the current status. I'm also wondering if it would be better to regenerate the modules from the Carbon or Universal Interfaces headers -- which is why I was asking about what you based the current builds on. ( Long ago, I asked some questions about the process of generating MacModules. I'm going to dig out that thread, but if you have anything to add or comment, now would be timely! ) ---| 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 operating systems want to be unix, All programming languages want to be lisp." From jack@oratrix.nl Wed Nov 1 13:33:37 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 01 Nov 2000 14:33:37 +0100 Subject: [Pythonmac-SIG] Re: API_MAC_CARBON In-Reply-To: Message by "Steven D. Majewski" , Wed, 1 Nov 2000 08:21:50 -0500 (EST) , Message-ID: <20001101133337.EAABA31C49C@snelboot.oratrix.nl> > I'm not sure what you mean by "non-carbon MacOSX" : carbon is supported > for all MacOSX. If you mean the programming model, calls can (and are) > mixed -- they are just different libraries (frameworks), [...] This is not what I understood. There are lots of things that are different, for instance, applications that use Carbon will see MacOS filenames (colon-separated pathnames, FSSpec records, etc) while applications that use the BSD API will see unix pathnames. Mixing these should give disappointing results. Or do I miss something? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Wed Nov 1 13:39:35 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 01 Nov 2000 14:39:35 +0100 Subject: [Pythonmac-SIG] Re: API_MAC_CARBON In-Reply-To: Message by "Steven D. Majewski" , Wed, 1 Nov 2000 08:21:50 -0500 (EST) , Message-ID: <20001101133935.DE00E31C49C@snelboot.oratrix.nl> > Well - I did take a stab at the Win module. > There are differences between the Carbon headers in the Carbon.framework > and the carbon supporting headers in Univeral Interfaces -- mostly for > backwards support. For example, MacWindows.h is the preferred file now. > In UI, there's a Windows.h file that is just a shim that includes > MacWindows.h. That's not in C.F. I think you should try this just as a proof-of-concept first: simply hack up the Winmodule.c file to include MacWindows.h (from Carbon.framework, I would guess) and rip out the stuff that doesn't exist there (possibly you'll have to copy some MacPython header files and rip stuff out of there too, but maybe just removing the includes of those headers from Winmodule.c is good enough). Then try to build a dynamic module for this with the normal (unix) tools. For the future we can use conditional compilation (which bgen now supports) to make a distinction between compiling-for-carbon-MacPython and compiling-for-unix-like-Python. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From sdm7g@virginia.edu Wed Nov 1 17:21:38 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Wed, 1 Nov 2000 12:21:38 -0500 (EST) Subject: [Pythonmac-SIG] Re: API_MAC_CARBON In-Reply-To: <20001101133337.EAABA31C49C@snelboot.oratrix.nl> Message-ID: On Wed, 1 Nov 2000, Jack Jansen wrote: > > > I'm not sure what you mean by "non-carbon MacOSX" : carbon is supported > > for all MacOSX. If you mean the programming model, calls can (and are) > > mixed -- they are just different libraries (frameworks), [...] > > This is not what I understood. There are lots of things that are different, > for instance, applications that use Carbon will see MacOS filenames > (colon-separated pathnames, FSSpec records, etc) while applications that use > the BSD API will see unix pathnames. Mixing these should give disappointing > results. > > Or do I miss something? I think that's true according to which *Filesystem* APIs you use. You could have a program which used Carbon APIs for most things, but used posix APIs for posix-y type things. Some of the developer example program (the ones to which I was directed when asking about the new Carbon event model!) use Carbon API calls mixed with calls to load Interface Builder Nib files -- something I'm pretty sure won't work on OS9 CarbonLib. ( The then call the new Carbon event RunApplicationEventLoop() to "run" the windows, but I'm not sure what events are automagically handled -- I tried inserting some new controls with IB, but they didn't "click" -- but maybe I was missing some other IB step to activate them. ) "Carbon" seems to be a multi-layered word to Apple. There's "Targeting to Carbon" -- which means writing to Carbon and Carbon only so it will run on OSX or OS8|9 + CarbonLib, and which may also imply a single CFM binary that runs on both, and there's OSX Carbon Apps, which may be CFM or mach-o, and just happen to use the Carbon framework/libraries along with other libs and frameworks. There's also a lot of other execution environment issues I haven't quite sorted out: for example there's a difference between command line posix programs and double-clickable GUI apps: I don't think, but I don't know for sure, if that will make a problem producing a command-line python that loads Carbon or Cocoa interface libs. BTW: I wonder if a carbonized MacPython could dynamically load GUSI+SIOUX for OS8|9 or the standard posix libraries on OSX ? ( Don't know if that's a path work pursuing -- there's so much to be done we'll have to choose our battles wisely! ) ---| 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 operating systems want to be unix, All programming languages want to be lisp." From sdm7g@virginia.edu Wed Nov 1 17:44:00 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Wed, 1 Nov 2000 12:44:00 -0500 (EST) Subject: [Pythonmac-SIG] Re: API_MAC_CARBON In-Reply-To: <20001101133935.DE00E31C49C@snelboot.oratrix.nl> Message-ID: On Wed, 1 Nov 2000, Jack Jansen wrote: > > > Well - I did take a stab at the Win module. > > There are differences between the Carbon headers in the Carbon.framework > > and the carbon supporting headers in Univeral Interfaces -- mostly for > > backwards support. For example, MacWindows.h is the preferred file now. > > In UI, there's a Windows.h file that is just a shim that includes > > MacWindows.h. That's not in C.F. > > I think you should try this just as a proof-of-concept first: simply hack up > the Winmodule.c file to include MacWindows.h (from Carbon.framework, I would > guess) and rip out the stuff that doesn't exist there (possibly you'll have to > copy some MacPython header files and rip stuff out of there too, but maybe > just removing the includes of those headers from Winmodule.c is good enough). > Then try to build a dynamic module for this with the normal (unix) tools. > That's what I was aiming for -- to manually hack one module into building, and then, after learning the gotcha's, figure out how to automate the process. I haven't given up on that -- I just found that there's more hacking required than I expected -- I need to do an OSX macglue and port some other support routines before I can do a complete build. BTW: I assume that the current modules are linked against InterfaceLib and not CarbonLib -- true? If they were Carbonized, and IF they were linked to CarbonLib and not InterfaceLib, and IF they weren't linked to GUSI or WASTE, etc. then they (the toolbox modules, not the Python EXE) would work on OSX if we added a CFM loader shim to support both mach-o and CFM for dynamic import. ) > For the future we can use conditional compilation (which bgen now supports) to > make a distinction between compiling-for-carbon-MacPython and > compiling-for-unix-like-Python. See above. I think there should be Carbon and Non-Carbon (both OSX and OS9) modules, and the Carbon stuff *SHOULD* be fairly source neutral ( I think some of the Apple example code has conditionals mainly for Metroworks compiler vs. OSX gcc based compiler. ), and *IF* we get the linking + loading problems out of the way, the same Carbon modules could work on either. But even if we don't aim for that, yes -- there ought to be one conditionally compiled MacWindows (Win) module eventually. ---| 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 operating systems want to be unix, All programming languages want to be lisp." From sdm7g@virginia.edu Thu Nov 2 05:19:54 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Thu, 2 Nov 2000 00:19:54 -0500 (EST) Subject: [Pythonmac-SIG] progress report: building Winmodule on OSX (fwd) Message-ID: Oops -- that pythonmac-sig, not macpython-sig! Try it one more time! ---------- Forwarded message ---------- Date: Thu, 2 Nov 2000 00:17:30 -0500 (EST) From: Steven D. Majewski To: Jack Jansen Cc: macpython-sig@python.org Subject: progress report: building Winmodule on OSX I did some of this before for one of the 2.0 betas. After a night of hacking, I got a bit further. Just in case it's again days before I can get back to this ( Got to go back to some Real Work tomorrow! ) I'll post a progress report. * Unpacked the MacPython 2.0 sources, copied the Mac directory from those sources into the (already built) Darwin/OSX build directory of Python2.0. Files all have mac line endings: use find and "tr '\r' '\n'" command to convert files. * rename the Python-2.0/Mac/Include/config.h so it doesn't get included instead of the Python-2.0/config.h * (previously) got latest Universal Interfaces and unpacked the CIncludes directory in /Local/Carbon/Universal.Interfaces/CIncludes (or where-ever) [ The headers in /System/Library/Frameworks/ are spread out in various frameworks and hard to find, U-I has them all in one place, as well as not needing to change Windows.h to MacWindows.h and other changes. ] * Compile Winmodule.c with: cc -c Winmodule.c -I../../../Include -I../../Include -I../../.. -I/Local/Carbon/Universal.Interfaces/CIncludes -DHAVE_CONFIG_H ( Relative to the Python-2.0/Mac/Modules/win/ directory that includes the Python-2.0/Include/ Python-2.0/Mac/Include Python2.0 (for config.h) and the Universal Interfaces includes. ) * had to comment out all of the PyOS_* calls in macglue.c, as well as PyErr_CheckSignals to avoid multiple definitions. Compiled macglue with: cc -c macglue.c -I../Include -I../../Include -I/Local/Carbon/Universal.Interfaces/CIncludes/ -I../../ -I../../Python -fpascal-strings Linked with: cc -bundle -undefined warning Winmodule.o -o Winmodule.so -framework System -framework Carbon ../../Python/macglue.o and what I get when I run and import Win is: Python 2.0 (#3, 10/22/00, 12:04:10) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> import Win dyld: python Undefined symbols: _GetWindowGoAwayFlag _GrafObj_New _QdRGB_New _ResObj_Convert _ResObj_New _SIOUXSetupMenus _mfs_GetFSSpecFSSpec _newmfssobject The SIOUX reference probably shouldn't be there -- need to track that down and kill it. Some like _ResObj are probably other macpython "glue" routines -- need to find and compile those files. Some may be non-carbon MacOS calls that also need to be removed. ( This is condensed from several iterations to find undefined or multiply defined symbols. ) ---| 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 operating systems want to be unix, All programming languages want to be lisp." From tom@othermedia.com Thu Nov 2 11:08:43 2000 From: tom@othermedia.com (tom smith) Date: Thu, 02 Nov 2000 11:08:43 +0000 Subject: [Pythonmac-SIG] MacPython and Pyxie In-Reply-To: Message-ID: hi, I'm looking for python tools to help me with xml work. I've tried working with pyxie (using Sean's book), but I keep getting errors of not finding the saxlib module. Am I right that the xml stuff has all been reorganized so pyxie will break, or am I missing something. thanks tom From sdm7g@virginia.edu Thu Nov 2 17:33:04 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Thu, 2 Nov 2000 12:33:04 -0500 (EST) Subject: [Pythonmac-SIG] progress report: building Winmodule on OSX (fwd) In-Reply-To: Message-ID: On Thu, 2 Nov 2000, Steven D. Majewski wrote: > > Python 2.0 (#3, 10/22/00, 12:04:10) > [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 > Type "copyright", "credits" or "license" for more information. > >>> import Win > dyld: python Undefined symbols: > _GetWindowGoAwayFlag > _GrafObj_New > _QdRGB_New > _ResObj_Convert > _ResObj_New > _SIOUXSetupMenus > _mfs_GetFSSpecFSSpec > _newmfssobject > > > Compiled Resmodule, Qdmodule and macfsmodule using the same includes as I used for Winmodule. Built, linked and run: bash-2.03$ python Python 2.0 (#3, 10/22/00, 12:04:10) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> import Win dyld: python Undefined symbols: _CtlObj_New _Dialog_Type _FindApplicationFromCreator _GetWindowGoAwayFlag _MenuObj_New _PyMac_GetFullPath _SIOUXSetupMenus bash-2.03$ Which starts to look like I can't easily pluck one module out of the batch to build -- there's too many cross dependencies, so it's probably time to write a makefile and figure out how to automate the build for the whole toolbox set. ---| 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 operating systems want to be unix, All programming languages want to be lisp." From cbarker@jps.net Thu Nov 2 20:21:50 2000 From: cbarker@jps.net (Chris Barker) Date: Thu, 02 Nov 2000 12:21:50 -0800 Subject: [Pythonmac-SIG] Time to switch to 2.0?? References: <000e01c0404d$95736100$0101a8c0@chrisl> <39FDB943.363C4533@jps.net> Message-ID: <3A01CCDE.2BA9FA89@jps.net> Hi all, I am in the early stages of a substantial project using Python, NumPy and an assortment of extensions I am writing myself. I am developing most of it on Linux, but I am also working on the Mac, and need it to work well there. My question is this: Is it time to switch to 2.0 ? I would like to use some of 2.0's features, but I can't deal with bugs at the moment. Has 2.0 turned out to be stable and usable with NumPy on the Mac?? A few minor install issues is fine, but it needs to run well once it is set up. How is it working for you all? (OS 8.6, but I may switch to 9 soon anyway, if it makes a difference) -thanks, -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From jack@oratrix.nl Thu Nov 2 22:38:08 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 02 Nov 2000 23:38:08 +0100 Subject: [Pythonmac-SIG] MacPython 2.0 released Message-ID: <20001102223813.6FD521301D2@oratrix.oratrix.nl> MacPython 2.0 is officially released as of now! For those of short attention spans: go to http:/www.cwi.nl/~jack/macpython.html to download the installer or the full source distribution. Aside from all the new machine-independent features, see www.python.org for those, here is the edited list of highlights when comparing this version with MacPython 1.5.2: - Thread support - Tkinter works again - Appearance support - Navigation support - Offscreen QuickDraw - Drag manager support - Much better CGI support and examples The bad news: - This release is PPC only. 68K users should stick with 1.5.2. - This release is not Carbonized yet. Expect a Carbon MacPython in a few months. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From sdm7g@virginia.edu Fri Nov 3 18:36:44 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Fri, 3 Nov 2000 13:36:44 -0500 (EST) Subject: MacCentral [was: [Pythonmac-SIG] MacPython 2.0 released] In-Reply-To: <20001102223813.6FD521301D2@oratrix.oratrix.nl> Message-ID: FYI: The release announcement made it's way to MacCentral: "MacPython snakes its way to 2.0" http://www.maccentral.com/news/0011/03.macpython.shtml ---| 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 operating systems want to be unix, All programming languages want to be lisp." From dma@cyrus.andrew.cmu.edu Fri Nov 3 18:50:07 2000 From: dma@cyrus.andrew.cmu.edu (David Andersen) Date: Fri, 03 Nov 2000 13:50:07 -0500 Subject: [Pythonmac-SIG] gusisioux_state Message-ID: <209851.3182248207@inuvik.andrew.cmu.edu> Trying to compile PythonCore from the Python 2.0 source distribution, I get 4 errors in macmain as "gusisioux_state" is not defined ? From owen@astro.washington.edu Fri Nov 3 19:09:55 2000 From: owen@astro.washington.edu (Russell E Owen) Date: Fri, 3 Nov 2000 11:09:55 -0800 Subject: [Pythonmac-SIG] Problem with Mac Python 2.0: Tk and sockets In-Reply-To: <209851.3182248207@inuvik.andrew.cmu.edu> References: <209851.3182248207@inuvik.andrew.cmu.edu> Message-ID: I have a simple telnet client that uses Tk and file events (part of a bigger project). It works fine in Mac Python 1.5.2 but not 2.0. Can anybody confirm this and does anybody have any ideas. I have appended the code. The symptoms of the problems in Python 2.0 are: - the Python client will send data successfully, but it seems to spend all of my free CPU cycles doing it. The reason I know I can send data is I have an application on the host computer that retransmits received data. If I connect a separate normal telnet client (NiftyTelnet) I can see any data that my Python client sends. When I do this, I see the data, but only if I switch out of Python Interpreter (bringing any other application in front). - the Python client will never display any returned data, period. It's as if file events aren't working. I suppose it may have something to do with spare CPU cycles, but I can keep sending data as much as I like, I just never see any of it back. -- Russell ##### test code, cut here ##### # to use: # - save as a file # - edit the host name (see "host =" line near the end) # - drop the file onto Python Interpreter # # It should work fine in Mac Python 1.5.2 # but I can't get it to work in Mac Python 2.0 import socket, Tkinter, sys class MyClient: __IAC = chr(255) # Interpret as command __DONT = chr(254) __DO = chr(253) __WONT = chr(252) __WILL = chr(251) def __init__ (self, inText, host, showNegotiation=0): self.inText = inText self.host = host self.showNegotiation = showNegotiation self.nnegotiations = 0 self.__iac = 0 self.__opt = '' self.__optText = '' self.__cleanchars = '' self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: self.sock.connect((self.host,23)) Tkinter.tkinter.createfilehandler(self.sock, Tkinter.tkinter.READABLE, self.__readSocket) except socket.error, e: print "connect failed:", e self.inText.bind('', self.__writeSocket) def __readSocket (self, sock, flags): """reads the socket, replies to negotiation requests and prints other data (omitting '\r' and '\0')""" data = sock.recv(1024) if not data: print "connection closed by foreign host" Tkinter.tkinter.deletefilehandler(self.sock) for c in data: if self.__opt: self.nnegotiations = self.nnegotiations + 1 if self.nnegotiations > 30: print "no more negotations" else: sock.send(self.__opt + c) if self.showNegotiation: print self.__optText, c self.__opt = '' self.__optText = "" elif self.__iac: self.__iac = 0 if c == self.__iac: self.__cleanchars = self.__cleanchars + c elif c in (MyClient.__DO, MyClient.__DONT): self.__opt = MyClient.__IAC + MyClient.__WONT if c == MyClient.__DO: self.__optText = "DO" else: self.__optText = "DONT" elif c in (MyClient.__WILL, MyClient.__WONT): self.__opt = MyClient.__IAC + MyClient.__DONT if c == MyClient.__WILL: self.__optText = "WILL" else: self.__optText = "WONT" elif c == MyClient.__IAC: self.__iac = 1 elif c == '\r': pass elif c == '\0': pass else: self.__cleanchars = self.__cleanchars + c print self.__cleanchars self.__cleanchars = '' def __writeSocket (self, evt): try: self.sock.send (inText.get() + '\r') except socket.error, e: print "send failed:", e inText.delete(0,Tkinter.END) host = 'tccdev' root = Tkinter.Tk() mainFrame = Tkinter.Frame(root) aLabel = Tkinter.Label(mainFrame, text="Type text to send, then to send it") aLabel.pack(fill=Tkinter.X, expand=Tkinter.YES) inText = Tkinter.Entry(mainFrame, takefocus=1) inText.pack(fill=Tkinter.X, expand=Tkinter.YES) mainFrame.pack() inText.focus_set() aClient = MyClient (inText, host, showNegotiation=1) root.mainloop() From reterry@bigplanet.com Sat Nov 4 03:22:46 2000 From: reterry@bigplanet.com (Robert E. Terry) Date: Fri, 03 Nov 2000 22:22:46 -0500 Subject: [Pythonmac-SIG] Has anyone ever ported PyFort to the Mac? Message-ID: <3A038105.B98D4278@bigplanet.com> Dear Pythonmac Group, OK, folks, there it is. I'm looking to build something of a research application shell with Python and I would like to smoothly incorporate MPW/Absoft fortran routines as operational elements. How far is the Linux or Windows PyFort away from what I need here? How much raw C++ programming is likely to be needed and would a text like Deitel & Deitel be a useful starting point? Curious, Robert Terry ================================================================ e-mail primary: reterry@bigplanet.com e-mail backup: terry@ccs.nrl.navy.mil From wtbridgman@Radix.Net Sat Nov 4 04:17:49 2000 From: wtbridgman@Radix.Net (W.T. Bridgman) Date: Fri, 3 Nov 2000 23:17:49 -0500 Subject: [Pythonmac-SIG] Building external module under MacPython 2.0 Message-ID: I'm trying to recompile a Python extension that ran under 1.5.1 to run under 2.0. I'm using CodeWarrior 5. I have the source code for the module but am not that familiar with the details of it's operation. After fixing a few other problems (Py_Malloc seems to have become more type-sensitive - the API docs suggest it may be gone, replaced by PyMem_Malloc?), I'm down to this error: Error : the file 'sys/time.h' cannot be opened pyport.h line 95 #include Could this be something that's changed between CW 5 & 6? I'm trying to track down just where this option gets set. The dependencies in config.h seem a bit different between Python 1.5.1 & 2.0. BTW, the old module still builds when linked to Python 1.5.1 so this seems to be strictly due to a change in 2.0. Ideas? Thanks, Tom -- Tom Bridgman, Ph.D. wtbridgman@radix.net Physics & Astronomy From schliep@zpr.uni-koeln.de Sun Nov 5 20:50:50 2000 From: schliep@zpr.uni-koeln.de (Alexander Schliep) Date: Sun, 5 Nov 2000 21:50:50 +0100 Subject: [Pythonmac-SIG] Tkinter crashes Message-ID: <1001105215051.ZM19688@Octopussy.MI.Uni-Koeln.DE> Hello, whenever I am running any Tk-application (try electrons.py in Demo:tkinter:guido) with its window in the foreground, a click on the visible part of the PythonInterpreter.out window crashes my Mac, so that cmd-opt-esc does not work anymore. Same thing happens the other way around and also with trying to switch between different Tk-windows, so hiding PythonInterpreter.out is no solution. Is it just me ? Any ideas what to try ? Btw, older versions did not have that particular bug. Alexander PS: - MacPython 2.0 (just downloaded), 40 MB Ram assigned to interpreter - MacOS 8.1 US with navigation services on a PB 2400c -- Alexander Schliep schliep@zpr.uni-koeln.de ZPR/ZAIK Tel: +49-221-470-6040 (w) University of Cologne FAX: +49-221-470-5160 Weyertal 80 http://www.zpr.uni-koeln.de/~schliep 50931 Cologne, Germany From gehlker@fastq.com Mon Nov 6 05:49:30 2000 From: gehlker@fastq.com (Chris Gehlker) Date: Sun, 05 Nov 2000 22:49:30 -0700 Subject: [Pythonmac-SIG] A Python bridge? Message-ID: I've just been looking at the document "Using the Java Bridge" in the OS X developer docs and on first glance it looks like the techniques used to access Objective-C from Java would also work from Python, giving access to the Cocoa frameworks. Has this been tried? Are there gotchas that I'm missing? From tom@othermedia.com Mon Nov 6 12:45:55 2000 From: tom@othermedia.com (tom smith) Date: Mon, 06 Nov 2000 12:45:55 +0000 Subject: [Pythonmac-SIG] on idle....idle()...and urllib In-Reply-To: Message-ID: In applescript you can create a handler that executes every n minutes. what's nice about this is that it doesn't hog the cpu. Is there a way to do this in python? Alternatively, is there a way to call idle()...my current script doesn't give much time to other apps? And another thing. I recently asked how to get a url and guarantee that I had the whole page. Someone suggested that I use readline() and wait for a 0, but this just ties up my computer completely...it doesn't seem to work. Has anyone done this? thanks tom From tom@othermedia.com Mon Nov 6 12:56:24 2000 From: tom@othermedia.com (tom smith) Date: Mon, 06 Nov 2000 12:56:24 +0000 Subject: [Pythonmac-SIG] on idle....idle()...and urllib In-Reply-To: Message-ID: This is the code I'm trying and it starts ok then seems to end up in a permanent loop. Using urllib.read() hardly ever gets all the data.... import urllib url1 = 'http://slashdot.org/slashdot.rdf' url2 = 'http://hack-the-planet.felter.org/rss.xml' url3 ='http://www.tomalak.org/recentTodaysLinks.xml' url_list = [url1, url2, url3] n =1 for x in url_list: f = open(str(n), 'w') u = urllib.urlopen(x) data = '' t = 0 while (u.readline()) != 0: print u.readline() data = data + u.readline() t = t + 1 if t >10000: break print data print f.write(data) f.close() n =n +1 From jack@oratrix.nl Mon Nov 6 13:07:15 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 06 Nov 2000 14:07:15 +0100 Subject: [Pythonmac-SIG] gusisioux_state In-Reply-To: Message by David Andersen , Fri, 03 Nov 2000 13:50:07 -0500 , <209851.3182248207@inuvik.andrew.cmu.edu> Message-ID: <20001106130716.1D3D131C49C@snelboot.oratrix.nl> > > Trying to compile PythonCore from the Python 2.0 source distribution, I get > 4 errors in macmain as "gusisioux_state" is not defined ? You should get the Python-specific version of GUSI, from the macpython download page. Alternatively you can rip out the gusisioux_state stuff, but then you'll lose the "keep sioux window open" functionality. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Mon Nov 6 13:10:16 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 06 Nov 2000 14:10:16 +0100 Subject: [Pythonmac-SIG] Problem with Mac Python 2.0: Tk and sockets In-Reply-To: Message by Russell E Owen , Fri, 3 Nov 2000 11:09:55 -0800 , Message-ID: <20001106131016.97D4431C49C@snelboot.oratrix.nl> There's a very good chance that Tk file handlers won't work. I must admit that I didn't look into them for this release, and the Tcl/Tk folks have been changing their I/O model every single release:-( I'll gladly accept fixes for this problem, but I'm afraid I don't have time to invest into it myself. The complete tcl/tk sourcetree that I finally managed to build Python/Tkinter with is available alongside the MacPython sources is someone wants to give it a try. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Mon Nov 6 13:14:53 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 06 Nov 2000 14:14:53 +0100 Subject: [Pythonmac-SIG] Building external module under MacPython 2.0 In-Reply-To: Message by "W.T. Bridgman" , Fri, 3 Nov 2000 23:17:49 -0500 , Message-ID: <20001106131453.B315331C49C@snelboot.oratrix.nl> > I'm trying to recompile a Python extension that ran under 1.5.1 to > run under 2.0. I'm using CodeWarrior 5. I have the source code for > the module but am not that familiar with the details of it's > operation. > > After fixing a few other problems (Py_Malloc seems to have become > more type-sensitive - the API docs suggest it may be gone, replaced > by PyMem_Malloc?), I'm down to this error: > > Error : the file 'sys/time.h' cannot be opened > pyport.h line 95 #include Your project file should have the "interpret unix/dos paths" option turned on, and the GUSI2/Include folder should have the recursive bit turned off. The example xx.prj project has this all correctly, but if you're converting an old project that doesn't help you much, of course. Still, you could check the various preferences settings for xx.prj and your project side-by-side to see what has changed. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Mon Nov 6 13:19:08 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 06 Nov 2000 14:19:08 +0100 Subject: [Pythonmac-SIG] Tkinter crashes In-Reply-To: Message by "Alexander Schliep" , Sun, 5 Nov 2000 21:50:50 +0100 , <1001105215051.ZM19688@Octopussy.MI.Uni-Koeln.DE> Message-ID: <20001106131914.272B331C49C@snelboot.oratrix.nl> > whenever I am running any Tk-application (try electrons.py in > Demo:tkinter:guido) with its window in the foreground, a click > on the visible part of the PythonInterpreter.out window crashes > my Mac, so that cmd-opt-esc does not work anymore. > [...] > PS: - MacPython 2.0 (just downloaded), 40 MB Ram assigned to interpreter > - MacOS 8.1 US with navigation services on a PB 2400c No such problem for me (G4/450, MacOS 9.0.4, 26Mb partition for the interpreter). Maybe a few other people could try electrons.py and let us hear the results so we can narrow this down? My guess is that 8.1 is the problem: I got another message from someone saying that Tcl/Tk 8.3 is unstable on older macosses. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Mon Nov 6 13:41:21 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 06 Nov 2000 14:41:21 +0100 Subject: [Pythonmac-SIG] on idle....idle()...and urllib In-Reply-To: Message by tom smith , Mon, 06 Nov 2000 12:56:24 +0000 , Message-ID: <20001106134121.E43DF31C49C@snelboot.oratrix.nl> > This is the code I'm trying and it starts ok then seems to end up in a > permanent loop. Using urllib.read() hardly ever gets all the data.... > > > > import urllib > url1 = 'http://slashdot.org/slashdot.rdf' > url2 = 'http://hack-the-planet.felter.org/rss.xml' > url3 ='http://www.tomalak.org/recentTodaysLinks.xml' > > url_list = [url1, url2, url3] > > n =1 > > for x in url_list: > f = open(str(n), 'w') > u = urllib.urlopen(x) > data = '' > > t = 0 > while (u.readline()) != 0: > print u.readline() > data = data + u.readline() > t = t + 1 > if t >10000: > break I assume you've massaged this code before publishing it, because in the way it's presented here it would drop 2 out of every three lines:-) What I would do is something like: def getalldata(url): u = urllib.urlopen(url) rv = '' newdata = u.read() while newdata: rv = rv + newdata newdata = u.read() return rv -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From kantel@mpiwg-berlin.mpg.de Mon Nov 6 14:02:15 2000 From: kantel@mpiwg-berlin.mpg.de (=?iso-8859-1?Q?J=F6rg?= Kantel) Date: Mon, 6 Nov 2000 15:02:15 +0100 Subject: [Pythonmac-SIG] Tkinter crashes In-Reply-To: <20001106131914.272B331C49C@snelboot.oratrix.nl> References: <20001106131914.272B331C49C@snelboot.oratrix.nl> Message-ID: >Maybe a few other people could try electrons.py and let us hear the results so >we can narrow this down? My guess is that 8.1 is the problem: I got another >message from someone saying that Tcl/Tk 8.3 is unstable on older macosses. I tried it on my machine here at the Institute (G3 blue/white, Mac OS 8.6, 16 MB for the Interpreter) and it runs without any problems - and I clicked to the Interpreter window more than once in and back... ;o) Maybe this evening I will try it at my machines home (which are running Mac OS 9.0.4) but I don't expect other results (I've done a lot of Tkinter work with the new MacPython 2.0 during this weekend at home. And all worked fine for me. ;o) HTH J"org -- -- -------------------------------------------------------------------------- J"org Kantel Max-Planck-Institute for the History of Science Computer-Department kantel@mpiwg-berlin.mpg.de joerg@kantel.de Wilhelmstr. 44 http://www.mpiwg-berlin.mpg.de/staff/kantel/kantel.html D-10117 Berlin fon:+4930-22667-220 mobil:+0170-9023970 fax:+4930-22667-299 -------------------------------------------------------------------------- From owen@astro.washington.edu Mon Nov 6 16:56:53 2000 From: owen@astro.washington.edu (Russell E Owen) Date: Mon, 6 Nov 2000 08:56:53 -0800 Subject: [Pythonmac-SIG] Tkinter crashes In-Reply-To: <1001105215051.ZM19688@Octopussy.MI.Uni-Koeln.DE> References: <1001105215051.ZM19688@Octopussy.MI.Uni-Koeln.DE> Message-ID: No crash here -- PowerMac 7200/90 running MacOS 8.6 and the preview version of 2.0 final, which as far as I know is identical to the final. PythonInterpreter has 20001 k, virtual memory is off. (However, file events are broken on my machine and possibly for everybody, see my earlier posting and Jack Jansen's reply.) -- Russell From boyle5@llnl.gov Mon Nov 6 17:35:56 2000 From: boyle5@llnl.gov (Jim Boyle) Date: Mon, 6 Nov 2000 09:35:56 -0800 Subject: [Pythonmac-SIG] Tkinter crashes Message-ID: On my PowerMac 7300/200 running OS9 and the MacPython 2.0 final I get a crash running the pyboids program ( boids is a flocking simulator described in the Amateur Scientist, Scientific American, Nov 2000, pyboids is in the vaults of parnassus). The trackback gives: TclError: too many nested calls to Tcl_Eval ( infinite loop?) This codes uses the threading and Tkinter modules. It runs fine on an 86 box using RedHat6.2 and on the other side of my Mac using PPCLinux. The code behaves the same for Python 1.5.2, I was hoping that 2.0 would fix things. Guido's electrons.py demo runs OK on the 2.0 version. Jim From jack@oratrix.nl Mon Nov 6 18:26:27 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 06 Nov 2000 19:26:27 +0100 Subject: [Pythonmac-SIG] Tkinter crashes In-Reply-To: Message by Jim Boyle , Mon, 6 Nov 2000 09:35:56 -0800 , Message-ID: <20001106182632.1CEE21301D7@oratrix.oratrix.nl> Recently, Jim Boyle said: > On my PowerMac 7300/200 running OS9 and the MacPython 2.0 final I get > a crash running the pyboids program ( boids is a flocking simulator > described in the Amateur Scientist, Scientific American, Nov 2000, > pyboids is in the vaults of parnassus). > > The trackback gives: > TclError: too many nested calls to Tcl_Eval ( infinite loop?) > > This codes uses the threading and Tkinter modules. Ah, yet another area that I didn't do any testing in: Tkinter and threading. I'd be interested in hearing reports of others who tried this combination and whether it does or does not work. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From sdm7g@minsky.med.virginia.edu Mon Nov 6 18:33:07 2000 From: sdm7g@minsky.med.virginia.edu (Steven D. Majewski) Date: Mon, 6 Nov 2000 13:33:07 -0500 (EST) Subject: [Pythonmac-SIG] Trying to build PyObjC on MacOSX -- what's missing? (fwd) Message-ID: Is anyone else in Python land working on porting to OSX ? I'm trying to build the objective-C bindings (PyObjC) for Python on MacOSX public beta. In PyObjC, I: * fixed (I hope) the call INSTMETH macro in objc_support.h to add missing 2nd arg. * undated obsolete & missing message send: NSMethodSignature *methinfo; [methinfo argumentInfoAtIndex:argn+2].type; to: [methinfo getArgumentTypeAtIndex:argn+2]; * added to objc_support.h includes ( for obsolete NXHash* functions ) * changed some '#include's to '#import's to keep the warnings down to a reasonable level so I could find other bugs. After that, it will compile on MacOSX public beta. The final link command from the Makefile is: cc -bundle -undefined suppress ObjC.o ObjCMethod.o ObjCObject.o ObjCPointer.o ObjCRuntime.o objc_support.o OC_PythonBundle.o OC_PythonInt.o OC_PythonObject.o OC_PythonString.o -o ObjC.so Trying to load it from Python, I get: [localhost:~/Src/PyObjC] sdm% python Python 2.0 (#3, 10/22/00, 12:04:10) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> import ObjC dyld: python Undefined symbols: .objc_class_name_NSBundle .objc_class_name_NSException .objc_class_name_NSInvocation .objc_class_name_NSMethodSignature .objc_class_name_NSNumber .objc_class_name_NSProxy .objc_class_name_NSString .objc_class_name_Protocol _NSSelectorFromString _NSStringFromSelector _NXInitHashState _NXNextHashState __NSAddHandler2 __NSConstantStringClassReference __NSExceptionObjectFromHandler2 __NSRemoveHandler2 _class_getInstanceMethod _objc_getClasses _objc_lookUpClass _objc_msgSend _objc_msgSendSuper _objc_setMultithreaded _object_getClassName _sel_getUid _sel_isMapped linking again, adding -lobjc: [localhost:~/Src/PyObjC] sdm% python Python 2.0 (#3, 10/22/00, 12:04:10) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> import ObjC dyld: python multiple definitions of symbol __objcInit python definition of __objcInit /usr/lib/libobjc.A.dylib(objc-runtime.o) definition of __objcInit which is the same thing I get if I try to link with "-framework Foundation" instead. 'otool -vR /usr/lib/libobjc_profile.A.dylib' tells me that some of those symbols are "undefined [lazy]" -- what does that mean? -- Steve Majewski From dmccarthy@ou.edu Mon Nov 6 21:29:05 2000 From: dmccarthy@ou.edu (David McCarthy) Date: Mon, 06 Nov 2000 15:29:05 -0600 Subject: [Pythonmac-SIG] Re: Tkinter crashes References: <20001106170245.A6C511CEC1@dinsdale.python.org> Message-ID: <3A07229F.D8C0B5E6@ou.edu> > >Maybe a few other people could try electrons.py and let us hear the results so > >we can narrow this down? My guess is that 8.1 is the problem: I got another > >message from someone saying that Tcl/Tk 8.3 is unstable on older macosses. > My tkinter-based program in Python 2.0 works fine with OS 9.04 and OS 8.6. Under OS 8.1 the program crashes when I click in the program window or in the interpreter window. I get a dialog box mentioning an error of type 3. Dave McCarthy dmccarthy@ou.edu From wtbridgman@Radix.Net Tue Nov 7 01:30:58 2000 From: wtbridgman@Radix.Net (W.T. Bridgman) Date: Mon, 6 Nov 2000 20:30:58 -0500 Subject: [Pythonmac-SIG] Building external module under MacPython 2.0 In-Reply-To: <20001106131453.B315331C49C@snelboot.oratrix.nl> References: <20001106131453.B315331C49C@snelboot.oratrix.nl> Message-ID: Rob & Jack, Thanks, that solved the problem. I think I used to have GUSI installed on my system but must have dumped it during a general cleanup - not realizing where it was being used. Thanks again, Tom > > I'm trying to recompile a Python extension that ran under 1.5.1 to >> run under 2.0. I'm using CodeWarrior 5. I have the source code for >> the module but am not that familiar with the details of it's >> operation. >> >> After fixing a few other problems (Py_Malloc seems to have become >> more type-sensitive - the API docs suggest it may be gone, replaced >> by PyMem_Malloc?), I'm down to this error: >> >> Error : the file 'sys/time.h' cannot be opened >> pyport.h line 95 #include > >Your project file should have the "interpret unix/dos paths" option turned on, >and the GUSI2/Include folder should have the recursive bit turned off. > >The example xx.prj project has this all correctly, but if you're converting an >old project that doesn't help you much, of course. Still, you could check the >various preferences settings for xx.prj and your project side-by-side to see >what has changed. >-- >Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ >Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ >www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm -- Tom Bridgman, Ph.D. wtbridgman@radix.net Physics & Astronomy From wtbridgman@Radix.Net Tue Nov 7 01:31:31 2000 From: wtbridgman@Radix.Net (W.T. Bridgman) Date: Mon, 6 Nov 2000 20:31:31 -0500 Subject: [Pythonmac-SIG] Tkinter crashes In-Reply-To: <1001105215051.ZM19688@Octopussy.MI.Uni-Koeln.DE> References: <1001105215051.ZM19688@Octopussy.MI.Uni-Koeln.DE> Message-ID: My Tkinter apps seem just fine, and I can still run electrons.py (which I regard as a general test of Tkinter functioning). MacOS 9.0.4, MacPython 2.0 (final), PowerBook G3/333. Tom >Hello, > >whenever I am running any Tk-application (try electrons.py in >Demo:tkinter:guido) with its window in the foreground, a click >on the visible part of the PythonInterpreter.out window crashes >my Mac, so that cmd-opt-esc does not work anymore. Same thing >happens the other way around and also with trying to switch >between different Tk-windows, so hiding PythonInterpreter.out >is no solution. > >Is it just me ? Any ideas what to try ? Btw, older versions >did not have that particular bug. > >Alexander > > >PS: - MacPython 2.0 (just downloaded), 40 MB Ram assigned to interpreter > - MacOS 8.1 US with navigation services on a PB 2400c > > > >-- >Alexander Schliep schliep@zpr.uni-koeln.de >ZPR/ZAIK Tel: +49-221-470-6040 (w) >University of Cologne FAX: +49-221-470-5160 >Weyertal 80 http://www.zpr.uni-koeln.de/~schliep >50931 Cologne, Germany > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://www.python.org/mailman/listinfo/pythonmac-sig From bobsavage@mac.com Tue Nov 7 01:50:31 2000 From: bobsavage@mac.com (Bob Savage) Date: Mon, 6 Nov 2000 17:50:31 -0800 Subject: [Pythonmac-SIG] PyObjC demos available Message-ID: <200011070150.RAA23754@smtp.Stanford.EDU> Steven, I found some demos using PyObjC. They are not in the 55 = distribution, they are in an older (54) distribution. Here is the link: http://www.codefab.com/unsupported/pyobjc-snapshot-19980802.tar.gz Congrats on all the progress you are making! Bob Bob Savage= From azeldis@wesleyan.edu Tue Nov 7 14:52:46 2000 From: azeldis@wesleyan.edu (Andrew Zeldis) Date: Tue, 7 Nov 2000 09:52:46 -0500 Subject: [Pythonmac-SIG] Re: Python Bridge References: <20001106170245.A6C511CEC1@dinsdale.python.org> Message-ID: <00dd01c048ca$63f04be0$9f804b3f@plumbdesign.com> There's an existing PyObjC module available from codefab's ftp site. It takes a little tweaking to build on OSX (I haven't done it myself) but apparently it works and allows access to all Objective-C on the system, by dynamically loading frameworks etc. It has some kinks but I'll be sure somebody lets the list know. Check ftp://ftp.codefab.com/pub/unsupported/. From jmillr@umich.edu Tue Nov 7 18:40:59 2000 From: jmillr@umich.edu (John A. Miller) Date: Tue, 7 Nov 2000 13:40:59 -0500 (EST) Subject: [Pythonmac-SIG] MacPython & BBEdit 6.0.1 In-Reply-To: <20001107170158.2BEEE1D03F@dinsdale.python.org> Message-ID: I'm new to (Mac)Python and this list. I've downloaded and installed the latest 2.0 version, and am just beginning to understand the MacPython way of working. As I gleaned from the documentation, there are basically two approaches: use the PythonIDE, or use the PythonInterpreter. The documentation further suggests that the recommended way of programming is to use the PythonIDE, but that the documentation itself focuses mainly on using the PythonInterpreter, which is fine since I hope to create some GUIs with TKinter, so I'm (currently) restricted to using the PythonInterpreter anyway (if I understand correctly). Furthermore, I'm fond of BBEdit 6.0.1 and would like to use it for my Python programming, so my question centers on recommendations for most closely integrating BBEdit with MacPython 2.0. The documentation refers to a 'BBPy' folder which seems to be missing the "Run as Python" extension, and the documention for *it* (BBPy) seems quite dated (although it may still be up-to-date!) Another piece of the puzzle is that BBEdit now has the capability of using 'Language Modules' for languages not natively supported. So, my interrelated questions are: * Is there a "Run as Python" extension (now called Plug-Ins) to use with BBEdit 6.0+? * Does anyone know of any effort to create a Python Language Module for BBEdit 6.0+? * Are there any suggestions born of experience for using BBEdit as a standalone editor with the PythonInterpreter? Thanks for any assistance getting my MacPython experience off on the right foot! John Miller From dameronm@rolfingsi.com Wed Nov 8 01:08:07 2000 From: dameronm@rolfingsi.com (Dameron Midgette) Date: Tue, 7 Nov 2000 20:08:07 -0500 Subject: [Pythonmac-SIG] osam? Message-ID: <19341002183951.21766@smtp.gwi.net> Hello all! Back to playing with 2.0! I had a question about the osam shlb in mac:contrib. What does it do? I'm looking at a fair bit of applescripting ahead, so *anything* that would make it more painless would help. I'm a relative newbie, who dabbled a bit about a year ago. TIA Cheers, Dameron From rwklee@home.com Wed Nov 8 14:44:04 2000 From: rwklee@home.com (Rick Lee) Date: Wed, 08 Nov 2000 09:44:04 -0500 Subject: [Pythonmac-SIG] Help with IDE Debugger please Message-ID: <3A0966B0.4E64EE5B@home.com> Hi, I am having trouble figuring out how to use the IDE debugger. I can start up IDE, and turn on debugger in the Hack menu. The debugger says running. After that, I am stumped. I import a file in the interpreter window; the file runs and does not hit the debugger. I open a file in the editor window, hit "run all", and nothing seems to happen. I have the same problem in 1.52 and 2.0 most recent version. I did not make any changes to the installed directories or installed files. I am used to IDLE, where, after turning on the debugger, typing in a command in the interpreter window automatically triggers the debugger. Thanks in advance. - Rick Lee rwklee@home.com From just@letterror.com Wed Nov 8 15:06:46 2000 From: just@letterror.com (Just van Rossum) Date: Wed, 8 Nov 2000 16:06:46 +0100 Subject: [Pythonmac-SIG] Help with IDE Debugger please In-Reply-To: <3A0966B0.4E64EE5B@home.com> Message-ID: At 9:44 AM -0500 08-11-2000, Rick Lee wrote: >Hi, > >I am having trouble figuring out how to use the IDE debugger. I can >start up IDE, and turn on debugger in the Hack menu. The debugger says >running. After that, I am stumped. I import a file in the interpreter >window; the file runs and does not hit the debugger. I open a file in >the editor window, hit "run all", and nothing seems to happen. I have >the same problem in 1.52 and 2.0 most recent version. I did not make >any changes to the installed directories or installed files. 1) The debugger isn't meant to work from the interactive window 2) The usual way to enable the debugger is to choose "Enable debugger" in the little popup menu present at the top right corner of the edit window. This allows you to set breakpoints. 3) The hack menu version triggers the debugger globally, but it will only stop at a breakpoint. See 2... Hope this helps, Just From jack@oratrix.nl Wed Nov 8 15:57:19 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 08 Nov 2000 16:57:19 +0100 Subject: [Pythonmac-SIG] Help with IDE Debugger please In-Reply-To: Message by Just van Rossum , Wed, 8 Nov 2000 16:06:46 +0100 , Message-ID: <20001108155720.6A21231C49C@snelboot.oratrix.nl> > 1) The debugger isn't meant to work from the interactive window > > 2) The usual way to enable the debugger is to choose "Enable debugger" in > the little popup menu present at the top right corner of the edit window. > This allows you to set breakpoints. Just, how much work would it be to add an "enable debugger" to the interactive window? When you switch the debugger on in the main window you would simply run the IDE mainloop with pdb.run(), so that a debugger would be started whenever an exception occurs. Or am I seeing things too simple? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tom@othermedia.com Wed Nov 8 16:06:57 2000 From: tom@othermedia.com (tom smith) Date: Wed, 08 Nov 2000 16:06:57 +0000 Subject: [Pythonmac-SIG] odbc on a mac? In-Reply-To: <19341002183951.21766@smtp.gwi.net> Message-ID: Hi, I'm writing that script that'll run on a PC, but I'm developing on a mac. I need to save data into an ODBC database. I've got FileMaker with the ODBC control panel, though the destination machine will be SQLServer. Has anybody ever got the ODBC modules working with MacPython.... I currently get errors from mxDateTime (on whicj I think ODBC relies) that it was built for a previous version of python. Are there any work-arounds? I'm currently using Gadfly for testing purposes... thanks tom From azeldis@wesleyan.edu Wed Nov 8 19:22:44 2000 From: azeldis@wesleyan.edu (Andrew Zeldis) Date: Wed, 8 Nov 2000 14:22:44 -0500 Subject: [Pythonmac-SIG] Newbie needs total explanation: building Python modules (linking, dyld, etc) Message-ID: <20001108192244.B49FB1CEB8@dinsdale.python.org> After hearing about the PyObjC module (and getting quite excited) I'm = downcast as I've run into the problem with multiply defined symbols. I = know this can be gotten around by linking the module into the python = interpreter statically, which I will do in a moment. But I ran into = this earlier with the MySQL module, and would like one of you gurus to = explain why this is happening and how python modules ought to be built. = I don't know enough about linking etc. to figure this out, and I need an = explanation starting from the beginning. (I hope that's not too much to = ask..) On a related note, the make -f Makefile.pre.in boot; make method doesn't = seem to work reliably with 2.0. I'm assuming this is because it has = been superseded by distutils, which also doesn't work for OSX. Has = anybody made a version of distutils that does work? Sorry for crossing lists, but this is really crossing topics... From sdm7g@minsky.med.virginia.edu Wed Nov 8 20:12:33 2000 From: sdm7g@minsky.med.virginia.edu (Steven D. Majewski) Date: Wed, 8 Nov 2000 15:12:33 -0500 (EST) Subject: [Pythonmac-SIG] [pyobjc] NSAutorelease support Message-ID: From reading the PyObjC(5.5) ChangeLog and the Python/Misc/HISTORY files along with the source code, it looks like some of the AutoreleasePool support was commented out when the support in Python itself for Objective-C disappeared: // if (!PyObjC_Active) // { // PyThreadState *tstate = PyThreadState_Get(); // // PyObjC_Active = 1; // tstate->interp->objc_autorelease_counter =OBJC_AUTORELEASE_FACTOR; // tstate->interp->objc_autorelease_pool = [[NSAutoreleasePool alloc]init]; // } After adding static declarations for PyObjC_Active and objc_autorelease_pool and putting back the [[NSAutoreleaseRool alloc]init] message, I can now get it to do the following sort of stuff without pages of 'just leaking' error messages: [localhost:~/Src/PyObjC] sdm% ./pyobjc Python 2.0 (#3, 10/22/00, 12:04:10) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> from ObjC import * >>> dir() ['__builtins__', '__doc__', '__name__', 'error', 'lookup_class', 'make_pointer', 'runtime'] >>> DC = lookup_class( 'NSCalendarDate' ) >>> DC >>> date = DC() >>> date >>> print date 2000-11-08 14:26:53 -0500 >>> >>> date.monthOfYear() 11 >>> date.dayOfMonth() 8 >>> I don't yet know enough about what I'm doing here to tell if that's a reasonable fix or an ugly leaking hack, but it does make pyobjc at least experimentally usable on OSX. I could not get pyobjc calls from Python to AutoreleasePool to work. Without that patch, I get >>> from ObjC import * >>> P = lookup_class( 'NSAutoreleasePool' ) >>> pool = P() Nov 08 14:58:11 pyobjc[465] *** Uncaught exception: *** -[NSAutoreleasePool retain]: Cannot retain an autorelease pool or >>> from ObjC import * >>> POOL = lookup_class( 'NSAutoreleasePool' ) >>> pool = POOL.alloc() Nov 08 14:59:04 pyobjc[466] *** _NSAutoreleaseNoPool(): Object 0x27c3a0 of class NSCFString autoreleased with no pool in place - just leaking Nov 08 14:59:04 pyobjc[466] *** _NSAutoreleaseNoPool(): Object 0x27eea0 of class NSInvocation autoreleased with no pool in place - just leaking Nov 08 14:59:04 pyobjc[466] *** _NSAutoreleaseNoPool(): Object 0x27f520 of class NSCFString autoreleased with no pool in place - just leaking Nov 08 14:59:04 pyobjc[466] *** _NSAutoreleaseNoPool(): Object 0x27f2c0 of class NSCFString autoreleased with no pool in place - just leaking Nov 08 14:59:04 pyobjc[466] *** _NSAutoreleaseNoPool(): Object 0x27fb00 of class NSException autoreleased with no pool in place - just leaking Traceback (most recent call last): File "", line 1, in ? ObjC.error: *** -[NSAutoreleasePool retain]: Cannot retain an autorelease pool >>> pool.init() Traceback (most recent call last): File "", line 1, in ? NameError: There is no variable named 'pool' >>> BTW: Trying to do something "visual" with AppKit, I get: >>> NSApp = lookup_class( 'NSApplication' ) >>> NSApp.sharedApplication() Nov 08 15:04:25 pyobjc[471] Warning - could not find theme file in System directory. Trying home directory. Bus error -- Steve Majewski From bbum@codefab.com Wed Nov 8 20:21:09 2000 From: bbum@codefab.com (Bill Bumgarner) Date: Wed, 8 Nov 2000 15:21:09 -0500 Subject: [Pythonmac-SIG] Re: [pyobjc] NSAutorelease support Message-ID: <200011082021.eA8KLAi10525@bjork.codefab.com> - autorelease pools I would much rather see support for autorelease pools as a call to the ObjC module. I.e. ObjC.pushReleasePool() ObjC.popReleasePool() Implementation is left as an exercise to the reader-- keep in mind that you can't use standard ObjC collection classes because they all retain/release stuff!!! The exception you are seeing makes sense-- the wrapping of the autrelease pool in the PyObject wrapper sends that release pool a -retain. Actually, a better implementation would be to simply use -isKindOfClass: to test the object to see if it is a release pool or not and simply do NOT retain release pools... this would also lead to an implementation with much better thread support [which, btw, i have patches to make threading at least build on OSXS]. --- Appkit: We will have to throw together a boostrapper that configures a mainBundle such that it has the appropriate property lists and such.... I think there was a discussion of doing wrapperless appkit apps on the osx-dev mailing list very recently. b.bum From: "Steven D. Majewski" Date: 2000-11-08 15:12:33 -0500 To: python-list@python.org, pythonmac-sig@python.org Subject: [pyobjc] NSAutorelease support cc: Andrew Zeldis , Bill Bumgarner , bobsavage@mac.com, jas@corpus-callosum.com, tony@metanet.com >From reading the PyObjC(5.5) ChangeLog and the Python/Misc/HISTORY files along with the source code, it looks like some of the AutoreleasePool support was commented out when the support in Python itself for Objective-C disappeared: // if (!PyObjC_Active) // { // PyThreadState *tstate = PyThreadState_Get(); // // PyObjC_Active = 1; // tstate->interp->objc_autorelease_counter =OBJC_AUTORELEASE_FACTOR; // tstate->interp->objc_autorelease_pool = [[NSAutoreleasePool alloc]init]; // } After adding static declarations for PyObjC_Active and objc_autorelease_pool and putting back the [[NSAutoreleaseRool alloc]init] message, I can now get it to do the following sort of stuff without pages of 'just leaking' error messages: [localhost:~/Src/PyObjC] sdm% ./pyobjc Python 2.0 (#3, 10/22/00, 12:04:10) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> from ObjC import * >>> dir() ['__builtins__', '__doc__', '__name__', 'error', 'lookup_class', 'make_pointer', 'runtime'] >>> DC = lookup_class( 'NSCalendarDate' ) >>> DC >>> date = DC() >>> date >>> print date 2000-11-08 14:26:53 -0500 >>> >>> date.monthOfYear() 11 >>> date.dayOfMonth() 8 >>> I don't yet know enough about what I'm doing here to tell if that's a reasonable fix or an ugly leaking hack, but it does make pyobjc at least experimentally usable on OSX. I could not get pyobjc calls from Python to AutoreleasePool to work. Without that patch, I get >>> from ObjC import * >>> P = lookup_class( 'NSAutoreleasePool' ) >>> pool = P() Nov 08 14:58:11 pyobjc[465] *** Uncaught exception: *** -[NSAutoreleasePool retain]: Cannot retain an autorelease pool or >>> from ObjC import * >>> POOL = lookup_class( 'NSAutoreleasePool' ) >>> pool = POOL.alloc() Nov 08 14:59:04 pyobjc[466] *** _NSAutoreleaseNoPool(): Object 0x27c3a0 of class NSCFString autoreleased with no pool in place - just leaking Nov 08 14:59:04 pyobjc[466] *** _NSAutoreleaseNoPool(): Object 0x27eea0 of class NSInvocation autoreleased with no pool in place - just leaking Nov 08 14:59:04 pyobjc[466] *** _NSAutoreleaseNoPool(): Object 0x27f520 of class NSCFString autoreleased with no pool in place - just leaking Nov 08 14:59:04 pyobjc[466] *** _NSAutoreleaseNoPool(): Object 0x27f2c0 of class NSCFString autoreleased with no pool in place - just leaking Nov 08 14:59:04 pyobjc[466] *** _NSAutoreleaseNoPool(): Object 0x27fb00 of class NSException autoreleased with no pool in place - just leaking Traceback (most recent call last): File "", line 1, in ? ObjC.error: *** -[NSAutoreleasePool retain]: Cannot retain an autorelease pool >>> pool.init() Traceback (most recent call last): File "", line 1, in ? NameError: There is no variable named 'pool' >>> BTW: Trying to do something "visual" with AppKit, I get: >>> NSApp = lookup_class( 'NSApplication' ) >>> NSApp.sharedApplication() Nov 08 15:04:25 pyobjc[471] Warning - could not find theme file in System directory. Trying home directory. Bus error -- Steve Majewski From sdm7g@minsky.med.virginia.edu Wed Nov 8 21:48:56 2000 From: sdm7g@minsky.med.virginia.edu (Steven D. Majewski) Date: Wed, 8 Nov 2000 16:48:56 -0500 (EST) Subject: [Pythonmac-SIG] Re: [pyobjc] NSAutorelease support In-Reply-To: <200011082021.eA8KLAi10525@bjork.codefab.com> Message-ID: On Wed, 8 Nov 2000, Bill Bumgarner wrote: > > - autorelease pools > > I would much rather see support for autorelease pools as a call to the ObjC module. > > I.e. > > ObjC.pushReleasePool() > ObjC.popReleasePool() > I think this would be The Right Thing. Right now, I'm just taking the path of least resistance while I bootstrap my understanding of how it all works. > Appkit: > > We will have to throw together a boostrapper that configures a mainBundle such > that it has the appropriate property lists and such.... I think there was a > discussion of doing wrapperless appkit apps on the osx-dev mailing list very > recently. I had wondered (worried) about this earlier: it would be great to be able to use InterfaceBuilder with Python, but I hoped that didn't mean you couldn't also do it all programatically without GUI tools. ( As on current MacOS<10: you can use & load Resources, or you can define objects procedurally. ) I cribbed the following code from Pete French post to , filled in the missing bits and turned his comments into Comments. Compiled and built without any nibs or bundles, it does demonstrate it's possible. I would guess that there's some pyobjc code that assumes that there is a bundle to load. -- Steve Majewski #include main() { NSAutoreleasePool *outer_pool; NSApplication *NSApp; NSWindow *theWindow; NSRect content_rect = { {100.0,100.0},{400,300} }; // For starters I make an application object and an outer autorelease // pool for the program: outer_pool = [NSAutoreleasePool new]; NSApp = [[NSApplication sharedApplication] retain]; // Then we create a window... (content rect is something sensible) theWindow = [[NSWindow alloc] initWithContentRect:content_rect styleMask:(NSTitledWindowMask | NSMiniaturizableWindowMask) backing:NSBackingStoreRetained defer:NO]; [theWindow setReleasedWhenClosed:YES]; // Send it to the front and fill it with grey [theWindow makeKeyAndOrderFront:nil]; [[theWindow contentView] lockFocus]; [[theWindow contentView] allocateGState]; [[NSColor grayColor] set]; NSRectFill((NSRect) { { 1, 1 }, { content_rect.size.width , content_rect.size.height } } ); [[theWindow contentView] unlockFocus]; sleep(100); } From bbum@codefab.com Wed Nov 8 22:00:42 2000 From: bbum@codefab.com (Bill Bumgarner) Date: Wed, 8 Nov 2000 17:00:42 -0500 Subject: [Pythonmac-SIG] Re: [pyobjc] NSAutorelease support In-Reply-To: <200011082021.eA8KLAi10525@bjork.codefab.com> Message-ID: <200011082200.eA8M0hi14192@bjork.codefab.com> Ultimately, I think what we need to do is *rewrite* the module entirely because of all of the changes between both OSX and Python 2.0. From sdm7g@virginia.edu Wed Nov 8 23:36:11 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Wed, 8 Nov 2000 18:36:11 -0500 (EST) Subject: [Pythonmac-SIG] Re: [pyobjc] NSAutorelease support In-Reply-To: <200011082200.eA8M0hi14192@bjork.codefab.com> Message-ID: On Wed, 8 Nov 2000, Bill Bumgarner wrote: > Ultimately, I think what we need to do is *rewrite* the module entirely > because of all of the changes between both OSX and Python 2.0. I also think this is likely. A lot will need to be done to add better Darwin/MacOSX/Carbon/Cocoa support and there doesn't appear to be a line of people willing to test changes for GnuStep or OpenStep. As CoreFoundation is common to Darwin and MacOSX, as well as CarbonLib on Classic MacOS, it would seem to make sense to build ontop of that ( CFBundle and the plugin-services [sort of COM for the Mac] ) rather than NSBundle et.al. which are only on OSX. ( and I assume GnuStep/NextStep/OpenStep ) Still, it might be good to get out one last "legacy" release of pyobjc -- Darwin and MacOSX might spark some more interest in Objective-C and GnuStep! ---| 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 operating systems want to be unix, All programming languages want to be lisp." From bbum@codefab.com Wed Nov 8 23:42:40 2000 From: bbum@codefab.com (Bill Bumgarner) Date: Wed, 8 Nov 2000 18:42:40 -0500 Subject: [Pythonmac-SIG] Re: [pyobjc] NSAutorelease support In-Reply-To: <200011082200.eA8M0hi14192@bjork.codefab.com> Message-ID: <200011082342.eA8Ngfi17841@bjork.codefab.com> AFAIK, Carbon on MacOS does not include ObjC-- so, no point in going to the relatively primitive CoreFoundation API because it won't gain portability to that environment and it will greatly impede portability to GnuStep/OpenStep.... I'm thinking that we can keep the basic code structure as is, but simply rewrite the internals to the modern underlying APIs. BTW: I have patches to makesetup and Python v. 2.0 that both fixes bugs and adds support for OSXS and OSX external shlib based modules... I'll try to pull 'em together and forward 'em sometime soon. b.bum From: "Steven D. Majewski" Date: 2000-11-08 18:36:11 -0500 To: Bill Bumgarner Subject: Re: [pyobjc] NSAutorelease support cc: Bill Bumgarner , python-list@python.org, pythonmac-sig@python.org, Andrew Zeldis , bobsavage@mac.com, jas@corpus-callosum.com, tony@metanet.com In-Reply-To: <200011082200.eA8M0hi14192@bjork.codefab.com> X-Sender: sdm7g@elvis.med.Virginia.EDU On Wed, 8 Nov 2000, Bill Bumgarner wrote: > Ultimately, I think what we need to do is *rewrite* the module entirely > because of all of the changes between both OSX and Python 2.0. I also think this is likely. A lot will need to be done to add better Darwin/MacOSX/Carbon/Cocoa support and there doesn't appear to be a line of people willing to test changes for GnuStep or OpenStep. As CoreFoundation is common to Darwin and MacOSX, as well as CarbonLib on Classic MacOS, it would seem to make sense to build ontop of that ( CFBundle and the plugin-services [sort of COM for the Mac] ) rather than NSBundle et.al. which are only on OSX. ( and I assume GnuStep/NextStep/OpenStep ) Still, it might be good to get out one last "legacy" release of pyobjc -- Darwin and MacOSX might spark some more interest in Objective-C and GnuStep! ---| 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 operating systems want to be unix, All programming languages want to be lisp." From sdm7g@virginia.edu Thu Nov 9 00:51:00 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Wed, 8 Nov 2000 19:51:00 -0500 (EST) Subject: [Pythonmac-SIG] [pyobjc] portability and clean starts (was:NSAutorelease support) In-Reply-To: <200011082342.eA8Ngfi17841@bjork.codefab.com> Message-ID: On Wed, 8 Nov 2000, Bill Bumgarner wrote: > AFAIK, Carbon on MacOS does not include ObjC-- so, no point in going to the > relatively primitive CoreFoundation API because it won't gain portability to > that environment and it will greatly impede portability to GnuStep/OpenStep.... My point is that portability w.r.t. GnuStep/OpenStep/NextStep/Cocoa/... is a different dimension than portability for Darwin(including Darwin on Intel)/MacOSX/ClassicMac+CarbonLib. There *MAY* be portability advantages (in that second dimension) to using the lower level and common (among that family) interfaces: more code to initially write, but less total code to support all of those system. Supporting all the *Step flavors probably means more work, and it becomes prohibitive if there aren't enough users, testers and maintainers. ( Isn't this why PyObjC was dropped from the Python core distribution ? If there are a lot of Python + GnuStep users lurking out there, please speak up! ) The main advantage of a clean start would seem to be to make a clean start and get rid of a lot of untested #ifdef's . ---| 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 operating systems want to be unix, All programming languages want to be lisp." From bbum@codefab.com Thu Nov 9 02:05:03 2000 From: bbum@codefab.com (Bill Bumgarner) Date: Wed, 08 Nov 2000 21:05:03 -0500 Subject: [Pythonmac-SIG] Re: [pyobjc] portability and clean starts (was:NSAutorelease support) References: Message-ID: <3A0A0650.42294B27@codefab.com> It was dropped because of very little interest combined with fairly sweeping changes to python that were sucking up everyone's time-- I remember when the decision was made-- and none of us [Lele, Jeff, myself or others] had the time/motivation to step up and maintain the stuff. There has basically been zero effort aimed at this codebase in the last 2.5 years-- and it was minimal for nearly 2 years before that.... My point was that Objective-C doesn't exist in the Carbon libraries on MacOS. The lack of the Foundation level APIs [NSBundle, mostly] on that platform are moot when considering the porting aspects. If the goal is to bring a binding into *some other* ObjC runtime on MacOS, then we need to seriously consider whether using any of Carbon or Foundation makes *any* sense beyond simply providing a shim into the existing object framework on that particular platform. Instead, maybe we would need to look at doing something like the os module in Python-- that is, provide a generic ObjC module, but have it effectively be an abstract cover for ObjC.GnuStep, ObjC.MacOS, ObjC.MacOSX, etc,etc,etc... In terms of supporting OSX/OSXS/Darwin, the existing codebase is close to doing that-- it just needs to be cleaned up a bit-- and could be relaitively easily spruced up to again support GnuStep (if it doesn't already-- anyone checked??). However, ultimately, I would rather not be distracted by such high level considerations. We have a codebase that mostly works [thanks to you, Steve!!] and with a bit of iterative refactoring, it could be cleaned up and become a relatively first class implementation across Darwin, GnuStep, and OSX[S]. b.bum "Steven D. Majewski" wrote: > On Wed, 8 Nov 2000, Bill Bumgarner wrote: > > > AFAIK, Carbon on MacOS does not include ObjC-- so, no point in going to the > > relatively primitive CoreFoundation API because it won't gain portability to > > that environment and it will greatly impede portability to GnuStep/OpenStep.... > > My point is that portability w.r.t. GnuStep/OpenStep/NextStep/Cocoa/... > is a different dimension than portability for > Darwin(including Darwin on Intel)/MacOSX/ClassicMac+CarbonLib. > > There *MAY* be portability advantages (in that second dimension) to > using the lower level and common (among that family) interfaces: > more code to initially write, but less total code to support all > of those system. > > Supporting all the *Step flavors probably means more work, and it > becomes prohibitive if there aren't enough users, testers and > maintainers. ( Isn't this why PyObjC was dropped from the Python > core distribution ? If there are a lot of Python + GnuStep users > lurking out there, please speak up! ) > > The main advantage of a clean start would seem to be to make a > clean start and get rid of a lot of untested #ifdef's . > > ---| 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 operating systems want to be unix, > All programming languages want to be lisp." From cbarker@jps.net Thu Nov 9 23:40:03 2000 From: cbarker@jps.net (Chris Barker) Date: Thu, 09 Nov 2000 15:40:03 -0800 Subject: [Pythonmac-SIG] 1.5.2c1 and time module. References: Message-ID: <3A0B35D3.B2D86E4D@jps.net> Hi all, I seem to be missing time.strptime() I kind of need it, why would it be missing? NOTE, this is 1.5.2c1. Maybe I have just found the compelling reason to make the switch to 2.0! -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From wtbridgman@Radix.Net Fri Nov 10 12:52:22 2000 From: wtbridgman@Radix.Net (W.T. Bridgman) Date: Fri, 10 Nov 2000 07:52:22 -0500 Subject: [Pythonmac-SIG] Tkinter crashes Message-ID: Spoke too soon! It looks like it does happen to me as well. The problem does seem to require clicking in the Tk window - not on a button. MacOS 9.0.4, MacPython 2.0 (final), PowerBook G3/333. Tom >Hello, > >whenever I am running any Tk-application (try electrons.py in >Demo:tkinter:guido) with its window in the foreground, a click >on the visible part of the PythonInterpreter.out window crashes >my Mac, so that cmd-opt-esc does not work anymore. Same thing >happens the other way around and also with trying to switch >between different Tk-windows, so hiding PythonInterpreter.out >is no solution. > >Is it just me ? Any ideas what to try ? Btw, older versions >did not have that particular bug. > >Alexander > > >PS: - MacPython 2.0 (just downloaded), 40 MB Ram assigned to interpreter > - MacOS 8.1 US with navigation services on a PB 2400c > > > >-- >Alexander Schliep schliep@zpr.uni-koeln.de >ZPR/ZAIK Tel: +49-221-470-6040 (w) >University of Cologne FAX: +49-221-470-5160 >Weyertal 80 http://www.zpr.uni-koeln.de/~schliep >50931 Cologne, Germany From lee.list@joramo.com Fri Nov 10 01:56:21 2000 From: lee.list@joramo.com (Lee Joramo) Date: Thu, 9 Nov 2000 18:56:21 -0700 Subject: [Pythonmac-SIG] MacPython & BBEdit 6.0.1 In-Reply-To: References: Message-ID: <19341004192805.32276@gj.net> I use BBEdit to write all of my Python scripts. To date all of my scripts are targeted to run on Linux systems so I have not felt a strong desire to give up BBEdit's excellent editing environment for the better integration that the IDE provides. I don't remember the details about the BBPy plug-in, but I believe it no longer is supported by the PythonInterpreter. In the past, BareBones has been interested in hearing feature requests to add Python to BBEdit. So I would encourage you to contact BareBones with your desire for Python support. One tip I can pass along: You can get BBEdit to provide colored highlighting for Python. Go to Preferences -> Languages and create a File Suffix Mapping Suffix: .py Language: Tcl Now BBEdit will add color to your Python code using the TCL color scheme. For most situations this works just fine. Off the top of my head the only problem I can think of is that multi-line quotations will not be colored properly. -- Lee A. Joramo ljoramo@nickads.com The Nickel Want Ads www.nickads.com Internet Manager 970-242-5555 >I'm new to (Mac)Python and this list. I've downloaded and installed the >latest 2.0 version, and am just beginning to understand the MacPython way >of working. As I gleaned from the documentation, there are basically two >approaches: use the PythonIDE, or use the PythonInterpreter. The >documentation further suggests that the recommended way of programming is >to use the PythonIDE, but that the documentation itself focuses mainly on >using the PythonInterpreter, which is fine since I hope to create some >GUIs with TKinter, so I'm (currently) restricted to using the >PythonInterpreter anyway (if I understand correctly). Furthermore, I'm >fond of BBEdit 6.0.1 and would like to use it for my Python programming, >so my question centers on recommendations for most closely integrating >BBEdit with MacPython 2.0. The documentation refers to a 'BBPy' folder >which seems to be missing the "Run as Python" extension, and the >documention for *it* (BBPy) seems quite dated (although it may still be >up-to-date!) Another piece of the puzzle is that BBEdit now has the >capability of using 'Language Modules' for languages not natively >supported. So, my interrelated questions are: > >* Is there a "Run as Python" extension (now called Plug-Ins) to use with >BBEdit 6.0+? > >* Does anyone know of any effort to create a Python Language Module for >BBEdit 6.0+? > >* Are there any suggestions born of experience for using BBEdit as a >standalone editor with the PythonInterpreter? > >Thanks for any assistance getting my MacPython experience off on the right >foot! > >John Miller > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://www.python.org/mailman/listinfo/pythonmac-sig > From jimholliman@heartsoft.com Fri Nov 10 22:03:43 2000 From: jimholliman@heartsoft.com (Jim Holliman) Date: Fri, 10 Nov 2000 16:03:43 -0600 Subject: [Pythonmac-SIG] Scripting Code Warrior Pro5.3 Message-ID: I'm starting a project to script CodeWarrior Pro5.3 using the MacPython gensuitemodule etc. After seeing some notes about problems with this in the Pythonmac-SIG archives I thought I'd ask if anyone of you has any tips or warnings. -- Thanks Jim Holliman Heartsoft Inc. From jack@oratrix.nl Fri Nov 10 22:29:13 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 10 Nov 2000 23:29:13 +0100 Subject: [Pythonmac-SIG] Scripting Code Warrior Pro5.3 In-Reply-To: Message by Jim Holliman , Fri, 10 Nov 2000 16:03:43 -0600 , Message-ID: <20001110222918.02CE71301D9@oratrix.oratrix.nl> The one thing I came across is a bug in the codewarrior scripting dictionary: the arguments that correspond to "save as xml" aren't correct (the implementation is correct, the dictionary is wrong). :Mac:lib:mkcwproject:cwtalker.py subclasses the standard MacPython codewarrior OSA class (which is machine-generated) to fix these bugs. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Nov 10 22:33:39 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 10 Nov 2000 23:33:39 +0100 Subject: [Pythonmac-SIG] Tkinter crashes In-Reply-To: Message by "W.T. Bridgman" , Fri, 10 Nov 2000 07:52:22 -0500 , Message-ID: <20001110223344.C8D621301D9@oratrix.oratrix.nl> Recently, "W.T. Bridgman" said: > Spoke too soon! It looks like it does happen to me as well. The > problem does seem to require clicking in the Tk window - not on a > button. > > MacOS 9.0.4, MacPython 2.0 (final), PowerBook G3/333. This is interesting, as you are the first one to report this on a new MacOS. I had already sort-of decided that this problem had to do with the instability of tcl under MacOS 8.1. Could you give me a recipy for repeating this? I still can't get tkinter to do anything bad... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From Jack.Jansen@oratrix.com Fri Nov 10 22:37:14 2000 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 10 Nov 2000 23:37:14 +0100 Subject: [Pythonmac-SIG] BBPy Message-ID: <3A0C78A1.26D292A5@oratrix.com> This is a multi-part message in MIME format. --------------DD12B5425B7D9C03C0CC148F Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Hmm, "Run as Python" should have been in the distribution (in :Mac:Contrib:BBPy) in binhexed form. I don't understand why it got left out, I probably messed up. It's attached here. --------------DD12B5425B7D9C03C0CC148F Content-Type: application/mac-binhex40; x-mac-type="54455854"; x-mac-creator="426E4871"; name="Run-as-Python.hqx" Content-Transfer-Encoding: 7bit Content-Description: Document Content-Disposition: inline; filename="Run-as-Python.hqx" (This file must be converted with BinHex 4.0) :%9*eEL"KFb"3HA4SEfiZFfPd!&0*9%46593K!*!%"DX!N!5Z&90*9#%!!3!!"DY b6'&e!J#3""B#DJd!$9*eEL"KFb"3HA4SEfib[!)TR,)!!!%!N!8#+Ckd!QN!N"V rN!4#3PK88LTMD!%!XpTK)l2DB5-!!!Np!*!'"58!N!5lk!#3#$)j)d31)LUlNDJ 8PGb"qYRclXkU6$*BH-K-D@UDkdNH2k[c6c[2kP4pQ5&*F9+dCAe8X$pfm0hY2rY E'p%XreHh(K*H(49CIBV$49&(e&9d&MGXCJVG3e&kbq8-D4DZTQ@db"(GGFBcG[a jLY62%IXV6$DBUTP-ckUUV#EVQ(G!bbTa0U4PQ5,hF@CU60&LNXQCE+l)Hp&5,Fh Hil3'8!mXR#jcl+EK0@XDbX(JLCc0k*@Jj`T"j@dpi*Rpkk0)M,5pmZ,MSBITpHD hFMpKCA[@!&[9mF+%dY"E43bF3emr"-@[@XbjEDq8d&PG6+1U'SdQeYA6j#Nh6&e 2$P3@PCYp[%Np`I'6Uac1*KT19McMU(+d$EIYIhDiThE+GU&%Q5R*LSEMIp6f8T2 &e"I83irrd58[RIrp2kQPb)@V,P3I@Yr9m3,e#0G'0U1*eC(Ve2,VKT00UiB6*r[ VU+aKfGjElfkY4rr3$EHhrXN,DrF(kB3Q+UX[ULm22C`,eK1kl+kI8m@X9H4D"F@ CVScMicGd[1!U#f@EhcVmPTAY5T(Y-jH&XU%XUfKrLdTUSk'XQ"0)[i@"GdH%QfX bc3Z)3QYc9p3AcGdLKYEfl*UZqQ@'R&6Ee0bcEB2N3Yr8X+cX!hZ2DjLkL&B&NL8 046hNq,,3`9dQU$5a,8@1$&99e428M[fGfZU#@V52+P#0d$ReGcS93UF+183[DeR I%K$HNjIPF[klJ63h,20-r*hHU$9GJKQpE#kHk%PCp6Z0hJ@0l1E1&MXIY`Cj`pD !HKLCFbZ@ND0Y-(IBIlIrlSCPhZ0Y09hJl9X6E@Zk`+lchlh[3TY$R)Q5$-($$UM I(ITcSU,2Vk,eAAR@ZJ+,0iAI+9h*FCEMCI$1!ePS1BF*BedMQ5#[b1*"9Tfm6)X (1AIbiZ`%ZhKLqSIIjE%C1R9Uk*a3pV))9q042QJf'mdYf!q`$@"l"MDFUP,&U6i U#chmp[jDULq##l,[K,1kkSYB(cP$ZpQ''@eXeCjCJJFXVFKBZC90VDIkmI8HU'i 9AQ&2'C0P+i6QE'KQlTR0A)pHe[&#aH631@a$Z#YdB%GDNPAEpjVkmKNUPFhG)MD &lBEQhf"UiQDe%GAABE22K0-eU*XaImTp2f%+dCkTUhbj[3NA*Le``AfjqckJjZl (@A!fpf$J*e55DGVMbcKQE"!Thl15Qf0(59k'abc2K,#re+b@@%dYcDJB&Xj,ae9 X&eUP*IjkUZJTQES&0iJZG)l[9Nc,Z,0DfcYD820Ea0N"U5ff0MR0E9ac)*,E1VC "&qFhk)Urfh@2#Tf-8,!EDT8C,P3qfhA,X(PmkfH6de+i*q1iTlYKkTSZ'i9k2Z2 F1peQ4*H,RH,!i4YSE`e9LHe+J0lk@5+"3N8FClCIePGKLU0b[abGBpFZThS4[pZ fcNeDH[DaI39k68Ip0HAp04he"h[*lSrUB8Sd8@!UhEDhMJdQCe"UF1ABaZrBM2D 0[K3ck)2YX8$-PQZI5jY35V9V3rTD[+@M[*JLkmD#EI+9$LQVaP*M#i93c3DfBFm (I--ERIlV3emrFN!VQ`1A0ZRlQ[lQ!-!a0*d*cV`'hccIr#9f+qaMUl+'bISPPA9 VKT&0XhV@`8f6klUQel&P'm&183U%+&8jijdI%qT$%i)c1i#Bk$SUlZHkZ0(MJZe 4`4R9h0%G4Cq*mcJ$r56dek%[XXjP3LSjFMNib5il9&e,``+6Mhq+,4[$9SpK$pJ B,&&#HprlrA%9!*!$*Ti!!!: --------------DD12B5425B7D9C03C0CC148F-- From jack@oratrix.nl Fri Nov 10 22:42:17 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 10 Nov 2000 23:42:17 +0100 Subject: [Pythonmac-SIG] 1.5.2c1 and time module. In-Reply-To: Message by Chris Barker , Thu, 09 Nov 2000 15:40:03 -0800 , <3A0B35D3.B2D86E4D@jps.net> Message-ID: <20001110224223.2D7771301E8@oratrix.oratrix.nl> Recently, Chris Barker said: > Hi all, > > I seem to be missing time.strptime() > > I kind of need it, why would it be missing? > > NOTE, this is 1.5.2c1. Maybe I have just found the compelling reason to > make the switch to 2.0! Yes, you have. strptime() isn't in the C library MacPython uses, so MacPython can't provide it. The good news is that in 2.0 there's a Python implementation of strptime in :Mac:Contrib:strptime. Tip: if you want to use this seamlessly you copy it to somewhere on sys.path (site-packages comes to mind) and add the following lines to site.py: import time if not hasattr(time, 'strptime'): import strptime time.strptime = strptime.strptime -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From wtbridgman@Radix.Net Sat Nov 11 00:50:55 2000 From: wtbridgman@Radix.Net (W.T. Bridgman) Date: Fri, 10 Nov 2000 19:50:55 -0500 Subject: [Pythonmac-SIG] Tkinter crashes In-Reply-To: <20001110223344.C8D621301D9@oratrix.oratrix.nl> References: <20001110223344.C8D621301D9@oratrix.oratrix.nl> Message-ID: Jack, I was able to reproduce it with electrons.py. I just clicked the mouse in the window and when the script finished, neither ctrl-D or command-Q would let me exit. Over the command window, the cursor would flicker between the i-beam and pointer (stuck in an event loop?). I was able to switch between other windows and exit other apps. I issued a shutdown which hung until I did a command-option-esc in the PythonInterpreter window. It successfully killed the app and the shutdown continued normally. Earlier, I was forced to do a hardware reboot. Then I double-checked without clicking in the Tk window. Sometimes it would lock-up the same way, other times I could exit with ctrl-D or command-Q. Some other notes about my configuration. I'm using the owner account with Multiple Users on. Also, I occasionally use a Logitech Marble Mouse USB which has been kind of flakey on my laptop but which was not in use during these tests. I still have Python v1.5.1 installed. I double-checked my Python home settings for both installations and that seems okay. BTW, electrons.py no longer works under Python v1.5.1, crashing unable to 'import rand'. I'm not sure if this is relevant. Anything else I could test? Hope this is helpful, Tom >Recently, "W.T. Bridgman" said: >> Spoke too soon! It looks like it does happen to me as well. The >> problem does seem to require clicking in the Tk window - not on a >> button. >> >> MacOS 9.0.4, MacPython 2.0 (final), PowerBook G3/333. > >This is interesting, as you are the first one to report this on a new >MacOS. I had already sort-of decided that this problem had to do with >the instability of tcl under MacOS 8.1. > >Could you give me a recipy for repeating this? I still can't get >tkinter to do anything bad... >-- >Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ >Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ >www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm -- Tom Bridgman, Ph.D. wtbridgman@radix.net Physics & Astronomy From wtbridgman@Radix.Net Sat Nov 11 02:55:20 2000 From: wtbridgman@Radix.Net (W.T. Bridgman) Date: Fri, 10 Nov 2000 21:55:20 -0500 Subject: [Pythonmac-SIG] XML file to Python Dictionary Message-ID: --============_-1238211163==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Recently, someone (I seem to recall on this list) asked about a code sample of using xmllib to read an XML file into a Python dictionary. I had been working on just such an idea for managing preferences and other configuration files for some scientific codes. Attached is a sample of the current progress. I packed it into a dropstuff(stuffit) archive to reduce chances of it getting mangled in the e-mail formatting. Some notes: 1) It currently parses numerical values into strings. 2) Lists are split out as dictionary elements. This code is a bit of a hack. Since I got the starter code from some location at sourceforge, I'm not sure how some parts of it really work so any improvements would be appreciated. Tom --============_-1238211163==_============ Content-Id: Content-Type: multipart/appledouble; boundary="============_-1238211163==_D============" --============_-1238211163==_D============ Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="%XML2Preferences.py.sit" Content-Disposition: attachment; filename="%XML2Preferences.py.sit" ; modification-date="Fri, 10 Nov 2000 20:25:31 -0500" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAABYAAAAJAAAAVAAAACAA AAAIAAAAdAAAABBYTUwyUHJlZmVyZW5jZXMucHkuc2l0U0lUNVNJVCEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABnxY6AZ8WO0ttDAABnytV --============_-1238211163==_D============ Content-Type: application/octet-stream; name="XML2Preferences.py.sit" ; x-mac-type="53495435" ; x-mac-creator="53495421" Content-Disposition: attachment; filename="XML2Preferences.py.sit" Content-Transfer-Encoding: base64 U3R1ZmZJdCAoYykxOTk3LTE5OTggQWxhZGRpbiBTeXN0ZW1zLCBJbmMuLCBodHRwOi8v d3d3LmFsYWRkaW5zeXMuY29tL1N0dWZmSXQvDQoaAAUQAAAFsAAAAHIAAQAAAHKXbA2l pVJlc2VydmVkpaUApaWlpQEAAEIAELYxr3G2MgoVAAAAAAAAAAAAAAAAABIc1QAADMwA AARiAAAAAA8AWE1MMlByZWZlcmVuY2VzLnB5AAGyelRFWFRQeXRoAQAAbwBvAAAAAAAA AAAAAIAAAAAAAAAAAAABfgAAAGgAAAAADwBCwdSZbYSUsejEfs/clH6wMnD2ohHP0Qgy ypcQKkRRfzRI+S/JdS5QEn6nWJfd0v8Xak9ztDALF8awVPHjQ3wNAe9Ndrq93br6Ku7E pLAJMzdRc8l2hSXesEw+xR2tqQbkT7dWpGOaXkLB1MGZtbTNL1oHPHNTQg12ZHtnotFf cm6qrRBWMKBTMN0vRGQtUYPMaoDWNjibP2c5yNgJcvXCuo6EvPs6eI1766pLaQNYUQjK d8+2ZeJnjPmc2mh2PsuMIc7kLaLjsFLJnD7cUKdr5oz5yxWjmJr6Y+/2Dx3P0eqFfi2I PsEbo0kmH5N6Rl+VcSAJ40vldv4GGtk70rPx5xLFOnn3GNYs8+kuMR0x8ZiQ3kc+a0Cc y/P6xaFVg4fHeRFDEKGIIe+2I/gZ9rSJGbfdoPdnBLCDiIRgmJTq5s8pHjL47c2DwWcN 7m08U7TNyMQDRwjzRmePWD+FtAetee7Qde4UzoOcCDGMaiqJmsyyuG6RdMpdHERtVOwl UbcVmkTVWtkgXMHEW41veg9xBTH0/v+ODh2cVnNuIjkEEIAsa3C+IrQBCR0ZYciIUHGj t0ETHUN1TBrEdMfatnDK4QV+BPgCfvfq2IytFSEaqkcdWfQUEN5fwtYSP2Zq0XUn+jxp g+20JK/mIqLgJqLSTv4aUsi2+vhpoKcy13pt/bB32olXifgtXoiUA74Eeu4uA469T8fd yFPEITbQdRKhqcBLqwcRF2lzwZroNMuZI7Il6h1jFafifUN52G2bJcUfqU8V/45pyjPS Vkin4DT1H4FMTPNNnvN6kM5zVwreNGLT5jzIWRrt284rzVrNgdIYo2o4hBaFkfrXeMUd UkTG5ZizDTw5tahJUzqgc+1U9AsopocbFYRXoJEsulWZkdLgrKshpwtrLcnVVRxdikTg QMFEZ8bKLg8DeK4IWOd/acczVw51NS+fMIOl2Xl/zdz7OQrIi1qdkssUKNfnh8183MmF bbi3mhJXEQLGkDLUYRSgmQGbKKzm6H+vIWivdoafakCw0DLaV5QZDrIYpXHatWXjTP2L r0qnDpyqO/cLSGo/H5gcQv+iDHvhL3zRA7Wjsiah8BVE5cERAKGbllclqOn3bOIg5sjJ RH2/ls3kMINevYgFVOE3byYkUvCFg+V1akI14OFUgQsjuctPnS1skqmE2WQTtuQBrZbg G/WCWCNtFw8JYsSdFwFW7VVroXIX4EA2/NrFw1ZKDhFjWJZ4nDdmpZDjFMRwvLITuuvG 8CBuZ1GqlYi2T4ymmp2/U4DWPv4XIxFqCLohne4aV1O7ej16f1otCYtMNGDojLWfUo8j qUqX7CXowF4FwEHXT5CPMVVidqPu5dCjGWBs8NNykrXGEyhSK0QaM64JQJqobMgBVot1 WqhHkKD1kpcfm+RVOSIMwscms7JbnFEKvkOa9PRcKK2gbeYsmEXoy0PcwPseUie941x9 6sQwZIRGMTkOo+S9GXEMu/oCbPjIPkUHHXjW1c9uyEYXzY360ap1UmDRl0mmReW9bH+0 w89hoj5awEv0PYS+ax4pllLjj4CDxsj++fs73H06EMQ1irq5EfGNK0Yx80OJOv1YFR62 J8T+ZX7J65MZy2d9EpKYvuqriUIxgJkVBDqZwA== --============_-1238211163==_D============-- --============_-1238211163==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" -- Tom Bridgman, Ph.D. wtbridgman@radix.net Physics & Astronomy --============_-1238211163==_============-- From tea2@nysaes.cornell.edu Sun Nov 12 22:16:27 2000 From: tea2@nysaes.cornell.edu (Terry Acree) Date: Sun, 12 Nov 2000 17:16:27 -0500 Subject: [Pythonmac-SIG] buildapplication problem in 2.0 Message-ID: <3A0F16BA.284C0CAA@cornell.edu> Hello all I am a new commer to python but my simple experiences with 1.52 and 1.6 were compelling. Trying to use 2.0 I have the following problem with BuildApplication the simplest code. e.g. from Tkinter import * root = Tk() # define toplevel window root.title('CharmAnalysis') # Label window root.geometry('788x530+0+20') # define and locate window mBar = Frame(root, relief=RAISED, borderwidth=2) mBar.pack(fill=X) Label(root, text='Here we go charming a snake').pack(pady=200) # scrible root.mainloop() # make it happen ? **** I always get this message: *** Traceback (most recent call last): File "Lugano:Monty:Python 2.0:Mac:scripts:BuildApplication.py", line 147, in ? main() File "Lugano:Monty:Python 2.0:Mac:scripts:BuildApplication.py", line 51, in main buildapplication() File "Lugano:Monty:Python 2.0:Mac:scripts:BuildApplication.py", line 73, in buildapplication architecture, ok = interact(tf) ValueError: unpack sequence of wrong size *** Any ideas? Terry Acree From jack@oratrix.nl Mon Nov 13 09:20:13 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 13 Nov 2000 10:20:13 +0100 Subject: [Pythonmac-SIG] buildapplication problem in 2.0 In-Reply-To: Message by Terry Acree , Sun, 12 Nov 2000 17:16:27 -0500 , <3A0F16BA.284C0CAA@cornell.edu> Message-ID: <20001113092014.8462535BAF6@snelboot.oratrix.nl> > Hello all > > I am a new commer to python but my simple experiences with 1.52 and 1.6 > were compelling. Trying to use 2.0 I have the following problem with > BuildApplication the simplest code. Oops, that's the first serious bug in 2.0! Luckily it's easy to fix: in BuildApplication.py change line 115 from return 'pwpc' to return 'pwpc', 1 and feed BuildApplication.py through BuildApplet and you'll have a brand new BuildApplication. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tom@othermedia.com Mon Nov 13 09:27:33 2000 From: tom@othermedia.com (tom smith) Date: Mon, 13 Nov 2000 09:27:33 +0000 Subject: [Pythonmac-SIG] MacPython & BBEdit 6.0.1 In-Reply-To: <19341004192805.32276@gj.net> Message-ID: on 10/11/00 1:56 am, Lee Joramo at lee.list@joramo.com wrote: > One tip I can pass along: You can get BBEdit to provide colored > highlighting for Python. Go to Preferences -> Languages and create a File > Suffix Mapping > Suffix: .py > Language: Tcl > Now BBEdit will add color to your Python code using the TCL color scheme. In BBEdit 6.0 it seems that Tcl has been removed from the languages list...darn! From tom@othermedia.com Mon Nov 13 09:29:55 2000 From: tom@othermedia.com (tom smith) Date: Mon, 13 Nov 2000 09:29:55 +0000 Subject: [Pythonmac-SIG] buildapplication problem in 2.0 In-Reply-To: <20001113092014.8462535BAF6@snelboot.oratrix.nl> Message-ID: on 13/11/00 9:20 am, Jack Jansen at jack@oratrix.nl wrote: > Luckily it's easy to fix: in BuildApplication.py change line 115 from > return 'pwpc' > to > return 'pwpc', 1 Whilst we're on this subject, does anyone know of any modifications to show line numbers in the IDE? thanks tom From Richard.Brooksby@pobox.com Sun Nov 12 22:25:38 2000 From: Richard.Brooksby@pobox.com (Richard.Brooksby@pobox.com) Date: Sun, 12 Nov 2000 22:25:38 +0000 Subject: [Pythonmac-SIG] Bug Report: Python debugger can't find source code for modules Message-ID: Hi. I installed Python 2.0 and moved the "Python 2.0" to my desktop, where I experimented with it for a while, before moving it to the "Python" folder in the "Applications" folder of my startup drive. But when I try to use the Python IDE to debug an exception in the "xml.dom.minidom" module it can't find the source. It seems to be looking in the desktop folder. I've tried deleting the Python preferences and poking around but can't find where the IDE is keeping this information. A quick perusal of the IDE source shows that it's asking the "imp" module for the source code file, but I can't find any more information than that. Note the that IDE module browser _can_ find the files. Thanks. From jack@oratrix.nl Mon Nov 13 11:09:58 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 13 Nov 2000 12:09:58 +0100 Subject: [Pythonmac-SIG] Bug Report: Python debugger can't find source code for modules In-Reply-To: Message by Richard.Brooksby@pobox.com , Sun, 12 Nov 2000 22:25:38 +0000 , Message-ID: <20001113110958.B0C7E35BAF6@snelboot.oratrix.nl> > Hi. > > I installed Python 2.0 and moved the "Python 2.0" to my desktop, > where I experimented with it for a while, before moving it to the > "Python" folder in the "Applications" folder of my startup drive. If you move Python you're best off removing *all* files with "Python" in their name from the system folder. This includes the Python preferences, the IDE preferences and the alias to PythonCore. After this run ConfigurePython from the Python folder. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From Richard.Brooksby@pobox.com Mon Nov 13 11:48:57 2000 From: Richard.Brooksby@pobox.com (Richard.Brooksby@pobox.com) Date: Mon, 13 Nov 2000 11:48:57 +0000 Subject: [Pythonmac-SIG] Bug Report: Python debugger can't find source code for modules In-Reply-To: <20001113110958.B0C7E35BAF6@snelboot.oratrix.nl> References: <20001113110958.B0C7E35BAF6@snelboot.oratrix.nl> Message-ID: At 2000-11-13 12:09 +0100, Jack Jansen wrote: > > Hi. >> >> I installed Python 2.0 and moved the "Python 2.0" to my desktop, >> where I experimented with it for a while, before moving it to the >> "Python" folder in the "Applications" folder of my startup drive. > >If you move Python you're best off removing *all* files with "Python" in their >name from the system folder. This includes the Python preferences, the IDE >preferences and the alias to PythonCore. > >After this run ConfigurePython from the Python folder. This has no effect, I'm afraid. From rb@ravenbrook.com Mon Nov 13 12:02:56 2000 From: rb@ravenbrook.com (Richard Brooksby) Date: Mon, 13 Nov 2000 12:02:56 +0000 Subject: [Pythonmac-SIG] How do I install packages? Message-ID: Hi. I've just started using Mac Python. I'm managing a commercial project using Python as its main language . But I'm mainly interested in Mac Python to do XML processing on my laptop. I installed Mac Python 2.0, and found that the XML DOM implementation chokes when fed the simple example from section 3.1.1 of the XHTML 1.0 specification . So I downloaded PyXML-0.6.1, hoping that it would be a newer version. But how do I install it? Is it possible to run the "setup.py" script somehow? Will it work? Is there a recommended method for doing this? It would be a good idea to mention this topic somewhere in the Mac Python docs, even if they just say that it isn't really possible. Thanks. From jack@oratrix.nl Mon Nov 13 13:49:56 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 13 Nov 2000 14:49:56 +0100 Subject: [Pythonmac-SIG] Bug Report: Python debugger can't find source code for modules In-Reply-To: Message by Richard.Brooksby@pobox.com , Mon, 13 Nov 2000 11:48:57 +0000 , Message-ID: <20001113134957.25A1835BAF6@snelboot.oratrix.nl> > >If you move Python you're best off removing *all* files with "Python" in their > >name from the system folder. This includes the Python preferences, the IDE > >preferences and the alias to PythonCore. > > > >After this run ConfigurePython from the Python folder. > > This has no effect, I'm afraid. Ah, bingo! You also have to remove all the .pyc files from your Python tree. These have been compiled while the tree was still in the old location, so the __file__ attributes will point there, which will cause the debugger to look in the wrong place. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Mon Nov 13 13:52:20 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 13 Nov 2000 14:52:20 +0100 Subject: [Pythonmac-SIG] How do I install packages? In-Reply-To: Message by Richard Brooksby , Mon, 13 Nov 2000 12:02:56 +0000 , Message-ID: <20001113135221.62CBC35BAF6@snelboot.oratrix.nl> > So I downloaded PyXML-0.6.1, hoping that it would be a newer version. > But how do I install it? Is it possible to run the "setup.py" script > somehow? Will it work? Is there a recommended method for doing this? You have to read the distutils documentation. Distutils and Mac can partially work together, but it isn't seamless yet. People are working on it, so for the next MacPython release it should indeed be as simple as running setup.py. Although, of course, there's always the problem that most distributions will need a C compiler, which Unix people usually have but Mac people hardly ever. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tom@othermedia.com Mon Nov 13 14:22:13 2000 From: tom@othermedia.com (tom smith) Date: Mon, 13 Nov 2000 14:22:13 +0000 Subject: [Pythonmac-SIG] How do I install packages? In-Reply-To: Message-ID: on 13/11/00 12:02 pm, Richard Brooksby at rb@ravenbrook.com wrote: > I installed Mac Python 2.0, and found that the XML DOM implementation > chokes when fed the simple example from section 3.1.1 of the XHTML > 1.0 specification . I found that all the xml stuff seems to have changed since 1.5. So far, I've found /lib/xml/dom/minidom.py to be the most useful parser. Rather than eating a character at a time, it builds xml files into python lists of objects. I've managed to load a 2mb xml file and play with the data... > So I downloaded PyXML-0.6.1, hoping that it would be a newer version. > But how do I install it? Is it possible to run the "setup.py" script > somehow? Will it work? Is there a recommended method for doing this? I think, you add the folder to /Lib/site-packages/ and then add the path to that folder using EditPythonPrefs.... but as I say, I think all the parsing modules have moved or been renamed. I think all the documentation is old too, so none of the xml examples work.. From jmillr@umich.edu Mon Nov 13 22:55:09 2000 From: jmillr@umich.edu (John A. Miller) Date: Mon, 13 Nov 2000 17:55:09 -0500 (EST) Subject: [Pythonmac-SIG] Re: MacPython & BBEdit 6.0.1 In-Reply-To: <19341004192805.32276@gj.net> Message-ID: Thanks for the help in getting started. I now have the "Run as Python" extension in the BBEdit 6 Plug-Ins folder, and have set .py for TCL syntax coloring (it IS in the BBEdit 6 distribution). However, the "PythonSlave.py" script seems not to do the right thing (besides the typo: "Types" should be "types" in line 21): Starting at the beginning with the "checktext.py" script in the 'example0' folder, if I simply double-click this script, it does the right thing. If, however, I open the script in BBEdit and choose "Run as Python" under the Tools menu, the PythonInterpreter.out window simply gives the following message: PythonSlave 0.1.3 ready. --- executing "checktest.py" --- --- done --- No dialog box, nothing. If I go on to the "dnslookup-1.py" script in the "example1" folder and double-click, it does the right thing. However, opening it up in BBEdit and choosing the "Run as Python" command generates an error dialog box "Cannot find dnslookup-1.rsrc" which is also located in the "example1" folder. The following is generated in the PythonInterpreter.out window: --- executing "dnslookup-1.py" --- Traceback (most recent call last): File "Moire:Programming:Python 2.0:Mac:Contrib:BBPy:PythonSlave.py", line 90, in MyExec exec stuff in {} File "", line 60, in ? File "", line 26, in main SystemExit: 1 --- done --- So, this is more than I can deal with by myself. Any ideas what needs to be done to get "Run as Python" extension to do the right thing? John Miller From jack@oratrix.nl Tue Nov 14 09:43:47 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 14 Nov 2000 10:43:47 +0100 Subject: [Pythonmac-SIG] Re: MacPython & BBEdit 6.0.1 In-Reply-To: Message by "John A. Miller" , Mon, 13 Nov 2000 17:55:09 -0500 (EST) , Message-ID: <20001114094348.773F135BAF6@snelboot.oratrix.nl> > If, however, I open the script in > BBEdit and choose "Run as Python" under the Tools menu, the > PythonInterpreter.out window simply gives the following message: > > PythonSlave 0.1.3 ready. > --- executing "checktest.py" --- > --- done --- checktext.py has the standard idiom for checking whether it is run as a main program or imported: if __name__ == '__main__': main() but this fails when running under BBPy. You could probably fix BBPy, look at the IDE code for "Run as __main__" for an example of how to do this. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From rb@ravenbrook.com Tue Nov 14 11:38:07 2000 From: rb@ravenbrook.com (Richard Brooksby) Date: Tue, 14 Nov 2000 11:38:07 +0000 Subject: [Pythonmac-SIG] Bug Report: Python debugger can't find source code for modules In-Reply-To: <20001113134957.25A1835BAF6@snelboot.oratrix.nl> References: <20001113134957.25A1835BAF6@snelboot.oratrix.nl> Message-ID: At 2000-11-13 14:49 +0100, Jack Jansen wrote: > > >If you move Python you're best off removing *all* files with >"Python" in their >> >name from the system folder. This includes the Python preferences, the IDE >> >preferences and the alias to PythonCore. >> > >> >After this run ConfigurePython from the Python folder. >> >> This has no effect, I'm afraid. > >Ah, bingo! You also have to remove all the .pyc files from your Python tree. >These have been compiled while the tree was still in the old location, so the >__file__ attributes will point there, which will cause the debugger to look in >the wrong place. Great, thanks. May I suggest this goes in the docs? From marcus.h.mendenhall@vanderbilt.edu Wed Nov 15 16:45:34 2000 From: marcus.h.mendenhall@vanderbilt.edu (Marcus H. Mendenhall) Date: Wed, 15 Nov 2000 10:45:34 -0600 Subject: [Pythonmac-SIG] python 2.0 and PythonCGISlave crash Message-ID: I am trying out the PythonCGISlave in conjunction with Apple Personal Web Server to run a trivial database application (using gadfly as the database). There is something funny going on in the slave, though. It works fine for a few (~10) transactions, but after a while causes a complete freeze of the computer (no mouse motion). I assume that a problem of this nature probably actually resides inside the GUSI code, but have not started chasing it down. Have any other people actually been trying the CGISlave, and either reporting success or failure? Marcus Mendenhall From jmillr@umich.edu Wed Nov 15 22:02:45 2000 From: jmillr@umich.edu (John A. Miller) Date: Wed, 15 Nov 2000 17:02:45 -0500 (EST) Subject: [Pythonmac-SIG] Re: MacPython & BBEdit 6.0.1 In-Reply-To: <20001114094348.773F135BAF6@snelboot.oratrix.nl> Message-ID: Thanks for the suggestion, but making this fix is beyond my current technical skill. However, if my scripts ever get to the point where I'm using this idiom, I'll know not to expect them to work when using BBPy. John Miller On Tue, 14 Nov 2000, Jack Jansen wrote: > > If, however, I open the script in > > BBEdit and choose "Run as Python" under the Tools menu, the > > PythonInterpreter.out window simply gives the following message: > > > > PythonSlave 0.1.3 ready. > > --- executing "checktest.py" --- > > --- done --- > > checktext.py has the standard idiom for checking whether it is run as a main > program or imported: > if __name__ == '__main__': > main() > > but this fails when running under BBPy. > > You could probably fix BBPy, look at the IDE code for "Run as __main__" for an > example of how to do this. > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > > From christian@rocketnetwork.com Thu Nov 16 04:57:49 2000 From: christian@rocketnetwork.com (Christian Reyes) Date: Wed, 15 Nov 2000 20:57:49 -0800 Subject: [Pythonmac-SIG] Catching exceptions with Python from a Shared Library In-Reply-To: <20001113170130.5A8D71D0A7@dinsdale.python.org> Message-ID: Catching exceptions from a Shared Library Using Phil Thompson's SIP tool, I've wrapped a C++ DLL into a Python shared library. However, I'm having major difficulties handling any exceptions that get thrown from the DLL into Python. My question is, is this even possible with MAC Python? Does Mac Python handle exceptions thrown from a DLL? If so, what do I need to do to get this to work? Please help, christian@rocketnetwork.com From Laurent.Pierron@loria.fr Thu Nov 16 08:59:06 2000 From: Laurent.Pierron@loria.fr (Laurent Pierron) Date: Thu, 16 Nov 2000 09:59:06 +0100 Subject: [Pythonmac-SIG] Problems with IDE Message-ID: <029001c04fab$7bb1b6a0$420c5198@loria.fr> This is a multi-part message in MIME format. ------=_NextPart_000_028D_01C04FB3.DB2B6B50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On my Mac : Mac OS 8.6 with Python 2.0, I don't have syntax coloring = with the IDE neither arguments completion like on Windows version, why ? I cannot redirect sys.stdin and sys.stdout on a file with MacPython 2.0, = when I set it in the preferences dialog on the script start. Why sys.stdin implements only readline(), no read() no readlines() ? -- Laurent Pierron ------=_NextPart_000_028D_01C04FB3.DB2B6B50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On my Mac : Mac OS 8.6 with Python 2.0, I don't have = syntax=20 coloring with the IDE neither arguments completion like on Windows = version,=20 why ?
 
I cannot redirect sys.stdin and sys.stdout on a = file with=20 MacPython 2.0, when I set it in the preferences dialog on the script=20 start.
 
Why sys.stdin implements only readline(), no read() = no=20 readlines() ?
 
--
Laurent Pierron
 
------=_NextPart_000_028D_01C04FB3.DB2B6B50-- From just@letterror.com Thu Nov 16 09:13:33 2000 From: just@letterror.com (Just van Rossum) Date: Thu, 16 Nov 2000 10:13:33 +0100 Subject: [Pythonmac-SIG] Problems with IDE In-Reply-To: <029001c04fab$7bb1b6a0$420c5198@loria.fr> Message-ID: At 9:59 AM +0100 16-11-2000, Laurent Pierron wrote: > On my Mac : Mac OS 8.6 with Python 2.0, I don't have syntax coloring >with the IDE neither arguments completion like on Windows version, why ? It's a completely different app, not a Mac version of the same. > I cannot redirect sys.stdin and sys.stdout on a file with MacPython >2.0, when I set it in the preferences dialog on the script start. That's one for Jack. As far as I know, this has never worked... >Why sys.stdin implements only readline(), no read() no readlines() ? -- >Laurent Pierron stdin support is neccesarily somewhat dumb, the mac has no native stdin, so it has to be emulated with a dialog. .read() and .readlines() make little sense with this dialog. Just From etienne@alias.it Thu Nov 16 09:27:51 2000 From: etienne@alias.it (Etienne Antoniutti Di Muro) Date: Thu, 16 Nov 2000 10:27:51 +0100 Subject: [Pythonmac-SIG] Python and Events References: <20001114170134.5474A1D142@dinsdale.python.org> Message-ID: <3A13A897.8244FA15@alias.it> List members, my application has a python core and a C++ GUI (MacApp), a pretty good embedding/extending work!! :-)) When the Python kernel is busy with some demanding process, the Python Interpreter takes over the CPU control, and GUI can't even handle any event (pressing buttons, dragging windows & dialogs......) until the kernel has finished. MacOS.SchedParams(doint,mask,besocial,interval,bgyield) seems not very sensitive to input fields changes. I run my app with no others open. I'm using: MacOS 9.0 PythonCore 1.5.2c1 MacApp R13 CW Pro 5 Is this due to the MacOS, MacApp,or the Python Interpreter itself ...????? any suggestion?? thanks etienne -- it's time to leave this town it's time to steal away let's go get lost anywhere in the U.S.A. (RHCP) From tom@othermedia.com Thu Nov 16 09:46:46 2000 From: tom@othermedia.com (tom smith) Date: Thu, 16 Nov 2000 09:46:46 +0000 Subject: [Pythonmac-SIG] Problems with IDE In-Reply-To: <029001c04fab$7bb1b6a0$420c5198@loria.fr> Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3057212806_292452_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit on 16/11/00 8:59 am, Laurent Pierron at Laurent.Pierron@loria.fr wrote: On my Mac : Mac OS 8.6 with Python 2.0, I don't have syntax coloring with the IDE neither arguments completion like on Windows version, why ? Check out http://www.strout.net/python/mac/, it gives you syntax colouring AND breakpoints. tom --MS_Mac_OE_3057212806_292452_MIME_Part Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Pythonmac-SIG] Problems with IDE on 16/11/00 8:59 am, Laurent Pierron at Laurent.Pierron@loria.fr wrote:

On my Mac : Mac OS 8.6 with Python 2.0, I don= 't have syntax coloring with the IDE neither arguments completion like on Wi= ndows version, why ?

Check out http://www.strout.net/python/mac/, it gives= you syntax colouring AND breakpoints.

tom

 --MS_Mac_OE_3057212806_292452_MIME_Part-- From tom@othermedia.com Thu Nov 16 09:51:25 2000 From: tom@othermedia.com (tom smith) Date: Thu, 16 Nov 2000 09:51:25 +0000 Subject: [Pythonmac-SIG] Python and Events In-Reply-To: <3A13A897.8244FA15@alias.it> Message-ID: on 16/11/00 9:27 am, Etienne Antoniutti Di Muro at etienne@alias.it wrote: > When the Python kernel is busy with some demanding process, the Python > Interpreter > takes over the CPU control, and GUI can't even handle any event (pressing > buttons, > dragging windows & dialogs......) until the kernel has finished. > MacOS.SchedParams(doint,mask,besocial,interval,bgyield) seems not very > sensitive I've been struggling with this too. I need a scheduler that runs scripts once a day/hour/whatever.(I think you can call SchedParam() with no values and it defaults to the, er, defaults). time.sleep() seemed to make no difference once I was in a repeat loop. I'm looking at creating a queue of jobs, and pulling them off when idle() gets called (does a job need doing? If so do it..... )This is really friendly to other apps, but might not be that quick for a gui-based app. I started from the BBpy application in the Mac/contrib folder. tom From jack@oratrix.nl Thu Nov 16 11:27:41 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 16 Nov 2000 12:27:41 +0100 Subject: [Pythonmac-SIG] Python and Events In-Reply-To: Message by tom smith , Thu, 16 Nov 2000 09:51:25 +0000 , Message-ID: <20001116112747.2D8881301EB@oratrix.oratrix.nl> The Python mainloop does handle the events while it is busy, but they probably never get back to your GUI code. If you look at PyMac_HandleEvent and PyMac_HandleEventIntern you'll see that it tries to handle events through a Python handler, if that doesn't work it handles mousedowns in other applications, and if that didn't handle the event it passes it to SIOUXHandleOneEvent. One way to get the events to your GUI-code is to create a Python method that passes the event to your GUI code, and call MacOS.SetEventHandler() with that method as parameter. Another option is to add a C API that allows other C code to register event handlers with PyMac_HandleEvent. The handlers should probably have the signature bool (*handleevent)(EventRecord *); and return true if the event is completely handled. PyMac_HandleEventIntern could call this handler first, and only continue its other processing if it returns false. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Thu Nov 16 11:37:54 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 16 Nov 2000 12:37:54 +0100 Subject: [Pythonmac-SIG] Catching exceptions with Python from a Shared Library In-Reply-To: Message by "Christian Reyes" , Wed, 15 Nov 2000 20:57:49 -0800 , Message-ID: <20001116113800.EE7431301EB@oratrix.oratrix.nl> Recently, "Christian Reyes" said: > Catching exceptions from a Shared Library > > Using Phil Thompson's SIP tool, I've wrapped a C++ DLL into a Python shared > library. > However, I'm having major difficulties handling any exceptions that get > thrown from the DLL into Python. > > My question is, is this even possible with MAC Python? Does Mac Python > handle exceptions thrown from a DLL? > If so, what do I need to do to get this to work? I've done all the things I think I should do to make C++ libraries work, i.e. I'm calling the __initialize routines and everything. But I've never tried to use exceptions, so there's a chance that it doesn't work. The other C++ feature that needs this support, dynamic initializers, does work. Note that you do have to catch the exception in your code: MacPython can't catch it as it is a C program and hence knows nothing about exceptions. But if the situation is as I understand (MacPython loading a dynamic module written by you, which calls a C++ DLL provided by someone else) the dynamic module should be able to catch the exception. And, if it doesn't work: could you provide me with a simple example of how it fails, then I can look into it. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Thu Nov 16 14:16:05 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 16 Nov 2000 15:16:05 +0100 Subject: [Pythonmac-SIG] IDE feature requests Message-ID: <20001116141610.213CF1301EB@oratrix.oratrix.nl> Now that I'm starting to use the IDE more and more (as the last MacPythoneer, probably) I'm coming up with things I'd like to have added too. I guess this wishlist is primarily aimed at Just, but if someone else wants to step in and provide code I'm sure that's okay too. - I'd like an "open recent" menu, which keeps the most recently opened/saved files. These should probably be saved in the preference file. - I'd like a way to copy a variable from one window to another. An example of when this is useful is when you see a variable in a browser or debugger window, and you want to call some method on it. How this could work is that a magic module is always available (__ide__?), and the variable you copy is assigned to, say, __ide__.clipboard. Then you could put the text "__ide__.clipboard" in the clipboard and ready you are. This is the only way I can think of that you can use to close files or such. - Another feature I'd like (and which may obviate the need for the copy variable) is the ability to execute arbitrary code in a stackframe in the debugger. I find that I have to return to pdb pretty often because the IDE debugger allows only inspection. - I'd like an option to make the output window popup when something is written to it. I always sit staring at wrong windows waiting for my output to appear. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From tom@othermedia.com Thu Nov 16 15:23:58 2000 From: tom@othermedia.com (tom smith) Date: Thu, 16 Nov 2000 15:23:58 +0000 Subject: [Pythonmac-SIG] IDE feature requests In-Reply-To: <20001116141610.213CF1301EB@oratrix.oratrix.nl> Message-ID: on 16/11/00 2:16 pm, Jack Jansen at jack@oratrix.nl wrote: I'm using MacPython about 12 hours a day at the mo' > - I'd like an "open recent" menu, which keeps the most recently > opened/saved files. These should probably be saved in the preference > file. I've been dreaming of having that feature all week! By the way, BBedit just stores a folder of aliases in the preferences folder. > - I'd like an option to make the output window popup when something is > written to it. I always sit staring at wrong windows waiting for my > output to appear. And that one! I'd like to be able to set the font & background colours of the different windows (output, interactive and code..so that I can locate them quicker) More "reliable" syntax colouring as standard. A simple tool to be able to run a python file with command line parameters... I'd like a key command for the output window. Command-Shift-0 I'd like a toggle-windows command command-tab ? A script to trash all .pyc files in a folder recursively. I always have to do global search and replaces in BBEdit. Line numbers The ability to open "****" files and make them "pide" files rather than just say "I can't open this file". I'd like to be able to REALLY look at variables in the debugger (maybe in a further double-click to open sub window), anything longer than a URL and I'm stuck. I'd like an Apple-Help file for the modules. PythonWin has function suggestions, to remind you what variables a function takes as you type. Nice. I tried getting the gui-builder (written in Tk) that writes Tk to work but it wouldn't launch...sigh I wish Grail worked... there more... Auto-completion of say tom.myVeryLongFunct.... , PythonWin has collapsable code, the ability to turn on drag & drop. regular expression searches... All of these would make my life at least a little less ... you know.... just because a programming language is written in text, doesn't mean the editor has to be so basic. cheers tom From cbarker@jps.net Thu Nov 16 17:52:10 2000 From: cbarker@jps.net (Chris Barker) Date: Thu, 16 Nov 2000 09:52:10 -0800 Subject: [Pythonmac-SIG] IDE feature requests References: Message-ID: <3A141ECA.D4F7AEB@jps.net> Tom and Jack have presented a list of nifty features for the IDE, most of which I think are pretty handy as well. A couple more: One I'd like to add is the ability to run a script "from scratch", that is, as if you had just dropped it on the interpreter, without any of the stuff left over from the last run effecting it (open files is my biggest bugaboo). An option to use spaces, rather than tabs, for indenting (still pressing the TAB button), this would make it more compatible with other systems (emacs mode, for instance). Also, perhaps, a script to convert to all spaces, or all tabs, built in to the IDE. Another thought: A lot of what we're suggesting is mostly a lot of improvements to the editor itself. Perhaps it would make more sense to put some effort into setting up the Python interpreter to play better with outside editors (BBedit, Pepper, Alpha, MPW, CodeWarrior). This is not consistent with the Mac paradigm of self-contained apps, but it is more consistent with other systems. On Linux, I do EVERYTHING that involves text files with XEmacs. Honestly, I don't love Xemacs, but I do love that I can do everything I want with it, and only have to know one editor. It drives me crazy that I have to use a half dozen different editors on the Mac. (MATLAB, BBedit for general use, Alpha for LaTeX, The MacPython IDE, CodeWarrior, etc.) What it would take to make the Interpreter more friendly (As in inexperienced Mac programmer, I don't understand the nuances of these).It seems we would need: - An event like "restart with this script", so you could run a script, have the output window stay open, and then re-run it, or run another, without having to manually quit the interpreter. - The ability to start up the interpreter with a given set of options, rather than having them pre-set for all start-ups (maybe it would just be OK to have a separate copy with different options, so you would have one that gets run from the editor, and one that gets run with a double-click on a script) - A way to start (or re-start) the interpreter with command line options (at least simulate drag and drop of files, so that you could develop applets) - Improvement to the command line window: It is almost unusable the way it is. It needs command line recall, and a little bit smarter line editing. Other nice additions would be colorization, command completion, etc. -Probably others I'm not thinking of. Another bonus to this approach is that it would help the IDE as well. The IDE could then have the option of using an external interpreter to run your scripts, so that you could write tkinter apps, or other GUI toolkits (wxPython some day?) NOTE: how will all this be different with OSX ? It seems some of it will be easier, but maybe the old MacOS will be around long enough that it needs to be addressed anyway. -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From pecora@anvil.nrl.navy.mil Thu Nov 16 17:45:00 2000 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Thu, 16 Nov 2000 12:45:00 -0500 Subject: [Pythonmac-SIG] IDE feature requests In-Reply-To: <20001116141610.213CF1301EB@oratrix.oratrix.nl> Message-ID: >Now that I'm starting to use the IDE more and more (as the last >MacPythoneer, probably) I'm coming up with things I'd like >to have added too. I guess this wishlist is primarily aimed at Just, >but if someone else wants to step in and provide code I'm sure that's >okay too. > >- I'd like an "open recent" menu, which keeps the most recently > opened/saved files. These should probably be saved in the preference > file. I second it. >- I'd like an option to make the output window popup when something is > written to it. I always sit staring at wrong windows waiting for my > output to appear. Absolutely. How 'bout text coloring for key words and my classes (too hard? Never tried it). Cheers, Lou Pecora From jwblist@olympus.net Thu Nov 16 17:55:30 2000 From: jwblist@olympus.net (John W Baxter) Date: Thu, 16 Nov 2000 09:55:30 -0800 Subject: [Pythonmac-SIG] IDE feature requests In-Reply-To: References: Message-ID: At 15:23 +0000 11/16/00, tom smith wrote: >By the way, BBedit just stores a folder of aliases in the preferences >folder. And, as a nice touch starting with BBEdit 6.0, if one locks one of those alias files, it stays around (doh!) and is presented below a dividing line, as a sort of favorites menu. [I just checked my other machine...I have some removing to do, since I've deleted most of the files in that part of the Open Recent menu, leaving just the broken aliases. Sigh! --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jack@oratrix.nl Thu Nov 16 22:56:37 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 16 Nov 2000 23:56:37 +0100 Subject: [Pythonmac-SIG] IDE feature requests In-Reply-To: Message by Chris Barker , Thu, 16 Nov 2000 09:52:10 -0800 , <3A141ECA.D4F7AEB@jps.net> Message-ID: <20001116225642.90A441301EB@oratrix.oratrix.nl> Recently, Chris Barker said: > One I'd like to add is the ability to run a script "from scratch", that > is, as if you had just dropped it on the interpreter, without any of the > stuff left over from the last run effecting it (open files is my biggest > bugaboo). I think this is difficult. Open files can probably be handled, but there's lots of other things that may "stay around" (like module-variables in imported modules). A possible solution might be to have the IDE restart itself through AppleEvents (is this possible?) to the finder or something. > An option to use spaces, rather than tabs, for indenting (still pressing > the TAB button), this would make it more compatible with other systems > (emacs mode, for instance). Also, perhaps, a script to convert to all > spaces, or all tabs, built in to the IDE. Yes, yes! Now that the standard Python convention is all spaces and the MacPython convention is all tabs this would be really handy to have. Especially if it was auto-detecting, like emacs python-mode. > A lot of what we're suggesting is mostly a lot of improvements to the > editor itself. Perhaps it would make more sense to put some effort into > setting up the Python interpreter to play better with outside editors > (BBedit, Pepper, Alpha, MPW, CodeWarrior). CodeWarrior has a way to do this, with BBEdit for instance. I assume it's through AppleEvents, so IDe could probably use the same mechanism. > What it would take to make the Interpreter more friendly (As in > inexperienced Mac programmer, I don't understand the nuances of > these).It seems we would need: I don't want to make the interpreter more friendly, really. It's only there for executing scripts and for a certain MacPython user whose name starts with two Js and who refuses to use the IDE, but aside from that I think all nifty features should go into the IDE. > - An event like "restart with this script", so you could run a script, > have the output window stay open, and then re-run it, or run another, > without having to manually quit the interpreter. Difficult, for the same reason stated above for the IDE. > - The ability to start up the interpreter with a given set of options, > rather than having them pre-set for all start-ups (maybe it would just > be OK to have a separate copy with different options, so you would have > one that gets run from the editor, and one that gets run with a > double-click on a script) [... Jack is off asking Guido the use of his time-machine ...] POOF!! This feature has been implemented a few years ago, and I think it's actually documented too. You copy the interpreter and drop the copy on EditPythonPrefs. Voila, an interpreter with a different set of default options. > - A way to start (or re-start) the interpreter with command line options > (at least simulate drag and drop of files, so that you could develop > applets) I'm not sure I understand this one. Please explain? > - Improvement to the command line window: It is almost unusable the way > it is. It needs command line recall, and a little bit smarter line > editing. Other nice additions would be colorization, command completion, > etc. I know. I think I want it to go away completely, to be replaced by something in Python (probably called early in initialization, like site.py or macfsn.py). EasyDialogs.GetArgv is probably a good starting point, but it needs to have stdio redirection added. If someone does the Python work I'll glue it into the interpreter. > NOTE: how will all this be different with OSX ? It seems some of it will > be easier, but maybe the old MacOS will be around long enough that it > needs to be addressed anyway. As of yet I'm not sure whether the eventual MacOXS Python will be based on Unix Python or MacPython. For the time being the two will co-exist, with Unix Python being mainly useful in the BSD domain and MacPython in the Carbon domain. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Thu Nov 16 23:03:36 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 17 Nov 2000 00:03:36 +0100 Subject: [Pythonmac-SIG] Catching exceptions with Python from a Shared Library In-Reply-To: Message by "Christian Reyes" , Thu, 16 Nov 2000 14:47:00 -0800 , Message-ID: <20001116230341.061C81301EB@oratrix.oratrix.nl> Chris, I've cc'd the SIG again, because I'd like these answers to be kept in the archive. Hope you don't mind... Recently, "Christian Reyes" said: > You understand the situation completely. I was hoping that there was a way > that python would catch the exception thrown from the DLL, but I now > understand that it is the dynamic module that must catch it. > > But how can I send it back to Python as a python exception from the dynamic > module? Is that possible? You catch the C++ exception in the C++ way, and then you raise a Python exception by calling one of the exception functions from pyerrors.h and returning NULL from your function. As I haven't done this before myself and may need to do so shortly you'd do me a great favor if you could post a code snippet once you have something working. Oh yes: note that, even if MacPython could catch C++ exceptions, you would really have to catch it in your module. You've probably allocated objects and such that you need to free, and maybe other cleanup to do. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jacobkm@cats.ucsc.edu Thu Nov 16 23:12:03 2000 From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss) Date: Thu, 16 Nov 2000 15:12:03 -0800 Subject: [Pythonmac-SIG] IDE feature requests In-Reply-To: <20001116225642.90A441301EB@oratrix.oratrix.nl> References: <20001116225642.90A441301EB@oratrix.oratrix.nl> Message-ID: >I don't want to make the interpreter more friendly, really. It's only >there for executing scripts and for a certain MacPython user whose >name starts with two Js and who refuses to use the IDE, but aside from >that I think all nifty features should go into the IDE. We still need the interpreter for one huge thing -- Tkinter. Since Tkinter destroys the IDE, having the interpreter around for running Tkinter apps is a must. It would be great to figure out how to get Tkinter running inside the IDE, but that seems quite a bit harder than a "Run With Interpreter" button in the IDE -- which brings me to my point. The biggest feature that the IDE needs (besides syntax coloring) is that "Run With Interpreter" button. Is anybody working on this right now? I have a idea of how it might work, but I don't want to duplicate work... Jacob From jwight@excitehome.net Thu Nov 16 23:49:43 2000 From: jwight@excitehome.net (Jonathan Wight) Date: Thu, 16 Nov 2000 17:49:43 -0600 Subject: [Pythonmac-SIG] gusisioux_state In-Reply-To: <20001106130716.1D3D131C49C@snelboot.oratrix.nl> Message-ID: On 11/6/00 7:07 AM, "Jack Jansen" wrote: >> >> Trying to compile PythonCore from the Python 2.0 source distribution, I get >> 4 errors in macmain as "gusisioux_state" is not defined ? > > You should get the Python-specific version of GUSI, from the macpython > download page. Alternatively you can rip out the gusisioux_state stuff, but > then you'll lose the "keep sioux window open" functionality. I just ran into this too - could we get it rolled into the main GUSI source code? I'd like (and I'm sure I'm not alone) to be able to grab the latest Mac python, grab the latest GUSI and just compile them without spending an hour fixing the little gotchas. Jon. From cbarker@jps.net Fri Nov 17 01:20:00 2000 From: cbarker@jps.net (Chris Barker) Date: Thu, 16 Nov 2000 17:20:00 -0800 Subject: [Pythonmac-SIG] IDE feature requests References: <20001116225642.90A441301EB@oratrix.oratrix.nl> Message-ID: <3A1487BF.2F814BE4@jps.net> Jacob Kaplan-Moss wrote: > >I don't want to make the interpreter more friendly, really. It's only > >there for executing scripts and for a certain MacPython user whose > >name starts with two Js and who refuses to use the IDE, I'm sure you're not he only one! > but aside from > >that I think all nifty features should go into the IDE. > > > We still need the interpreter for one huge thing -- Tkinter. Since > Tkinter destroys the IDE, having the interpreter around for running > Tkinter apps is a must. Exactly. This is a symptom a fundamental problem with the IDE: the same Python interpreter is running your code and the IDE itself. That's why you can't use tkinter (or the hopefully forthcoming wxPython), that's why you can't do a "run from scratch", that's why any text files created by your script have the Creator set to the Python IDE, ... All these things are what keep me running back to the raw interpreter. I know I got a little carried away with my suggestions on my last post, but the basics of making the interpreter more usable don't seem like much (to a non-mac programmer anyway). The most critical thing is having it able to receive that tells it to restart with a given script (and command line options, if possible). This would make it easier to run from an editor, and, in fact allow the IDE to use it as a separate interpreter as well. Then all the other nifty features could be in the IDE. All I want is for the interpreter to work like it does on *nix! -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From sdm7g@virginia.edu Fri Nov 17 02:47:50 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Thu, 16 Nov 2000 21:47:50 -0500 (EST) Subject: [Pythonmac-SIG] "All I want..." [was: IDE feature requests] In-Reply-To: <3A1487BF.2F814BE4@jps.net> Message-ID: On Thu, 16 Nov 2000, Chris Barker wrote: > > All I want is for the interpreter to work like it does on *nix! > Well Chris: you could try it on MacOSX -- only problem is that to run Tkinter, you have to log out and log in a console session so you can start X11 --- which means you can't run you other Mac apps. ( Or you can run MacPython in the "Classic" enviromnent -- which is pretty much the same as what you've got now. ) But, just to take this as an excuse for an update (if anyone is interested) : PyObjC is more-or-less working on MacOSX -- I can load Foundation classes, but when I try to load the AppKit classes to open and display a window, it gives a warning about not finding a theme file just before it crashes with a bus error. ( The good news is that on OSX, everything else keeps chugging away after your bus error! ) PyObjC development is in the process of being set up at SourceForge. I haven't yet tried another attempt at building Python Carbon libs -- AppKit looked like it was closer to working, so that's been on the shelf. ( Last attempt: I was able to compile some modules against Universal Interfaces, but there were so many module interdependencies that I'm going to have to build all or most of it to get modules to link. Is anyone else out there taking a hack at it ? ---| 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 operating systems want to be unix, All programming languages want to be lisp." From jmillr@umich.edu Fri Nov 17 19:52:09 2000 From: jmillr@umich.edu (John A. Miller) Date: Fri, 17 Nov 2000 14:52:09 -0500 (EST) Subject: [Pythonmac-SIG] IDE feature requests In-Reply-To: <20001116225642.90A441301EB@oratrix.oratrix.nl> Message-ID: On Thu, 16 Nov 2000, Jack Jansen wrote: > > NOTE: how will all this be different with OSX ? It seems some of it will > > be easier, but maybe the old MacOS will be around long enough that it > > needs to be addressed anyway. > > As of yet I'm not sure whether the eventual MacOXS Python will be > based on Unix Python or MacPython. For the time being the two will > co-exist, with Unix Python being mainly useful in the BSD domain and > MacPython in the Carbon domain. > -- One angle that hasn't been mentioned in this regard is JPython. Might this be a viable option in MacOSX? John Miller From bobsavage@mac.com Fri Nov 17 20:46:53 2000 From: bobsavage@mac.com (Bob Savage) Date: Fri, 17 Nov 2000 12:46:53 -0800 Subject: [Pythonmac-SIG] IDE feature requests In-Reply-To: Message-ID: on 11/17/00 11:52 AM, John A. Miller wrote: > > One angle that hasn't been mentioned in this regard is JPython. Might this > be a viable option in MacOSX? > Yes, it also works. (An embarrasment of riches, eh?) -Bob From cbarker@jps.net Sat Nov 18 00:47:43 2000 From: cbarker@jps.net (Chris Barker) Date: Fri, 17 Nov 2000 16:47:43 -0800 Subject: [Pythonmac-SIG] Building an Extension Module with NumPy and CodeWarrior References: Message-ID: <3A15D1AF.AFAEDEEF@jps.net> Hi all, I'm trying got build an extension module that uses NumPy arrays. I'm new to programming on the Mac, and new to Codewarrior, so this should be simple, but I'm stuck. I have the line: #include "arrayobject.h" to include the NumPy array stuff, but Codewarior can't find it. I've tried adding multiarray.ppc.slb and _numpy.ppc.slb to the project, and that didn't do it. Where is that header file info? -Thanks, -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From eric_grundstrom@acm.org Sat Nov 18 17:00:51 2000 From: eric_grundstrom@acm.org (Eric Grundstrom) Date: Sat, 18 Nov 2000 09:00:51 -0800 Subject: [Pythonmac-SIG] cgi newbie Message-ID: I apoligize in advance if this isn't the right forum, but I'm not finding adequate documentation anywhere. I'm trying to figure out how to configure Web Sharing to run Python CGI scripts. It seems that whatever I do I get the error "502 Bad Gateway" with the message "A CGI or internal server component could not complete the requested action." I'm running Mac OS 9.04 on a G4 cube. I've installed MacPython 2.0 and scripts run fine in the IDE. I'm using TCP/IP and have turned on Web Sharing. In Web Sharing, I added an action "Launch at Suffix .py" pointing to PythonInterpreter. I can see my index page fine, but when I run a cgi script that's when I get the 502 error. Here are my questions: 1) How do I setup Web Sharing? Should I use "Pre-process", "Post-proces", or "Filter"? 2) Do I need to do something with paths or aliases or permissions or extensions so that CGI can find and run the python code? Thanks so much. Please respond in email mailto:eric_grundstrom@acm.org Eric From jack@oratrix.nl Sat Nov 18 18:17:38 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 18 Nov 2000 19:17:38 +0100 Subject: [Pythonmac-SIG] Forwarded: webmaster@cgiscriptsonline.com: New Search Engine Requires Your Input. Message-ID: <20001118181743.AA7D11301E8@oratrix.oratrix.nl> --boogadaboogadabooga Content-Type: text/plain; charset="us-ascii" Does anyone feel like putting MacPython CGI info on this site? --boogadaboogadabooga Content-Type: message/rfc822 From nobody@coloc2.premium-host.com Sat Nov 18 11: 23:37 2000 Return-Path: Delivered-To: jack@oratrix.nl Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1]) by oratrix.oratrix.nl (Postfix) with ESMTP id 91AB61301EB for ; Sat, 18 Nov 2000 11:23:36 +0100 (MET) Received: from coloc2.premium-host.com (coloc2.premium-host.com [209.5.80.51]) by hera.cwi.nl with ESMTP id LAA17160 for ; Sat, 18 Nov 2000 11:23:34 +0100 (MET) Received: (from nobody@localhost) by coloc2.premium-host.com (8.11.0/8.11.0) id eAIAIXM07659; Sat, 18 Nov 2000 05:18:33 -0500 Date: Sat, 18 Nov 2000 05:18:33 -0500 Message-Id: <200011181018.eAIAIXM07659@coloc2.premium-host.com> From: webmaster@cgiscriptsonline.com To: Jack.Jansen@cwi.nl Subject: New Search Engine Requires Your Input. Sender: nobody@coloc2.premium-host.com You were identified as a potential contributor to our search engine database. W e are opening up a new site dedicated to CGI scripts, programming, web developm ent resources and all information relating to these topics. You have received this email because we believe you have a skill, an opportunit y, site URL or other information you can contribute to the script and programin g related database which will be the focus of our search engine. Our site will basically be a directory type of search engine based on the Yahoo model but specifically focused on what is CGI script related. We have presently categorized our main sections as Applescript Scripts, Books & Tutorials, C Scripts, CGI News Groups, CGI Script Related Jobs, Custom Script Programers, FAQs & Documentation, Java Scripts, Other Scripts, Ot her Web Resources, PHP Scripts, Perl Scripts, Python Scripts, Remotely Hosted Scripts, Script Inst allation Services, Virtual Basic Scripts. If you can contribute to any of the categories mentioned above we encourage you to go to http://www.cgiscriptsonline.com and to add your URL to our search eng ine. Submission of URLs are totally free. We welcome any comment from you and hope to be able to build a mutually rewardi ng association in the immediate future. If this message has reached you in error and you do not have anything to contri bute to a search engine focused on CGI Scripts, Programing and/or Web Resources then please accept our appologies and click on the link below to remove yourse lf from our mailng list. If you simply want to be removed from our mailing list for whatever reason then please click on the link below and you will automatic ally be removed. Thank You, Norm Admin@CGIScriptsOnline.com http://www.CGIScriptsOnline.com --------------------------------------------------------------------- Click on the link below to be removed from the CGI Scripts Online Mailing List. http://www.cgiscriptsonline.com/cgi-bin/mail/mailmachine.cgi?jack@cwi.nl --------------------------------------------------------------------- --boogadaboogadabooga-- From cta206@is9.nyu.edu Sat Nov 18 22:04:37 2000 From: cta206@is9.nyu.edu (Christopher Thomas Ariza) Date: Sat, 18 Nov 2000 17:04:37 -0500 (EST) Subject: [Pythonmac-SIG] freezing Pmw/buildapp and Pmw on mac Message-ID: im trying to build an application using Pmw with the Mac Python 2.0 BuildApplication script. BuildApplication succeeds, with no errors. however, when executing the program, i get the following error message: File "python 2.0:Pmw:__init__.py", line 28, in ? _listdir = os.listdir(_dir) mac.error: (2, 'No such file or directory') this seems to be a problem with the Pmw Dynamic Loader. the pmw web page says this should be fixed by creating a frozen Pmw.py module that includes all Pmw code. the standard download includes the necessary script: Pmw:Pmw_0_8_4:bin:bundlepmw.py however, this file seems to only run on unix. my question: is there a pre-frozen copy of a complete Pmw.py module available on the web? will this solve my problem with BuildApplication, or only when freezing? Other solutions? thanks! From jwmdck@monmouth.com Sun Nov 19 17:52:18 2000 From: jwmdck@monmouth.com (Murphy/Kostick) Date: Sun, 19 Nov 2000 12:52:18 -0500 Subject: [Pythonmac-SIG] "All I want..." [was: IDE feature requests] References: Message-ID: <3A181351.43C27440@monmouth.com> Steven: I am interested in the work you're doing with PyObjC. I think it would be very nice to have access from Python to the Cocoa API, in particular the Application Kit. Although my skills and time are very limited (I estimate it would take me at least 2-3 months to get where you are now), I nevertheless have also downloaded Lele's project from codefab and have started to play with it (I'm learning about make files now). So you at least have one cheerleader! I'll keep my eye on SourceForge to see if there's anyway I can materially help. -- Jim Murphy Wall Township, New Jersey USA "Steven D. Majewski" wrote: > > On Thu, 16 Nov 2000, Chris Barker wrote: > > > > All I want is for the interpreter to work like it does on *nix! > > > > Well Chris: you could try it on MacOSX -- only problem is that > to run Tkinter, you have to log out and log in a console session > so you can start X11 --- which means you can't run you other Mac > apps. ( Or you can run MacPython in the "Classic" enviromnent -- > which is pretty much the same as what you've got now. ) > > But, just to take this as an excuse for an update (if anyone is > interested) : PyObjC is more-or-less working on MacOSX -- I can > load Foundation classes, but when I try to load the AppKit classes > to open and display a window, it gives a warning about not finding > a theme file just before it crashes with a bus error. ( The good > news is that on OSX, everything else keeps chugging away after > your bus error! ) > > PyObjC development is in the process of being set up at SourceForge. > > I haven't yet tried another attempt at building Python Carbon libs -- > AppKit looked like it was closer to working, so that's been on the > shelf. ( Last attempt: I was able to compile some modules against > Universal Interfaces, but there were so many module interdependencies > that I'm going to have to build all or most of it to get modules > to link. > > Is anyone else out there taking a hack at it ? > > ---| 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 operating systems want to be unix, > All programming languages want to be lisp." > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://www.python.org/mailman/listinfo/pythonmac-sig From sdm7g@virginia.edu Sun Nov 19 19:15:28 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Sun, 19 Nov 2000 14:15:28 -0500 (EST) Subject: [Pythonmac-SIG] "All I want..." [was: IDE feature requests] In-Reply-To: <3A181351.43C27440@monmouth.com> Message-ID: On Sun, 19 Nov 2000, Murphy/Kostick wrote: > Steven: > > I am interested in the work you're doing with PyObjC. > I think it would be very nice to have access from Python to > the Cocoa API, in particular the Application Kit. > > Although my skills and time are very limited (I estimate it would take > me at least 2-3 months to get where you are now), I > nevertheless have also downloaded Lele's project from codefab > and > have started to play with it (I'm learning about make files now). > > So you at least have one cheerleader! I'll keep my eye on SourceForge > to see if there's anyway I can materially help. > Bill Bumgarner has posted some patches to Python2.0 on the Python SourceForge site that enables building ObjC as a dynamically loadable shared module -- makesetup needs to know about objc .m files, and changes the link commands. One of the effects of this has been to remove some of the errors I was getting trying to use AppKit. ( Thanks Bill -- I had to edit the patches manually on my already well hacked Python distribution, but they worked. ) You want to get the '20001114' PyObjC snapshot from Codefab and patch Python2.0 with those SourceForge patches. ( I think we'll try to package these both up together soon to make it easier for folks to try it out without having to hack the distribution. ) Foundation classes seem to work well, but although I'm no longer getting 'missing theme file' errors from AppKit, and the methods all seem to return the correct values or objects, I haven't yet been able to coax it to display a window on the screen. ( But I'm learning Cocoa at the same time, working from some objc examples that do seem to behave -- so it may be a simple problem that I'm clueless about. ) I've tried to modify some of the demos from an earlier snapshot, but none of those produce anything visible. ( I'm linking to AppKit rather than loading the Bundle -- maybe I'll try it the other way and see if that makes a difference. ) BTW to Bill: Is there a way to produce the nil object ? I don't see it available as a constant and methods that should return nil seem to produce Python None. Is the runtime smart enough to convert None to nil in the other direction ? Also: This snapshot seems to have also fixed errors in using python array indexing on NSArray's. The following used to crash on me. Bill -- did you fix something here when you fixed the autorelease pool, or is this another side effect of finally getting it to link properly? >>> from ObjC import * >>> P = runtime.NSAutoreleasePool() >>> P >>> all = runtime.NSBundle.allFrameworks() >>> all >>> print all ( NSBundle (loaded), NSBundle (loaded), NSBundle (loaded), NSBundle (loaded) ) >>> all[0] # This array access used to crash me! >>> for x in all : print x # not to mention this! ... NSBundle (loaded) NSBundle (loaded) NSBundle (loaded) NSBundle (loaded) >>> ---| 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 operating systems want to be unix, All programming languages want to be lisp." From bbum@codefab.com Sun Nov 19 19:32:51 2000 From: bbum@codefab.com (Bill Bumgarner) Date: Sun, 19 Nov 2000 14:32:51 -0500 (EST) Subject: [Pythonmac-SIG] "All I want..." [was: IDE feature requests] In-Reply-To: Message-ID: On Sun, 19 Nov 2000, Steven D. Majewski wrote: > BTW to Bill: Is there a way to produce the nil object ? I don't > see it available as a constant and methods that should return nil > seem to produce Python None. Is the runtime smart enough to convert > None to nil in the other direction ? nil is equivalent to NULL in Objective-C. I.e. it isn't really an object, just a fancy name for the address 0x00000 for portabiities sake. Who knows; maybe some day we will run into a system that defines 0xBEEFFACE as Null/nil. However, one key difference in ObjC is that [foo anyMethod] where (foo == nil) is, effectively, a no-op. As long as anyMethod is declared as returning a pointer type return value, such an invocation will always evalauate to nil. In the case of float or structure-on-stack returns, the return value is undefined. I'm not necessarily sure I ever agreed with that particular design decision, but it has been convenient *at times* (it has also led to many a wasted hour at other times). The Python<->ObjC bridge *should* be smart enough to deal with converting nil->None and None->nil. However, I haven't explicitly tested it. > Also: This snapshot seems to have also fixed errors in using python > array indexing on NSArray's. The following used to crash on me. > Bill -- did you fix something here when you fixed the autorelease > pool, or is this another side effect of finally getting it to link > properly? I can't imagine a side effect of the linking process that would have fixed this problem. However, I did diddle with the handling of object references *slightly* to fix the Autoreleasepool problem. I can't imagine how that would have changed things. I'm glad to see this is now working even if it is disturbing that it would magically start working again. The sourceforge account is stil broken; they screwed up the cvs configuration by leaving the history file unwritable by group. So far, I'm not impressed by SF's handling of a basic acocunt creation. b.bum > >>> from ObjC import * > >>> P = runtime.NSAutoreleasePool() > >>> P > > >>> all = runtime.NSBundle.allFrameworks() > >>> all > > >>> print all > ( > NSBundle (loaded), > NSBundle (loaded), > NSBundle (loaded), > NSBundle (loaded) > ) > >>> all[0] # This array access used to crash me! > > >>> for x in all : print x # not to mention this! > ... > NSBundle (loaded) > NSBundle (loaded) > NSBundle (loaded) > NSBundle (loaded) > >>> > > > > ---| 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 operating systems want to be unix, > All programming languages want to be lisp." > > From jack@oratrix.nl Sun Nov 19 20:43:16 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 19 Nov 2000 21:43:16 +0100 Subject: [Pythonmac-SIG] cgi newbie In-Reply-To: Message by Eric Grundstrom , Sat, 18 Nov 2000 09:00:51 -0800 , Message-ID: <20001119204321.C57E81301E4@oratrix.oratrix.nl> Recently, Eric Grundstrom said: > I'm trying to figure out how to configure Web Sharing to run Python CGI > scripts. It seems that whatever I do I get the error "502 Bad Gateway" with > the message "A CGI or internal server component could not complete the > requested action." > > I'm running Mac OS 9.04 on a G4 cube. I've installed MacPython 2.0 and > scripts run fine in the IDE. I'm using TCP/IP and have turned on Web > Sharing. In Web Sharing, I added an action "Launch at Suffix .py" pointing > to PythonInterpreter. I can see my index page fine, but when I run a cgi > script that's when I get the 502 error. Using Python for CGI scripting is a bit more involved than that. The place to look for more info is Python:Mac:Tools:CGI, the readme file there explains how to use Python for CGI scripting. The summary is that you can more-or-less follow the method you sketch above but then you have to use PythonCGISlave in stead of PythonInterpreter as the application, or you can turn your Python CGI script into an applet with BuildCGIApplet. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From sdm7g@virginia.edu Mon Nov 20 00:54:50 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Sun, 19 Nov 2000 19:54:50 -0500 (EST) Subject: [Pythonmac-SIG] [MacOSX] Re: Where are you with Carbonized Python Mac Modules? In-Reply-To: <3A174427.4D950FD6@pacbell.net> Message-ID: Re: MacOSX Python Carbon modules update: After compiling most of the Mac Modules, and commenting out the few remaining undefined references ( SIOUXSetupMenus and some others ) I've manages to get Winmodule to build, load and put up a window on the screen on MacOSX. There may be some holes left to fall into from some of the bits commented out, and I compiled with both -DTARGET_API_MAC_CARBON and -DTARGET_API_MAC_CARBON_NOTYET ( I'm not sure what the implications of that are (Jack?) -- I was hoping it was for Carbon routines that weren't yet in whatever version of CarbonLib Jack had to build against.) FYI: This is the compile command I've been using (from the Mac/Modules directory ) -- with the addition of -fpascal-strings for macglue.c. cc -c $MODULE -I../../Include -I../Include -I../.. -I/Local/Carbon/Universal.Interfaces/CIncludes/ -DHAVE_CONFIG_H -DTARGET_API_MAC_CARBON -DTARGET_API_MAC_CARBON_NOTYET $* I'll try to tar up a snapshot of the current project sometime soon. If anyone else is interested in hacking at it, drop me a line. In the mean time, I'm going to try to build a few more modules and see if I can get something like EasyDialogs.py or Framework.py to run. ---| 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 operating systems want to be unix, All programming languages want to be lisp." From sdm7g@virginia.edu Mon Nov 20 02:30:39 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Sun, 19 Nov 2000 21:30:39 -0500 (EST) Subject: [Pythonmac-SIG] More update [MacOSX] Re: Where are you with Carbonized Python Mac Modules? In-Reply-To: Message-ID: Got a whole bunch of Mac modules to build under OSX. I can import and load any one of them, but trying to load another yields a multiple definition error: Python 2.0 (#7, 11/17/00, 16:20:11) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> import Win >>> import Menu dyld: python multiple definitions of symbol _BMObj_Convert Winmodule.so definition of _BMObj_Convert Menumodule.so definition of _BMObj_Convert As far as I could find, that symbol was only used in Qdmodule, but it seems to be dragged in by it's mention in pymactoolbox.h. Commenting that out just produces an error on the next symbol. ( In fact, on the first pass, that error was for _BMObj_New ) However, removing those references really won't work (I believe) because there are real dependencies present: for example, some menu or window functions return Resource Objects. If none of these are circular, then there is probably an order in which the .so 's can be linked against each other that will work. ( Right now, I've put all the .o files into a static library which I link against. ) Jack: Do you have any tips or clues regarding how this is done in the OS9 MacPython build ? BTW: ColorPicker.GetColor( ... ) puts up the color picker dialog, but, although Python is busy and doesn't give another prompt, the window doesn't *DO* anything, and I had to kill the process. I assume that this is because the unix based main python module doesn't have code to let Modal Dialogs grab events in the main loop. ( In fact, I wonder if my problems with AppKit via the ObjC module have something to do with that ? ) ---| 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 operating systems want to be unix, All programming languages want to be lisp." From sdm7g@virginia.edu Mon Nov 20 02:39:55 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Sun, 19 Nov 2000 21:39:55 -0500 (EST) Subject: [Pythonmac-SIG] [MacOSX] Re: Where are you with Carbonized Python Mac Modules? (fwd) Message-ID: I received a copy of my followup to this message, but I never saw the first one appear, so I'm resending it. -- Steve. ---------- Forwarded message ---------- Date: Sun, 19 Nov 2000 19:54:50 -0500 (EST) From: Steven D. Majewski To: Dan Wolfe Cc: pythonmac-sig@python.org Subject: [MacOSX] Re: Where are you with Carbonized Python Mac Modules? Re: MacOSX Python Carbon modules update: After compiling most of the Mac Modules, and commenting out the few remaining undefined references ( SIOUXSetupMenus and some others ) I've manages to get Winmodule to build, load and put up a window on the screen on MacOSX. There may be some holes left to fall into from some of the bits commented out, and I compiled with both -DTARGET_API_MAC_CARBON and -DTARGET_API_MAC_CARBON_NOTYET ( I'm not sure what the implications of that are (Jack?) -- I was hoping it was for Carbon routines that weren't yet in whatever version of CarbonLib Jack had to build against.) FYI: This is the compile command I've been using (from the Mac/Modules directory ) -- with the addition of -fpascal-strings for macglue.c. cc -c $MODULE -I../../Include -I../Include -I../.. -I/Local/Carbon/Universal.Interfaces/CIncludes/ -DHAVE_CONFIG_H -DTARGET_API_MAC_CARBON -DTARGET_API_MAC_CARBON_NOTYET $* I'll try to tar up a snapshot of the current project sometime soon. If anyone else is interested in hacking at it, drop me a line. In the mean time, I'm going to try to build a few more modules and see if I can get something like EasyDialogs.py or Framework.py to run. ---| 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 operating systems want to be unix, All programming languages want to be lisp." From jack@oratrix.nl Mon Nov 20 09:34:43 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 20 Nov 2000 10:34:43 +0100 Subject: [Pythonmac-SIG] Re: More update [MacOSX] Re: Where are you with Carbonized Python Mac Modules? In-Reply-To: Message by "Steven D. Majewski" , Sun, 19 Nov 2000 21:30:39 -0500 (EST) , Message-ID: <20001120093443.E92E835BAF6@snelboot.oratrix.nl> > Python 2.0 (#7, 11/17/00, 16:20:11) > [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 > Type "copyright", "credits" or "license" for more information. > >>> import Win > >>> import Menu > dyld: python multiple definitions of symbol _BMObj_Convert > Winmodule.so definition of _BMObj_Convert > Menumodule.so definition of _BMObj_Convert What is your linker commandline for (for example) Winmodule.so? It appears you're somehow not sharing your copy of Qdmodule.so among Winmodule and Menumodule. Hmm, or you're recursively importing Winmodule or something. Since MacPython 1.5.2 the core toolbox modules (AE, Ctl, Dlg, Evt, Menu, Qd, Res, Win) are expecting to have access to each others globals, mainly the xxx_New and xxx_Convert routines. The circular dependencies were getting too much to handle. It could be that you're running into the same problem here. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tom@othermedia.com Mon Nov 20 09:48:32 2000 From: tom@othermedia.com (tom smith) Date: Mon, 20 Nov 2000 09:48:32 +0000 Subject: [Pythonmac-SIG] ODBC, mxDateTime and Python 2.0......help?! In-Reply-To: <3A15D1AF.AFAEDEEF@jps.net> Message-ID: hi, the app I'm currently developing needs to save stuff to an ODBC (SQLServer or Access) database. That means I'm having to spend all day in virtual PC. I'd much rather develop on a mac, maybe using Omnis-Studio or PrimeBase (even FileMaker if I could connect via ODBC to it). I (think I) need a recently compiled version of mxDateTime, could anyone do this for me. http://www.lemburg.com/files/python/mxExtensions.html#mxDateTime. I'm not sure if once I've got this the odbc modules will actually work, but until I have a "new" mxDateTime, I won't know Or if anyone has any other suggestions.... idle and WinPython are no match for MacPython... the ActiveState python editor was like kidpix... take pity on a poor mac user and run CodeWarrior up for me, will ya? :-) tom From cbarker@jps.net Mon Nov 20 17:35:22 2000 From: cbarker@jps.net (Chris Barker) Date: Mon, 20 Nov 2000 09:35:22 -0800 Subject: [Pythonmac-SIG] Building an Extension Module with NumPy and CodeWarrior References: <20001119204557.BE3931301E4@oratrix.oratrix.nl> Message-ID: <3A1960DA.BC3A9B77@jps.net> Jack Jansen wrote: > > #include "arrayobject.h" > > It should be installed if you select the "developer option" in the > Python installer. In the 2.0 distribution it will be put in > Python:Extensions:Numeric:Include, so you'l have to add that folder to > your search path. Just so you all don't think I'm a complete idiot, I really did install the developer option, and I did do a "find" for arrayobject.h" ,and I did look in the Numerical tree for an include folder or something like it. No arrayobject.h anywhere. What I was too stupid to put in the first post was that I'm still using 1.5.2c, I havn't yet switched to 2.0. I'm in the middle of a project with a tight deadline, and I didn't want to face any more unknowns that neccesary. So, where do I get arrayobject.h for 1.5.2 ? -Thanks, -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From sdm7g@minsky.med.virginia.edu Mon Nov 20 17:29:35 2000 From: sdm7g@minsky.med.virginia.edu (Steven D. Majewski) Date: Mon, 20 Nov 2000 12:29:35 -0500 (EST) Subject: [Pythonmac-SIG] [OSX] More AppKit puzzles and progress [was: "All I want..."] Message-ID: Some success with AppKit finally! In a thread on macosx-dev, Frederick Stark ansered a question from someone trying to bring up a window procedurally, without IB or Nibs: | Displaying a window mean drawing its content. This bear no relation | on wether the window is visible or not. You need to have a: | | [w makeKeyAndOrderFront:self] In the example code that I based my python AppKit test on, it called [win makeKeyAndOrderFront:nil] Bill: This was the line that prompted my question about nil <-> None. If I try win.makeKeyAndOrderFront_(None) I got kCGSErrorNoneAvailable : CGSOrderFrontConditionally: Process not found. The docs on this stuff is pretty rough sledding: there is nothing in the reference manual to indicate the connection of that message with window visibility and the arg is supposed to be: (id) sender. It wasn't clear what valid values for sender might be. I tried using the App returned from NSApplication.sharedApplication(), but that produced the same error. I tried some of the other related methods listed under makeKeyAndOrder... win.setLevel(3) didn't do anything on it's own, but I finally found win.orderFrontRegardless(), which didn't require an argument, and made the window pop up. If I can put together at least one documented example that puts up a window and does something functional with it, I think I'll feel ready to release an alpha or something for folks to use. ---| 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 operating systems want to be unix, All programming languages want to be lisp." From sdm7g@virginia.edu Mon Nov 20 17:35:12 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Mon, 20 Nov 2000 12:35:12 -0500 (EST) Subject: [Pythonmac-SIG] Re: More update [MacOSX] Re: Where are you with Carbonized Python Mac Modules? In-Reply-To: <20001120093443.E92E835BAF6@snelboot.oratrix.nl> Message-ID: On Mon, 20 Nov 2000, Jack Jansen wrote: > What is your linker commandline for (for example) Winmodule.so? It appears > you're somehow not sharing your copy of Qdmodule.so among Winmodule and > Menumodule. Hmm, or you're recursively importing Winmodule or something. I know that I'm doing it totally wrong, Jack. I just don't know enough OSX to know how to do it right yet! On AIX, with it's import and export files, I know you can link to a library that doesn't yet exist -- the import files tell it what symbols are going to be resolved from where. I don't know how to do this on OSX yet, so I'm running into a chicken and egg problem. > Since MacPython 1.5.2 the core toolbox modules (AE, Ctl, Dlg, Evt, Menu, Qd, > Res, Win) are expecting to have access to each others globals, mainly the > xxx_New and xxx_Convert routines. The circular dependencies were getting too > much to handle. It could be that you're running into the same problem here. ---| 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 operating systems want to be unix, All programming languages want to be lisp." From cbarker@jps.net Tue Nov 21 01:24:12 2000 From: cbarker@jps.net (Chris Barker) Date: Mon, 20 Nov 2000 17:24:12 -0800 Subject: [Pythonmac-SIG] Building an Extension Module with NumPy and CodeWarrior References: <3124AB5C4D11D31187DC005004185D1B4CD472@BIGPIG> Message-ID: <3A19CEBC.2DE5F219@jps.net> "Magladry, Stephen" wrote: > A quick note on how to include directories using the Mac. This a general > template, when ever I have a problem with include files. Thanks, this actually was helpful, as I'm new to the Mac and codewarrior, although I really didn't have the arrayobject.h file! Lou Pecora sent it to me, and I have gotten a lot farthar along, but now I am getting a linking error: undefined '__ptr_glue' (code_) It seems to be in functions that use NumPy arrays, and are in the Methods Table, but not in those that don't use NumPy arrays, or aren't in the methods table, although I have a small sample, so I'm not sure. What do I do now? -Chris > > 1. Use Sherlock to find the file in question. In your case > arraryobject.h. > 2. In Code Warrior, which I hope your using, select the project > settings... for the edit menu. This is the second to the last menu entry and > will not say project setting... but will replace your project name with > project. > 3. Click on the access path tab. > 4. Drag the folder containing the file in question to the appropriate > pane, whether that is Users Path or System Path in the Setting dialog. If > your will be sharing the project with someone else, make sure to set the > path relative to project or system (compiler) as appropriate. > > A note on folder dragging: you should be able to drag a folder from Sherlock > and drop it on the appropriate access pane. Also, if you have a recent > enough OS, Mac Os 8.6, I believe, if you click and wait on the folder icon > that appears at top of a Finder window until you see it highlight. At that > point, you can drop that folder on the access pains in the dialog. > > I can't help you if you are using MPW, but to say that MPW has access paths > and will have to explore that on your own. -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From christian@rocketnetwork.com Tue Nov 21 01:15:07 2000 From: christian@rocketnetwork.com (Christian Reyes) Date: Mon, 20 Nov 2000 17:15:07 -0800 Subject: [Pythonmac-SIG] python core library In-Reply-To: <20001117170218.1049C1D2C0@dinsdale.python.org> Message-ID: I don't have the python-mac source code but I have a question regarding the project file. Does the python core library sse __initialize, __start, and __terminate entry points? Thanks, christian -----Original Message----- From: pythonmac-sig-admin@python.org [mailto:pythonmac-sig-admin@python.org]On Behalf Of pythonmac-sig-request@python.org Sent: Friday, November 17, 2000 9:02 AM To: pythonmac-sig@python.org Subject: Pythonmac-SIG digest, Vol 1 #567 - 9 msgs Send Pythonmac-SIG mailing list submissions to pythonmac-sig@python.org To subscribe or unsubscribe via the World Wide Web, visit http://www.python.org/mailman/listinfo/pythonmac-sig or, via email, send a message with subject or body 'help' to pythonmac-sig-request@python.org You can reach the person managing the list at pythonmac-sig-admin@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Pythonmac-SIG digest..." From christian@rocketnetwork.com Tue Nov 21 01:42:02 2000 From: christian@rocketnetwork.com (Christian Reyes) Date: Mon, 20 Nov 2000 17:42:02 -0800 Subject: [Pythonmac-SIG] debugging in python mac In-Reply-To: <20001117170218.1049C1D2C0@dinsdale.python.org> Message-ID: Question 1: Can someone please tell me how to best go about debugging Python mac code? Question 2: Is there a way to do searches on the pythonmac-SIG archives? Thanks, christian -----Original Message----- From: pythonmac-sig-admin@python.org [mailto:pythonmac-sig-admin@python.org]On Behalf Of pythonmac-sig-request@python.org Sent: Friday, November 17, 2000 9:02 AM To: pythonmac-sig@python.org Subject: Pythonmac-SIG digest, Vol 1 #567 - 9 msgs Send Pythonmac-SIG mailing list submissions to pythonmac-sig@python.org To subscribe or unsubscribe via the World Wide Web, visit http://www.python.org/mailman/listinfo/pythonmac-sig or, via email, send a message with subject or body 'help' to pythonmac-sig-request@python.org You can reach the person managing the list at pythonmac-sig-admin@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Pythonmac-SIG digest..." From christian@rocketnetwork.com Tue Nov 21 03:21:12 2000 From: christian@rocketnetwork.com (Christian Reyes) Date: Mon, 20 Nov 2000 19:21:12 -0800 Subject: [Pythonmac-SIG] Preferred Pythonmac Editor In-Reply-To: <20001117170218.1049C1D2C0@dinsdale.python.org> Message-ID: Are there any editors that y'all would recommend? Ones that recognize keywords and other python syntax? Thanks, Christian From christian@rocketnetwork.com Tue Nov 21 04:12:54 2000 From: christian@rocketnetwork.com (Christian Reyes) Date: Mon, 20 Nov 2000 20:12:54 -0800 Subject: [Pythonmac-SIG] python mac IDE In-Reply-To: <20001117170218.1049C1D2C0@dinsdale.python.org> Message-ID: Is there any way to set tab sizes in the python mac IDE editor? Mine defaults to 8 right now, and I can't figure out how to change it to 4. I'm running code that I've written on other platforms, but the interpreter is choking on mismatched tab and space indents. Thanks, christian -----Original Message----- From: pythonmac-sig-admin@python.org [mailto:pythonmac-sig-admin@python.org]On Behalf Of pythonmac-sig-request@python.org Sent: Friday, November 17, 2000 9:02 AM To: pythonmac-sig@python.org Subject: Pythonmac-SIG digest, Vol 1 #567 - 9 msgs Send Pythonmac-SIG mailing list submissions to pythonmac-sig@python.org To subscribe or unsubscribe via the World Wide Web, visit http://www.python.org/mailman/listinfo/pythonmac-sig or, via email, send a message with subject or body 'help' to pythonmac-sig-request@python.org You can reach the person managing the list at pythonmac-sig-admin@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Pythonmac-SIG digest..." From jack@oratrix.nl Tue Nov 21 09:03:48 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 21 Nov 2000 10:03:48 +0100 Subject: [Pythonmac-SIG] Building an Extension Module with NumPy and CodeWarrior In-Reply-To: Message by Chris Barker , Mon, 20 Nov 2000 17:24:12 -0800 , <3A19CEBC.2DE5F219@jps.net> Message-ID: <20001121090349.64F3435BAF6@snelboot.oratrix.nl> > "Magladry, Stephen" wrote: > > A quick note on how to include directories using the Mac. This a general > > template, when ever I have a problem with include files. > > Thanks, this actually was helpful, as I'm new to the Mac and > codewarrior, although I really didn't have the arrayobject.h file! > > Lou Pecora sent it to me, and I have gotten a lot farthar along, but now > I am getting a linking error: > > undefined '__ptr_glue' (code_) This is a routine from the MetroWerks runtime system. You should add ShLibRuntime.Lib to your project and then everything should be fine. While most of the runtime stuff will be grabbed from PythonCore (which also contains a full copy) there are a few of the runtime routines that have to be in the fragment from which they're called: besides __ptr_glue setjmp is the most obvious one. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Tue Nov 21 09:06:47 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 21 Nov 2000 10:06:47 +0100 Subject: [Pythonmac-SIG] python core library In-Reply-To: Message by "Christian Reyes" , Mon, 20 Nov 2000 17:15:07 -0800 , Message-ID: <20001121090647.A391135BAF6@snelboot.oratrix.nl> > I don't have the python-mac source code but I have a question regarding the > project file. > Does the python core library sse __initialize, __start, and __terminate > entry points? That depends on what you mean by "sse" :-) If you mean "use": yes, it uses __initialize and __terminate (not start, that isn't for libraries), although it actually uses its own wrapper around the initialize routine, __initialize_with_resources, because it wants to keep an fssspec for the file it was loaded from (so it can add it to the resource chain later on). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tom@othermedia.com Tue Nov 21 16:26:12 2000 From: tom@othermedia.com (tom smith) Date: Tue, 21 Nov 2000 16:26:12 +0000 Subject: [Pythonmac-SIG] debugging in python mac In-Reply-To: Message-ID: on 21/11/00 1:42 am, Christian Reyes at christian@rocketnetwork.com wrote: > Question 1: Can someone please tell me how to best go about debugging > Python mac code? Check out http://www.strout.net/python/mac/, it gives you syntax colouring AND breakpoints. I use it and love it. (Sometimes you have to re-select 'syntax colouring, but rather than than black & white code). From cbarker@jps.net Tue Nov 21 18:07:03 2000 From: cbarker@jps.net (Chris Barker) Date: Tue, 21 Nov 2000 10:07:03 -0800 Subject: [Pythonmac-SIG] python mac IDE References: Message-ID: <3A1AB9C7.DE3F7B24@jps.net> This is a multi-part message in MIME format. --------------806AA6D681F037B6ED4318BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christian Reyes wrote: > Is there any way to set tab sizes in the python mac IDE editor? Mine > defaults to 8 right now, and I can't figure out how to change it to 4. > I'm running code that I've written on other platforms, but the interpreter > is choking on mismatched tab and space indents. Yes, there is, but I'm at a loss at the moment as to how to do it, I'm sure someone else knows. The bigger issue here is that mixing tabs and spaces is a "bad thing". I have no idea why Guido allowed it in the first place, but so be it. The solution I came up with is to use only tabs. I set up emacs to that for me in Linux, and that is the easiest thing to so on the Mac. Then what you need is a way to convert all your existing Python script to all tabs. I use a script that I derived from one called "tabcleaner" It's mostly someone elses code, but their name wasn't in the file, so I have no idea who. Thanks to whoever wrote it. By the way, Python assumes that tabs are 8 spaces, so that is the setting you should use if you have a mixture of tabs ans spaces in your code. I have enclosed it with this email. If you build it as an applet, you can drag and drop files on it to have them converted. --- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ --------------806AA6D681F037B6ED4318BA Content-Type: text/plain; charset=us-ascii; name="Py_to_tabs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Py_to_tabs" #!/usr/bin/python import tokenize import string TABSONLY = 'TABSONLY' SPACESONLY = 'SPACESONLY' MIXED = 'MIXED' class PyText: def __init__(self, fnm, optdict): self.optdict = optdict self.fnm = fnm self.txt = open(self.fnm, 'r').readlines() self.indents = [(0, 0, )] self.lnndx = 0 self.indentndx = 0 def getline(self): if self.lnndx < len(self.txt): txt = self.txt[self.lnndx] self.lnndx = self.lnndx + 1 else: txt = '' return txt def tokeneater(self, type, token, start, end, line): if type == tokenize.INDENT: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, start[0]-1) self.indents.append((lvl+1, start[0]-1,)) elif type == tokenize.DEDENT: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, start[0]-1) self.indents.append((lvl-1, start[0]-1,)) elif type == tokenize.ENDMARKER: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, len(self.txt)) def split(self, ln): content = string.lstrip(ln) if not content: return ('', '\n') lead = ln[:len(ln) - len(content)] lead = string.expandtabs(lead) return (lead, content) def process(self): style = self.optdict.get('style', TABSONLY) indent = string.atoi(self.optdict.get('indent', '4')) tabsz = string.atoi(self.optdict.get('tabs', '8')) print 'file %s -> style %s, tabsize %d, indent %d' % (self.fnm, style, tabsz, indent) tokenize.tokenize(self.getline, self.tokeneater) #import pprint #pprint.pprint(self.indents) new = [] for (lvl, s, e) in self.indents: if s >= len(self.txt): break if s == e: continue oldlead, content = self.split(self.txt[s]) #print "oldlead", len(oldlead), `oldlead` if style == TABSONLY: newlead = '\t'*lvl elif style == SPACESONLY: newlead = ' '*(indent*lvl) else: sz = indent*lvl t,spcs = divmod(sz, tabsz) newlead = '\t'*t + ' '*spcs new.append(newlead + content) for ln in self.txt[s+1:e]: lead, content = self.split(ln) #print "lead:", len(lead) new.append(newlead + lead[len(oldlead):] + content) self.save(new) #print "---", self.fnm #for ln in new: # print ln, #print def save(self, txt): bakname = os.path.splitext(self.fnm)[0]+'.bak' print "backing up", self.fnm, "to", bakname #print os.getcwd() try: os.rename(self.fnm, bakname) except os.error: os.remove(bakname) os.rename(self.fnm, bakname) open(self.fnm, 'w').writelines(txt) def test(): tc = PyText('test1.py') tc.process() tc = PyText('test1.py') tc.process(style=TABSONLY) tc = PyText('test1.py') tc.process(style=MIXED, indent=4, tabs=8) tc = PyText('test1.py') tc.process(style=MIXED, indent=2, tabs=8) def cleanfile(fnm, d): if os.path.isdir(fnm) and not os.path.islink(fnm): names = os.listdir(fnm) for name in names: fullnm = os.path.join(fnm, name) if (os.path.isdir(fullnm) and not os.path.islink(fullnm)) or \ os.path.normcase(fullnm[-3:]) == ".py": cleanfile(fullnm, d) return tc = PyText(fnm, d) tc.process() usage="""\ %s [options] [path...] options -T : reformat to TABS ONLY -S : reformat to SPACES ONLY ( -i option is important) -M : reformat to MIXED SPACES / TABS ( -t and -i options important) -t : tab is worth characters -i : indents should be characters -h : print this text path is file or directory """ if __name__ == '__main__': import sys, getopt, os opts, args = getopt.getopt(sys.argv[1:], "TSMht:i:") d = {} print `opts` for opt in opts: if opt[0] == '-T': d['style'] = TABSONLY elif opt[0] == '-S': d['style'] = SPACESONLY elif opt[0] == '-M': d['style'] = MIXED elif opt[0] == '-t': d['tabs'] = opt[1] elif opt[0] == '-i': d['indent'] = opt[1] elif opt[0] == '-h': print usage % sys.argv[0] sys.exit(0) if not args: print usage % sys.argv[0] for arg in args: cleanfile(arg, d) --------------806AA6D681F037B6ED4318BA-- From owen@astro.washington.edu Tue Nov 21 17:57:09 2000 From: owen@astro.washington.edu (Russell E Owen) Date: Tue, 21 Nov 2000 09:57:09 -0800 Subject: [Pythonmac-SIG] Anybody have a fix for time in 1.5.2c? Message-ID: I'm just starting to try to read file creation times and things aren't working as expected. For a file created Jul 5, 2000: >>> ap = "RussMain:Desktop Folder:test" >>> ct = os.stat(ap)[stat.ST_CTIME] >>> ct 3045641098.0 >>> time.localtime(ct) (1996, 7, 6, 11, 24, 58, 5, 188, -1) >>> time.gmtime(ct) (1996, 7, 6, 19, 24, 58, 5, 188, -1) I looked back and found a discussion that was probably about this same problem, but no solution. Any suggested patches? I am still using 1.5.2 because Tk is broken in 2.0 (file events don't work). -- Russell P.S. for anybody else using 1.5.2c, here's another fix: in macpath.py remove all three instances of "stat." or explicitly include stat in addition to the existing import stat *. From cbarker@jps.net Tue Nov 21 18:15:25 2000 From: cbarker@jps.net (Chris Barker) Date: Tue, 21 Nov 2000 10:15:25 -0800 Subject: [Pythonmac-SIG] Building an Extension Module with NumPy and CodeWarrior References: <20001121090349.64F3435BAF6@snelboot.oratrix.nl> Message-ID: <3A1ABBBD.F4016037@jps.net> Jack Jansen wrote: > > undefined '__ptr_glue' (code_) > > This is a routine from the MetroWerks runtime system. You should add > ShLibRuntime.Lib to your project and then everything should be fine. > While most of the runtime stuff will be grabbed from PythonCore (which also > contains a full copy) there are a few of the runtime routines that have to be > in the fragment from which they're called: besides __ptr_glue setjmp is the > most obvious one. Thanks, Jack. That did it. I was confused because I could get a simple extension working without that Library. Has any of this been written up anywhere? I'm keeping notes, and adding them to some notes written by Lou Pecora, and what I'd really like to do is get a section added to the "Extending and Embedding" Official Python Doc. If anyone one has it written up, or has some more notes to add, please send them along to me, and I'll try to put them together. -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From christian@rocketnetwork.com Tue Nov 21 19:10:09 2000 From: christian@rocketnetwork.com (Christian Reyes) Date: Tue, 21 Nov 2000 11:10:09 -0800 Subject: [Pythonmac-SIG] python core library In-Reply-To: <20001121133510.B568235BAF6@snelboot.oratrix.nl> Message-ID: Yes I have Jack. That "targeting MacOs pdf" has been my primary source of info up to this point. It seems to state that I'm doing exactly what i'm supposed to (Seems being the operative word there). I know it's probably just some setting in one of the projects that i'm overlooking. I will send you a copy of my projects and source as soon as i get back to the office. They're CW5 projects. Really appreciate your help. cheers, Christian -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Tuesday, November 21, 2000 5:35 AM To: christian@rocketnetwork.com Subject: Re: [Pythonmac-SIG] python core library Crhistian, have you looked at the "targeting MacOS" book from MetroWerks (it's in PDF form on your documentation CD). I'm not 100% sure that the libraries you use (runtime ppc++.dll and shlibruntime) are the correct ones for this case. The targeting MacOS book (at least, I _think_ it's that one, otherwise it's the c++ book) has an explanation of exactly how to determine the settings you need for shared libraries and such. If you don't find the info there (or if you've looked there already) can you pack up the sources and projects for your simple test and send them to me? I won't promise anything, but I'll try to find the time to look into it. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Tue Nov 21 22:21:25 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 21 Nov 2000 23:21:25 +0100 Subject: [Pythonmac-SIG] Building an Extension Module with NumPy and CodeWarrior In-Reply-To: Message by Chris Barker , Tue, 21 Nov 2000 10:15:25 -0800 , <3A1ABBBD.F4016037@jps.net> Message-ID: <20001121222130.D0CF21301E4@oratrix.oratrix.nl> Recently, Chris Barker said: > Jack Jansen wrote: > > > undefined '__ptr_glue' (code_) > > > > This is a routine from the MetroWerks runtime system. You should add > > ShLibRuntime.Lib to your project and then everything should be fine. > > Thanks, Jack. That did it. I was confused because I could get a simple > extension working without that Library. > > Has any of this been written up anywhere? It is sort-of in the MetroWerks documentation (I think in "targeting MacOS") and in the last paragaph of Python:Mac:Demo:building.html. > I'm keeping notes, and adding > them to some notes written by Lou Pecora, and what I'd really like to do > is get a section added to the "Extending and Embedding" Official Python > Doc. If anyone one has it written up, or has some more notes to add, > please send them along to me, and I'll try to put them together. Yes! Great! -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From vincem@en.com Wed Nov 22 04:51:31 2000 From: vincem@en.com (Vincent Marchetti) Date: Tue, 21 Nov 2000 23:51:31 -0500 Subject: [Pythonmac-SIG] Building mxDateTime for Python 2.0 Message-ID: I am trying to re-compile the mxDateTime shared library to let me use DateTime in Python 2.0 -- the shared library provided throws exception on import about using the wrong version. I have never compiled any type of shared library before, so girding my loins and firing up CW 5 I set up a shared library project and: 1. included the mxDateTime.c code 2. included stub libraries PythonCore and MSL ShLibRuntime.Lib Result: -- Link failure, could not find function 'floor' I knew this is a standard C function, so I threw the stub MathLib into the pot and cooked. Got a bunch of warnings about duplicate definitions of math functions (in PythonCore and MathLib). Decided to ignore warnings. Successfully made the shared library, successfully imported DateTime into Python 2.0 (actually 2.0b1). However, the test script for mxDateTime failed an assertion. Basically, a function DateTimeFromTicks, which uses the floor function, fails to give predicted results. My question: Am I including the correct library in my project to get the "right" version of floor? Thanks, Vince Marchetti From tom@othermedia.com Wed Nov 22 10:27:31 2000 From: tom@othermedia.com (tom smith) Date: Wed, 22 Nov 2000 10:27:31 +0000 Subject: [Pythonmac-SIG] Building mxDateTime for Python 2.0 In-Reply-To: Message-ID: If you manage to do this can I have a copy please... by the way, are you using this in conjuction with odbc? Do you know if it works...where is the dbi module thanks tom From cbarker@jps.net Wed Nov 22 23:02:30 2000 From: cbarker@jps.net (Chris Barker) Date: Wed, 22 Nov 2000 15:02:30 -0800 Subject: [Pythonmac-SIG] Trouble with extension using NumPy on the Mac References: Message-ID: <3A1C5086.1679B31A@jps.net> Hi all, I'm cross posting this to the NumPy List and the MacPython list, because it involves NumPy on the Mac, so I'm not sure which group can be most helpfull. It took me a while to get this far, and I finally got everything to compile, but now I have a crashing problem. It seems to be a problem with PyArray_Type not being seen as a PyObject. I am pretty new to C, but I have consulted with a number of folks I work with that know a lot more than I do, and this seems to be a pretty esoteric C issue. It also seems to be compiler dependent, because I have all this working fine on Linux with gcc. I have chopped my problem down into a very small function that demonstrates the problem. The function takes a contiguous NumPy array of Floats (doubles) and multiplies every element by two (in place), and returns None. Here is the code as it works on Linux: #include "Python.h" #include "arrayobject.h" /* A function that doubles an array of Floats in place*/ static PyObject * minimal_doublearray(PyObject *self, PyObject *args) { PyArrayObject *array; int i, num_elements; double *data_array ; if (!PyArg_ParseTuple(args, "O!", &PyArray_Type, &array)) return NULL; if (array->descr->type_num != PyArray_DOUBLE) { PyErr_SetString(PyExc_ValueError, "array must be of type Float"); return NULL; } data_array = (double *) array->data; /*num_elements = PyArray_Size((PyObject *) array);*/ num_elements = PyArray_Size(array); printf("The size of the array is: %i elements\n",num_elements); for (i= 0; i < num_elements; i++) data_array[i] = 2 * data_array[i]; return Py_None; } static PyMethodDef minimalMethods[] = { {"doublearray", minimal_doublearray, METH_VARARGS}, {NULL, NULL} /* Sentinel */ }; void initminimal() { (void) Py_InitModule("minimal", minimalMethods); } Note that the call to: "PyArray_Size(array)" gives me a "./minimal.c:28: warning: passing arg 1 from incompatible pointer type " on gcc on linux. In CodeWarrior on the Mac, it is an fatal error. With the typcast (see previous commented out line) it gives no warnings, and compiles on both systems. Here is a small script to test it: #!/usr/bin/env python from Numeric import * import minimal print "\nTesting doublearray" a = arange(10.0) print a minimal.doublearray(a) print a print "the second version should be doubled" This works fine on Linux, and gives the appropriate errors if the wrong type object is passed in. On the Mac, it crashes. Trying various things, I found that it crashes on the if (!PyArg_ParseTuple(args, "O!", &PyArray_Type, &array)) return NULL; line. If I use: if (!PyArg_ParseTuple(args, "O", &array)) return NULL; It works. Then it crashes on the: num_elements = PyArray_Size((PyObject *) array); line. If I use another way to determine the number of elements, like: num_elements = 1; for (i=0,ind,i++) num_elements = num_elements * array->dimensions[1]; Then I can get it to work. What is going on? anyone have any suggestions? MacPython 1.5.2c The NumPy that came with MacPython 1.5.2c CodeWarrior pro 5. Thanks for any suggestions, -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From dgoodger@bigfoot.com Thu Nov 23 01:48:26 2000 From: dgoodger@bigfoot.com (David Goodger) Date: Wed, 22 Nov 2000 20:48:26 -0500 Subject: [Pythonmac-SIG] python mac IDE In-Reply-To: <20001122170123.2F0731D37A@dinsdale.python.org> Message-ID: > The bigger issue here is that mixing tabs and spaces is a "bad thing". I > have no idea why Guido allowed it in the first place, but so be it. The > solution I came up with is to use only tabs. You realize of course that 4 spaces per indent has become the standard for library code (Python's entire standard library was converted recently). Unfortunately there's no setting in the IDE to use spaces. It would be nice if there were! -- David Goodger dgoodger@bigfoot.com Open-source projects: - The Go Tools Project: http://gotools.sourceforge.net (more to come!) From fgranger@altern.org Fri Nov 24 20:35:56 2000 From: fgranger@altern.org (Francois Granger) Date: Fri, 24 Nov 2000 21:35:56 +0100 Subject: [Pythonmac-SIG] BuildApplet issue Message-ID: I am in the group of french translator for Python doc. They did a script for preparing LaTex source. I used to use previous versions without much problem. With this one, when I drag&drop it on BuildApplet, this one complains : 'Syntax error in script "HD:PyDoc:prepare_tex15.py"' I hacked it to have a file open dialog instead. But this seems strange. #!/usr/bin/env python """ SYNOPSIS Usage: prepare_tex [-h/-?/--h/--help] [-d] [--version=value/-v value...] \ [--translator=value/-t value...] [-lang=value...] [--output_file=value/-o \ value...] latex_src_file **-h/-?/--help/--h** Show this little help **-d** Show the whole doc string of this script **--version=value (-v)** *default version=2.0* Set the version of the translation **--output_file (-o)** *default outputfile=inputfile+_+lang* Set the output file destination **--translator=value (-t)** *default translator='unknown'* Set the name of the translator **-lang=value(-l)** *default lang=FR* Prepare for French(fr) or other, as you want For most parameters an interactive input will be given if the arg is not in the command line. Except output_file which is STDOUT by default. Result of this script : For each paragraph of the source file given in the command line: %%% TRANSLATION ORIG % original lines % of the paragraph %%% TRANSLATION FR # ready to write here %%% /TRANSLATION And we add a translation INFO paragraph in the header: %%% TRANSLATION INFO :\n") % Original : release 2.0 % Translation : CVS Id % Translator : Unknow % Language : FR FILE $Id: prepare_tex.py,v 1.5 2000/10/24 20:25:25 olberger Exp $ DESCRIPTION *Prepare_tex* Generate to output a new Latex file with comments and tokens for translation. AUTHOR Odile Bénassy, developped for the French Python Translation Workgroup. Contributions by Olivier Berger and Regis Leroy LICENCE GNU General Public License HISTORY $Log: prepare_tex.py,v $ Revision 1.5 2000/10/24 20:25:25 olberger Typo et correction mineure Revision 1.4 2000/10/24 14:36:14 olberger Ajout version améliorée encore par Régis Leroy - Revision 1.4 2000/10/24 15:30:00 rage o All args can be given in command line, if an arg is missing there is an interactive input. o To get the doc string the command line arg is now -d o add --help and --h to command line args. o add a TODO section - Revision 1.3 2000/10/22 10:22:25 rage o Doc strings corrections, gendoc compatibility, cosmetic changes. o command line parser o add possibility of changing the 'FR' token - Revision 1.2 2000/10/23 obenassy o Interactive input of header parameters o Header generation - Revision 1.1 2000/10/18 15:47:07 oberger o some improvements on limit cases o CVS integration - Version 1.0 2000/10/18 15:47:07 Original author : Odile Bénassy, developped for the French Python Translation Workgroup. (http://sourceforge.net/project/frpython). TODO - a --reverse function to get the original copy ? - verifying existence of the output file before writing on it. - add a space after 'release' in the output? """ ######### # IMPORTS import sys, string, re, os, getopt ######### # GLOBALS BLANK = re.compile('^[%s]*$' % string.whitespace) LANG_TOKEN = "" TRANSLATOR = "" VERSION = "" OUTPUTFILE = "" __author__ = "Odyle Benassy" # CVS crud __version__ = "$Revision: 1.5 $" # $Source: /cvsroot/frpython/translation/fr/outils/prepare_tex.py,v $ __usage__ = """ Usage: prepare_tex [-h/-?/--h/--help] [-d] [--version=value/-v value...] \ [--translator=value/-t value...] [-lang=value...] [--output_file=value/-o \ value...] latex_src_file **-h/-?/--help/--h** Show this little help **-d** Show the whole doc string of this script **--version=value (-v)** *default version=2.0* Set the version of the translation **--output_file (-o)** *default outputfile=inputfile+_+lang* Set the output file destination **--translator=value (-t)** *default translator='unknown'* Set the name of the translator **-lang=value(-l)** *default lang=FR* Prepare for French(fr) or other, as you want For most parameters an interactive input will be given if the arg is not in the command line. Except output_file which is STDOUT by default. Result of this script : For each paragraph of the source file given in the command line: %%% TRANSLATION ORIG % original lines % of the paragraph %%% TRANSLATION FR # ready to write here %%% /TRANSLATION """ ########### # FUNCTIONS def handle_line(para, line, converted_lines): """ handle a line in the input. if inside a paragraph, adds it to the current paragraph : para. Else, if terminates the current paragraph (blank line), return the converted paragraph into converted_lines. *para* -- The current paragraph *line* -- the original line, should be a text line without '\n'. *converted_lines* -- the addition of all the converted lines made by this function before. **Warning** : para and converted_lines must be changed in place (with append()). """ # if it's a blank line, ending the paragraph # dump the converted paragraph if BLANK.match(line): if para: # insert header converted_lines.append("%%% TRANSLATION ORIG\n") # insert converted paragraph for lineOfPar in para : lineOfPar = '% ' + lineOfPar lineOfPar = lineOfPar + '\n' converted_lines.append(lineOfPar) # end the current paragraph (changed in place) para[:] = [] # insert footer converted_lines.append("%%% TRANSLATION ") converted_lines.append(LANG_TOKEN) converted_lines.append("\n \n") converted_lines.append("%%% /TRANSLATION\n") # then add back the original blank line line = line + "\n" converted_lines.append(line) # case of a line inside a paragraph # just add it to the current paragraph else: para.append(line) def prepare_para_orig_tex(lines): """ Converts paragraphs (from arg lines) in commented blocks. Return all the converted lines. Use handle_line to treat each line and to create the converted lines text. *lines* -- The whole text to handle """ # current paragraph para = [] # result of conversion of lines of the file converted_lines = [] # header converted_lines.append("%%% TRANSLATION INFO :\n") converted_lines.append("%% Original : release %s\n" % VERSION) converted_lines.append("%% Translation : $%s$\n" % "Id") converted_lines.append("%% Translator : %s\n" % TRANSLATOR) converted_lines.append("%% Language : %s\n\n" % LANG_TOKEN) # loop through the file for line in lines: # handle correctly a file not terminated with \n, not to # truncate last char if line[-1] == '\n' : line = line[:-1] handle_line(para, line, converted_lines) # handle the last paragraph properly (termination of the last # paragraph) # check if the last line is not blank, which means that the last # paragraph needs to be copied on the output. line = lines[-1] if not BLANK.match(line): handle_line(para, '', converted_lines) converted_lines = converted_lines[:-1] return converted_lines def main_parseopts(): """ Handle args given in the command line. Return the file name or exit the script if there is none or if a -h, -v or -? was given. -l or --lang can change the LANG_TOKEN used in the output of the script. """ global LANG_TOKEN global TRANSLATOR global VERSION global OUTPUTFILE # Process command line arguments try: optlist, args = getopt.getopt(sys.argv[1:], 'd?hl:v:t:o:',('lang=','version=','translator=','output_file=','h','he lp')) except getopt.error, str: sys.stderr.write('prepare_tex: %s\n' % str) sys.stderr.write(__usage__) sys.exit(-1) for opt in optlist: if opt[0] == '-d': print __version__ print print __doc__ sys.exit(0) elif (opt[0] == '-h') or (opt[0] == '--h') or(opt[0] == '--help') \ or (opt[0] == '-?'): print __usage__ sys.exit(0) elif (opt[0] == '-t') or (opt[0]=='--translator'): TRANSLATOR = opt[1] elif (opt[0] == '-o') or (opt[0]=='--output_file'): OUTPUTFILE = opt[1] elif (opt[0] == '-v') or (opt[0]=='--version'): VERSION = opt[1] elif (opt[0] == '-l') or (opt[0]=='--lang'): LANG_TOKEN = opt[1] if not args: sys.stderr.write\ ('\nError: prepare_tex: You must pass at least one Latex file.\n') sys.stderr.write(__usage__) sys.exit(1) else: return args[0] def run(): global TRANSLATOR global VERSION global OUTPUTFILE global LANG_TOKEN inputfile = main_parseopts() if not LANG_TOKEN: LANG_TOKEN = raw_input('Language: [FR] ') if not LANG_TOKEN: LANG_TOKEN = "FR" if not VERSION: VERSION = raw_input\ ('Release of the original on which you apply the translation: [2.0]? ') if not VERSION: VERSION = "2.0" if not TRANSLATOR: TRANSLATOR = raw_input('Your name: ') if not TRANSLATOR: TRANSLATOR = "Unknown" lines = open(inputfile).readlines() # if the file is empty, need to do nothing if lines : res = prepare_para_orig_tex(lines) if not OUTPUTFILE: OUT = sys.stdout else: OUT = open(OUTPUTFILE,'w') for line in res : OUT.write(line) if __name__=='__main__': run() # $Log: prepare_tex.py,v $ # Revision 1.5 2000/10/24 20:25:25 olberger # Typo et correction mineure # # Revision 1.4 2000/10/24 14:36:14 olberger # Ajout version améliorée encore par Régis Leroy # # Revision 1.3 2000/10/23 21:45:32 olberger # Intégration des contributions de Régis Leroy # # Revision 1.1.2.1 2000/10/23 21:00:30 olberger # Intégration contribution Regis Leroy basé sur révision 1.1 # # Revision 1.2 2000/10/23 20:36:08 olberger # Intégration V1.2 d'Odile # # Revision 1.1 2000/10/18 17:45:45 olberger # Ajout scripts pour gestion des commentaires dans les documents traduits # -- "Faites des phrases courtes. Un sujet, un verbe, un complément. Quand vous voudrez ajouter un adjectif, vous viendrez me voir." - Georges Clemenceau, 1841-1929, médecin et homme politique français. Consignes aux journalistes de "L'Aurore". d'après From ranch1@earthlink.net Sat Nov 25 14:12:06 2000 From: ranch1@earthlink.net (Tom Fetherston) Date: Sat, 25 Nov 2000 09:12:06 -0500 Subject: [Pythonmac-SIG] Indentation Styles Message-ID: Hi all, Having opened a few of the files in the distribution, it seems to me that the indenting of statements is using "only-tabs" style, is this (or should this be) the default behavior on the Mac? Some of the contributions use the "all-spaces" form of indentation, but that seems to be just the their preference. Does ide/idle have one of this set as the default? There is a "Warn about inconsistent tab usage" check box in the pythonInterpreter run options dialog, could someone elaborate on what python does to check this (and/or point me to module that does this if it isn't hard coded in C?). I tried the above with what I thought should have been legal indenting -- "unix-like" where one indent is four spaces, multiple indents are made up of tabs (equivalent to eight spaces) for the even portion of the indent, and an actual four spaces make up the the odd remainder (if any). Seems that the above setting complained about this. I'm looking at all this to set up how my editor handles python files. I figure that I should make the default behavior be to have all file with mac line endings use tabs for indentation, and have tabs display as the equivalent of four spaces. Opening files with other styles/line-endings that have consistant indentation would present a dialog asking if you wish to convert them. Inconsistant styles would just open with a warning fix the indentation. To simplfy things for those working on files that are intended for other systems, the path name will be parsed, and if one of the folders is the path is either "unix" or "ibm" then the defualt behavoir will be over-riden, and the file will open for editing in that style/line-endings. What should the default style be for ibm stuff. Any comments or suggestion would be appreciated. Tom From fgranger@altern.org Sat Nov 25 16:42:55 2000 From: fgranger@altern.org (Francois Granger) Date: Sat, 25 Nov 2000 17:42:55 +0100 Subject: [Pythonmac-SIG] Indentation Styles In-Reply-To: References: Message-ID: At 9:12 -0500 25/11/00, in message [Pythonmac-SIG] Indentation Styles, Tom Fetherston wrote: >Having opened a few of the files in the distribution, it seems to me that >the indenting of statements is using "only-tabs" style, is this (or should >this be) the default behavior on the Mac? Some of the contributions use >the "all-spaces" form of indentation, but that seems to be just the their >preference. I use only tab in my own scripts. I never understood why to use spaces because you need four char instead of one and this lend to easy errors. For foreign script I receive, either they run "out of the box", or, if I need to edit them, I first do a search and replace of spaces for tab before editing. I uses Pepper as my main editor. -- http://francois.granger.free.fr/MacPython/ From jack@oratrix.nl Sun Nov 26 21:35:03 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 26 Nov 2000 22:35:03 +0100 Subject: [Pythonmac-SIG] Indentation Styles In-Reply-To: Message by Tom Fetherston , Sat, 25 Nov 2000 09:12:06 -0500 , Message-ID: <20001126213508.5C1B41301EF@oratrix.oratrix.nl> The Official Python Way is to use spaces for indentation, because Guido says so. However, Just and myself being the people we are, and both abhorring spaces used in places where tabs should be used have so far refrained from converting te Mac-specific parts of MacPython, so these are still tab-indented. And the contributions will follow either the space or the tab-convention, depending on the taste of the contributor. We should really adopt the official python convention, but I'm rather reluctant to do so. I mainly use BBEdit for my editing, and while it has the "auto-convert tabs to spaces" option this is only half the job, I want to have an easier way of undenting that typing four backspaces. Moreover, selecting a whole line is a pain in the behind, because my hand consistently seems to manage to miss the first space on the line:-( -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From ranch1@earthlink.net Sun Nov 26 23:10:18 2000 From: ranch1@earthlink.net (Tom Fetherston) Date: Sun, 26 Nov 2000 18:10:18 -0500 Subject: [Pythonmac-SIG] BBedit questions Message-ID: Hi, in a reply on the "indentation Styles" thread, Jack Jansen said: >We should really adopt the official python convention, but I'm rather >reluctant to do so. I mainly use BBEdit for my editing, and while it >has the "auto-convert tabs to spaces" option this is only half the >job, I want to have an easier way of undenting that typing four >backspaces. Moreover, selecting a whole line is a pain in the behind, >because my hand consistently seems to manage to miss the first space >on the line:-( This brings up some questions regarding BBedit and python (it's not my editor). How does BBedit integrate with Python these days. Does it still use "PythonSlave.py"? The version in the 2.0 distribution has a mistake that stopped me for a while: import Types should be: import types to work. If it uses some other hook into Python I'd like to know about it. Any other functionality that it provides with respect to Python? Any cool things you'd like to see? Tom From ranch1@earthlink.net Sun Nov 26 23:11:00 2000 From: ranch1@earthlink.net (Tom Fetherston) Date: Sun, 26 Nov 2000 18:11:00 -0500 Subject: [Pythonmac-SIG] Indentation Styles Message-ID: >The Official Python Way is to use spaces for indentation, because >Guido says so. However, Just and myself being the people we are, and >both abhorring spaces used in places where tabs should be used have so >far refrained from converting te Mac-specific parts of MacPython, so >these are still tab-indented. And the contributions will follow either >the space or the tab-convention, depending on the taste of the >contributor. Does that mean that unix-like 8-space-equivalent-tabs mixed with four spaces (when needed) is completely depreciated? That would explain the interpreter warnings. Tom From sdm7g@virginia.edu Mon Nov 27 03:15:50 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Sun, 26 Nov 2000 22:15:50 -0500 (EST) Subject: [Pythonmac-SIG] Carbon modules (for OSX and also OS8|9) Message-ID: I've read the man pages for ld several times, tried several combinations of linker switches, and asked for help on macosx-dev list, but I haven't found a way around the cross-reference problem with the Carbon modules on OSX. ( One problem: there's a difference between a -dylib (shared library) and a -bundle (loadable module -- which is how the python dynamically loadable modules are built on OSX) but that difference doesn't seem to be documented. The workaround which I've tried is to make a Carbonmodule, which is linked to all of the other modules -- all the toolbox symbols are resolved in one dynamic bundle -- which contains all of the toolbox modules: #include "Python.h" #include "pymactoolbox.h" static PyMethodDef CarbonMethods[] = { {NULL, NULL} /* sentinal */ }; void initCarbon() { PyObject *m; int status; m = Py_InitModule("Carbon",CarbonMethods ); (void) initWin(); (void) initMenu(); (void) initEvt(); (void) initDlg(); (void) initCtl(); (void) initQd(); (void) initRes(); ... etc ... The init*'s put the modules into the sys.modules table, so that after 'import Carbon', 'import Win' or whatever will bring that module into the namespace without needing to load a separate .so module. Adding the following macro: #define ADD_MODULE(x) if (-1 == \ PyModule_AddObject( m, (x), PyImport_ImportModule((x)))) return NULL And a series of lines, for example: ADD_MODULE("Win") after the initWin(); will put those modules into the Carbonmodule namespace. You can then do "from Carbon import Win" or "from Carbon import *" This makes things slightly more source incompatible from "classic" MacPython than just having to do the 'import Carbon' first. However: I wonder if having a Carbon module for MacOS8|9 doesn't make sense. i.e. having both a "classic" Win mac toolbox module, and a CarbonLib based Carbon.Win. CarbonLib, while adding some of it's own incompatabilities, at least also bundles up a whole lot of OS version and Gestalt possibilities into one piece. ( i.e. OS8.5 toolbox additions, 9.0 additions, Appearance Manager, etc. ). From what I recall of previous discussions, this is just what we were asking for -- rather than doing Gestalt calls to test for each feature, or calling toolbox routines which may turn out to be unsupported, as simple distinction: is all the new stuff supported? Anyone have any thoughts on this matter ? BTW: With the above Carbon modules, there are still some incompatabilities, for example I haven't tried porting macosmodule yet, so EasyDialogs and others (I would guess Framework and IDE) won't run yet. ---| 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 operating systems want to be unix, All programming languages want to be lisp." From jack@oratrix.nl Mon Nov 27 09:31:50 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 27 Nov 2000 10:31:50 +0100 Subject: [Pythonmac-SIG] Carbon modules (for OSX and also OS8|9) In-Reply-To: Message by "Steven D. Majewski" , Sun, 26 Nov 2000 22:15:50 -0500 (EST) , Message-ID: <20001127093151.3303135BB03@snelboot.oratrix.nl> The Carbon.Win problem can easily be solved in a backward compatible way by having a wrapper module Win.py that contains nothing more than "from Carbon.Win import *". -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tom@othermedia.com Mon Nov 27 10:20:01 2000 From: tom@othermedia.com (tom smith) Date: Mon, 27 Nov 2000 10:20:01 +0000 Subject: [Pythonmac-SIG] ODBC plea?! In-Reply-To: Message-ID: hi all, this is just a request. Has anyone out there got an ODBC database going (or heard of somebody getting one going) and connecting to python? I just need to know if it's remotely possible. thanks anyone... tom. I've tried FileMaker (I suspect the odbc drivers are dodgy). I'm trying Omnis-Studio, in the past I've tried dtF...I may look at Primebase, though I'd had to write python drivers.... From i2eye@mac.com Mon Nov 27 13:47:38 2000 From: i2eye@mac.com (Beatrice Beaubien) Date: Mon, 27 Nov 2000 08:47:38 -0500 Subject: [Pythonmac-SIG] ODBC plea?! In-Reply-To: References: Message-ID: Hello Tom, >hi all, > >this is just a request. Has anyone out there got an ODBC database going (or >heard of somebody getting one going) and connecting to python? > >I just need to know if it's remotely possible. I have no idea but I am fascinated by the possibilities. Please post to the list if you find anything. >thanks anyone... > >tom. > >I've tried FileMaker (I suspect the odbc drivers are dodgy). I'm trying >Omnis-Studio, in the past I've tried dtF...I may look at Primebase, though >I'd had to write python drivers.... I believe the ODBC command set supported by the FMP drivers is extremely limited. If you haven't already, you might want to get in touch with Branko Rumora (, http://www.rumora.nl) who knows more about ODBC and FMP than most, and writes ODBC drivers for the Mac platform. I hope this is helpful. Biti From sdm7g@virginia.edu Mon Nov 27 18:43:35 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Mon, 27 Nov 2000 13:43:35 -0500 (EST) Subject: [Pythonmac-SIG] Carbon modules (for OSX and also OS8|9) In-Reply-To: <20001127093151.3303135BB03@snelboot.oratrix.nl> Message-ID: On Mon, 27 Nov 2000, Jack Jansen wrote: > The Carbon.Win problem can easily be solved in a backward compatible way by > having a wrapper module Win.py that contains nothing more than "from > Carbon.Win import *". That's one good way around the compatability problem. Once Carbon has been imported, the toolbox modules are also in the sys.modules list, so 'import Win' , etc. all work once Carbon has been imported. So another way would be to stick 'import Carbon' into site.py or some other convenient place. But the other question was whether it might be a good idea NOT to hide the packaging. Two things come to mind: [1] Possible Module name clashes -- This hasn't been a problem before as whether you're on MacOS or Windows, you don't really care if the other platform has a 'Win' module or a ColorPicker. But Darwin/OSX already has (very alpha) support for Carbon-mactoolbox, AppKit, Tkinter, PyGtk ... ( maybe WxWindows will be next; I have Qt libs for Darwin, but I haven't tried to build anything with it yet. X11 and Motif interfaces should probably build, but it's not something I've tried. ) Both Carbon and AppKit have a ColorPicker, and I wouldn't be surprised if a few others did. [2] Migration path to Carbon on OS on MacOS[89].* We had some previous discussions on pythonmac-sig about Appearance Mgr and some of the new manager interfaces introduced in 8.5 and 9.0, and how to manage using those without having to use a lot of Gestalt calls as in C. You could never just rely on the OS version, as a lot of those new features could be retro-fit to older systems with system extensions. CarbonLib wraps up most of those new features into a single extension, but it also deprecates or eliminates quite a few things. I don't think in current MacPython, there is a good guide to targeting exactly which systems will be supported by a python program. I think all you have is runtime checks. ( I suppose "import App" fails if you don't have a system with Appearance Manager support, but what about some of the new functions added to old managers. In the other direction: if you try to use non-Carbon toolbox functions on OSX, it should either not load or crash -- probably depending on how it was linked. ) I was suggesting that it might be a good idea for "classic" MacPython to have both classic and carbon versions of toolbox routines. It wouldn't solve the MacOS system versioning problem, but it would simplify it to two cases. ---| 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 operating systems want to be unix, All programming languages want to be lisp." From sdm7g@virginia.edu Mon Nov 27 18:54:18 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Mon, 27 Nov 2000 13:54:18 -0500 (EST) Subject: [Pythonmac-SIG] Re: Where are you with Carbonized Python Mac Modules? In-Reply-To: <3A174427.4D950FD6@pacbell.net> Message-ID: MacOSX Python Carbon toolbox Progress Report: Python 2.0 (#7, 11/17/00, 16:20:11) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> import Carbon >>> dir(Carbon) ['AE', 'App', 'Cm', 'ColorPicker', 'Ctl', 'Dlg', 'Drag', 'Evt', 'Fm', 'Icn', 'List', 'Menu', 'Qd', 'Res', 'TE', 'Win', '__doc__', '__file__', '__name__'] >>> Hardly any of that has been tested -- I've put up a window and tried catching some events -- that is just what's compiled, linked and loaded without complaining about unresolved symbols. I still have some problems with Scrap, Qt and MacOS modules. Not having MacOS is what prevents some of the higher level scripts ( I've been using EasyDialogs.py as a test target, but I'm sure Framework and others break on the same things. ) ---| 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 operating systems want to be unix, All programming languages want to be lisp." From cbarker@jps.net Mon Nov 27 23:10:44 2000 From: cbarker@jps.net (Chris Barker) Date: Mon, 27 Nov 2000 15:10:44 -0800 Subject: [Pythonmac-SIG] Indentation Styles References: Message-ID: <3A22E9F4.C29EB85A@jps.net> Francois Granger wrote: > For foreign script I receive, either they run "out of the box", or, > if I need to edit them, I first do a search and replace of spaces for > tab before editing. I uses Pepper > as my main editor. Be Careful! If you do that search and replace with a file that has mixed spaces and tabs, you will get a real mess! That's why I use the script that I posted earlier to convert my files. It uses the Python tokenizer to interpret the indenting, so I am guaranteed to get the same thing that the interpreter would get. As Jack said, using spaces is harder than tabs, at least on the Mac. What we need are smarter editors. Pepper has promise. I'd like to see what it can do with the space/tab thing. On Linux, I use emacs, and emacs python-mode can be set to put in tabs, spaces, or a mixture. It used to be that the mixture was the default, which is why so many files had it! In all the language modes Ive used with emacs, the tab key is mapped to the "indent this line" function, and the delete key gets mapped to "remove one level of indentation" when it's in the whitespace at the beginning of a line. This level of abstraction makes it easy to use any indentation style you want. So, while it still seems silly to use four bytes where one would do, it is not any harder to do, if you have a smart enough editor. Are any Mac editors smart enough to be set up to be used this way? I'd love to have that. -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From vincem@en.com Tue Nov 28 03:15:02 2000 From: vincem@en.com (Vincent Marchetti) Date: Mon, 27 Nov 2000 22:15:02 -0500 Subject: [Pythonmac-SIG] Re: Fix for time in 1.5.2c1 Message-ID: Russell Owen wrote: ------------------------------- I'm just starting to try to read file creation times and things aren't working as expected. For a file created Jul 5, 2000: >>> ap = "RussMain:Desktop Folder:test" >>> ct = os.stat(ap)[stat.ST_CTIME] >>> ct 3045641098.0 >>> time.localtime(ct) (1996, 7, 6, 11, 24, 58, 5, 188, -1) >>> time.gmtime(ct) (1996, 7, 6, 19, 24, 58, 5, 188, -1) I looked back and found a discussion that was probably about this same problem, but no solution. Any suggested patches? ... ----------------------------------- It was unclear from the post whether you knew that this problem was fixed in Python 2.0, (it is), but apparently you can't use 2.0 because of Tk problems. The solution is to add to the 'ct' variable the number of seconds in 4 years (i.e. 4 * 365 *24 *60 *60) Apparently, the "stat" clock is starting at Jan 1, 1904, while the time.localtime conversion is assuming a start date of Jan 1, 1900. Vince Marchetti From fgranger@altern.org Tue Nov 28 09:24:41 2000 From: fgranger@altern.org (Francois Granger) Date: Tue, 28 Nov 2000 10:24:41 +0100 Subject: [Pythonmac-SIG] Indentation Styles In-Reply-To: <3A22E9F4.C29EB85A@jps.net> Message-ID: on 28/11/00 0:10, Chris Barker at cbarker@jps.net wrote: > So, while it still seems silly to > use four bytes where one would do, it is not any harder to do, if you > have a smart enough editor. Are any Mac editors smart enough to be set > up to be used this way? I'd love to have that. There is an Emacs KeyBinding for Pepper. I've never used it. -- Digital Printing Systems Informations Subscribe: dpsi-subscribe@onelist.com http://www.onelist.com/community/dpsi From tom@othermedia.com Tue Nov 28 09:43:33 2000 From: tom@othermedia.com (tom smith) Date: Tue, 28 Nov 2000 09:43:33 +0000 Subject: [Pythonmac-SIG] general modules question In-Reply-To: Message-ID: hi all, I'm writing an app where python files get loaded and sent a "run() message by a simple queue-app (python file). Is there a way to... a. Set a flag so that when files are imported they are always reloaded. b. For a module to "inherit" loaded modules (and reload) them? At the moment every python file has... import toms_utils, toms_db, toms_time reload(toms_utils) reload(toms_db) reload(toms_time) ...partly because the files mentioned aren't finished yet... ideas? thanks tom From tom@othermedia.com Tue Nov 28 09:58:30 2000 From: tom@othermedia.com (tom smith) Date: Tue, 28 Nov 2000 09:58:30 +0000 Subject: [Pythonmac-SIG] Indentation Styles In-Reply-To: <3A22E9F4.C29EB85A@jps.net> Message-ID: on 27/11/00 11:10 pm, Chris Barker at cbarker@jps.net wrote: > Be Careful! If you do that search and replace with a file that has mixed > spaces and tabs, you will get a real mess! That's why I use the script > that I posted earlier to convert my files I looked in my pythonMac folder and couldn't find the script you mention, could you post it again please? thanks tom p.s I'm unclear about how python uses tabs and spaces differently on macs and pcs....could someone write a 1 sentence explanation. I'm in the awkward position of having files whose indentation can only be acheived by copying and pasting the indentation....would the script fix this.... I move the files between mac and pc a lot From jack@oratrix.nl Tue Nov 28 13:51:47 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 28 Nov 2000 14:51:47 +0100 Subject: [Pythonmac-SIG] Carbon modules (for OSX and also OS8|9) In-Reply-To: Message by "Steven D. Majewski" , Mon, 27 Nov 2000 13:43:35 -0500 (EST) , Message-ID: <20001128135147.A10EB35BB03@snelboot.oratrix.nl> > But the other question was whether it might be a good idea NOT to > hide the packaging. Two things come to mind: > > [1] Possible Module name clashes -- > ... You're absolutely right. Let's leave the modules in the Carbon package (and then it's a question whether we should put them in sys.modules, I think not). It's much cleaner. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From cbarker@jps.net Tue Nov 28 18:07:51 2000 From: cbarker@jps.net (Chris Barker) Date: Tue, 28 Nov 2000 10:07:51 -0800 Subject: [Pythonmac-SIG] Indentation Styles References: Message-ID: <3A23F477.D28CBB2C@jps.net> This is a multi-part message in MIME format. --------------EEA524229073D82538A170DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit tom smith wrote: > I looked in my pythonMac folder and couldn't find the script you mention, > could you post it again please? > p.s I'm unclear about how python uses tabs and spaces differently on macs > and pcs....could someone write a 1 sentence explanation. Python uses tabs and spaces exactly the same on all platforms. The problem is that differrent editors use tabs differently. The Unix standard is for a tab to equal eight spaces, so Guido hard coded this into Python, so that you could use a mix of tabs and spaces for indenting. I belive the mixture has now been deprecated, and the new "standard", at least for library files, is to use only spaces. Since mixed tabs and spaces were allowed, the emacs mode for Python used the mixture by default (it can be set to do whatever you want). As a result there used to be a lot of files that used this scheme: a single level indent was four spaces, two levels are a tab, three a tab and then four spaces, etc. This would work and look fine in any editor that displayed a tab as eight spaces, but would be a mess on an editor with a different number of spaces per tab. Since the MacPython IDE, and every other Mac editor that I use make it much easier to indent with only tabs, that's what I use as my standard, and I have set up emacs on my linux box to do that also, since I have done that I have ceased having problems. When I get a file from someone else, the first thing I do is run it through the following script, it can be set to convert to any of the standard conventions. NOTE: if someone wants to build this, or something like it, into the IDE, that would be great! -Chris #!/usr/bin/python import tokenize import string TABSONLY = 'TABSONLY' SPACESONLY = 'SPACESONLY' MIXED = 'MIXED' class PyText: def __init__(self, fnm, optdict): self.optdict = optdict self.fnm = fnm self.txt = open(self.fnm, 'r').readlines() self.indents = [(0, 0, )] self.lnndx = 0 self.indentndx = 0 def getline(self): if self.lnndx < len(self.txt): txt = self.txt[self.lnndx] self.lnndx = self.lnndx + 1 else: txt = '' return txt def tokeneater(self, type, token, start, end, line): if type == tokenize.INDENT: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, start[0]-1) self.indents.append((lvl+1, start[0]-1,)) elif type == tokenize.DEDENT: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, start[0]-1) self.indents.append((lvl-1, start[0]-1,)) elif type == tokenize.ENDMARKER: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, len(self.txt)) def split(self, ln): content = string.lstrip(ln) if not content: return ('', '\n') lead = ln[:len(ln) - len(content)] lead = string.expandtabs(lead) return (lead, content) def process(self): style = self.optdict.get('style', TABSONLY) indent = string.atoi(self.optdict.get('indent', '4')) tabsz = string.atoi(self.optdict.get('tabs', '8')) print 'file %s -> style %s, tabsize %d, indent %d' % (self.fnm, style, tabsz, indent) tokenize.tokenize(self.getline, self.tokeneater) #import pprint #pprint.pprint(self.indents) new = [] for (lvl, s, e) in self.indents: if s >= len(self.txt): break if s == e: continue oldlead, content = self.split(self.txt[s]) #print "oldlead", len(oldlead), `oldlead` if style == TABSONLY: newlead = '\t'*lvl elif style == SPACESONLY: newlead = ' '*(indent*lvl) else: sz = indent*lvl t,spcs = divmod(sz, tabsz) newlead = '\t'*t + ' '*spcs new.append(newlead + content) for ln in self.txt[s+1:e]: lead, content = self.split(ln) #print "lead:", len(lead) new.append(newlead + lead[len(oldlead):] + content) self.save(new) #print "---", self.fnm #for ln in new: # print ln, #print def save(self, txt): bakname = os.path.splitext(self.fnm)[0]+'.bak' print "backing up", self.fnm, "to", bakname #print os.getcwd() try: os.rename(self.fnm, bakname) except os.error: os.remove(bakname) os.rename(self.fnm, bakname) open(self.fnm, 'w').writelines(txt) def test(): tc = PyText('test1.py') tc.process() tc = PyText('test1.py') tc.process(style=TABSONLY) tc = PyText('test1.py') tc.process(style=MIXED, indent=4, tabs=8) tc = PyText('test1.py') tc.process(style=MIXED, indent=2, tabs=8) def cleanfile(fnm, d): if os.path.isdir(fnm) and not os.path.islink(fnm): names = os.listdir(fnm) for name in names: fullnm = os.path.join(fnm, name) if (os.path.isdir(fullnm) and not os.path.islink(fullnm)) or \ os.path.normcase(fullnm[-3:]) == ".py": cleanfile(fullnm, d) return tc = PyText(fnm, d) tc.process() usage="""\ %s [options] [path...] options -T : reformat to TABS ONLY -S : reformat to SPACES ONLY ( -i option is important) -M : reformat to MIXED SPACES / TABS ( -t and -i options important) -t : tab is worth characters -i : indents should be characters -h : print this text path is file or directory """ if __name__ == '__main__': import sys, getopt, os opts, args = getopt.getopt(sys.argv[1:], "TSMht:i:") d = {} print `opts` for opt in opts: if opt[0] == '-T': d['style'] = TABSONLY elif opt[0] == '-S': d['style'] = SPACESONLY elif opt[0] == '-M': d['style'] = MIXED elif opt[0] == '-t': d['tabs'] = opt[1] elif opt[0] == '-i': d['indent'] = opt[1] elif opt[0] == '-h': print usage % sys.argv[0] sys.exit(0) if not args: print usage % sys.argv[0] for arg in args: cleanfile(arg, d) -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ --------------EEA524229073D82538A170DD Content-Type: text/plain; charset=us-ascii; name="Py_to_tabs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Py_to_tabs" #!/usr/bin/python import tokenize import string TABSONLY = 'TABSONLY' SPACESONLY = 'SPACESONLY' MIXED = 'MIXED' class PyText: def __init__(self, fnm, optdict): self.optdict = optdict self.fnm = fnm self.txt = open(self.fnm, 'r').readlines() self.indents = [(0, 0, )] self.lnndx = 0 self.indentndx = 0 def getline(self): if self.lnndx < len(self.txt): txt = self.txt[self.lnndx] self.lnndx = self.lnndx + 1 else: txt = '' return txt def tokeneater(self, type, token, start, end, line): if type == tokenize.INDENT: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, start[0]-1) self.indents.append((lvl+1, start[0]-1,)) elif type == tokenize.DEDENT: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, start[0]-1) self.indents.append((lvl-1, start[0]-1,)) elif type == tokenize.ENDMARKER: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, len(self.txt)) def split(self, ln): content = string.lstrip(ln) if not content: return ('', '\n') lead = ln[:len(ln) - len(content)] lead = string.expandtabs(lead) return (lead, content) def process(self): style = self.optdict.get('style', TABSONLY) indent = string.atoi(self.optdict.get('indent', '4')) tabsz = string.atoi(self.optdict.get('tabs', '8')) print 'file %s -> style %s, tabsize %d, indent %d' % (self.fnm, style, tabsz, indent) tokenize.tokenize(self.getline, self.tokeneater) #import pprint #pprint.pprint(self.indents) new = [] for (lvl, s, e) in self.indents: if s >= len(self.txt): break if s == e: continue oldlead, content = self.split(self.txt[s]) #print "oldlead", len(oldlead), `oldlead` if style == TABSONLY: newlead = '\t'*lvl elif style == SPACESONLY: newlead = ' '*(indent*lvl) else: sz = indent*lvl t,spcs = divmod(sz, tabsz) newlead = '\t'*t + ' '*spcs new.append(newlead + content) for ln in self.txt[s+1:e]: lead, content = self.split(ln) #print "lead:", len(lead) new.append(newlead + lead[len(oldlead):] + content) self.save(new) #print "---", self.fnm #for ln in new: # print ln, #print def save(self, txt): bakname = os.path.splitext(self.fnm)[0]+'.bak' print "backing up", self.fnm, "to", bakname #print os.getcwd() try: os.rename(self.fnm, bakname) except os.error: os.remove(bakname) os.rename(self.fnm, bakname) open(self.fnm, 'w').writelines(txt) def test(): tc = PyText('test1.py') tc.process() tc = PyText('test1.py') tc.process(style=TABSONLY) tc = PyText('test1.py') tc.process(style=MIXED, indent=4, tabs=8) tc = PyText('test1.py') tc.process(style=MIXED, indent=2, tabs=8) def cleanfile(fnm, d): if os.path.isdir(fnm) and not os.path.islink(fnm): names = os.listdir(fnm) for name in names: fullnm = os.path.join(fnm, name) if (os.path.isdir(fullnm) and not os.path.islink(fullnm)) or \ os.path.normcase(fullnm[-3:]) == ".py": cleanfile(fullnm, d) return tc = PyText(fnm, d) tc.process() usage="""\ %s [options] [path...] options -T : reformat to TABS ONLY -S : reformat to SPACES ONLY ( -i option is important) -M : reformat to MIXED SPACES / TABS ( -t and -i options important) -t : tab is worth characters -i : indents should be characters -h : print this text path is file or directory """ if __name__ == '__main__': import sys, getopt, os opts, args = getopt.getopt(sys.argv[1:], "TSMht:i:") d = {} print `opts` for opt in opts: if opt[0] == '-T': d['style'] = TABSONLY elif opt[0] == '-S': d['style'] = SPACESONLY elif opt[0] == '-M': d['style'] = MIXED elif opt[0] == '-t': d['tabs'] = opt[1] elif opt[0] == '-i': d['indent'] = opt[1] elif opt[0] == '-h': print usage % sys.argv[0] sys.exit(0) if not args: print usage % sys.argv[0] for arg in args: cleanfile(arg, d) --------------EEA524229073D82538A170DD-- From christian@rocketnetwork.com Tue Nov 28 19:04:08 2000 From: christian@rocketnetwork.com (Christian Reyes) Date: Tue, 28 Nov 2000 11:04:08 -0800 Subject: [Pythonmac-SIG] Building PythonMac In-Reply-To: <20001126213508.5C1B41301EF@oratrix.oratrix.nl> Message-ID: Hey Jack, Not sure if you recall the thread we shared last week about the exception handling across code fragments. But I'm still working on the issue and could use some more advice. Right now I'm looking at two alternatives to addressing the problem. My first alternative involves building the 1.5.2 code against the MSL shared runtime dll. But before I attempt that I need to be able to build the distributed source. Which brings me to my first issue. I'm trying to build the 1.5.2 source using Code Warrior 5.3 and am having some difficulty. You were right, most of my problems are from conflicts with the GUSI (2.12) headers and the MSL headers from 5.3. Do you remember what version of CW you used to build the 1.5.2 pythoncore and can you give me some suggestions on how to handle building GUSI? Is there another version of Gusi that might be more agreeable with the CW5.3 MSL headers? My second question is, what version of CW did you use to build the 2.0 source? And would you anticipate the 2.0 release having compile issues with the GUSI headers? Thanks, christian From jack@oratrix.nl Tue Nov 28 21:32:55 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 28 Nov 2000 22:32:55 +0100 Subject: [Pythonmac-SIG] Re: Building PythonMac In-Reply-To: Message by "Christian Reyes" , Tue, 28 Nov 2000 11:04:08 -0800 , Message-ID: <20001128213300.DCE621301E7@oratrix.oratrix.nl> Recently, "Christian Reyes" said: > Hey Jack, > Not sure if you recall the thread we shared last week about the exception > handling across code fragments. But I'm still working on the issue and > could use some more advice. Right now I'm looking at two alternatives to > addressing the problem. My first alternative involves building the 1.5.2 > code against the MSL shared runtime dll. But before I attempt that I need > to be able to build the distributed source. Which brings me to my first > issue. > I'm trying to build the 1.5.2 source using Code Warrior 5.3 and am having > some difficulty. > You were right, most of my problems are from conflicts with the GUSI (2.12) > headers and the MSL headers from 5.3. > Do you remember what version of CW you used to build the 1.5.2 pythoncore > and can you give me some suggestions on how to handle building GUSI? Is > there another version of Gusi that might be more agreeable with the CW5.3 > MSL headers? It is long ago, so I'm not 100% sure what I say here is correct, but I think that 1.5.2 was built with CW Pro 5.0 or 5.1. The :Mac:Demo:building.html document should have the details. I used a modified CWGUSI 1.5.2, which you can still find on the ftp site, in ftp://ftp.cwi.nl/pub/jack/python/mac/old . > My second question is, what version of CW did you use to build the 2.0 > source? And would you anticipate the 2.0 release having compile issues with > the GUSI headers? The 2.0 source distribution should build with CW Pro 5.3 and GUSI 2.1.1. Building with CW Pro 6 shouldn't be much of a problem, except for GUSI. You'll need a modified GUSI 2.1.3. I'll put one up on the ftp site later tonight. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From redbird@rbisland.cx Wed Nov 29 00:11:22 2000 From: redbird@rbisland.cx (Gordon Worley) Date: Tue, 28 Nov 2000 19:11:22 -0500 Subject: [Pythonmac-SIG] Indentation Styles In-Reply-To: <3A22E9F4.C29EB85A@jps.net> References: <3A22E9F4.C29EB85A@jps.net> Message-ID: At 3:10 PM -0800 11/27/2000, Chris Barker wrote: >have a smart enough editor. Are any Mac editors smart enough to be set >up to be used this way? I'd love to have that. Yes, there are. There is a version of Emacs for Classic Mac OS (I'm not sure about what version or anything like that, I'm a Vim fan), which probably does what you want. Just search for it on and you'll probably find the latest version available. Or, you could just use the Mac OS X version of Python and build the latest emacs release. ;-) -- Gordon Worley http://www.rbisland.cx/ mailto:redbird@rbisland.cx PGP: C462 FA84 B811 3501 9010 20D2 6EF3 77F7 BBD3 B003 From redbird@rbisland.cx Wed Nov 29 00:11:22 2000 From: redbird@rbisland.cx (Gordon Worley) Date: Tue, 28 Nov 2000 19:11:22 -0500 Subject: [Pythonmac-SIG] Indentation Styles In-Reply-To: <3A22E9F4.C29EB85A@jps.net> References: <3A22E9F4.C29EB85A@jps.net> Message-ID: At 3:10 PM -0800 11/27/2000, Chris Barker wrote: >have a smart enough editor. Are any Mac editors smart enough to be set >up to be used this way? I'd love to have that. Yes, there are. There is a version of Emacs for Classic Mac OS (I'm not sure about what version or anything like that, I'm a Vim fan), which probably does what you want. Just search for it on and you'll probably find the latest version available. Or, you could just use the Mac OS X version of Python and build the latest emacs release. ;-) -- Gordon Worley http://www.rbisland.cx/ mailto:redbird@rbisland.cx PGP: C462 FA84 B811 3501 9010 20D2 6EF3 77F7 BBD3 B003 From sdm7g@minsky.med.virginia.edu Thu Nov 30 22:28:59 2000 From: sdm7g@minsky.med.virginia.edu (Steven D. Majewski) Date: Thu, 30 Nov 2000 17:28:59 -0500 (EST) Subject: [Pythonmac-SIG] pyobjc-dev mailing list at SourceForge (fwd) Message-ID: There seems to now be a pyobjc-dev mailing list on SourceForge. http://lists.sourceforge.net/mailman/listinfo/pyobjc-dev Except for the occasional progress report, pyobjc discussion will move there. -- Steve Majewski