From chriss@dnastar.com Sat Jul 1 04:48:18 2000 From: chriss@dnastar.com (Chris) Date: Fri, 30 Jun 2000 22:48:18 -0500 Subject: [Pythonmac-SIG] Shape of Source Tree? Message-ID: Where dose macpython go in the python source tree, that is, is 'python' in macpython's root (':python:mac:') ment to align with the first 'python' in :python:dist:src:Python --like this-- python: dist: Mac: <-- MacPython ***** nondist: --or the 2., giving : python: dist: src: acconfig.h BeOS: config.h.in configure configure.in CVS Demo: Doc: Grammar: Include: install-sh Lib: Makefile.in Misc: Modules: Objects: Parser: PC: PCbuild: Python: atof.c bltinmodule.c ceval.c . . . importdl.c importdl.h Makefile.in Mac: <-- MacPython ***** marshal.c memmove.c modsupport.c mystrtoul.c pyfpe.c . . . thread_sgi.h thread_solaris.h thread_wince.h traceback.c README Tools: nondist: ? From redbird@rbisland.cx Sat Jul 1 14:01:06 2000 From: redbird@rbisland.cx (Gordon Worley) Date: Sat, 01 Jul 2000 09:01:06 -0400 Subject: [Pythonmac-SIG] Problems with shelve Message-ID: Are there any known problems on the Mac with the shelve module? Files seem to be created sporaticaly in either the Python folder or the same folder as the script. Unfortunately, opening files with shelve for reading always looks in the same folder as the script. Maybe I just can't handle the power of shelve? :-) -- - Gordon Worley http://www.rbisland.cx/ mailto:redbird@rbisland.cx From redbird@rbisland.cx Sat Jul 1 14:04:35 2000 From: redbird@rbisland.cx (Gordon Worley) Date: Sat, 01 Jul 2000 09:04:35 -0400 Subject: [Pythonmac-SIG] Wkeys modification Message-ID: Just, In the Wkeys file, is there any reason why clearkey = "\033" is not included? I'm getting tired of implimenting this in each script that needs it. Is it just that when the file was created the keyboard that was used didn't have a clear key? -- - Gordon Worley http://www.rbisland.cx/ mailto:redbird@rbisland.cx From just@letterror.com Sat Jul 1 16:08:58 2000 From: just@letterror.com (Just van Rossum) Date: Sat, 1 Jul 2000 16:08:58 +0100 Subject: [Pythonmac-SIG] Wkeys modification In-Reply-To: Message-ID: At 9:04 AM -0400 01-07-2000, Gordon Worley wrote: >Just, > >In the Wkeys file, is there any reason why > >clearkey = "\033" > >is not included? I'm getting tired of implimenting this in each >script that needs it. Is it just that when the file was created the >keyboard that was used didn't have a clear key? Erm, you mean the key at the top left of the numeric keypad? On my keyboard it says "num verg" which is abbreviated dutch for "num lock". But it does indeed appear to clear things in some apps... I've _never_ used that key -- it's about the cleanest key on my keyboard... I'll add it to Wkeys.py, so look for it in the next release. Just From fgranger@altern.org Sat Jul 1 15:40:00 2000 From: fgranger@altern.org (Francois Granger) Date: Sat, 1 Jul 2000 16:40:00 +0200 Subject: [Pythonmac-SIG] Problems with shelve In-Reply-To: References: Message-ID: At 9:01 -0400 on 1/07/00, in message [Pythonmac-SIG] Problems with shelve, you wrote: >Files seem to be created sporaticaly in either the Python folder or >the same folder as the script. What about giving a full path name ? (code not tested) import os from os.path import * fullFileName = join(split(os.getcwd ())[0], 'filename') -- "Computers are like horses; they can sense fear and will act based on that. Or, look at it like this. If you have a premonition of danger, maybe you're right." - Adam Engst From redbird@rbisland.cx Sat Jul 1 15:35:22 2000 From: redbird@rbisland.cx (Gordon Worley) Date: Sat, 1 Jul 2000 10:35:22 -0400 Subject: [Pythonmac-SIG] Wkeys modification In-Reply-To: References: Message-ID: At 4:08 PM +0100 7/1/2000, Just van Rossum wrote: >At 9:04 AM -0400 01-07-2000, Gordon Worley wrote: >>Just, >> >>In the Wkeys file, is there any reason why >> >>clearkey = "\033" >> >>is not included? I'm getting tired of implimenting this in each >>script that needs it. Is it just that when the file was created the >>keyboard that was used didn't have a clear key? > >Erm, you mean the key at the top left of the numeric keypad? On my keyboard >it says "num verg" which is abbreviated dutch for "num lock". But it does >indeed appear to clear things in some apps... I've _never_ used that key -- >it's about the cleanest key on my keyboard... > >I'll add it to Wkeys.py, so look for it in the next release. > >Just On my Mac USB keyboard, the clear key (in the location you describe) is also the num lock key, though managing to activate and deactivate num lock is a bit of a challenge (I think pressing option-clear toggles num lock, but some times it does other weird stuff). -- - Gordon Worley http://www.rbisland.cx/ mailto:redbird@rbisland.cx From sales@lookelu.com Sun Jul 2 03:05:40 2000 From: sales@lookelu.com (The Western Web) Date: Sun, 2 Jul 2000 02:05:40 Subject: [Pythonmac-SIG] The Western Web (Advertisement) Message-ID: <20000702090449.92A3A1CE21@dinsdale.python.org> The Western Web has just finished our new classified ad section. We have added new sections in the classifieds, hay/feed/shavings, livestock, camelids, cattle, deer and elk, poultry, rabbits, sheep, livestock equipment, swine, donkeys, dogs, mules and model horses. Ad Photos, Video and Audio for FREE! http://www.thewesternweb.com The new classified section is automated now and your ads will be posted immediatly. You can also add Multi-Media files (photos, sound and video) on line. This is a free service to you so use it at your will. http://www.westernwebclassified.com We have also finished the Western Web Search Engine, which is solely optimized for the western way of life. Please stop by the search engine add your site. http://www.searchthewesternweb.com Our message board is also now up and running so please use it . http://www.westernmessageboard.com/cgi-bin/Ultimate.cgi Thank you, http://www.thewesternweb.com If you received this message in error please reply to this emal address with the word "remove " in the subject line. From jack@oratrix.nl Mon Jul 3 09:16:47 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 03 Jul 2000 10:16:47 +0200 Subject: [Pythonmac-SIG] Shape of Source Tree? In-Reply-To: Message by Chris , Fri, 30 Jun 2000 22:48:18 -0500 , Message-ID: <20000703081648.48AFE37186E@snelboot.oratrix.nl> > Where dose macpython go in the python source tree, that is, > is 'python' in macpython's root (':python:mac:') > ment to align with the first 'python' in :python:dist:src:Python It should go in the "src", in this example. So, beside the system-independent Modules, Python, Objects, etc. The wording is for python the Mac stuff in a tarball-distribution of Python. I'll put in a note that it is different when you checkout Python from the repository. -- 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 chriss@dnastar.com Tue Jul 4 03:24:38 2000 From: chriss@dnastar.com (Chris) Date: Mon, 3 Jul 2000 21:24:38 -0500 Subject: [Pythonmac-SIG] TARGET_API_MAC_CARBO Message-ID: New versions of Unviersal Headers always define TARGET_API_MAC_CARBON either as '1' or '0'. So at some point MacPython's ubiquitous #ifndef TARGET_API_MAC_CARBON should be grep'd to: #if !TARGET_API_MAC_CARBON Though I don't think there's any particular urgancy in this, I think I was able to do it i one Replace All, or not much more. From owen@astro.washington.edu Wed Jul 5 22:00:45 2000 From: owen@astro.washington.edu (Russell E Owen) Date: Wed, 5 Jul 2000 14:00:45 -0700 Subject: [Pythonmac-SIG] Single character input example: Message-ID: I am trying to code a simple "press any key to continue". I thought: print "press any key to continue" sys.stderr.read(1) would do it, but it doesn't continue until the user types a (no matter how many characters the user types). Am I missing something obvious? Is this a bug in the Mac Python 1.5.2c? By the way, what I'm really trying to do is get the interpreter to pause at the end (until the user is satisfied) and then quit without forcing the user to type ctrl-Q. -- Russell From jack@oratrix.nl Thu Jul 6 09:38:54 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 06 Jul 2000 10:38:54 +0200 Subject: [Pythonmac-SIG] Single character input example: In-Reply-To: Message by Russell E Owen , Wed, 5 Jul 2000 14:00:45 -0700 , Message-ID: <20000706083854.8262D37186E@snelboot.oratrix.nl> > I am trying to code a simple "press any key to continue". I thought: > print "press any key to continue" > sys.stderr.read(1) > would do it, but it doesn't continue until the user types a > (no matter how many characters the user types). Am I missing > something obvious? Is this a bug in the Mac Python 1.5.2c? I/O to stdin/stdout/stderr is always line-based in MacPython, so this won't work. If you really want to do this you could use Evt.WaitNextEvent() with only keyboard events in the mask. > By the way, what I'm really trying to do is get the interpreter to > pause at the end (until the user is satisfied) and then quit without > forcing the user to type ctrl-Q. But what's wrong with >>> print "Type return to exit-" >>> sys.stdin.readline() I don't really see why that is worse than >>> print "Type any key to exit-" >>> lots_of_complicated_code -- 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 lefebvre@med.mcgill.ca Fri Jul 7 14:39:02 2000 From: lefebvre@med.mcgill.ca (Luc Lefebvre) Date: Fri, 07 Jul 2000 09:39:02 -0400 Subject: [Pythonmac-SIG] python extension on MacOS Message-ID: Hi, I am currently looking at various technical options for an upcoming project. --begin-background-- I have some experience at cross platform (linux, MacOS, Windoze) Tcl/Tk development, including Tcl/Tk extension via shared libraries with the help of SWIG. I have been looking at Python and like what I see (including Tkinter, in that it is X-platform and my Tk experience is useful there). --end-background-- In order for choosing Python for this project I would need to be able to extend it (using a shared library? as I have done for Tcl/Tk) in order to interface with some hardware (a data acquisition system). Is there an example project out there of a Python extension for the Mac that I could use (preferably using CodeWarrior for the MacOS) as a template? I also have *very* limited experience with the Python extensions like numpy. Is it feasible to do all of my number crunching (typical would be matrix operations, scaling for plotting purposes) using numpy on the Mac? Are there any plotting extensions for the Mac? Also, with MacOS-X (server?) out there, would I be better off going directly to that and using *nix tools instead? I am currently working through ORA "Learning Python". Any other recommendations? tia ------------------------------- Luc Lefebvre project engineer Aerospace Medical Research Unit McGill University Montreal Canada -----BEGIN PGP PUBLIC KEY BLOCK----- Available upon request or public keyservers. key fingerprint: D2E5 5E35 B910 6F4E 0242 EC63 0FD9 96D0 C7F4 784E -----END PGP PUBLIC KEY BLOCK----- From lefebvre@med.mcgill.ca Fri Jul 7 15:15:48 2000 From: lefebvre@med.mcgill.ca (Luc Lefebvre) Date: Fri, 07 Jul 2000 10:15:48 -0400 Subject: [Pythonmac-SIG] python extension on MacOS Message-ID: Hi, I am currently looking at various technical options for an upcoming project. --begin-background-- I have some experience at cross platform (linux, MacOS, Windoze) Tcl/Tk development, including Tcl/Tk extension via shared libraries with the help of SWIG. I have been looking at Python and like what I see (including Tkinter, in that it is X-platform and my Tk experience is useful there). --end-background-- In order for choosing Python for this project I would need to be able to extend it (using a shared library? as I have done for Tcl/Tk) in order to interface with some hardware (a data acquisition system). Is there an example project out there of a Python extension for the Mac that I could use (preferably using CodeWarrior for the MacOS) as a template? I also have *very* limited experience with the Python extensions like numpy. Is it feasible to do all of my number crunching (typical would be matrix operations, scaling for plotting purposes) using numpy on the Mac? Are there any plotting extensions for the Mac? Also, with MacOS-X (server?) out there, would I be better off going directly to that and using *nix tools instead? I am currently working through ORA "Learning Python". Any other recommendations? tia ------------------------------- Luc Lefebvre project engineer Aerospace Medical Research Unit McGill University Montreal Canada -----BEGIN PGP PUBLIC KEY BLOCK----- Available upon request or public keyservers. key fingerprint: D2E5 5E35 B910 6F4E 0242 EC63 0FD9 96D0 C7F4 784E -----END PGP PUBLIC KEY BLOCK----- From jack@oratrix.nl Fri Jul 7 16:07:44 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 07 Jul 2000 17:07:44 +0200 Subject: [Pythonmac-SIG] python extension on MacOS In-Reply-To: Message by Luc Lefebvre , Fri, 07 Jul 2000 09:39:02 -0400 , Message-ID: <20000707150749.91669E2673@oratrix.oratrix.nl> Recently, Luc Lefebvre said: > In order for choosing Python for this project I would need to be able to > extend it (using a shared library? as I have done for Tcl/Tk) in order to > interface with some hardware (a data acquisition system). Is there an > example project out there of a Python extension for the Mac that I could > use (preferably using CodeWarrior for the MacOS) as a template? Yes, this is pretty easy under MacPython. The standard installer already has the "developer option", install that to get all needed headers and a sample project. This should be enough to develop extensions, otherwise you can always go to source. > I also have *very* limited experience with the Python extensions like > numpy. Is it feasible to do all of my number crunching (typical would be > matrix operations, scaling for plotting purposes) using numpy on the Mac? Probably. > Are there any plotting extensions for the Mac? I think Imaging will do some plotting, but I've never used it. Anyone else know an answer to this? > Also, with MacOS-X (server?) out there, would I be better off going > directly to that and using *nix tools instead? For MacOS X Server: yes, probably. For MaxOS X it is unclear currently whether the best solution will be based on current Unix Python or MacPython. But don't worry, the result will be called MacPython:-) > I am currently working through ORA "Learning Python". Any other > recommendations? Programming Python is good too. -- 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 owen@astro.washington.edu Fri Jul 7 16:37:40 2000 From: owen@astro.washington.edu (Russell E Owen) Date: Fri, 7 Jul 2000 08:37:40 -0700 Subject: [Pythonmac-SIG] python extension on MacOS In-Reply-To: References: Message-ID: >Are there any plotting extensions for the Mac? Packages to look at. I've not used them, so cannot comment on them. MatPy - Matrix package for Python Chris Barker posted the following to this mailing list on April 7: ----- begin excerpt ----- As far as using Python on the Mac for "RAD/experimental tool for numerical programming and scientific work", the real shortcoming is the lack of a scientific plotting package. All the ones that exist are really links to varios plotting packages that araen't available on the Mac. (Dislin, gnuplot, yorick, etc.). The one exception to this is the Piddle/graphite combination. Piddle (Python Interactive Drawing, Does Little Else) is an output-device independent drawing api for python. It allows you to do basic drawing stuff (points, lines polygons, text, etc) the same why for a variety of output modes, including postscriipt, pdf, Apple Quick Draw, tk, wxPython, etc.) Graphite is a graphing package based on PIDDLE, developed by Joe and Michele (I think I got her name right) Strout et. al. I'm not sure about PIDDLE, but development on Graphite seems to have halted development. It's a pretty good start, however. I think you can find it on sourceforge. (http://Graphite.sourceforge.net/) Hey! I hjust took a look, and it looks like there is a new project coordinator, yippie! So, if you need to do any scientific plotting, you will need to put some work into developing the tools as well. I'm intending to do this myself. ----- begin excerpt ----- >I am currently working through ORA "Learning Python". Any other >recommendations? My favorite book, so far, is "Python Essential Reference", by David Beazley. Good solid reference, compact and yet with examples. Also includes a very readable introduction to the language. Only marred by a poor index; I've been annotating mine as I go. "The Quick Python Book" by Harms and McDonald is also good. A slightly odd mix of material, but does a very nice job with the fundamentals. "Python and Tkinter Programming" by John Grayson is presently the only book on Tkinter. The intro is fine but the reference material is weak -- sparse and very difficult to read. Basically it is the on-line Tk documentation edited. The conventions are not explained and a lot of information is buried or missing. For example many methods are said to be inherited from "Widget", but the "Widget" object is never described per se. Also, some important reference information is definitely missing, such as file event handling. Read before you buy; the books I've seen are wildly different and are unlikely to all appeal to you. -- Russell From sdm7g@virginia.edu Fri Jul 7 19:09:04 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Fri, 7 Jul 2000 14:09:04 -0400 (EDT) Subject: [Pythonmac-SIG] python extension on MacOS In-Reply-To: Message-ID: On Fri, 7 Jul 2000, Luc Lefebvre wrote: > In order for choosing Python for this project I would need to be able to > extend it (using a shared library? as I have done for Tcl/Tk) in order to > interface with some hardware (a data acquisition system). At what sort of level is the hardware interfacing ? I have done a Python interface to the MacOS Device Manager routines used for low level read/write/config to a data acq. device's device driver. If your device has MacOS drivers, you could adapt this code. ( This module has not been more widely promoted because, other than using it for serial I/O, it's all pretty device specific what you do with it, plus, most of the really interesting Mac devices all have higher level managers ( SCSI, USB, etc. ) that you would rather use. ) If you want to do I/O register twiddling directly from Python, you can use SWIG's pointer package, or write some C code that wraps the device registers as a struct, and use SWIG to write the code to twiddle the struct elements (registers). > Also, with MacOS-X (server?) out there, would I be better off going > directly to that and using *nix tools instead? OS-X with it's Mach and BSD layers is more suited for real-time prog. in many ways than other Mac OSes. However, you are definitely going to want to go thru a proper device driver. Random bit twiddling in kernel memory is highly discouraged as it defeats the whole purpose of a modern protected kernel OS. Will the hardware vendor support OSX and provide drivers ? If not, the good news is that one of the advantages of the Darwin (OSX) kernel is supposed to be the IOKit and the relative simplicity of writing drivers. ( I've started looking at the documentation on this, but I haven't actually tried it. ) See: especially "Hello Kernel" and "Hello IOKit" -- but read "Kernel Environment" first. The problems with "going directly" are: [1]that OS-X isn't released yet, although you may be able to get DP4 ("Developer Preview 4"), there are rumors of a public beta "this summer", and there is Darwin & XFree86 right now, and [2] Python for OSX or Darwin doesn't yet support all of the cool extensions you would want or need. ( But some of us are working on it, and if that public beta gets released as $free$, then I expect work will really pick up on it.) My advice would probably be to start this on current MacOS using Python, but to read up on OSX and consider what parts are going to need to change for OSX (low level I/O ?), and what parts you may want to change, perhaps to take advantage to Quartz graphics, and use higher level python interfaces to insulate the stuff that's going to change. ---| 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 |--- From w_keller@gmx.de Fri Jul 7 23:26:49 2000 From: w_keller@gmx.de (Wolfgang Keller) Date: Sat, 8 Jul 2000 00:26:49 +0200 Subject: [Pythonmac-SIG] python extension on MacOS In-Reply-To: References: Message-ID: At 8:37 Uhr -0700 07.07.2000, Russell E Owen wrote: >As far as using Python on the Mac for "RAD/experimental tool for >numerical programming and scientific work", the real shortcoming is the >lack of a scientific plotting package. All the ones that exist are >really links to varios plotting packages that araen't available on the >Mac. (Dislin, gnuplot, yorick, etc.). I have seen ports of all Gnuplot and Yorick for the Mac myself, so they _are_ available. In what version and whether the Python modules work is an entirely different issue, however. Wolfgang Keller Zu Risiken und Nebenwirkungen von Junkmail lesen Sie de.admin.net-abuse.mail und fragen sie Ihren Postmaster oder Provider From rbl@hal.cwru.edu Sat Jul 8 01:07:14 2000 From: rbl@hal.cwru.edu (Robin B. Lake) Date: Fri, 7 Jul 2000 20:07:14 -0400 (EDT) Subject: [Pythonmac-SIG] Python Scientific Graphics Message-ID: <200007080007.UAA24124@hal.epbi.cwru.edu> If I'm not mistaken, OpenGL is now supported on the Mac. Would this be a reasonable approach for implementing a scientific graphics package? Rob Lake rbl@hal.cwru.edu From kelvin.chu@uvm.edu Sat Jul 8 03:36:33 2000 From: kelvin.chu@uvm.edu (Kelvin Chu) Date: Fri, 7 Jul 2000 22:36:33 -0400 Subject: [w_keller@gmx.de: Re: [Pythonmac-SIG] python extension on MacOS] Message-ID: <20000707223633.A99482@chipotle.physics.uvm.edu> Hi fellow PythonMac-ers. The problem of a lack of a true cross-platform plotting program is one that has troubled me for a while. My lab has 2 flavors of Unix (IRIX and RedHat), Windows and Macs. The evil windows box is forced upon us because it's the data-taking machine, but it's okay because we aren't forced to do too much computation and analysis on it. I cobbled together a more-or-less okay GUI driven solution by doing TKinter and PMW that drove Gnuplot (yes, there is a version of Gnuplot for the Mac). It isn't satisfactory for really intense use on the Mac, but it works on all 4 platforms. Some things that don't work: ---------------------------- DISLIN is okay on the Linux boxes, and seems to do what it should, but the author wants some outrageous amount of money for the SGI version, and when I last wrote to him, was not at all interested in porting to the Mac - neither MacOS nor the LinuxPPC platform. Too bad for him (and for us, I assume). Yorick works on my G3 (233MHz) powerbook running MacOS 8.1, but is the kiss of death on my iMac (350 MHz) running MacOS 9.0.4. I have been unsuccesful in getting any Gisty stuff to run. If you are committed to the MacOS platform, I think your option is Gnuplot and TKinter. Either that or you start coughing up money for programs like Igor or IDL for the Mac. Running Gist and emulating X using the Mi/X interface is truly painful. Do things look brighter once MacOSX is released? I hope so. Cheers, -k >As far as using Python on the Mac for "RAD/experimental tool for >numerical programming and scientific work", the real shortcoming is the >lack of a scientific plotting package. All the ones that exist are >really links to varios plotting packages that araen't available on the >Mac. (Dislin, gnuplot, yorick, etc.). -- kelvin.chu@uvm.edu (802) 656-0064 http://www.uvm.edu/~kchu/ FAX: (802) 656-0817 From jack@oratrix.nl Sat Jul 8 15:47:50 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 08 Jul 2000 16:47:50 +0200 Subject: [Pythonmac-SIG] Python Scientific Graphics In-Reply-To: Message by "Robin B. Lake" , Fri, 7 Jul 2000 20:07:14 -0400 (EDT) , <200007080007.UAA24124@hal.epbi.cwru.edu> Message-ID: <20000708144756.1B2BCE2679@oratrix.oratrix.nl> Recently, "Robin B. Lake" said: > If I'm not mistaken, OpenGL is now supported on the Mac. Would this > be a reasonable approach for implementing a scientific graphics > package? This is definitely worth looking into! I don't have the time to do it, but if someone gets the Python openGL module working on the Mac I'd love to include it in the distribution... -- 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 Jul 10 10:45:41 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 11:45:41 +0200 Subject: [Pythonmac-SIG] Symantec C compiler Message-ID: <20000710094541.9A02C37186D@snelboot.oratrix.nl> Folks, there are talks in python-dev of cleaning out ifdefs for the Symantec C compiler (__SC__). So, if anyone still uses it: scream loudly now or remain forever silent. -- 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 lefebvre@med.mcgill.ca Mon Jul 10 14:09:12 2000 From: lefebvre@med.mcgill.ca (Luc Lefebvre) Date: Mon, 10 Jul 2000 09:09:12 -0400 Subject: [Pythonmac-SIG] python extension on MacOS In-Reply-To: <20000708160124.A36191CDA5@dinsdale.python.org> References: <20000708160124.A36191CDA5@dinsdale.python.org> Message-ID: Hi Steven, I am contemplating interfacing with a data acquisition card which would have MacOS drivers (National Instruments for example and their Ni-DAQ software libraries for example, which is a project which I have done using Tcl/Tk). I have been messing with the Python extension project bundled with the 1.5.2 distribution for the Mac and it would seem to require a PythonCore library file which I don't seem to have (currently using CodeWarrior V3.1). Also there is a requirement for CWGUSI directory which I don't seem to have in the distribution. There is a reference in the docs to a site where one can get this GUSI but then there is also a GUSI-mods directory with the source. I am not quite sure how all of this fits together. Did I miss something obvious in the documentation? Any further advice would be appreciated. tia >Message: 1 >Date: Fri, 7 Jul 2000 14:09:04 -0400 (EDT) >From: "Steven D. Majewski" >To: Luc Lefebvre >Cc: Pythonmac-SIG@python.org >Subject: Re: [Pythonmac-SIG] python extension on MacOS > > >On Fri, 7 Jul 2000, Luc Lefebvre wrote: > >> In order for choosing Python for this project I would need to be able to >> extend it (using a shared library? as I have done for Tcl/Tk) in order to >> interface with some hardware (a data acquisition system). > >At what sort of level is the hardware interfacing ? >I have done a Python interface to the MacOS Device Manager routines >used for low level read/write/config to a data acq. device's device >driver. If your device has MacOS drivers, you could adapt this code. > >( This module has not been more widely promoted because, other than > using it for serial I/O, it's all pretty device specific what you > do with it, plus, most of the really interesting Mac devices all > have higher level managers ( SCSI, USB, etc. ) that you would rather > use. ) > > >If you want to do I/O register twiddling directly from Python, you >can use SWIG's pointer package, or write some C code that wraps >the device registers as a struct, and use SWIG to write the code >to twiddle the struct elements (registers). > > > > >> Also, with MacOS-X (server?) out there, would I be better off going >> directly to that and using *nix tools instead? > > >OS-X with it's Mach and BSD layers is more suited for real-time prog. >in many ways than other Mac OSes. However, you are definitely going >to want to go thru a proper device driver. Random bit twiddling in >kernel memory is highly discouraged as it defeats the whole purpose >of a modern protected kernel OS. Will the hardware vendor support OSX >and provide drivers ? If not, the good news is that one of the advantages >of the Darwin (OSX) kernel is supposed to be the IOKit and the relative >simplicity of writing drivers. ( I've started looking at the documentation >on this, but I haven't actually tried it. ) > >See: > especially "Hello Kernel" and "Hello IOKit" -- but read "Kernel > Environment" first. > > >The problems with "going directly" are: [1]that OS-X isn't released yet, >although you may be able to get DP4 ("Developer Preview 4"), there >are rumors of a public beta "this summer", and there is Darwin & >XFree86 right now, and [2] Python for OSX or Darwin doesn't yet >support all of the cool extensions you would want or need. >( But some of us are working on it, and if that public beta gets > released as $free$, then I expect work will really pick up on it.) > > >My advice would probably be to start this on current MacOS using >Python, but to read up on OSX and consider what parts are going >to need to change for OSX (low level I/O ?), and what parts you >may want to change, perhaps to take advantage to Quartz graphics, >and use higher level python interfaces to insulate the stuff that's >going to change. > > >---| 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 |--- > > > > -- ------------------------------- Luc Lefebvre project engineer Aerospace Medical Research Unit McGill University Montreal Canada -----BEGIN PGP PUBLIC KEY BLOCK----- Available upon request or public keyservers. key fingerprint: D2E5 5E35 B910 6F4E 0242 EC63 0FD9 96D0 C7F4 784E -----END PGP PUBLIC KEY BLOCK----- From jack@oratrix.nl Mon Jul 10 14:46:54 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 15:46:54 +0200 Subject: [Pythonmac-SIG] python extension on MacOS In-Reply-To: Message by Luc Lefebvre , Mon, 10 Jul 2000 09:09:12 -0400 , Message-ID: <20000710134654.A88DF37186D@snelboot.oratrix.nl> > I am contemplating interfacing with a data acquisition card which > would have MacOS drivers (National Instruments for example and their > Ni-DAQ software libraries for example, which is a project which I > have done using Tcl/Tk). I have been messing with the Python > extension project bundled with the 1.5.2 distribution for the Mac and > it would seem to require a PythonCore library file which I don't seem > to have (currently using CodeWarrior V3.1). PythonCore you have, it's in the main Python folder. The xx project should have been setup in such a way that it finds it automatically, but apparently it didn't? > Also there is a requirement for CWGUSI directory which I don't seem > to have in the distribution. There is a reference in the docs to a > site where one can get this GUSI but then there is also a GUSI-mods > directory with the source. I am not quite sure how all of this fits > together. Did I miss something obvious in the documentation? Any > further advice would be appreciated. Hmm, you're right, building an extension is theoretically dependent on the CWGUSI include files, I never really thought about that. It's only dependent on the include files, the library itself is incorporated in PythonCore. For 99.9% of the extension modules you can get away with removing CWGUSI from the access path in the project. You'll only have problems if you are using I/O calls that are part of GUSI and that are incompatible with their MSL counterparts (or nonexistent in MSL), such as socket, select, stat, threading. -- 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 managan@llnl.gov Mon Jul 10 15:35:43 2000 From: managan@llnl.gov (Rob Managan) Date: Mon, 10 Jul 2000 07:35:43 -0700 Subject: [Pythonmac-SIG] Python Scientific Graphics In-Reply-To: <20000708144756.1B2BCE2679@oratrix.oratrix.nl> References: <20000708144756.1B2BCE2679@oratrix.oratrix.nl> Message-ID: At 4:47 PM +0200 7/8/00, Jack Jansen wrote: >Recently, "Robin B. Lake" said: >> If I'm not mistaken, OpenGL is now supported on the Mac. Would this >> be a reasonable approach for implementing a scientific graphics >> package? > >This is definitely worth looking into! I don't have the time to do it, >but if someone gets the Python openGL module working on the Mac I'd >love to include it in the distribution... >-- I am the guilty party here. When I last looked at it I had a working OpenGL. the downside was that it only worked with GLUT since there is no ToGL module for Tk. -- *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan LLNL ph: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From jack@oratrix.nl Mon Jul 10 15:53:02 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 16:53:02 +0200 Subject: [Pythonmac-SIG] Python Scientific Graphics In-Reply-To: Message by Rob Managan , Mon, 10 Jul 2000 07:35:43 -0700 , Message-ID: <20000710145302.5C55437186E@snelboot.oratrix.nl> > >This is definitely worth looking into! I don't have the time to do it, > >but if someone gets the Python openGL module working on the Mac I'd > >love to include it in the distribution... > > I am the guilty party here. When I last looked at it I had a working > OpenGL. the downside was that it only worked with GLUT since there is > no ToGL module for Tk. Rob Lake just mailed me that he has been looking into OpenGL, but he can't do the development: it turns out that OpenGL needs a new (>=1999) G3 machine with a RAGE card. And he only has a beige G3. So the project is up for grabs again. Also, I don't understand your GLUT to ToGL references. Could you explain a little? -- 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 Mon Jul 10 18:24:16 2000 From: cbarker@jps.net (Chris Barker) Date: Mon, 10 Jul 2000 10:24:16 -0700 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #455 - 5 msgs References: <20000708160123.34F4D1CD96@dinsdale.python.org> Message-ID: <396A06C0.94FAE554@jps.net> Kelvin Chu wrote: > I cobbled together a more-or-less okay GUI driven solution by doing TKinter > and PMW that drove Gnuplot (yes, there is a version of Gnuplot for the > Mac). It isn't satisfactory for really intense use on the Mac, but it > works on all 4 platforms. > > > If you are committed to the MacOS platform, I think your option is > Gnuplot and TKinter. A) Do you have your Python-Gnuplot stuff available anywhere we can get it? B) is the TK stuff needed to use Gnuplot, or is just what you used to create your "GUI-driven" solution. -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From dpennell@guardnet.com Mon Jul 10 18:48:28 2000 From: dpennell@guardnet.com (David Pennell) Date: Mon, 10 Jul 2000 10:48:28 -0700 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #440 - 4 msgs Message-ID: > >In the Perl universe, MacPerl itself presents a similar problem -- it >cannot open Perl applets. ??? You can save a MacPerl script as: - Plain Text - uses MacPerl to run - Runtime Version [aka applet] - runs by itself. Can run on machines without MacPerl installed. ** - CGI script - uses MacPerl to run - Droplet. - uses MacPerl to run All of these can be opened by the MacPerl app. I use Tex-Edit plus, not BBEdit, as my MacPerl editor (because I have built a lot of scripts into TE+). I certainly have never created anything with MacPerl I couldn't open with MacPerl. It shocks me that you think you can't - my question is, which version of MacPerl are you using? I have 5.2 r 4. I think I have only done one upgrade to get here. Anyway, MacPerl is much like AppleScript - except it doesn't have, (so far as I know) the option of saving an unopenable, uneditable copy. In other words, if you send a macperl applet to someone, your code is always accessible. Not necessarily true of an AppleScript. But in both, typically, you can open an app, script, or droplet and save it as an app, script or droplet. >But BBEdit comes to the rescue -- it can >edit Perl applets! Hence one can easily debug, modify and generally >tweak up scripts and only has to keep the one file around. BBEdit can do this, as far as I can tell, because MacPerl saves a complete script + MacPerl core + compiled binary in each applet. Specifically, the binary compiled Perl applet is in the data fork, the resource fork contains a basic MacPerl, and the TEXT resource is the original script. The advantage of Python on the Mac is that a Python applet is smaller and more portable. I do about 10% of my scripting in Python, even though I am more of a perl person, for this very reason. Essentially if you or someone at python central changed the appbuilder applet to add a TEXT resource to the completed applet, containing the main python script, I think it would be easy to write a BBEdit plug-in to load up a python script. Right now, it seems to put a .pyc resource in (called "PYC "), dunno if thats a full pyc or not. If it is,isn't there some way already to decompile in python? If so, instead of looking to BBEdit to do anything, it might be easier to make a python droplet to extract the script from an applet and then feed it to BBEdit. ================ ** Unless you code very carefully to include file manager stuff in your applet's start, you can easily have problems running a MacPerl applet on a computer without MacPerl (specifically, vanilla perl is fine, but you can have troubles with includes. You usually have to send them along, and modify the paths somehow. Furthermore, it's really hard (I have found) to get the autoloader to properly load in something with an .xs, because those are usually compiled on the target machine. David Pennell Audiotex Programmer/Operator The Register-Guard PO Box 10188 Eugene, OR 97440-2188 (541)338-2578 From a.m.ingraldi@larc.nasa.gov Mon Jul 10 19:10:07 2000 From: a.m.ingraldi@larc.nasa.gov (Anthony Ingraldi) Date: Mon, 10 Jul 2000 14:10:07 -0400 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #455 - 5 msgs Message-ID: <200007101810.OAA26444@post.larc.nasa.gov> > B) is the TK stuff needed to use Gnuplot, or is just what you used to > create your "GUI-driven" solution. > You can drive Mac Gnuplot from python via the "standard" Gnuplot.py module. The module is available at http://monsoon.harvard.edu/~mhagger/Gnuplot/Gnuplot.html. The latest version includes support for the Mac. Also, the Mac gnuplot distribution contains a simple console written in python. You can obtain the Mac port of gnuplot at http://users.ece.gatech.edu/~schooley/gnuplot.html. It looks like it hasn't been updated in over 2 years. -- Tony Ingraldi A.M.INGRALDI@LaRC.NASA.GOV Phone : (757) 864-3039 Fax : (757) 864-7892 From dante@oz.net Tue Jul 11 00:39:27 2000 From: dante@oz.net (Michael Esveldt) Date: Mon, 10 Jul 2000 16:39:27 -0700 Subject: [Pythonmac-SIG] Get Info Comments Message-ID: Is it possible to set the Comments section of a file or folders info through python? I went through the macfs module and couldn't see a way to do this. Thanks Michael -- a big sensation/there's orange juice in my vodka/sunny gets sunnier ... Michael Esveldt mailto:dante@oz.net - http://velocity.editthispage.com/ #FightThePower on irc.openprojects.net From lefebvre@med.mcgill.ca Tue Jul 11 18:57:23 2000 From: lefebvre@med.mcgill.ca (Luc Lefebvre) Date: Tue, 11 Jul 2000 13:57:23 -0400 Subject: [Pythonmac-SIG] extending MacPython, feedback In-Reply-To: <20000711160129.E25E91D0FD@dinsdale.python.org> References: <20000711160129.E25E91D0FD@dinsdale.python.org> Message-ID: I thought I would give some feedback to all of the kind folks who gave me some pointers. I tried using modulator and (once I clued in that PythonCore library required by the CW project was the shlb in the distribution, the different icons threw me... , and that I did not need GUSI) it seemed to work fine. I then used a method that I have been using for Tcl/Tk. I wrap the code using SWIG on the Linux side. Move the source and wrap files to the MacOS side, drop them into the project, compile, and voila! Great! On to learning more about Python. thanks again. -- ------------------------------- Luc Lefebvre project engineer Aerospace Medical Research Unit McGill University Montreal Canada -----BEGIN PGP PUBLIC KEY BLOCK----- Available upon request or public keyservers. key fingerprint: D2E5 5E35 B910 6F4E 0242 EC63 0FD9 96D0 C7F4 784E -----END PGP PUBLIC KEY BLOCK----- From dpennell@guardnet.com Tue Jul 11 22:46:08 2000 From: dpennell@guardnet.com (David Pennell) Date: Tue, 11 Jul 2000 14:46:08 -0700 Subject: [Pythonmac-SIG] Python Mac app vs. MacPerl app - a correction Message-ID: I tested it, and actually the TEXT resource in a MacPerl Run-Time Version applet is the whole program, the rest, including the (DATA FORK) is just MacPerl-helper. The only reason i could come up with that Macperl wouldnt open an app is if the source code in the app was too big to edit in macperl, but even then, it should suggest you edit it in your default text editor, and if you click okay, it should spit the source out to that editor, which can indeed be BBEdit, but doesnt have to be. Anyway, a python app for mac is a fancy .pyc - and the fact that its not .py source is good, it gives you the option of sending the source code or not. .py text files arent usually so big its a hassle sending them, surely? DP David Pennell Audiotex Programmer/Operator The Register-Guard PO Box 10188 Eugene, OR 97440-2188 (541)338-2578 From maccgi@bellsouth.net Wed Jul 12 02:51:05 2000 From: maccgi@bellsouth.net (Richard Gordon) Date: Tue, 11 Jul 2000 21:51:05 -0400 Subject: [Pythonmac-SIG] A little x-platform issue... Message-ID: I decided to take a swing at getting the adzapper.py proxy server (based on Medusa) running on a Mac and have stumbled thru various problems but am greatly puzzled by what happens when it hits a line that uses int(time.time()). On the Mac, Python chokes and returns a float overflow (or words to that effect) error, while both mkLinux and OpenBSD don't seem to mind. Exploring this a little further, I see that time.time() returns a value with 3 places to the right of the decimal on the *nix boxes while the Mac returns xxxxxxxxx.0. In my simple world, the Mac's value is already an integer so I just got rid of the int() part only to be foiled by something else later, but I was wondering what the deal is here? Why does this result in a float overflow? The denouement is that I got tired of fighting with this and just set it up on OpenBSD, but I'd still like to know why this happened. Thanks. Richard Gordon -------------------- Gordon Consulting & Design Database Design/Scripting Languages http://www.richardgordon.net From chriss@dnastar.com Wed Jul 12 05:13:51 2000 From: chriss@dnastar.com (Chris) Date: Tue, 11 Jul 2000 22:13:51 -0600 Subject: [Pythonmac-SIG] Python #includes (and such) In-Reply-To: <20000710134654.A88DF37186D@snelboot.oratrix.nl> References: <20000710134654.A88DF37186D@snelboot.oratrix.nl> Message-ID: While you're ANSIfiing the code, there are a few other minor but global issues which you may want to consider. 'TARGET_API_MAC_CARBON' is allways defined (as 1 or 0) since UH3.1 or so switching < #ifdef TARGET_API_MAC_CARBON --- > #if TARGET_API_MAC_CARBON would stop producing stillborn Carbon/Classic chimiras with newer header (& I belive would still work with old ones) Also at UH3.1 we have a soloution to this problem: < #define resNotFound -192 /* Can't include because of Python's "errors.h" */ --- > #include although this wouldn't compile 'out of the box' under older verisons of Universal Headers. Note that apple has also renamed a coluple of other headers which confict with others, though there isn't clear need to switch here. < #include -- > #include < #include -- > #include < #include -- > #include From just@letterror.com Wed Jul 12 08:41:01 2000 From: just@letterror.com (Just van Rossum) Date: Wed, 12 Jul 2000 08:41:01 +0100 Subject: [Pythonmac-SIG] A little x-platform issue... In-Reply-To: Message-ID: At 9:51 PM -0400 11-07-2000, Richard Gordon wrote: >I decided to take a swing at getting the adzapper.py proxy server >(based on Medusa) running on a Mac and have stumbled thru various >problems but am greatly puzzled by what happens when it hits a line >that uses int(time.time()). On the Mac, Python chokes and returns a >float overflow (or words to that effect) error, while both mkLinux >and OpenBSD don't seem to mind. Exploring this a little further, I >see that time.time() returns a value with 3 places to the right of >the decimal on the *nix boxes while the Mac returns xxxxxxxxx.0. In >my simple world, the Mac's value is already an integer so I just got >rid of the int() part only to be foiled by something else later, but >I was wondering what the deal is here? Why does this result in a >float overflow? You get an "OverflowError: float too large to convert" error. I noticed that, too, the last time I played with Medusa. I think in some earlier version of Python, time.time() returned an int, but as MacPython's epoch is at 1900 (unix's is 1970), so a Mac date can't fit in an (signed, 4 byte) int. So to try to convert it to an int anyway is bad, and it's an honest bug in Medusa. Maybe you'd like to report it to Sam Rushing? (Apart from this problem, Medusa runs fine under MacOS.) Just From christian@rocketnetwork.com Thu Jul 13 00:47:29 2000 From: christian@rocketnetwork.com (Christian Reyes) Date: Wed, 12 Jul 2000 16:47:29 -0700 Subject: [Pythonmac-SIG] creating python importable dll's Message-ID: I could really use some help with a project i'm working on. I've been using Phil Thompson's SIP tool to generate python importable dll's on my pc, But my attempts to do the equivalent on the mac have been rather unsuccessful. I'm a novice mac programmer and would like to know if creating wrappers around a C++ dll (or shared library) on the mac is even plausible. Could someone please give me some insight into this? thanks in advance, christian@rocketnetwork.com From jack@oratrix.nl Thu Jul 13 09:37:43 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 13 Jul 2000 10:37:43 +0200 Subject: [Pythonmac-SIG] creating python importable dll's In-Reply-To: Message by Christian Reyes , Wed, 12 Jul 2000 16:47:29 -0700 , Message-ID: <20000713083743.E389737186D@snelboot.oratrix.nl> > I could really use some help with a project i'm working on. I've been using > Phil Thompson's SIP tool to generate python importable dll's on my pc, But > my attempts to do the equivalent on the mac have been rather unsuccessful. > I'm a novice mac programmer and would like to know if creating wrappers > around a C++ dll (or shared library) on the mac is even plausible. Definitely possible, there are numerous ways to do it: 1. Use calldll. This will only work for DLLs that export only routines with integer/float/char/string/etc arguments, but the advantage is that you don't have to build any C code. 2. Use bgen or swig. These are tools that read C/C++ .h header files and produce the C source code for an extension module. Both of these are difficult to use, bgen even more so than swig (but bgen is a lot more powerful than swig, too). But the difficulty is offset by the amount of work: once you get the hang of them you can produce modules with hundreds of methods in a matter of minutes. 3. Use modulator. This will only generate the framework of your module, but for small libraries you want to export to Python the framework is 80% of the code anyway, and implementing 4 or 5 methods in C is a lot less work than getting bgen or swig setup. 4. Write it by hand. For all of these except case 1 you will need a C compiler. CodeWarrior is preferred, but some success for extension modules has been booked with Apple's free MPW C compiler, check out the pythonmac-sig archives for details. Could you tell a bit more about the SIP tool? If it's a nifty idea we should implement something similar for the mac... -- 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 awatson@bigfoot.com Fri Jul 14 08:19:38 2000 From: awatson@bigfoot.com (Andrew Watson) Date: Fri, 14 Jul 2000 15:19:38 +0800 Subject: [Pythonmac-SIG] Lockup sending SMTP to AppleshareIP mail server In-Reply-To: <20000713160128.0CD401CE21@dinsdale.python.org> References: <20000713160128.0CD401CE21@dinsdale.python.org> Message-ID: When I use the SMTP library to send email to an AppleshareIP server running on the same machine, the machine locks up, whereas it works perfectly as long as (mac)python and the mail server are running on seperate machines ( as they are at the moment). Is a) this some known threading issue with a workaround b) me using the SMTP lib wrongly or c) something I just have to live with? Andrew Watson Formsteel. From jack@oratrix.nl Fri Jul 14 12:47:05 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 14 Jul 2000 13:47:05 +0200 Subject: [Pythonmac-SIG] Lockup sending SMTP to AppleshareIP mail server In-Reply-To: Message by Andrew Watson , Fri, 14 Jul 2000 15:19:38 +0800 , Message-ID: <20000714114710.251BC191AA7@oratrix.oratrix.nl> Recently, Andrew Watson said: > When I use the SMTP library to send email to an AppleshareIP server > running on the same machine, the machine locks up, whereas it works > perfectly as long as (mac)python and the mail server are running on > seperate machines ( as they are at the moment). Is a) this some known > threading issue with a workaround b) me using the SMTP lib wrongly or > c) something I just have to live with? Definitely a bug, but I'm not sure where to put the blame. If you have a code fragment that shows the bug, and is small enough to post here please do so, that other people can investigate. I'll dig around my CDs to see whether I have an AppleShareIP SMTP server somewhere (I never bought one, but there may be something on one of my developer CDs). Running the code in verbose mode (hmm, let me check that smtplib has verbose... Yes, call setdebuglevel() with a high value) should also show where exactly things fail. Another thing to try is to download MacPython 1.6alfa from ftp://ftp.cwi.nl/pub/jack/python/mac as this uses a newer I/O library, maybe that makes the problem disappear. -- 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 Fri Jul 14 02:20:32 2000 From: redbird@rbisland.cx (Gordon Worley) Date: Thu, 13 Jul 2000 21:20:32 -0400 Subject: [Pythonmac-SIG] Strange behavior with W Message-ID: In a program I have, I first create a class that inherits from W.Window and can be called Document for our purposes. In the Document, there is an instance of W.List called list. Document sometimes calls a class to edit items in this list called List_Editor. Among other things, List_Editor takes a Document object as an argument. When finishing up, the code that makes the change looks something like this (note: up in __init__, the passed Document is put into self.document): self.document.list[index] = self.w.display.get() Which does what might be expected of it. Yet this next line of code will do the same thing: self.document.w.list[index] = self.w.display.get() Yet Document never creates any object called w, much less put anything in it. While I realize that complaining about my program working isn't necessarily the best thing to do, this behavior, to me at least, does not seem normal. How can this be happening? -- - Gordon Worley http://www.rbisland.cx/ mailto:redbird@rbisland.cx From just@letterror.com Fri Jul 14 19:56:36 2000 From: just@letterror.com (Just van Rossum) Date: Fri, 14 Jul 2000 19:56:36 +0100 Subject: [Pythonmac-SIG] Strange behavior with W In-Reply-To: Message-ID: At 9:20 PM -0400 13-07-2000, Gordon Worley wrote: >In a program I have, I first create a class that inherits from >W.Window and can be called Document for our purposes. In the >Document, there is an instance of W.List called list. Document >sometimes calls a class to edit items in this list called >List_Editor. Among other things, List_Editor takes a Document object >as an argument. When finishing up, the code that makes the change >looks something like this (note: up in __init__, the passed Document >is put into self.document): > >self.document.list[index] = self.w.display.get() > >Which does what might be expected of it. Yet this next line of code >will do the same thing: > >self.document.w.list[index] = self.w.display.get() > >Yet Document never creates any object called w, much less put >anything in it. While I realize that complaining about my program >working isn't necessarily the best thing to do, this behavior, to me >at least, does not seem normal. How can this be happening? So there should be no attribute called 'w'? Are you sure the Document class never assigns to self.w? The W.Window class certianly doesn't: >>> import W >>> w = W.Window((100, 100)) >>> w.open() >>> w.w Traceback (innermost last): File "", line 1, in ? File "DevDev:PyPy:Python current:Mac:Tools:IDE:Wwindows.py", line 406, in __getattr__ raise AttributeError, attr AttributeError: w >>> Any chance you're playing with __getattr__? (W.Window does...) Just From redbird@rbisland.cx Fri Jul 14 23:56:38 2000 From: redbird@rbisland.cx (Gordon Worley) Date: Fri, 14 Jul 2000 18:56:38 -0400 Subject: [Pythonmac-SIG] Strange behavior with W In-Reply-To: References: Message-ID: At 7:56 PM +0100 7/14/2000, Just van Rossum wrote: >At 9:20 PM -0400 13-07-2000, Gordon Worley wrote: >>In a program I have, I first create a class that inherits from >>W.Window and can be called Document for our purposes. In the >>Document, there is an instance of W.List called list. Document >>sometimes calls a class to edit items in this list called >>List_Editor. Among other things, List_Editor takes a Document object >>as an argument. When finishing up, the code that makes the change >>looks something like this (note: up in __init__, the passed Document >>is put into self.document): >> >>self.document.list[index] = self.w.display.get() >> >>Which does what might be expected of it. Yet this next line of code >>will do the same thing: >> >>self.document.w.list[index] = self.w.display.get() >> >>Yet Document never creates any object called w, much less put >>anything in it. While I realize that complaining about my program >>working isn't necessarily the best thing to do, this behavior, to me >>at least, does not seem normal. How can this be happening? > >So there should be no attribute called 'w'? Are you sure the Document class >never assigns to self.w? The W.Window class certianly doesn't: Yes I'm sure. > >>> import W >>>> w = W.Window((100, 100)) >>>> w.open() >>>> w.w >Traceback (innermost last): > File "", line 1, in ? > File "DevDev:PyPy:Python current:Mac:Tools:IDE:Wwindows.py", line 406, >in __getattr__ > raise AttributeError, attr >AttributeError: w >>>> > >Any chance you're playing with __getattr__? (W.Window does...) Nope. Actually, I just tried to reproduce this event again and it didn't work. I get an AttribureError: w if I use the second line of code from above. All I can figure is that restarting my computer did it (I restarted the IDE to see if it would still happen yesterday and it did, but today nothing). Must have been some weirdness in the memory. You know, those blocks just love to pick their own addresses. ;-) -- - Gordon Worley http://www.rbisland.cx/ mailto:redbird@rbisland.cx From fgranger@altern.org Sun Jul 16 12:03:17 2000 From: fgranger@altern.org (Francois Granger) Date: Sun, 16 Jul 2000 13:03:17 +0200 Subject: [Pythonmac-SIG] [Newbee] Schedule Message-ID: I am trying to do a watch folder script. But I find that the Macintosh responsivness is not really good during execution. I found the instruction params = MacOS.SchedParams (1, 0, 1, 0.1, 0.25) and lower the interval value from 0.25 to 0.1 to make it better responsive, but this does not seems enought. My config is G4 400 with MacOS FU1 9.0.4 and the code is : #(doint, evtmask, besocial, interval, bgyield) params = MacOS.SchedParams (1, 0, 1, 0.1, 0.25) # -- main loop while 1: filesToProcess = [] filesToProcess = os.listdir(inFolder) for file in filesToProcess: file = join(inFolder, file) print 'processing file : ' , file result = process(file) if result: logAction(file, result) print "Moving old to Done ...", file temp = findertools.move (file, doneFolder) else: logAction(file, 'rejected') print "Moving old to Rej ...", file # -- move to rejected temp = findertools.move (file, rejFolder) -- "Computers are like horses; they can sense fear and will act based on that. Or, look at it like this. If you have a premonition of danger, maybe you're right." - Adam Engst From jack@oratrix.nl Sun Jul 16 20:51:55 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 16 Jul 2000 21:51:55 +0200 Subject: [Pythonmac-SIG] [Newbee] Schedule In-Reply-To: Message by Francois Granger , Sun, 16 Jul 2000 13:03:17 +0200 , Message-ID: <20000716195200.5ED3759214@oratrix.oratrix.nl> Recently, Francois Granger said: > I am trying to do a watch folder script. But I find that the > Macintosh responsivness is not really good during execution. I found > the instruction > params = MacOS.SchedParams (1, 0, 1, 0.1, 0.25) and lower the > interval value from 0.25 to 0.1 to make it better responsive, but > this does not seems enought. I've had the exact same problems (and I wrote the code:-). There seems to be values for the interval and bgyield that give both sufficient performance for Python and responsiveness for other applications. I sort-of gave up on the problem, because it seems most cpu-intensive programs have exactly the same problem. Try running Stuffit Expander in the background, for instance. Ah, I just remember you said "MacOS 9". There's one thing under MacOS 9 that makes the situation even worse, and that's turning on the "Allow processor sleep" option in the energy control panel. This will make MacOS basically ignore the sleeptime parameter in WaitNextEvent (basically the bgyield parameter in SchedParams) and double the sleep time for every WaitNextEvent that doesn't return an event. This wreaks havoc with Python's attempt to be nice to other applications, basically starving it from CPU time in a short while. -- 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 Jul 17 09:07:12 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 17 Jul 2000 10:07:12 +0200 Subject: [Pythonmac-SIG] [Newbee] Schedule In-Reply-To: Message by Jack Jansen , Sun, 16 Jul 2000 21:51:55 +0200 , <20000716195200.5ED3759214@oratrix.oratrix.nl> Message-ID: <20000717080713.6B4E637186D@snelboot.oratrix.nl> > I've had the exact same problems (and I wrote the code:-). There seems > to be values for the interval and bgyield that give both sufficient > performance for Python and responsiveness for other applications. Oops, what I intended to say was "There seem to be NO values for the interval etc etc". -- 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 fgranger@altern.org Mon Jul 17 09:46:57 2000 From: fgranger@altern.org (Francois Granger) Date: Mon, 17 Jul 2000 10:46:57 +0200 Subject: [Pythonmac-SIG] [Newbee] Schedule In-Reply-To: <20000717080713.6B4E637186D@snelboot.oratrix.nl> Message-ID: on 17/07/00 10:07, Jack Jansen at jack@oratrix.nl wrote: >=20 >> I've had the exact same problems (and I wrote the code:-). There seems >> to be values for the interval and bgyield that give both sufficient >> performance for Python and responsiveness for other applications. >=20 > Oops, what I intended to say was "There seem to be NO values for the inte= rval > etc etc". Thanks for your answer. I need to get some acceptable values. the processin= g of the script being really low. Basically, the script reads mail messages, do some modifications and write them back in another folder. It then move the original file to a third folder. So even if processing is slow, that is not an issue. I think that the most intensive task is opening writing and closing files. = I do it with the standard portable commands. May be using some Mac only commands would be better ? In AppleScript, there is a command "Yield", wich pass back control to the OS. I was hopping that some command like "pass" maybe would do the same in Python ... I'll do some testing and let you know what I find. --=20 Fran=E7ois Granger fgranger@altern.org From jack@oratrix.nl Mon Jul 17 10:28:17 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 17 Jul 2000 11:28:17 +0200 Subject: [Pythonmac-SIG] [Newbee] Schedule In-Reply-To: Message by Francois Granger , Mon, 17 Jul 2000 10:46:57 +0200 , Message-ID: <20000717092818.0D9E437186D@snelboot.oratrix.nl> > Thanks for your answer. I need to get some acceptable values. the proce= ssing > of the script being really low. Basically, the script reads mail messag= es, > do some modifications and write them back in another folder. It then mo= ve > the original file to a third folder. So even if processing is slow, tha= t is > not an issue. > = > I think that the most intensive task is opening writing and closing fil= es. I > do it with the standard portable commands. May be using some Mac only > commands would be better ? > = > In AppleScript, there is a command "Yield", wich pass back control to t= he > OS. I was hopping that some command like "pass" maybe would do the same= in > Python ... Using the standard open/etc calls should be fine. And a yield call isn't = available, although I agree that it has some uses, I'll think about it fo= r a = future version. If you really don't care all that much about Python performance you shoul= d set = checkinterval to a low value (causing frequent yields, both in foreground= and = background) and reasonably high bgyield (causing the processor to be give= n up = for so many seconds at most, when in the background. In the foreground we= = always give up the processor for the shortest time possible). -- 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 erik@letterror.com Mon Jul 17 12:50:13 2000 From: erik@letterror.com (Erik van Blokland) Date: Mon, 17 Jul 2000 12:50:13 +0100 Subject: [Pythonmac-SIG] [Newbee] Schedule Message-ID: <200007171054.MAA28978@leidschenveen.denhaag.dataweb.net> Jack Jansen, 7/16/00 8:51 PM: >I sort-of gave up on the problem, because it seems most cpu-intensive >programs have exactly the same problem. Try running Stuffit Expander >in the background, for instance. I can only find "Allow processor cycling" in my Powerbook 9.04 system (Energy Saver version 2.5.5), my G3 deskdrawer machine does not have any processor specific settings but that's version 2.5.2. >Ah, I just remember you said "MacOS 9". There's one thing under MacOS >9 that makes the situation even worse, and that's turning on the "Allow >processor sleep" option in the energy control panel. This will make >MacOS basically ignore the sleeptime parameter in WaitNextEvent >(basically the bgyield parameter in SchedParams) and double the sleep >time for every WaitNextEvent that doesn't return an event. This wreaks >havoc with Python's attempt to be nice to other applications, >basically starving it from CPU time in a short while. Not sure whether this is related to, the same, or something completely different from this thread, but it's bugging me so I'm asking anyway. Pardon the wordy explanation, in technical terms it is probably not so difficult. A python scripts calls another application (Finder, Filemaker) via appleevents. When a script calls for the Finder to do something simple like moving or copying files (I have reasons to want the Finder to do it - I am aware of more python-like ways)), it will take forever when the IDE is in the foreground (up to the point of an AE timeout error), whereas if the Finder is in the front it will zoom right through it. As if python is _so_ busy waiting for an answer from the AE that the called application actually gets no time to deal with the request. I can work around it by getting the other application to the foreground when the script is running, but some of these scripts can take up to 10 minutes (a lot of stuff gets done) and it is a nuisance to carefully _not_ click the IDE to the front by accident. This will then cause an AE timeout and the whole thing has to start again. Erik van Blokland -- letterror From jack@oratrix.nl Mon Jul 17 13:19:41 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 17 Jul 2000 14:19:41 +0200 Subject: [Pythonmac-SIG] [Newbee] Schedule In-Reply-To: Message by Erik van Blokland , Mon, 17 Jul 2000 12:50:13 +0100 , <200007171054.MAA28978@leidschenveen.denhaag.dataweb.net> Message-ID: <20000717121942.2D1A537186E@snelboot.oratrix.nl> > I can only find "Allow processor cycling" in my Powerbook 9.04 system > (Energy Saver version 2.5.5), my G3 deskdrawer machine does not have any > processor specific settings but that's version 2.5.2. That could definitely be the wording in english. I translated from the dutch "processor rust toegestaan" (Energiestand version N1-2.5.5). It's there on both my G4 and my iMac DV. > A python scripts calls another application (Finder, Filemaker) via > appleevents. When a script calls for the Finder to do something simple > like moving or copying files (I have reasons to want the Finder to do it > - I am aware of more python-like ways)), it will take forever when the > IDE is in the foreground (up to the point of an AE timeout error), > whereas if the Finder is in the front it will zoom right through it. As > if python is _so_ busy waiting for an answer from the AE that the called > application actually gets no time to deal with the request. And now _I_ am wondering whether this is related to the problems Andrew Watson mentioned last week, where talking to the AppleShareIP SMTP server on the same machine would hang. Andrew: were you execting your script from the IDE or from the bare Python interpreter? When Python is in the foreground it doesn't give much time to background processes when it is not idle. When it is idle, however, such as when waiting for socket I/O or for an AppleEvent reply, it should be giving ample time to background tasks. It sounds as though there could be a bug in there somewhere, though. My first guess is that the bug is in the IDE: I run scripts from the interpreter many times dayly (to recompile Python, for instance) and I haven't seen this behaviour. And the IDE takes over most event handling from the core. But it could also be in the interpreter core, and that I don't see it is somehow because CodeWarrior isn't susceptible to the lockout problem. Erik: could you check whether your lockout problem is only with IDE in the foreground, or whether the same happens with the bare interpreter? -- 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 billb@mousa.demon.co.uk Mon Jul 17 14:54:13 2000 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Mon, 17 Jul 2000 14:54:13 +0100 Subject: [Pythonmac-SIG] [Newbee] Schedule In-Reply-To: <200007171054.MAA28978@leidschenveen.denhaag.dataweb.net> References: <200007171054.MAA28978@leidschenveen.denhaag.dataweb.net> Message-ID: <241500146144344575137@mousa.demon.co.uk> At 12:50 pm +0100 17/07/00, Erik van Blokland wrote: >Not sure whether this is related to, the same, or something completely >different from this thread, but it's bugging me so I'm asking anyway. >Pardon the wordy explanation, in technical terms it is probably not so >difficult. > >A python scripts calls another application (Finder, Filemaker) via >appleevents. When a script calls for the Finder to do something simple >like moving or copying files (I have reasons to want the Finder to do it >- I am aware of more python-like ways)), it will take forever when the >IDE is in the foreground (up to the point of an AE timeout error), >whereas if the Finder is in the front it will zoom right through it. As >if python is _so_ busy waiting for an answer from the AE that the called >application actually gets no time to deal with the request. I don't think this is only a python problem, you can get the same sort of thing happening with folder actions >I can work around it by getting the other application to the foreground >when the script is running, but some of these scripts can take up to 10 >minutes (a lot of stuff gets done) and it is a nuisance to carefully >_not_ click the IDE to the front by accident. This will then cause an AE >timeout and the whole thing has to start again. Can't you hide the IDE when the script is running? In applescript:- tell application "Finder" set visible of process "Eudora" to false end tell -- Bill Bedford Tourist, he decided, meant "idiot". From cbarker@jps.net Mon Jul 17 20:35:11 2000 From: cbarker@jps.net (Chris Barker) Date: Mon, 17 Jul 2000 12:35:11 -0700 Subject: [Pythonmac-SIG] BuildApplication References: <20000717160156.521101D0FF@dinsdale.python.org> Message-ID: <39735FEF.402193E9@jps.net> I'm trying to use BuildApplication to build an application (what else?) that uses ftplib. It crashes with a "macmodulefinder.Missing: ['SOCKS']" error. It seems to work fine on simpler scripts with no ftplib, and it crashes the same way on a very simple script with ftplib, so I'm guessing that's the problem. I'm also guessing that 'SOCKS' has something to do with sockets, but I have no idea what to do now. The script runs fine if I drop it on the Python interpretter, so all the required libraries are there. -Thanks, -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From just@letterror.com Mon Jul 17 22:06:40 2000 From: just@letterror.com (Just van Rossum) Date: Mon, 17 Jul 2000 22:06:40 +0100 Subject: [Pythonmac-SIG] BuildApplication In-Reply-To: <39735FEF.402193E9@jps.net> References: <20000717160156.521101D0FF@dinsdale.python.org> Message-ID: At 12:35 PM -0700 17-07-2000, Chris Barker wrote: >I'm trying to use BuildApplication to build an application (what else?) >that uses ftplib. > >It crashes with a "macmodulefinder.Missing: ['SOCKS']" error. > >It seems to work fine on simpler scripts with no ftplib, and it crashes >the same way on a very simple script with ftplib, so I'm guessing that's >the problem. I'm also guessing that 'SOCKS' has something to do with >sockets, but I have no idea what to do now. > >The script runs fine if I drop it on the Python interpretter, so all the >required libraries are there. A workaround for now would be to uncomment the lines if error: raise Missing, error from macmodulefinder.py. (This is only for 1.5.2c1) Just From fgranger@altern.org Mon Jul 17 21:50:11 2000 From: fgranger@altern.org (Francois Granger) Date: Mon, 17 Jul 2000 22:50:11 +0200 Subject: [Pythonmac-SIG] [Newbee] Schedule In-Reply-To: <20000717121942.2D1A537186E@snelboot.oratrix.nl> References: <20000717121942.2D1A537186E@snelboot.oratrix.nl> Message-ID: At 14:19 +0200 17/07/00, in message Re: [Pythonmac-SIG] [Newbee] Schedule, Jack Jansen wrote: >Erik: could you check whether your lockout problem is only with IDE in the >foreground, or whether the same happens with the bare interpreter? I noticed this behaviour in my script. It basically read a file, write another file, and then ask the finder to move the original. Then do the same with the next file in the same folder. When running in the IDE. At some time, it will look as if it stopped after the first file. If I clicked on the finder, the IDE was going to background and then my script was processing all other files in the folder at normal speed. I did not had this behaviour with the script running with the interpreter or being converted to an applet. -- "Computers are like horses; they can sense fear and will act based on that. Or, look at it like this. If you have a premonition of danger, maybe you're right." - Adam Engst From cbarker@jps.net Mon Jul 17 22:26:55 2000 From: cbarker@jps.net (Chris Barker) Date: Mon, 17 Jul 2000 14:26:55 -0700 Subject: [Pythonmac-SIG] BuildApplication References: <20000717160156.521101D0FF@dinsdale.python.org> Message-ID: <39737A1F.5D289EAE@jps.net> Just van Rossum wrote: > >I'm trying to use BuildApplication to build an application (what else?) > >that uses ftplib. > > > >It crashes with a "macmodulefinder.Missing: ['SOCKS']" error. > > A workaround for now would be to uncomment the lines > > if error: > raise Missing, error > > from macmodulefinder.py. (This is only for 1.5.2c1) Thanks, Just. That seems to work. What might I have broken for other things? -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cbarker@jps.net Tue Jul 18 00:22:11 2000 From: cbarker@jps.net (Chris Barker) Date: Mon, 17 Jul 2000 16:22:11 -0700 Subject: [Pythonmac-SIG] Wierd Output window bug in BuildApplication References: <20000711160128.986901D0FA@dinsdale.python.org> Message-ID: <39739523.18361AAF@jps.net> Hi all, I am able to build my little app with BuildApplication (thanks to some help from Just), but I've found a wierd bug. when I run the app, (it is a tkInter app), it suddenly brings up an output window for no apparent reason. The same script dropped onto the Python interpreter doesn not open the window. It makes no difference what settings I use in EditPythonPrefs. I seem to have narrowed it down to when I open and wrote to a file. If I open and write to a file, the output window appears, if not, it doesn't. There is nothing in the output window. Anyone have any ideas? -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From chriss@dnastar.com Tue Jul 18 02:34:02 2000 From: chriss@dnastar.com (Chris) Date: Mon, 17 Jul 2000 20:34:02 -0500 Subject: [Pythonmac-SIG] _sre.c vs. CodeWarrior Message-ID: Since several include _sre.c, I assume someone is compiling them. However every time I attempt to compile '_sre.c'- or even check syntax on it - I crash into the gray screen of death. So is everyone else useing a beta or has anyone gotten it to work with CWPro5.2? (that's IDE 4.0.4) From jack@oratrix.nl Tue Jul 18 08:52:45 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 18 Jul 2000 09:52:45 +0200 Subject: [Pythonmac-SIG] _sre.c vs. CodeWarrior In-Reply-To: Message by Chris , Mon, 17 Jul 2000 20:34:02 -0500 , Message-ID: <20000718075250.0966CDB4D6@oratrix.oratrix.nl> Recently, Chris said: > Since several include _sre.c, I assume someone is compiling them. > However every time I attempt to compile '_sre.c'- or even check > syntax on it - I crash into the gray screen of death. So is everyone > else useing a beta or has anyone gotten it to work with CWPro5.2? > (that's IDE 4.0.4) CodeWarrior needs generous amounts of memory to compile _sre.c (mine has 18MB), and you need to be careful with inlining too. If you grab the PythonStandSmall project from the repository: I've recently checked that in, if I'm not mistaken, and it should have _sre.c, so you can get the settings values from there. -- 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 Jul 18 08:57:48 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 18 Jul 2000 09:57:48 +0200 Subject: [Pythonmac-SIG] Wierd Output window bug in BuildApplication In-Reply-To: Message by Chris Barker , Mon, 17 Jul 2000 16:22:11 -0700 , <39739523.18361AAF@jps.net> Message-ID: <20000718075753.6F236DB4D6@oratrix.oratrix.nl> Recently, Chris Barker said: > when I run the app, (it is a tkInter app), it suddenly brings up an > output window for no apparent reason. The same script dropped onto the > Python interpreter doesn not open the window. It makes no difference > what settings I use in EditPythonPrefs. > > I seem to have narrowed it down to when I open and wrote to a file. If I > open and write to a file, the output window appears, if not, it doesn't. > There is nothing in the output window. Hmm, strange. The output window is opened (if you have the "delay until needed" bit set) only if something is written to it or read from it. What you could try is closing stdin/stdout/stderr, or redirecting them to some other place. If that fixes the problem then the problem is probably in Python (as it goes away when you make it impossible for Python code to get at the sioux window), if it doesn't go away it is probably in the C code somewhere. I assume this is using 1.5.2? You could also try it under 1.6alfa and see what happens there... -- 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 fgranger@altern.org Tue Jul 18 09:30:51 2000 From: fgranger@altern.org (Francois Granger) Date: Tue, 18 Jul 2000 10:30:51 +0200 Subject: [Pythonmac-SIG] timing and moving files In-Reply-To: <20000717092818.0D9E437186D@snelboot.oratrix.nl> Message-ID: on 17/07/00 11:28, Jack Jansen at jack@oratrix.nl wrote: > If you really don't care all that much about Python performance you shoul= d set > checkinterval to a low value (causing frequent yields, both in foreground= and > background) and reasonably high bgyield (causing the processor to be give= n up > for so many seconds at most, when in the background. In the foreground we > always give up the processor for the shortest time possible). Following this advice, I did the following testing. All tests were done in forground. inFolder contains 19 files for a total of 6.1 MB test 1 MacOS.SchedParams() interval and bgyield to their default values (0.25) File move done with findertools.move (file, doneFolder) Time =3D 23s test 2 MacOS.SchedParams() interval =3D 0.1 bgyield =3D 0.5 File move done with findertools.move (file, doneFolder) Time =3D 29s test 3 MacOS.SchedParams() interval =3D 0.1 bgyield =3D 0.5 File move done with os.rename(file, temp) Time =3D 1s I feel that my real concern was using AppleEvent to do the move. I'll recod= e my app to use rename. The current code i came with for the testing was: def process(file): # temp =3D findertools.move (file, doneFolder) a, b =3D split(file) temp =3D join(doneFolder, b) os.rename(file, temp) return 1 This may be improved ;-) --=20 Fran=E7ois Granger fgranger@altern.org From jack@oratrix.nl Tue Jul 18 09:47:16 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 18 Jul 2000 10:47:16 +0200 Subject: [Pythonmac-SIG] timing and moving files In-Reply-To: Message by Francois Granger , Tue, 18 Jul 2000 10:30:51 +0200 , Message-ID: <20000718084717.7B66337186E@snelboot.oratrix.nl> I did found a bug in the Python AE event loop: the idle function (which is called while you're waiting for your reply) should set the timeout value the first time around, but it doesn't. I'll fix that. -- 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 awatson@bigfoot.com Wed Jul 19 10:26:52 2000 From: awatson@bigfoot.com (Andrew Watson) Date: Wed, 19 Jul 2000 17:26:52 +0800 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #463 - 7 msgs In-Reply-To: <20000717160156.8EDAD1D100@dinsdale.python.org> References: <20000717160156.8EDAD1D100@dinsdale.python.org> Message-ID: > >And now _I_ am wondering whether this is related to the problems Andrew Watson >mentioned last week, where talking to the AppleShareIP SMTP server on the same >machine would hang. > >Andrew: were you execting your script from the IDE or from the bare Python >interpreter? > Hmm...not sure. Certainly not the interpreter, probably the IDE, maybe PythonCGISlave ( which just uses the PythonLib? ) When I get a chance, I'll take my production system down and test this ( and 1.6 ). Andrew From cbarker@jps.net Wed Jul 19 17:55:10 2000 From: cbarker@jps.net (Chris Barker) Date: Wed, 19 Jul 2000 09:55:10 -0700 Subject: [Pythonmac-SIG] My attempts to use 1.6a3 References: <20000718075753.6F236DB4D6@oratrix.oratrix.nl> Message-ID: <3975DD6E.4C06BA4E@jps.net> Hi folks, I was having some wierd problems with an app built with BuildApplication popping up unwanted output window, and Jack suggested I try 1.6, so I did. The following is an entirely too detailed account of my experience. Most of my problems were minor problems with the default install, that I fixed, but I have afew stumpers that I can't get passed. The big one is that I can't get EditPythonPrefs to allow me to change my startup otions. As a result, I couldn't test to see if the above problem was fixed. For the details, see below: -Chris Notes on MacPython 1.6a2. ------------------------------- Installed from the installer on 7/18/00. On a Blue&White G3, running MacOS 8.6 test.autotest: In the README, it states that test_strftime is expected to fail. For me, test_zlib failed as well (not a big deal) Testing TKinter: -------------------------------- >>>import Tkinter: ImportError: No module named Tkinter OOPS, not on the path (I thought this was fixed) I added $(PYTHON):Lib:lib-tk to the path now when I import Tkinter I get: SystemError: NULL object passed to PyObject_Init >>> import _tkinter works, when I then try: >>> import Tkinter shift: no mem in addchild Traceback (most recent call last): File "", line 1, in ? MemoryError HMM. I up the memory for the interpretter to 12000 k and it now import Tkinter works! I try >>> Tkinter._test() and the interpreter crashes with a "type 11 error" I gave it more memory and the same thing happens. I remembered that there are known problems using tkinter at the command line, so I put the test code in a file and drop it on the interpreter. All is well! Testing EditPythonPrefs: ----------------------------------- I don't want to see the ouput window come up everytime, so I try EditPythonPrefs, click on Startup options, and get: Traceback (most recent call last): File "Macintosh HD:SWdev:Jack:Python:Mac:scripts:EditPythonPrefs.py", line 186, in ? File "Macintosh HD:SWdev:Jack:Python:Mac:scripts:EditPythonPrefs.py", line 179, in main File "Macintosh HD:SWdev:Jack:Python:Mac:scripts:EditPythonPrefs.py", line 162, in edit_preferences File "Macintosh HD:SWdev:Jack:Python:Mac:scripts:EditPythonPrefs.py", line 144, in interact File "Macintosh HD:SWdev:Jack:Python:Mac:scripts:EditPythonPrefs.py", line 81, in optinteract KeyError: nonavservices I'm stumped on this one. testing BuildApplication: ----------------------------------------- First it crashed with a memory error. I added memory, and it seemed to work (I really, really, hate MacOS memory "management"). then I got an error and it asked me where Pythoncore could be found. It turns out there was a dead alias in the Extentions folder. I put a good one in there, and it still asked me for the core, but this time I pointed it to the alias, and it worked. Does that alias need to be named anything in particular? (I tried PythonCore 1.6a2) When I run the application, however, I get the error: 'import macfsn' failed; use -v for traceback XXX rds_object called with exception set ImportError: No module named macfsn my little test app did not directly import macfsn. It just ran Tkinter._test() I'm stumped again so, that's where I'm at. any ideas anyone? -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cbarker@jps.net Wed Jul 19 18:01:17 2000 From: cbarker@jps.net (Chris Barker) Date: Wed, 19 Jul 2000 10:01:17 -0700 Subject: [Pythonmac-SIG] Wierd Output window bug in BuildApplication References: <20000718075753.6F236DB4D6@oratrix.oratrix.nl> Message-ID: <3975DEDD.B07EB5F4@jps.net> Jack Jansen wrote: > > I seem to have narrowed it down to when I open and wrote to a file. If I > > open and write to a file, the output window appears, if not, it doesn't. > > There is nothing in the output window. > Hmm, strange. The output window is opened (if you have the "delay > until needed" bit set) only if something is written to it or read from > it. Well, I tried getting rid of the code that wrote a temp file, and used an in-memory version, but it still happened. Then I realised that part of what the app does is FTP a file selected by the user, and ftplib needs an open file object passed to it, so there is no way to get around opening a file, which is when the window seems to pop up. > What you could try is closing stdin/stdout/stderr, or redirecting > them to some other place. If that fixes the problem then the problem > is probably in Python (as it goes away when you make it impossible for > Python code to get at the sioux window), well, I tried: sys.stdout = None (and similarly for stdin/stderr) I also tried redirecting them to a file: sys.stdout = open('tempfile','w') etc.. Neither of these makes a difference. > if it doesn't go away it is > probably in the C code somewhere. There you have it. Remember that it ONLY happens with an app built with BuildApplication, If I drag and drop the script onthe interpretter, it doesn't bring up the window. > I assume this is using 1.5.2? You could also try it under 1.6alfa and > see what happens there... See my other post for the results of my attempt to do this. The short version is that I don't know, because I couldn't get EditPythonPrefs to work. -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cbarker@jps.net Wed Jul 19 19:41:49 2000 From: cbarker@jps.net (Chris Barker) Date: Wed, 19 Jul 2000 11:41:49 -0700 Subject: [Pythonmac-SIG] Wierd Output window bug in BuildApplication References: <20000718075753.6F236DB4D6@oratrix.oratrix.nl> <3975DEDD.B07EB5F4@jps.net> Message-ID: <3975F66D.74989A1@jps.net> Chris Barker wrote: > well, I tried: > sys.stdout = None (and similarly for stdin/stderr) OOPS!!! I also tried sys.stdout.close(), etc. also with no change. -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From jack@oratrix.nl Wed Jul 19 22:17:15 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 19 Jul 2000 23:17:15 +0200 Subject: [Pythonmac-SIG] My attempts to use 1.6a3 In-Reply-To: Message by Chris Barker , Wed, 19 Jul 2000 09:55:10 -0700 , <3975DD6E.4C06BA4E@jps.net> Message-ID: <20000719211720.B700A191AA8@oratrix.oratrix.nl> Recently, Chris Barker said: > I was having some wierd problems with an app built with BuildApplication > popping up unwanted output window, and Jack suggested I try 1.6, so I > did. The following is an entirely too detailed account of my experience. No, no, no!! The following is a briliant account of your experience! I wish more people would do this (that was a hint to the rest of the readership here:-) Most of the problems have been solved in the current source tree, I'll go through them one by one: > test.autotest: > > In the README, it states that test_strftime is expected to fail. For me, > test_zlib > failed as well (not a big deal) This is again the memory problem (it works if you run the test suite the second time). The next release will have 16 Mb as preferred memory size, 4Mb minimum. > Testing TKinter: > -------------------------------- > > >>>import Tkinter: > > ImportError: No module named Tkinter > > OOPS, not on the path (I thought this was fixed) So did I. I'll check it again. Well, it's fixed in the sources, so it should be ok in the next release. > now when I import Tkinter I get: > > SystemError: NULL object passed to PyObject_Init Again, the memory error, I presume. This "shouldn't happen", however, I'll investigate. > >>> import Tkinter > shift: no mem in addchild Again the memory error. this one is difficult to fix, though: it occurs in an obscure place in the parser. > >>> Tkinter._test() > > and the interpreter crashes with a "type 11 error" It works for me, although Python behaves weird after you quit the test dialog. Did you test it from PythonInterpreter or from IDE? You cannot use Tkinter from IDE, and horrible things happen if you try. We'll try to put in a warning in the next release. > Testing EditPythonPrefs: > ----------------------------------- Fixed in the sources. The easy fix is to change nonavservice in Mac:lib:pythonprefs.py to nonavservices. > testing BuildApplication: > ----------------------------------------- > > When I run the application, however, I get the error: > > 'import macfsn' failed; use -v for traceback > XXX rds_object called with exception set > ImportError: No module named macfsn Again a stupid omission on my side. BuildApplication doesn't know that all programs implicitly include macfsn. Adding an "import macfsn" to your source is the quickest workaround (since then BuildApplication does know it's needed). -- 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 jaredu@its.caltech.edu Thu Jul 20 01:06:52 2000 From: jaredu@its.caltech.edu (Jared Updike) Date: Wed, 19 Jul 2000 17:06:52 -0700 (PDT) Subject: [Pythonmac-SIG] test_socket failed Message-ID: I ran test_all and test_socket failed. So I ran test_socket by itself to get more info and it says 'hostname not found' when it gets to the line hname, aliases, ipaddrs = socket.gethostbyaddr(ip) I read on comp.lang.python about the same problem w/ test_socket on Windows and there was simple solution: to add a line to a c:\windows\hosts text file. I need to get sockets working to talk to another machine (an SGI run Python on IRIX) but I'm using a Mac, so I'm not certain what the solution is. I attempted writing a small test script to do essentially the same thing as the test_socket script, and it represents more of the end goal of what I'm going to be doing with sockets: # from socket import * snd = socket(AF_INET, SOCK_STREAM) snd.connect('tarsier.bio.caltech.edu', 4127) # quits here with 'socket # not connected' snd.send("quit") # this will eventually change based on input, etc. snd.close() # Eventually I will need to embed this into a C program, or extend the script to use some C functions to do another task. I have CodeWarrior 2.0b3, IDE 4.0 and (Mac)Python 1.5.2. I have the CWGUSI (I'm not sure it applies here, but I'm also curious as to what this does, in relation to Python in particular). I've read through much of the documentation and the whole FAQ, so any help you can give would be appreciated. Thanks. --Jared Web: http://waffles.caltech.edu Phone: (626)395-1154 Campus Adress: Blacker Hovse, Room 31 Adress: MSC 935 Caltech Pasadena, CA 91126-0935 From andrewc@vasci.com Thu Jul 20 01:49:41 2000 From: andrewc@vasci.com (Andrew Cunningham) Date: Wed, 19 Jul 2000 17:49:41 -0700 Subject: [Pythonmac-SIG] Building Python on OS X DR/4 Message-ID: This is probably violating my NDA, but I am trying to build Python on OS X DR/4. Of course it's a dream to build under DR/4 vs Classic MacOS as you have all the GNU tools. In fact, it built from start to finish without an error, but when I ran the test example, it failed when running the tests. If anyone else has some light to shed on this, please e-mail me directly. I wish to respect my NDA somewhat, and do not want to get into a general discussion about OS X things on the list. Thanks Andrew ---------------------- Andrew Cunningham Vibro-Acoustic Sciences Inc http://www.vasci.com mailto: andrewc@vasci.com From jack@oratrix.nl Thu Jul 20 09:16:40 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 20 Jul 2000 10:16:40 +0200 Subject: [Pythonmac-SIG] test_socket failed In-Reply-To: Message by Jared Updike , Wed, 19 Jul 2000 17:06:52 -0700 (PDT) , Message-ID: <20000720081640.678F537186E@snelboot.oratrix.nl> > I ran test_all and test_socket failed. So I ran test_socket by itself to > get more info and it says 'hostname not found' when it gets to the line > > hname, aliases, ipaddrs = socket.gethostbyaddr(ip) Your nameserver is broken. The three calls in the test script are hostname = socket.gethostname() ip = socket.gethostbyname(hostname) hname, aliases, ipaddrs = socket.gethostbyaddr(ip) and only the final one, which does the reverse lookup on your IP address, apparently fails. The various RFC standards specify that for each IP address the reverse mapping should always work. As an aside, you'll also have trouble accessing ftp.cwi.nl to load a new MacPython (as that machine uses reverse mapping as part of its anti-abuse policy). > Eventually I will need to embed this into a C program, or extend the > script to use some C functions to do another task. I have CodeWarrior > 2.0b3, IDE 4.0 and (Mac)Python 1.5.2. Yes, that's fine. Look at the xx module for an example project and such. Hmm, I do seem to remember that something reasonably serious was fixed in this area, so maybe you should try MacPython 1.6alfa, from http://www.cwi.nl/ftp/jack/python/mac . > I have the CWGUSI (I'm not sure it applies here, but I'm also curious > as to what this does, in relation to Python in particular). I've read > through much of the documentation and the whole FAQ, so any help you can > give would be appreciated. Thanks. You probably won't need CWGUSI, you'll just need to remove it from the access path of your module project (it was there inadvertantly). Unless you use socket(), select(), stat() or another unix-compatible I/O call from within your extension module. -- 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 Jul 20 09:21:31 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 20 Jul 2000 10:21:31 +0200 Subject: [Pythonmac-SIG] Building Python on OS X DR/4 In-Reply-To: Message by Andrew Cunningham , Wed, 19 Jul 2000 17:49:41 -0700 , Message-ID: <20000720082132.10DF437186E@snelboot.oratrix.nl> > This is probably violating my NDA, but I am trying to build Python on OS X > DR/4. Hm, you're right, DP4 is under NDA. Hadn't noticed that before, and it's also a bit strange for something which they gave away to every Mac developer on the face of the earth:-) > Of course it's a dream to build under DR/4 vs Classic MacOS as you have all > the GNU tools. > In fact, it built from start to finish without an error, but when I ran the > test example, it failed when running the tests. Could you be a bit more specific? Which tests failed? How? I've seen one problem with Python (but I only tried on DP3) and that was that you had to fiddle the Makefile if you built on an HFS+ partition (a name conflict between the python binary and the Python directory). Also: I assume your building standard Python, or are you building MacPython from the CVS repository? -- 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 dma@andrew.cmu.edu Thu Jul 20 14:35:05 2000 From: dma@andrew.cmu.edu (David Andersen) Date: Thu, 20 Jul 2000 09:35:05 -0400 Subject: [Pythonmac-SIG] CXX extensions Message-ID: <2013031096.964085705@DAWSON.WV.CC.CMU.EDU> Has anyone compiled anything that uses the CXX extensions on the Mac? I'm stuck on references to "random_access_iterator()" - I'm fairly sure I have the project (CodeWarrior 5.2) set up wrong, but I don't know where. Does anyone have an example project? From Tom Smith" This is a multi-part message in MIME format. ------=_NextPart_000_002C_01BFF25A.C17434A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20 I'm using MacOS 9.0.2 Webstar & python 1.6 on a G4 ... and if I set a cgi's memory below 12MB I get an error like this... the push: no mem in addchild Traceback (most recent call last): File "Apps:WebSTAR Server Suite 4.2:cgitest.cgi.py", line 2, in ? execfile('realcgitest.py') File "realcgitest.py", line 4, in ? from MiniAEFrame import AEServer, MiniApplication File "System:Python 1.6a2:Mac:Lib:lib-toolbox:MiniAEFrame.py", line = 21, in ? import aetools File "System:Python 1.6a2:Mac:Lib:lib-toolbox:aetools.py", line 30, in = ? from aetypes import * File "System:Python 1.6a2:Mac:Lib:lib-toolbox:aetypes.py", line 4, in = ? from AERegistry import * MemoryError ...any ideas? cheers tom ------=_NextPart_000_002C_01BFF25A.C17434A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I'm using MacOS 9.0.2 Webstar & = python 1.6 on a=20 G4 ...
 
and if I set a cgi's memory below 12MB = I get an=20 error like this...
 
 the push: no mem in = addchild
Traceback=20 (most recent call last):
  File "Apps:WebSTAR Server Suite=20 4.2:cgitest.cgi.py", line 2, in ?
   =20 execfile('realcgitest.py')
  File "realcgitest.py", line 4, in=20 ?
    from MiniAEFrame import AEServer,=20 MiniApplication
  File "System:Python=20 1.6a2:Mac:Lib:lib-toolbox:MiniAEFrame.py", line 21,=20 in
?
    import aetools
  File = "System:Python=20 1.6a2:Mac:Lib:lib-toolbox:aetools.py", line 30, in = ?
    from=20 aetypes import *
  File "System:Python=20 1.6a2:Mac:Lib:lib-toolbox:aetypes.py", line 4, in = ?
    from=20 AERegistry import *
MemoryError
...any ideas?
 
cheers
 
tom
 
------=_NextPart_000_002C_01BFF25A.C17434A0-- From cbarker@jps.net Thu Jul 20 20:42:51 2000 From: cbarker@jps.net (Chris Barker) Date: Thu, 20 Jul 2000 12:42:51 -0700 Subject: [Pythonmac-SIG] My attempts to use 1.6a3 References: <20000719211720.B700A191AA8@oratrix.oratrix.nl> Message-ID: <3977563B.421FBCDD@jps.net> Jack Jansen wrote: > > >>> Tkinter._test() > > > > and the interpreter crashes with a "type 11 error" > > It works for me, although Python behaves weird after you quit the test > dialog. Did you test it from PythonInterpreter or from IDE? You cannot > use Tkinter from IDE, and horrible things happen if you try. We'll try > to put in a warning in the next release. I just tried it again from the interpreter (NOT the IDE), and it crashed again. My understanding is that running tk form the interpreter is problematic anyway, so it's no big deal. > > Testing EditPythonPrefs: > > ----------------------------------- > > Fixed in the sources. The easy fix is to change nonavservice in > Mac:lib:pythonprefs.py to nonavservices. Thanks, that did it. > > testing BuildApplication: > > ----------------------------------------- > > > > When I run the application, however, I get the error: > > > > 'import macfsn' failed; use -v for traceback > > XXX rds_object called with exception set > > ImportError: No module named macfsn > > Again a stupid omission on my side. BuildApplication doesn't know that > all programs implicitly include macfsn. Adding an "import macfsn" to > your source is the quickest workaround (since then BuildApplication > does know it's needed). Another little note on BuildApplication: It asks whether you want a Fat, PPC or 68k app, but I thought 68k was no longer supported. Also, I still need to keep telling it where PythonCore is. How do I stop that? -chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From jack@oratrix.nl Fri Jul 21 11:08:42 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 21 Jul 2000 12:08:42 +0200 Subject: [Pythonmac-SIG] My attempts to use 1.6a3 In-Reply-To: Message by Chris Barker , Thu, 20 Jul 2000 12:42:51 -0700 , <3977563B.421FBCDD@jps.net> Message-ID: <20000721100847.1737CD2CC3@oratrix.oratrix.nl> Recently, Chris Barker said: > > I just tried it again from the interpreter (NOT the IDE), and it crashed > again. My understanding is that running tk form the interpreter is > problematic anyway, so it's no big deal. Problematic, yes. But "crashing" is taking "problematic" to the extreme:-) Anyway: could you pls remember to try this again when the next release comes out? Maybe it only works correctly for me:-) > Another little note on BuildApplication: It asks whether you want a Fat, > PPC or 68k app, but I thought 68k was no longer supported. Ah, good one. I'll fix it. > Also, I still need to keep telling it where PythonCore is. How do I stop > that? Try removing anything with "python" in the name from your system folder and running ConfigurePython. -- 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 rtrocca@libero.it Fri Jul 21 16:01:17 2000 From: rtrocca@libero.it (Riccardo Trocca) Date: Fri, 21 Jul 2000 17:01:17 +0200 Subject: [Pythonmac-SIG] OpenGL and MacPython Message-ID: Hello does somebody know how to use OpenGL from macPython? I was using it with Python under LinuxPPC, but I don't think that the same solution would work with Mac. Anywayy I'd just need a connection to AGL, so I think that using bgen or something similar should work. THe problem is that I never used them. So I'm asking if somebody already did it or knows how to do it. Some advice (I've already looked at bgen examples, but I've been a little bit scared by them.... :-( ). Riccardo From smith@oe.fau.edu Fri Jul 21 18:58:56 2000 From: smith@oe.fau.edu (Samuel Smith) Date: Fri, 21 Jul 2000 13:58:56 -0400 Subject: [Pythonmac-SIG] Pythoncore not found and web sharing cgi In-Reply-To: <20000721100847.1737CD2CC3@oratrix.oratrix.nl> References: <20000721100847.1737CD2CC3@oratrix.oratrix.nl> Message-ID: --============_-1247920153==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > >> Also, I still need to keep telling it where PythonCore is. How do I stop > that? >Try removing anything with "python" in the name from your system >folder and running ConfigurePython. I have had a similar problem. I had an alias to the python core in my system:extensions folder. But I kept getting can't find python core errors. If I throw away the alias and then make a new one it works fine with no errors until the next time I restart my Mac then the error occurs again. I finally just moved the pythoncore into my extensions folder and got rid of the alias. I looked at the original for the alias and it had the appletalk domain: machine name: on the front of the path. I find that interesting. Not all aliases on my machine do this but all the recent ones I make have it. This is something strange about MacOS I am not familiar with. Could this be breaking the lookup by python? I have MacOS 9.0.4 on a Lombard Powerbook and python 1.5.2c1. Note the pythoncore was on a different partition than the system folder when the problem occured. This may not be relevant. BTW. On a completely unrelated topic . I was able to get python cgi scripts running with personal web sharing using the pythoncgislave (thanks Just). I am surprised that the latest incarnation (march 2000) of the pythoncgislave script is not readily available either in the vaults of parnasses or on the python mac web page, it is really useful. I found it in an old posting. Anyway if you add a "launch on suffix" action to web sharing with the suffix set to .py and the application to launch set to the pythoncgislave applet then any url with a .py will run as a cgi script. Examples are attached below. Sam, --============_-1247920153==_============ Content-Id: Content-Type: text/html; name="submit.html"; charset="us-ascii" ; format="flowed" Content-Disposition: attachment; filename="submit.html" ; modification-date="Tue, 4 Jul 2000 18:02:00 -0400" ; x-mac-type="54455854" ; x-mac-creator="522A6368" Adept Test Page

Please enter your name and address.
















 
 
[Adept Systems]
--============_-1247920153==_============ Content-Id: Content-Type: multipart/appledouble; boundary="============_-1247920153==_D============" --============_-1247920153==_D============ Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="%processform.py" Content-Disposition: attachment; filename="%processform.py" ; modification-date="Sat, 8 Jul 2000 09:43:57 -0400" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAAA4AAAAJAAAATAAAACAA AAAIAAAAbAAAABBwcm9jZXNzZm9ybS5weVRFWFRSKmNoAQAACwEUAAAAAAAAAAAAAIAA AAAAAAAAAPR6HgD5tF1LbQwAAQsTpw== --============_-1247920153==_D============ Content-Type: application/octet-stream; name="processform.py" Content-Disposition: attachment; filename="processform.py" Content-Transfer-Encoding: base64 IiIiDVNlbmRzIGVtYWlsIHdpdGggbmFtZSBhbmQgY29udGFjdCBpbmZvcm1hdGlvbi4N YXNzdW1lcyBjZXJ0YWluIGZpZWxkcyBpbiBmb3JtIG9yIGdldCBVUkwNYXNzdW1lcyB0 aGF0IHRoaXMgc2NyaXB0IGlzIHJ1biBieSBjZ2lzbGF2ZXNlcnZlciBvbiBhIG1hY2lu dG9zaA0JIA0iIiINDWltcG9ydCBvcw1pbXBvcnQgc3lzDWltcG9ydCBjZ2kNaW1wb3J0 IHN0cmluZw1pbXBvcnQgY1N0cmluZ0lPDWltcG9ydCBzbXRwbGliDQ0jIGRlZmF1bHQg dmFsdWVzIGZvciBlbWFpbA1tYWlsc2VydmVyID0gInNhdmFpaS5hZGVwdHN5c3RlbXNp bmMuY29tIgkgDW1haWxzZW5kZXIgPSAid2VibWFzdGVyQGFkZXB0c3lzdGVtc2luYy5j b20iDW1haWxyZWNpcGllbnQgPSBtYWlsc2VuZGVyDW1haWxzdWJqZWN0ID0gIkNvbnRh Y3QgaW5mbyBmcm9tIHdlYiBwYWdlIGZvcm0uIg0NIyBzZXQgdXAgc3RyaW5nIGZpbGUg b2JqZWN0IHNvIHdlIGNhbiB1c2UgZmlsZSBpbyB0byBnZW5lcmF0ZSBtYWlsIG1lc3Nh Z2UNbWFpbHRleHQgPSBjU3RyaW5nSU8uU3RyaW5nSU8oKQkNDSMgc2V0dXAgZmlsZSB0 byBzdG9yZSByZXF1ZXN0cw1maWxlbmFtZSA9ICJjb250YWN0ZGF0YS50eHQiDQ0jIHBy b2Nlc3MgdGhlIGNnaSBpbnB1dA1mb3JtID0gY2dpLkZpZWxkU3RvcmFnZSgpDQ0NIyBj aGVjayB0byBzZWUgaWYgcmVxdWlyZWQgZmllbGRzIGFyZSBwcmVzZW50LiB0aGUgZmll bGQgbmFtZWQgJ3JlcXVpcmVkJw0jIGhhcyB0aGUgbmFtZXMgb2YgdGhlIHJlcXVpcmVk IGZpZWxkcyBhcyBhIHNwYWNlIGRlbGltaXRlZCBsaXN0IG9mIHdvcmRzDQ1taXNzaW5n ID0gW10gICMgcGxhY2UgdG8gcHV0IG1pc3NpbmcgZmllbGQgbmFtZXMgaWYgYW55DQ1p ZiBmb3JtLmhhc19rZXkoInJlcXVpcmVkIik6ICMgaXRlcmF0ZSB0aHJvdWdoIGxpc3Qg b2YgcmVxdWlyZWQgZmllbGQgbmFtZXMNCWZvciBmaWVsZCBpbiBzdHJpbmcuc3BsaXQo Zm9ybVsicmVxdWlyZWQiXS52YWx1ZSk6IA0JCWlmIG5vdChmb3JtLmhhc19rZXkoZmll bGQpKSBvciBmb3JtW2ZpZWxkXS52YWx1ZSA9PSAiIjogIA0JCQltaXNzaW5nLmFwcGVu ZChmaWVsZCkgIyBhcHBlbmQgbWlzc2luZyBmaWVsZCBuYW1lIHRvIGxpc3QNCQ1pZiBt aXNzaW5nICE9IFtdOgkgIyBwcmludCBvdXQgZXJyb3IgcGFnZQ0JcHJpbnQgIiIiSFRU UC8xLjAgMjAwIE9LDQkJCQlTZXJ2ZXI6IFBlcnNvbmFsV2ViU2hhcmluZzsgcHl0aG9u LWNnaS1zY3JpcHQNCQkJCU1JTUUtVmVyc2lvbjogMS4wDQkJCQlDb250ZW50LXR5cGU6 IHRleHQvaHRtbA0JCQkiIiINCXByaW50ICIiIg0JCQkJPGh0bWw+DQkJCQkJPGhlYWQ+ DQkJCQkJCTx0aXRsZT5TdWJtaXNzaW9uIEZhaWxlZDwvdGl0bGU+DQkJCQkJPC9oZWFk Pg0JCQkJCQk8Ym9keT4NCQkJCQkJCTxoMT5TdWJtaXNzaW9uIEZhaWxlZDwvaDE+DQkJ CQkJCQk8cD5UaGUgZm9sbG93aW5nIGZpZWxkcyB3ZXJlIG5vdCBmaWxsZWQgaW46PC9w Pg0JCQkJCQkJPFVMPg0JCQkiIiINCWZvciBmaWVsZCBpbiBtaXNzaW5nOg0JCXByaW50 ICIJPGxpPiIgKyBmaWVsZA0JIA0JcHJpbnQgIiIiDQkgCQkJIDwvVUw+DQkJCQkJPHA+ IFBsZWFzZSBnbyBiYWNrIGFuZCBjb21wbGV0ZSBhbGwgcmVxdWlyZWQgZmllbGRzIDwv cD4NCQkJCSA8L2JvZHk+DQkJCQkgPC9odG1sPg0JCQkgIiIiDWVsc2U6CSAjIGFsbCBy ZXF1aXJlZCBmaWVsZHMgYXJlIHByZXNlbnQgDQkjIGdldCBtYWlsIGZpZWxkcyBpZiBw cmVzZW50DQlpZiBmb3JtLmhhc19rZXkoInJlY2lwaWVudCIpIGFuZCBmb3JtWyJyZWNp cGllbnQiXS52YWx1ZSAhPSAiIjoNCQltYWlscmVjaXBpZW50ID0gZm9ybVsicmVjaXBp ZW50Il0udmFsdWUgICNzZXQgcmVjaXBpZW50IG90aGVyd2lzZSB1c2UgZGVmYXVsdAkJ CQkgDQkNCWlmIGZvcm0uaGFzX2tleSgic3ViamVjdCIpIGFuZCBmb3JtWyJzdWJqZWN0 Il0udmFsdWUgIT0gIiI6DQkJbWFpbHN1YmplY3QgPSBmb3JtWyJzdWJqZWN0Il0udmFs dWUgICNzZXQgc3ViamVjdCBvdGhlcndpc2UgdXNlIGRlZmF1bHQNCQ0JIyBnZXQgZmls ZSBmaWVsZCBpZiBwcmVzZW50IGFuZCBzZXQgdXAgZmlsZQ0JaWYgZm9ybS5oYXNfa2V5 KCJmaWxlIikgYW5kIGZvcm1bImZpbGUiXS52YWx1ZSAhPSAiIjoNCQlmaWxlbmFtZSA9 IGZvcm1bImZpbGUiXS52YWx1ZSAgI3NldCBmaWxlbmFtZSBvdGhlcndpc2UgdXNlIGRl ZmF1bHQNCQ0JY29udGFjdGZpbGUgPSBvcGVuKGZpbGVuYW1lLCJhKyIpDQljb250YWN0 ZmlsZS5zZWVrKDApDQkNCWlmIGNvbnRhY3RmaWxlLnJlYWQoMSkgPT0gIiI6DQkJd3Jp dGVoZWFkZXIgPSAxDQllbHNlOg0JCXdyaXRlaGVhZGVyID0gMA0JDQljb250YWN0Zmls ZS5zZWVrKDAsMikNCQ0JIyBGaWxsIGluIGhlYWRlciB0byBlbWFpbA0JbWFpbHRleHQu d3JpdGUoIlN1YmplY3Q6ICVzIFxuVG86ICVzXG5cbiIgJSAobWFpbHN1YmplY3QsbWFp bHJlY2lwaWVudCkgKQ0JDQlmaWVsZGxpc3QgPSBbXQ0JaWYgZm9ybS5oYXNfa2V5KCJz dWJtaXR0ZWQiKTogIyBpdGVyYXRlIHRocm91Z2ggbGlzdCBvZiBmaWVsZCBuYW1lcyB0 byBzdWJtaXQNCQlmaWVsZGxpc3QgPSBzdHJpbmcuc3BsaXQoZm9ybVsic3VibWl0dGVk Il0udmFsdWUpDQkJIyB3cml0ZSBmaWVsZCBuYW1lcw0JCWZvciBmaWVsZCBpbiBmaWVs ZGxpc3RbOi0xXTogDQkJCW1haWx0ZXh0LndyaXRlKCIlc1x0IiAlIGZpZWxkKQ0JCQlp ZiB3cml0ZWhlYWRlcjoNCQkJCWNvbnRhY3RmaWxlLndyaXRlKCIlc1x0IiAlIGZpZWxk KQ0JCW1haWx0ZXh0LndyaXRlKCIlc1xuIiAlIGZpZWxkbGlzdFstMV0pDQkJaWYgd3Jp dGVoZWFkZXI6DQkJCWNvbnRhY3RmaWxlLndyaXRlKCIlc1xuIiAlIGZpZWxkbGlzdFst MV0pDQkJCQkNCQkjIHdyaXRlIGZpZWxkIHZhbHVlcw0JCWZvciBmaWVsZCBpbiBmaWVs ZGxpc3RbOi0xXTogDQkJCWlmIGZvcm0uaGFzX2tleShmaWVsZCk6ICANCQkJCW1haWx0 ZXh0LndyaXRlKCIlc1x0IiAlIGZvcm1bZmllbGRdLnZhbHVlKQ0JCQkJY29udGFjdGZp bGUud3JpdGUoIiVzXHQiICUgZm9ybVtmaWVsZF0udmFsdWUpDQkJCWVsc2U6DQkJCQlt YWlsdGV4dC53cml0ZSgiXHQiKQ0JCQkJY29udGFjdGZpbGUud3JpdGUoIlx0IikNCQlp ZiBmb3JtLmhhc19rZXkoZmllbGRsaXN0Wy0xXSk6DQkJCW1haWx0ZXh0LndyaXRlKCIl c1xuIiAlIGZvcm1bZmllbGRsaXN0Wy0xXV0udmFsdWUpDQkJCWNvbnRhY3RmaWxlLndy aXRlKCIlc1xuIiAlIGZvcm1bZmllbGRsaXN0Wy0xXV0udmFsdWUpDQkJZWxzZToNCQkJ bWFpbHRleHQud3JpdGUoIlxuIikNCQkJY29udGFjdGZpbGUud3JpdGUoIlxuIikNCQ0J Y29udGFjdGZpbGUuY2xvc2UoKQ0JDQkjIHNlbmQgZW1haWwJCQkJCQkNCXNlcnZlciA9 IHNtdHBsaWIuU01UUChtYWlsc2VydmVyKQ0Jc2VydmVyLnNlbmRtYWlsKG1haWxzZW5k ZXIsbWFpbHJlY2lwaWVudCxtYWlsdGV4dC5nZXR2YWx1ZSgpKQ0JbWFpbHRleHQuY2xv c2UoKQ0Jc2VydmVyLnF1aXQoKQ0JDQkNCQkNCSMgZm9ybWF0IGNvbmZpcm1hdGlvbiBw YWdlDQlwcmludCAiIiJIVFRQLzEuMCAyMDAgT0sNCQkJCVNlcnZlcjogUGVyc29uYWxX ZWJTaGFyaW5nOyBweXRob24tY2dpLXNjcmlwdA0JCQkJTUlNRS1WZXJzaW9uOiAxLjAN CQkJCUNvbnRlbnQtdHlwZTogdGV4dC9odG1sDQkJCSIiIg0JcHJpbnQgIiIiDQkJCQk8 aHRtbD4NCQkJCQk8aGVhZD4NCQkJCQkJPHRpdGxlPlN1Ym1pc3Npb24gU3VjY2VlZGVk PC90aXRsZT4NCQkJCQk8L2hlYWQ+DQkJCQkJCTxib2R5Pg0JCQkJCQkJPGgxPllvdXIg U3VibWlzc2lvbiBTdWNjZWVkZWQ8L2gxPg0JCQkJCQkJPHA+V2UgaGF2ZSByZWNlaXZl ZCB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uOzwvcD4NCQkJCQkJCQ0JCQkiIiINCWZv ciBmaWVsZCBpbiBmaWVsZGxpc3Q6IA0JCWlmIGZvcm0uaGFzX2tleShmaWVsZCk6ICAN CQkJcHJpbnQgIiVzOiAlczxicj4iICUgKGZvcm1bZmllbGRdLm5hbWUsIGZvcm1bZmll bGRdLnZhbHVlKQ0JCQkNCQ0gDQlwcmludCAiIiINCQkJCQk8cD5UaGFuayB5b3UgdmVy eSBtdWNoITwvcD4NCQkJCSA8L2JvZHk+DQkJCQkgPC9odG1sPg0JCQkgIiIiCQ0JDQkN CQ0= --============_-1247920153==_D============-- --============_-1247920153==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" -- ********************************** Samuel M. Smith Ph.D. Professor Director Advanced Marine Systems Lab **************(Dania Building)*********************** Institute for Ocean and Systems Engineering Florida Atlantic University Rm. 225 B, SeaTech Bldg. 101 North Beach Road, Dania, FL 33004 (voice) 954-924-7232 (secretary Paula) 954-924-7230 (fax) 954-924-7233 (mobile) 561-251-2114 (email) smith@oe.fau.edu (web) http://www.oe.fau.edu ************** (Boca Raton Campus) ******************* Ocean Engineering Dept. Bldg. 36 Florida Atlantic University 777 Glades Rd, Boca Raton FL 33431 (voice) 561-297-3606 (reception) 561-297-3430 (fax) 561-297-3885 (email) smith@oe.fau.edu (web) http://www.oe.fau.edu *********************************** --============_-1247920153==_============-- From sales@lookelu.com Fri Jul 21 12:15:59 2000 From: sales@lookelu.com (The Western Web) Date: Fri, 21 Jul 2000 11:15:59 Subject: [Pythonmac-SIG] The Western Web Newsletter Message-ID: <20000721181422.1ED721CF00@dinsdale.python.org> THE WESTERN WEB WEEKLY NEWS LETTER Serving Over 75,000 Recipients The Western Web continues to grow and your patronage is greatly appreciated. The Western Web now has over 1500 new classified ads. You can now add pictures,video and audio for free with your free ad. It is easy to do and with our automated system these ads are posted immediately. To place an ad go to: http://www.westernwebclassified.com/cgi-bin/classifieds/classifieds.cgi Be sure to check out our search engine. We have over 1700 links to western lifestyles with categories for Art, Auto Racing, Dogs, Fishing, Gifts, Horses, Hunting,Livestock, Model Horses, Rodeo, Tractors, Trailers, Truck, Western Furniture,Western Lifestyles and Western Wear. All of the listed categories also have many subcategories to meet all your personal needs. You can go to the site and add a link to your site free. It is easy and your site will be posted in a timely manner. For all of you who have posted your Internet Sites go to our search engine to make sure your site has been posted and the links are correct. Take care when typing your web address. We test all sites before posting, if the link is not good, they are not posted. If your site has not been posted please resubmit. You can access the Search Engine from The Western Web home page or http://www.searchthewesternweb.com To add your link, select a category and necessary subcategories. Click on Add-a-listing and post you link. It is easy and free. Now, take a look at our upgraded message board: http://www.westernmessageboard.com/cgi-bin/Ultimate.cgi Many new groupings have been added. You can check prices on Logo or Banner advertising at: http://www.thewesternweb.com/Advertising/Advertising.htm For you convenience, there are links to these sites and more, from The Western Web Home Page. Thank You, http://www.thewesternweb.com If you receive this message in error or want us to remove you from our newsletter of mailing list, please reply to this email address with the word "Remove" in the subject line. From jack@oratrix.nl Fri Jul 21 22:49:05 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 21 Jul 2000 23:49:05 +0200 Subject: [Pythonmac-SIG] Pythoncore not found and web sharing cgi In-Reply-To: Message by Samuel Smith , Fri, 21 Jul 2000 13:58:56 -0400 , Message-ID: <20000721214910.672E8D2CC4@oratrix.oratrix.nl> That's interesting, the bit about the alias containing the host name. It also reminds me that the alias file that is dropped in the extensions folder is created by code that I wrote myself and that tries to mimic the Finder behaviour in creating alias files. This behaviour isn't documented, though (at least: it wasn't a few years ago when I did it) and there is no official API for it either. So it could well be that the alias file isn't completely what MacOS expects. If someone knows of Apple documentation that specifies how to create alias files and we use that maybe this problem will go away? Maybe someone who has this problem could create a finder alias (through the Finder) to PythonCore and use ResEdit or Resourcerer to look whether this aslias is exactly identical to the one ConfigurePython creates? I just tried it on my system here at home (iMac, 9.0.4, File sharing off) and they are almost identical (in the Finder alias file the alis resource has the name "PythonCore", not so in the ConfigurePython one). The alis resource doesn't list the machine or zone name. But then I don't have problem, of course... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jaredu@its.caltech.edu Sat Jul 22 01:05:44 2000 From: jaredu@its.caltech.edu (Jared Updike) Date: Fri, 21 Jul 2000 17:05:44 -0700 (PDT) Subject: [Pythonmac-SIG] test_socket failed, reverse name lookup Message-ID: >Your nameserver is broken. The three calls in the test script are > hostname = socket.gethostname() > ip = socket.gethostbyname(hostname) > hname, aliases, ipaddrs = socket.gethostbyaddr(ip) >and only the final one, which does the reverse lookup on your IP address, >apparently fails. The various RFC standards specify that for each IP >address the reverse mapping should always work. Now my question is, exactly how do I go about fixing this? Is there a configuration I need to set on this machine so MacOS knows the machine's name, and/or is it external to this machine? (in which case I have already sent e-mail to the network admins with the same question)? I'm guessing that there are multiple places for things to go wrong, and no single, easy solution, but I honestly don't understand exactly what's wrong, and hence how to fix it. I'll read te RFC about it, for now. >As an aside, you'll also have trouble accessing ftp.cwi.nl to load a new >MacPython (as that machine uses reverse mapping as part of its anti-abuse >policy). BTW your prediction was correct (I'd had that problem before you even mentioned it...) --Jared Web: http://waffles.caltech.edu Phone: (626)395-1154 Campus Adress: Blacker Hovse, Room 31 Adress: MSC 935 Caltech Pasadena, CA 91126-0935 From smith@oe.fau.edu Sat Jul 22 17:23:34 2000 From: smith@oe.fau.edu (Samuel Smith) Date: Sat, 22 Jul 2000 12:23:34 -0400 Subject: [Pythonmac-SIG] Pythoncore not found and web sharing cgi In-Reply-To: <20000721214910.672E8D2CC4@oratrix.oratrix.nl> References: <20000721214910.672E8D2CC4@oratrix.oratrix.nl> Message-ID: --============_-1247839463==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >That's interesting, the bit about the alias containing the host name. >It also reminds me that the alias file that is dropped in the >extensions folder is created by code that I wrote myself and that >tries to mimic the Finder behaviour in creating alias files. This >behaviour isn't documented, though (at least: it wasn't a few years >ago when I did it) and there is no official API for it either. > >So it could well be that the alias file isn't completely what MacOS >expects. If someone knows of Apple documentation that specifies how to >create alias files and we use that maybe this problem will go away? > >Maybe someone who has this problem could create a finder alias >(through the Finder) to PythonCore and use ResEdit or Resourcerer to >look whether this aslias is exactly identical to the one >ConfigurePython creates? I have the problem with both the alias that configure python creates and any aliases I make myself with the finder. It might be something to do with how the python core shared library is loaded (something gets lost in the directory lookup when the reference is an alias with the appletalk domain and host prepended. But that doesn't explain why it works until the next reset. Anyway attached is a resource file with both of my alias resources (I couldn't attach the aliases themselves Eudora kept attaching the original. >I just tried it on my system here at home (iMac, 9.0.4, File sharing >off) and they are almost identical (in the Finder alias file the alis >resource has the name "PythonCore", not so in the ConfigurePython >one). The alis resource doesn't list the machine or zone name. But >then I don't have problem, of course... Yea I get the same difference except mine have the zone name and host >-- >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 > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://www.python.org/mailman/listinfo/pythonmac-sig --============_-1247839463==_============ Content-Id: Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="Test" Content-Disposition: attachment; filename="Test" ; modification-date="Sat, 22 Jul 2000 12:21:14 -0400" AAUWAAACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAADAAAASgAAAAQAAAAJAAAATgAAACAA AAAIAAAAbgAAABAAAAACAAAAfgAABHlUZXN0cnNyY1JTRUQBAABAAIEAAAAAAAAAAAAA AAAAAAAAAAABDE3NAQxOOkttDAABDE7ZAAABAAAABDAAAAMwAAAASQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZQAAAAAAZQAAgAABkludEhEQgAAAAAA AAAAAAAAAAAAAAAAAAAAALS6eJtCRAAAAAAowgpQeXRob25Db3JlAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC6LtRbEcnNo bGJQeXRoAAEAAwAAABEAAAAAAAAAAAAAAAAAAAAOUHl0aG9uIDEuNS4yYzEAAQAIAAAo wgAAKHsAAgAsSW50SERCOlB5dGhvblN0dWZmOlB5dGhvbiAxLjUuMmMxOlB5dGhvbkNv cmUACQCoAKhhZnBtAAAAAAADABgAOQBZAHUAlQCeBWFkZXB0AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABVVwb2x1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGSW50SERC AAAAAAAAAAAAAAAAAAAAAAAAAAAADFNhbXVlbCBTbWl0aAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA//8AAAAAAZQAAAAAAZQAAgAABkludEhEQgAAAAAA AAAAAAAAAAAAAAAAAAAAALS6eJtCRAAAAAAowgpQeXRob25Db3JlAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC6LtRbEcnNo bGJQeXRo/////wAAABEAAAAAAAAAAAAAAAAAAAAOUHl0aG9uIDEuNS4yYzEAAQAIAAAo wgAAKHsAAgAsSW50SERCOlB5dGhvblN0dWZmOlB5dGhvbiAxLjUuMmMxOlB5dGhvbkNv cmUACQCoAKhhZnBtAAAAAAADABgAOQBZAHUAlQCeBWFkZXB0AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABVVwb2x1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGSW50SERC AAAAAAAAAAAAAAAAAAAAAAAAAAAADFNhbXVlbCBTbWl0aAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA//8AAAAAAQAAAAQwAAADMAAAAEkIDAqkBeoAAAAc AD4AAGFsaXMAAQAKAAAAAAAAAAAIDAlwAID//wAAAZgIDAm0ClB5dGhvbkNvcmU= --============_-1247839463==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" -- ********************************** Samuel M. Smith Ph.D. Professor Director Advanced Marine Systems Lab **************(Dania SeaTech Building)*********************** Institute for Ocean and Systems Engineering Florida Atlantic University Rm. 225 B, SeaTech Bldg. 101 North Beach Road, Dania, FL 33004 (voice) 954-924-7232 (secretary Paula) 954-924-7230 (fax) 954-924-7233 (mobile) 561-251-2114 (email) smith@oe.fau.edu (web) http://www.oe.fau.edu --============_-1247839463==_============-- From smith@oe.fau.edu Sat Jul 22 17:33:04 2000 From: smith@oe.fau.edu (Samuel Smith) Date: Sat, 22 Jul 2000 12:33:04 -0400 Subject: [Pythonmac-SIG] Using Python .py scripts for CGI with personal web sharing Message-ID: --============_-1247838906==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I am reposting this on its own just in case it got lost as part of the other post. I was able to get python .py cgi scripts running with personal web sharing using the pythoncgislave (thanks Just). Anyway if you add a "launch on suffix" action to web sharing with the suffix set to .py and the application to launch set to the pythoncgislave applet then any url with a .py will run as a cgi script. Examples are attached. I am surprised that the latest incarnation (march 2000) of the pythoncgislave script is not readily available either in the vaults of parnasses or on the python mac web page. I found it in an old posting from Just. It is attached FYI. Sam, --============_-1247838906==_============ Content-Id: Content-Type: text/html; name="submit.html"; charset="us-ascii" ; format="flowed" Content-Disposition: attachment; filename="submit.html" ; modification-date="Fri, 21 Jul 2000 14:05:09 -0400" ; x-mac-type="54455854" ; x-mac-creator="522A6368" Adept Test Page

Please enter your name and address.
















 
 
[Adept Systems]
--============_-1247838906==_============ Content-Id: Content-Type: multipart/appledouble; boundary="============_-1247838906==_D============" --============_-1247838906==_D============ Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="%processform.py" Content-Disposition: attachment; filename="%processform.py" ; modification-date="Sat, 8 Jul 2000 09:43:57 -0400" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAAA4AAAAJAAAATAAAACAA AAAIAAAAbAAAABBwcm9jZXNzZm9ybS5weVRFWFRSKmNoAAAAAAAAAAAAAAAAAAAAAIAA AAAAAAAAAPR6HgD5tF0BCxUVAQxRBg== --============_-1247838906==_D============ Content-Type: application/octet-stream; name="processform.py" Content-Disposition: attachment; filename="processform.py" Content-Transfer-Encoding: base64 IiIiDVNlbmRzIGVtYWlsIHdpdGggbmFtZSBhbmQgY29udGFjdCBpbmZvcm1hdGlvbi4N YXNzdW1lcyBjZXJ0YWluIGZpZWxkcyBpbiBmb3JtIG9yIGdldCBVUkwNYXNzdW1lcyB0 aGF0IHRoaXMgc2NyaXB0IGlzIHJ1biBieSBjZ2lzbGF2ZXNlcnZlciBvbiBhIG1hY2lu dG9zaA0JIA0iIiINDWltcG9ydCBvcw1pbXBvcnQgc3lzDWltcG9ydCBjZ2kNaW1wb3J0 IHN0cmluZw1pbXBvcnQgY1N0cmluZ0lPDWltcG9ydCBzbXRwbGliDQ0jIGRlZmF1bHQg dmFsdWVzIGZvciBlbWFpbA1tYWlsc2VydmVyID0gInNhdmFpaS5hZGVwdHN5c3RlbXNp bmMuY29tIgkgDW1haWxzZW5kZXIgPSAid2VibWFzdGVyQGFkZXB0c3lzdGVtc2luYy5j b20iDW1haWxyZWNpcGllbnQgPSBtYWlsc2VuZGVyDW1haWxzdWJqZWN0ID0gIkNvbnRh Y3QgaW5mbyBmcm9tIHdlYiBwYWdlIGZvcm0uIg0NIyBzZXQgdXAgc3RyaW5nIGZpbGUg b2JqZWN0IHNvIHdlIGNhbiB1c2UgZmlsZSBpbyB0byBnZW5lcmF0ZSBtYWlsIG1lc3Nh Z2UNbWFpbHRleHQgPSBjU3RyaW5nSU8uU3RyaW5nSU8oKQkNDSMgc2V0dXAgZmlsZSB0 byBzdG9yZSByZXF1ZXN0cw1maWxlbmFtZSA9ICJjb250YWN0ZGF0YS50eHQiDQ0jIHBy b2Nlc3MgdGhlIGNnaSBpbnB1dA1mb3JtID0gY2dpLkZpZWxkU3RvcmFnZSgpDQ0NIyBj aGVjayB0byBzZWUgaWYgcmVxdWlyZWQgZmllbGRzIGFyZSBwcmVzZW50LiB0aGUgZmll bGQgbmFtZWQgJ3JlcXVpcmVkJw0jIGhhcyB0aGUgbmFtZXMgb2YgdGhlIHJlcXVpcmVk IGZpZWxkcyBhcyBhIHNwYWNlIGRlbGltaXRlZCBsaXN0IG9mIHdvcmRzDQ1taXNzaW5n ID0gW10gICMgcGxhY2UgdG8gcHV0IG1pc3NpbmcgZmllbGQgbmFtZXMgaWYgYW55DQ1p ZiBmb3JtLmhhc19rZXkoInJlcXVpcmVkIik6ICMgaXRlcmF0ZSB0aHJvdWdoIGxpc3Qg b2YgcmVxdWlyZWQgZmllbGQgbmFtZXMNCWZvciBmaWVsZCBpbiBzdHJpbmcuc3BsaXQo Zm9ybVsicmVxdWlyZWQiXS52YWx1ZSk6IA0JCWlmIG5vdChmb3JtLmhhc19rZXkoZmll bGQpKSBvciBmb3JtW2ZpZWxkXS52YWx1ZSA9PSAiIjogIA0JCQltaXNzaW5nLmFwcGVu ZChmaWVsZCkgIyBhcHBlbmQgbWlzc2luZyBmaWVsZCBuYW1lIHRvIGxpc3QNCQ1pZiBt aXNzaW5nICE9IFtdOgkgIyBwcmludCBvdXQgZXJyb3IgcGFnZQ0JcHJpbnQgIiIiSFRU UC8xLjAgMjAwIE9LDQkJCQlTZXJ2ZXI6IFBlcnNvbmFsV2ViU2hhcmluZzsgcHl0aG9u LWNnaS1zY3JpcHQNCQkJCU1JTUUtVmVyc2lvbjogMS4wDQkJCQlDb250ZW50LXR5cGU6 IHRleHQvaHRtbA0JCQkiIiINCXByaW50ICIiIg0JCQkJPGh0bWw+DQkJCQkJPGhlYWQ+ DQkJCQkJCTx0aXRsZT5TdWJtaXNzaW9uIEZhaWxlZDwvdGl0bGU+DQkJCQkJPC9oZWFk Pg0JCQkJCQk8Ym9keT4NCQkJCQkJCTxoMT5TdWJtaXNzaW9uIEZhaWxlZDwvaDE+DQkJ CQkJCQk8cD5UaGUgZm9sbG93aW5nIGZpZWxkcyB3ZXJlIG5vdCBmaWxsZWQgaW46PC9w Pg0JCQkJCQkJPFVMPg0JCQkiIiINCWZvciBmaWVsZCBpbiBtaXNzaW5nOg0JCXByaW50 ICIJPGxpPiIgKyBmaWVsZA0JIA0JcHJpbnQgIiIiDQkgCQkJIDwvVUw+DQkJCQkJPHA+ IFBsZWFzZSBnbyBiYWNrIGFuZCBjb21wbGV0ZSBhbGwgcmVxdWlyZWQgZmllbGRzIDwv cD4NCQkJCSA8L2JvZHk+DQkJCQkgPC9odG1sPg0JCQkgIiIiDWVsc2U6CSAjIGFsbCBy ZXF1aXJlZCBmaWVsZHMgYXJlIHByZXNlbnQgDQkjIGdldCBtYWlsIGZpZWxkcyBpZiBw cmVzZW50DQlpZiBmb3JtLmhhc19rZXkoInJlY2lwaWVudCIpIGFuZCBmb3JtWyJyZWNp cGllbnQiXS52YWx1ZSAhPSAiIjoNCQltYWlscmVjaXBpZW50ID0gZm9ybVsicmVjaXBp ZW50Il0udmFsdWUgICNzZXQgcmVjaXBpZW50IG90aGVyd2lzZSB1c2UgZGVmYXVsdAkJ CQkgDQkNCWlmIGZvcm0uaGFzX2tleSgic3ViamVjdCIpIGFuZCBmb3JtWyJzdWJqZWN0 Il0udmFsdWUgIT0gIiI6DQkJbWFpbHN1YmplY3QgPSBmb3JtWyJzdWJqZWN0Il0udmFs dWUgICNzZXQgc3ViamVjdCBvdGhlcndpc2UgdXNlIGRlZmF1bHQNCQ0JIyBnZXQgZmls ZSBmaWVsZCBpZiBwcmVzZW50IGFuZCBzZXQgdXAgZmlsZQ0JaWYgZm9ybS5oYXNfa2V5 KCJmaWxlIikgYW5kIGZvcm1bImZpbGUiXS52YWx1ZSAhPSAiIjoNCQlmaWxlbmFtZSA9 IGZvcm1bImZpbGUiXS52YWx1ZSAgI3NldCBmaWxlbmFtZSBvdGhlcndpc2UgdXNlIGRl ZmF1bHQNCQ0JY29udGFjdGZpbGUgPSBvcGVuKGZpbGVuYW1lLCJhKyIpDQljb250YWN0 ZmlsZS5zZWVrKDApDQkNCWlmIGNvbnRhY3RmaWxlLnJlYWQoMSkgPT0gIiI6DQkJd3Jp dGVoZWFkZXIgPSAxDQllbHNlOg0JCXdyaXRlaGVhZGVyID0gMA0JDQljb250YWN0Zmls ZS5zZWVrKDAsMikNCQ0JIyBGaWxsIGluIGhlYWRlciB0byBlbWFpbA0JbWFpbHRleHQu d3JpdGUoIlN1YmplY3Q6ICVzIFxuVG86ICVzXG5cbiIgJSAobWFpbHN1YmplY3QsbWFp bHJlY2lwaWVudCkgKQ0JDQlmaWVsZGxpc3QgPSBbXQ0JaWYgZm9ybS5oYXNfa2V5KCJz dWJtaXR0ZWQiKTogIyBpdGVyYXRlIHRocm91Z2ggbGlzdCBvZiBmaWVsZCBuYW1lcyB0 byBzdWJtaXQNCQlmaWVsZGxpc3QgPSBzdHJpbmcuc3BsaXQoZm9ybVsic3VibWl0dGVk Il0udmFsdWUpDQkJIyB3cml0ZSBmaWVsZCBuYW1lcw0JCWZvciBmaWVsZCBpbiBmaWVs ZGxpc3RbOi0xXTogDQkJCW1haWx0ZXh0LndyaXRlKCIlc1x0IiAlIGZpZWxkKQ0JCQlp ZiB3cml0ZWhlYWRlcjoNCQkJCWNvbnRhY3RmaWxlLndyaXRlKCIlc1x0IiAlIGZpZWxk KQ0JCW1haWx0ZXh0LndyaXRlKCIlc1xuIiAlIGZpZWxkbGlzdFstMV0pDQkJaWYgd3Jp dGVoZWFkZXI6DQkJCWNvbnRhY3RmaWxlLndyaXRlKCIlc1xuIiAlIGZpZWxkbGlzdFst MV0pDQkJCQkNCQkjIHdyaXRlIGZpZWxkIHZhbHVlcw0JCWZvciBmaWVsZCBpbiBmaWVs ZGxpc3RbOi0xXTogDQkJCWlmIGZvcm0uaGFzX2tleShmaWVsZCk6ICANCQkJCW1haWx0 ZXh0LndyaXRlKCIlc1x0IiAlIGZvcm1bZmllbGRdLnZhbHVlKQ0JCQkJY29udGFjdGZp bGUud3JpdGUoIiVzXHQiICUgZm9ybVtmaWVsZF0udmFsdWUpDQkJCWVsc2U6DQkJCQlt YWlsdGV4dC53cml0ZSgiXHQiKQ0JCQkJY29udGFjdGZpbGUud3JpdGUoIlx0IikNCQlp ZiBmb3JtLmhhc19rZXkoZmllbGRsaXN0Wy0xXSk6DQkJCW1haWx0ZXh0LndyaXRlKCIl c1xuIiAlIGZvcm1bZmllbGRsaXN0Wy0xXV0udmFsdWUpDQkJCWNvbnRhY3RmaWxlLndy aXRlKCIlc1xuIiAlIGZvcm1bZmllbGRsaXN0Wy0xXV0udmFsdWUpDQkJZWxzZToNCQkJ bWFpbHRleHQud3JpdGUoIlxuIikNCQkJY29udGFjdGZpbGUud3JpdGUoIlxuIikNCQ0J Y29udGFjdGZpbGUuY2xvc2UoKQ0JDQkjIHNlbmQgZW1haWwJCQkJCQkNCXNlcnZlciA9 IHNtdHBsaWIuU01UUChtYWlsc2VydmVyKQ0Jc2VydmVyLnNlbmRtYWlsKG1haWxzZW5k ZXIsbWFpbHJlY2lwaWVudCxtYWlsdGV4dC5nZXR2YWx1ZSgpKQ0JbWFpbHRleHQuY2xv c2UoKQ0Jc2VydmVyLnF1aXQoKQ0JDQkNCQkNCSMgZm9ybWF0IGNvbmZpcm1hdGlvbiBw YWdlDQlwcmludCAiIiJIVFRQLzEuMCAyMDAgT0sNCQkJCVNlcnZlcjogUGVyc29uYWxX ZWJTaGFyaW5nOyBweXRob24tY2dpLXNjcmlwdA0JCQkJTUlNRS1WZXJzaW9uOiAxLjAN CQkJCUNvbnRlbnQtdHlwZTogdGV4dC9odG1sDQkJCSIiIg0JcHJpbnQgIiIiDQkJCQk8 aHRtbD4NCQkJCQk8aGVhZD4NCQkJCQkJPHRpdGxlPlN1Ym1pc3Npb24gU3VjY2VlZGVk PC90aXRsZT4NCQkJCQk8L2hlYWQ+DQkJCQkJCTxib2R5Pg0JCQkJCQkJPGgxPllvdXIg U3VibWlzc2lvbiBTdWNjZWVkZWQ8L2gxPg0JCQkJCQkJPHA+V2UgaGF2ZSByZWNlaXZl ZCB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uOzwvcD4NCQkJCQkJCQ0JCQkiIiINCWZv ciBmaWVsZCBpbiBmaWVsZGxpc3Q6IA0JCWlmIGZvcm0uaGFzX2tleShmaWVsZCk6ICAN CQkJcHJpbnQgIiVzOiAlczxicj4iICUgKGZvcm1bZmllbGRdLm5hbWUsIGZvcm1bZmll bGRdLnZhbHVlKQ0JCQkNCQ0gDQlwcmludCAiIiINCQkJCQk8cD5UaGFuayB5b3UgdmVy eSBtdWNoITwvcD4NCQkJCSA8L2JvZHk+DQkJCQkgPC9odG1sPg0JCQkgIiIiCQ0JDQkN CQ0= --============_-1247838906==_D============-- --============_-1247838906==_============ Content-Id: Content-Type: multipart/appledouble; boundary="============_-1247838906==_D============" --============_-1247838906==_D============ Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="%PythonCGISlave.sit" Content-Disposition: attachment; filename="%PythonCGISlave.sit" ; modification-date="Sun, 26 Mar 2000 23:48:50 -0400" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAABIAAAAJAAAAUAAAACAA AAAIAAAAcAAAABBQeXRob25DR0lTbGF2ZS5zaXRTSVREU0lUIQEAACUAyQAAAAAAAAAA AAAAAAAAAAAoewBxXmEAcV5iS20MAAEMUQc= --============_-1247838906==_D============ Content-Type: application/octet-stream; name="PythonCGISlave.sit" ; x-mac-type="53495444" ; x-mac-creator="53495421" Content-Disposition: attachment; filename="PythonCGISlave.sit" Content-Transfer-Encoding: base64 U0lUIQABAAAKWXJMYXUCAAAAABYAACAgDlB5dGhvbkNHSVNsYXZlAAAAAAAAAAAAAAAA AAAAAABmcQmGARYAIALrArAAAAACAAAAAAAAAAAAAAAAAAAAhgAAAhD/////AwC1BDaP tQQ2lQAAAAAAABEQAAAAAAAACdP/8P/4AADDQAAA1NENDRFQeXRob25DR0lTbGF2ZS5w eQAAAAAAAAAAAAAAAAAALZ4JhgAAAAAAAAAAAAAAAAAAABYAAAiwAAAAFv////9URVhU UGlkZQEAr2MJfrUEL90AAAIHAAANxwAAAS0AAAaNcHSNOgAAAAAAAHbLEQAIHPwDhyDW 4i2zuKSZjeO83kzJo7gZrhEf5xVUZgmGSVAWCgyVaZy1bts+mE4GUV90aERSXNdXu0pU 0ox+1AOhpJ6hQCRMESjnsU7j70Mp3q0B4q4G8OSq8dHLLI9DpF86dYptwynpJDMTV8QZ 1Kndnul4t9D0aP+sdNyfC5xBBkZYKpY6Dr0n+7z62CC/t1VmLoeyEn2RYbSyx9G2xmqC l9GXzyGdnMlMKqXTta+ytvYVcIh5CQ2c8RpBwjIjetytXofMi9GKIceJ0eOyCAvzwf14 Fgtn99j6tiY4wtY9ndCtLzjl+/I68vYs1odk9skgEZYdj736aDpNkRHOsjf6dNxMUjr/ iPkb+oxqNM5RKNTWO60LOpoIo7IPkL9vn3CB7CnkWatOAgAAAAtOKXk8QQYwwTPCySqt NTyn3AgnnBwlt/IjlNCTRY9L6Blfn0W5hHJK8ASA4s/1PCb+jQF81Uo44QT9iAWq6+lz evwkxyPHn8w4QdP28AfsDCAMw4utzVV99P3pohQbGTdb2tsjDyKT6qKxZKTeSE2yFjdl Ua97NDiprTMgL+XNwgodB8Fpbawoy4Boj1IthZUkahJNU0pLatVRP6h1TE0pUkk2B5ln MqqSd7nUkora4TqFtFIlBDvSDnmYVbiAdzwIplreUShSW6g6BAyGUGHp4t3yZHaOe1mk t8wNGUThUa6UkSHdtNbCVVFnMLyUKfxqdWdI7BSvFVlFi3a1Kj7SGZAIg3mWbTw6vng3 JrttJC2nPy87DqXpJTJyou7Yjjulbw109dZGgCu4oiEtpTt50+Vul+4KGGgkjEGWDtmQ 6UbWls14yhPUrKBCijR/DKmWH1ppbExnylhcS7kRoGdoI7SopJXakEDarLiVNa20qiDF peterQuGhb0yQ/agXZlY1ptCqzqmZQ5eJuwqYy2tIflRpq2VGadnmRcAVG2JqBh6Wxcf 94zdltK5IAxVLTzDf6OMKW5KOUYHOKwXZCBOwAPNHt/pwlrobZS2qKQtmVy1ZUY1giVK 8HK0/qwmokVRo2aeIuPDVStLH9rCIrO+dQzlQmeQJmrIgwDbNqSQxlwK5+fpisMoP6ay 4ZohlaYtQtSV0r1x47/0soPcGJwyje67EdxICohVgUxwYyFlz2UptVYafcNBhMjaOeaz JQm5QorRErJClFFVCinNpBjT+xahhy+pMFAPJiluqZKV0ts4wAAIghfBC7rsMnWzpR+Y EA1Bc2SxrcbcjNCn15KjZlXZVQTcFxXqgVKVSUcMF2OoCYqKo8k9NlsE7i9epLnMLrht TLQ/pv3dwEk4K+ricPqaS4g61sPpwvXe2INRQEUqOGODLmX6i7EaHdxf04U7n84G+HZg GmLWA6oCvadUaYIgSSDXQGGS0IRGX8X7owCpoFKtfR5dqbr0BZAUG4tm0aBSjawjRiAc m6v9a/qcwi6m2B2h+DzcDYJMrpCQGhLt68WikWm0Mmb3INjR0rYaUTLgN0kjbF4jBhEo of1wSnvfPlQsVd3eCIR8BQzU/xrsjI5P59PRAUWj49nR27Pp+TKZz2bLEQbHo+LdMahu 4aKj+vHtdP4uWSznp+ffg+lc1dIRvEmLxhHMp2ez5TQ5PD6eP+LNpq4cfjGd/zSdJ+eH Z9MnfGMf8RezOTsx4EWWeQM6fSezxe94k/b6juanF8s/9SGveccPCxfL5GyKQXd8T/Eb kpOWwpjn5oz+rhSOYbDDCU0SIG2SRNh+K4btPFPFTwwg6FV9QvJ/XPgpLGSOwi6ljkZC bizcGilEGf+OhSskwf0/Wq77npZv/1JeXl7+8uqbr5nVZCrtWdN10VEwd4OytBR+Zqir P8IJOzXbxiF9Rs5NeOsSlSS4cD0lyRhZGfpy8KASRV0q1aC+ukSxRU7DmF6+REG6zvNk DLX8kjChL3u6PgifKBvo71nuHex4uDaZ6XdGrbDnJliLa3PlK/L6uWJhhB+qk25DxFq6 V4jIk7ouukZ8vuAMHYxcXkDPpW9ivsTvVVFHrBThclqYA5+ifs2bYXI/R+L+0Il7s9If RtdMtyq0sXhTYTrPCx9ExghnUmU4I8NUic+kMWItI8/lZpTT3A2C3/yV58qt3PLog4AY JxO5XDDP1ehkubxIRtgqnfNt03CcnmIAUiyYPZ4xSbi7e802mPUVYNedzZaXpg9Z7I7O MXeJDRaWO3dWjLEny9a95jgCZ0axYijPpsmEVTrQDoYLqqGVHYNfO3GO+IKMbfFOspVO WDd0sH3hhSPrTXL8A9yz7ngfEM4eFzkEe+Xj4XWx3w7oUlMaOYi+Gh1OP6WHfWFOgO4F 4fMw4CZ4QNt4lMEoURjV4PNzEscOhoQMqKJmBc88/ysW12g96z/dE+NdJhrhjYWHRIhc Dy6leVboqO823FxR8tGR9CMX0q4YxPliBtPwyx2qJ+znQXiALCc8B3DjQrJ667sHr0G8 pp2oMQ3sLM+/oziaYajHbp8kgDp3e3sxr+NV2Zq8Q33aEwNVFx0ftgecz5gLG6O6Hc4j kugF5XhFwlMMP0O6By3/+HnLj0v+cegOz1T89sM7/7vHHMQp3la08+U+jn+Y8JcHnQUh V/MXX8b79Gp/n2ZvfqlDFA14ObeuVtzrwPO63Q3+Dw0AE1B5dGhvbkNHSVNsYXZlLnJz cmMAAAAAAAAAAAAAAABCYgmGAAAAAAAAAAAAAAAAAAAAhgAACekAAAAW/////3JzcmNS U0VEAQC1BAEXtQQDyQAAAUIAAAAAAAAAyQAAAADIUAAAAAAAAAAAMpQRAAgczHEIorJj GNDIgFHJzm0cnNvwQWCO7oPcuVEsFAkMlWmctW7bPphOBlGfyBQpFNf11a4iHKHP7xmn HaFgUiIC5TyWPP5+NxZtkK1wFQDy7vHKZrm3fisjf4Vtzihw47Mbx+SvvnvekpvFxfZ8 9ca4neLfvrKVnofUuiNoInEsZFwFvVYGy0pPdzgFmJPjrjhu57hb6786uzDZuZ3GZQ+8 9Jqj5kLumS1izxs7M8f0WffgrFIo3OJJ01EBCPCodDQRnpiz7CQhIQ5QeXRob25DR0lT bGF2ZQAAAAAAAAAAAAAAAAAAAAAAAAAJhgEWACAC6wKwAAAAAQAACLAAAAAAAAAAFgAA AIYAAAIQ/////wMAtQQ2j7UENpUAAAAAAAAREAAAAAAAAAlj//D/+AAAw0AAAEje --============_-1247838906==_D============-- --============_-1247838906==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" -- ********************************** Samuel M. Smith Ph.D. Professor Director Advanced Marine Systems Lab **************(Dania SeaTech Building)*********************** Institute for Ocean and Systems Engineering Florida Atlantic University Rm. 225 B, SeaTech Bldg. 101 North Beach Road, Dania, FL 33004 (voice) 954-924-7232 (secretary Paula) 954-924-7230 (fax) 954-924-7233 (mobile) 561-251-2114 (email) smith@oe.fau.edu (web) http://www.oe.fau.edu --============_-1247838906==_============-- From billb@mousa.demon.co.uk Sat Jul 22 18:00:17 2000 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Sat, 22 Jul 2000 18:00:17 +0100 Subject: [Pythonmac-SIG] Pythoncore not found and web sharing cgi In-Reply-To: References: <20000721214910.672E8D2CC4@oratrix.oratrix.nl> Message-ID: At 12:23 pm -0400 22/07/00, Samuel Smith wrote: > >I have the problem with both the alias that configure python creates >and any aliases I make myself with the finder. It might be something >to do with how the python core shared library is loaded (something >gets lost in the directory lookup when the reference is an alias >with the appletalk domain and host prepended. But that doesn't >explain why it works until the next reset. Have you tried rebuilding the desktop? It would probably be a good idea to run Norton or Diskwarrior too -- Bill Bedford You did something because it had always been done, and the explanation was "but we've always done it this way." A million dead people can't have been wrong, can they? From jack@oratrix.nl Sat Jul 22 21:02:33 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 22 Jul 2000 22:02:33 +0200 Subject: [Pythonmac-SIG] test_socket failed, reverse name lookup In-Reply-To: Message by Jared Updike , Fri, 21 Jul 2000 17:05:44 -0700 (PDT) , Message-ID: <20000722200239.3F872D2CC4@oratrix.oratrix.nl> Recently, Jared Updike said: > >Your nameserver is broken. The three calls in the test script are > > hostname = socket.gethostname() > > ip = socket.gethostbyname(hostname) > > hname, aliases, ipaddrs = socket.gethostbyaddr(ip) > >and only the final one, which does the reverse lookup on your IP address, > >apparently fails. The various RFC standards specify that for each IP > >address the reverse mapping should always work. > > Now my question is, exactly how do I go about fixing this? This should be fixed at your nameserver. If your machine is managed on a local network the fix is easy: tell the network manager to fix it. If the machine is connected to an ISP it's a bit more difficult: you've got o get the ISP to fix it. If you *are* the network manager you should make sure that for every IP address you provide DNS service for you also provide the reverse lookup. So, if your nameserver serves domain foo.com on class C network 192.1.1.* you should make sure that for every record ahost.foo.com IN A 192.1.1.12 there's also a record 12.1.1.192.in-addr.arpa IN PTR ahost.foo.com The two don't necessarily have to match, but if you have an IP address and do lookup(reverselookup(ipaddr)) you should get ipaddr back. (by "don't have to match" I mean that it is not necessary that reverselookup(lookup(name)) returns the same name). All this should be fixed in the configuration files of your nameserver. To find out where your nameserver is look in the tcp/ip control panel, there you'll find it's IP address. This should at least tell you whether it's under your control, under control of your sysmgr or under control of an ISP. www.bind.com will probably contain pointers to all the relevant information. -- 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 Sat Jul 22 21:15:27 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 22 Jul 2000 22:15:27 +0200 Subject: [Pythonmac-SIG] Pythoncore not found and web sharing cgi In-Reply-To: Message by Samuel Smith , Sat, 22 Jul 2000 12:23:34 -0400 , Message-ID: <20000722201532.A951ED2CC4@oratrix.oratrix.nl> Okay, could everyone who has the "pythoncore not found" problem after rebooting send me their Apple System Profiler output, please? Then I'l just print them all out and see whether I can detect what your machines have in common that mine doesn't have. -- 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 billb@mousa.demon.co.uk Sat Jul 22 23:59:54 2000 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Sat, 22 Jul 2000 23:59:54 +0100 Subject: [Pythonmac-SIG] FAQ Wizard Message-ID: Has anyone got the this to work on a Mac? or can suggest an alternative that will do a similar thing? -- Bill Bedford You did something because it had always been done, and the explanation was "but we've always done it this way." A million dead people can't have been wrong, can they? From billb@mousa.demon.co.uk Sat Jul 22 23:56:19 2000 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Sat, 22 Jul 2000 23:56:19 +0100 Subject: [Pythonmac-SIG] Pythoncore not found and web sharing cgi In-Reply-To: <20000722201532.A951ED2CC4@oratrix.oratrix.nl> References: <20000722201532.A951ED2CC4@oratrix.oratrix.nl> Message-ID: At 10:15 pm +0200 22/07/00, Jack Jansen wrote: >Okay, could everyone who has the "pythoncore not found" problem after >rebooting send me their Apple System Profiler output, please? Then I'l >just print them all out and see whether I can detect what your >machines have in common that mine doesn't have. I don't know if this will help but when I used BuildCGIApplet I got an odd message to the effect that a resource was old or corrupt. The error number was -196 \301 which is points to an icon resource I believe. A couple of other things I've found BuildCGIApplet changes the name of the cgi it produces to ****.cgi, so the files in Mac:demo:cgi need their names changing to remove the '.cgi' I've been playing with Medusa lately and I've found that it has problems with pages which have imported graphics. In 1.5.2 the most of the images were quietly ignored, in 1.6a2 I get a loop with server accept() threw EWOULDBLOCK I don't know whether this is a problem with Medusa or 1.6a2 or my browser (I'm using iCab) -- Bill Bedford You did something because it had always been done, and the explanation was "but we've always done it this way." A million dead people can't have been wrong, can they? From redbird@rbisland.cx Sat Jul 22 20:34:13 2000 From: redbird@rbisland.cx (Gordon Worley) Date: Sat, 22 Jul 2000 15:34:13 -0400 Subject: [Pythonmac-SIG] BuildApplication crashing Message-ID: BuildApplication returns the following returns the following when I try to build my program (I'm using the 1.6 Alpha, but it hardly would matter if I switched to 1.5.2c1's BuildApplication, since I can't get it to work either): Searching for modules... Traceback (most recent call last): File "Macintosh HD:SWdev:Jack:Python:Mac:scripts:BuildApplication.py", line 142, in ? File "Macintosh HD:SWdev:Jack:Python:Mac:scripts:BuildApplication.py", line 48, in main File "Macintosh HD:SWdev:Jack:Python:Mac:scripts:BuildApplication.py", line 83, in buildapplication File "Scooby:Applications:Development:Python 1.6a2:Mac:Tools:macfreeze:macgen_bin.py", line 25, in generate module_dict, missing = macmodulefinder.process(input, [], [], 1) File "Scooby:Applications:Development:Python 1.6a2:Mac:Tools:macfreeze:macmodulefinder.py", line 86, in process modfinder.run_script(program) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 94, in run_script self.load_module('__main__', fp, pathname, stuff) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 261, in load_module self.scan_code(co, m) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 281, in scan_code self.import_hook(name, m) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 106, in import_hook q, tail = self.find_head_package(parent, name) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 147, in find_head_package q = self.import_module(head, qname, parent) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 233, in import_module m = self.load_module(fqname, fp, pathname, stuff) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 261, in load_module self.scan_code(co, m) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 303, in scan_code self.scan_code(c, m) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 281, in scan_code self.import_hook(name, m) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 106, in import_hook q, tail = self.find_head_package(parent, name) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 147, in find_head_package q = self.import_module(head, qname, parent) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 233, in import_module m = self.load_module(fqname, fp, pathname, stuff) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 261, in load_module self.scan_code(co, m) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 281, in scan_code self.import_hook(name, m) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 106, in import_hook q, tail = self.find_head_package(parent, name) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 147, in find_head_package q = self.import_module(head, qname, parent) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 233, in import_module m = self.load_module(fqname, fp, pathname, stuff) File "Scooby:Applications:Development:Python 1.6a2:Tools:freeze:modulefinder.py", line 248, in load_module co = compile(fp.read()+'\n', pathname, 'exec') MemoryError Any ideas? BTW, sorry if this wraps. -- Gordon Worley http://www.rbisland.cx/ mailto:redbird@rbisland.cx PGP: C462 FA84 B811 3501 9010 20D2 6EF3 77F7 BBD3 B003 From just@letterror.com Sun Jul 23 08:46:05 2000 From: just@letterror.com (Just van Rossum) Date: Sun, 23 Jul 2000 08:46:05 +0100 Subject: [Pythonmac-SIG] FAQ Wizard In-Reply-To: Message-ID: At 11:59 PM +0100 22-07-2000, Bill Bedford wrote: >Has anyone got the this to work on a Mac? I looked at it while searching test CGI scripts for PythonCGISlave but it can't run on the Mac: it depends on RCS, which is used through os.system() calls :-(. >or can suggest an >alternative that will do a similar thing? Sorry, no. Just From just@letterror.com Sun Jul 23 08:49:41 2000 From: just@letterror.com (Just van Rossum) Date: Sun, 23 Jul 2000 08:49:41 +0100 Subject: Medusa (Re: [Pythonmac-SIG] Pythoncore not found and web sharing cgi) In-Reply-To: References: <20000722201532.A951ED2CC4@oratrix.oratrix.nl> <20000722201532.A951ED2CC4@oratrix.oratrix.nl> Message-ID: At 11:56 PM +0100 22-07-2000, Bill Bedford wrote: >I've been playing with Medusa lately and I've found that it has >problems with pages which have imported graphics. In 1.5.2 the most >of the images were quietly ignored, in 1.6a2 I get a loop with > >server accept() threw EWOULDBLOCK > >I don't know whether this is a problem with Medusa or 1.6a2 or my >browser (I'm using iCab) Erm, I've noticed things like that when running the server and browser on the same machine. I think I got it to work correctly at some point by not doing that ;-). I'm not sure who's to blame for this: the OS? Gusi? Python? I don't think it's the browser, as the problem was the same with Navigator as well as MSIE. Just From just@letterror.com Sun Jul 23 08:55:11 2000 From: just@letterror.com (Just van Rossum) Date: Sun, 23 Jul 2000 08:55:11 +0100 Subject: [Pythonmac-SIG] Using Python .py scripts for CGI with personal web sharing In-Reply-To: Message-ID: At 12:33 PM -0400 22-07-2000, Samuel Smith wrote: >I am reposting this on its own just in case it got lost as part of >the other post. > > I was able to get python .py cgi scripts running with personal web >sharing using the pythoncgislave (thanks Just). Thanks for letting us know that it works! >Anyway if you add a "launch on suffix" action to web sharing with the >suffix set to .py and the application to launch set to the >pythoncgislave applet then any url with a .py will run as a cgi >script. Examples are attached. Cool. > I am surprised that the latest incarnation (march 2000) of the >pythoncgislave script is not readily available either in the vaults >of parnasses or on the python mac web page. I found it in an old >posting from Just. It is attached FYI. Erm, that's mainly because it's supposed to become included with the MacPython distribution. It is in the 1.6 alpha's, but I have to look into it, as it appears its' res file is broken for 1.6 (different prefs res format?). Just From just@letterror.com Sun Jul 23 08:50:44 2000 From: just@letterror.com (Just van Rossum) Date: Sun, 23 Jul 2000 08:50:44 +0100 Subject: [Pythonmac-SIG] BuildApplication crashing In-Reply-To: Message-ID: At 3:34 PM -0400 22-07-2000, Gordon Worley wrote: >BuildApplication returns the following returns the following when I >try to build my program (I'm using the 1.6 Alpha, but it hardly would >matter if I switched to 1.5.2c1's BuildApplication, since I can't get >it to work either): > >Searching for modules... >Traceback (most recent call last): [ ... ] >MemoryError > >Any ideas? BTW, sorry if this wraps. How about giving BuildApplication more memory? Just From fgranger@altern.org Sun Jul 23 21:48:46 2000 From: fgranger@altern.org (Francois Granger) Date: Sun, 23 Jul 2000 22:48:46 +0200 Subject: [Pythonmac-SIG] rfc822 lib Message-ID: I am currently using this lib to create a script to help moderators of newsgroups wich works on macintoshes. In the docs it says: Input lines as read from the file may either be terminated by CR-LF or by a single linefeed; a terminating CR-LF is replaced by a single linefeed before the line is stored. I uses the simple script: try: f = open(file, 'r') except IOError, msg: print file, ': can\'t open :', msg return 0 m = rfc822.Message(f, 1) With a Mac file it works. With a dos file, it does not recognise the header. You can easily see it by browsing the 'm' object under debugger. -- "Computers are like horses; they can sense fear and will act based on that. Or, look at it like this. If you have a premonition of danger, maybe you're right." - Adam Engst From rmore@rmore.net Sun Jul 23 22:01:04 2000 From: rmore@rmore.net (Rod Morehead) Date: Sun, 23 Jul 2000 16:01:04 -0500 (CDT) Subject: [Pythonmac-SIG] rfc822 lib In-Reply-To: References: Message-ID: <14715.23824.614973.222951@ghostwheel.rmore.net> Francois Granger writes: > I am currently using this lib to create a script to help moderators > of newsgroups wich works on macintoshes. In the docs it says: > > Input lines as read from the file may either be terminated by CR-LF > or by a single linefeed; a terminating CR-LF is replaced by a single > linefeed before the line is stored. > > > I uses the simple script: > > try: > f = open(file, 'r') > except IOError, msg: > print file, ': can\'t open :', msg > return 0 > m = rfc822.Message(f, 1) > > With a Mac file it works. With a dos file, it does not recognise the > header. You can easily see it by browsing the 'm' object under > debugger. I would guess that this is because if you open a file in text mode on the Mac CR and LF are swapped and CR-LF become LF-CR which confuses the code (if you open it in binary mode they aren't, but then '\n' isn't a mac newline '\r' is). If performance isn't too important an easy workaround would be to try opening the file in binary mode ('rb') and then if that fails fall back to text mode. If that still fails then I would suspect something else is the problem. Thanks, --Rod Morehead rmore@rmore.net http://rmore.net From jimmy@CS.cofc.EDU Mon Jul 24 00:55:03 2000 From: jimmy@CS.cofc.EDU (James B. Wilkinson) Date: Sun, 23 Jul 2000 19:55:03 -0400 Subject: [Pythonmac-SIG] Can someone tell me why ('A',) isn't a sequence? In-Reply-To: References: <20000623182849.55170.qmail@hotmail.com> Message-ID: This doesn't have anything to do with the Mac, but you guys are the only Python folks I know. In what follows "handler" is bound to this method in another class. def do_char(self, ch, *rest): #ch must be a character # *rest is just for this debugging session Here's the end of the traceback: ok, t, s = apply(handler, ('A',)) TypeError: unpack non-sequence Experiments follow: Let's try an integer instead: ok, t, s = apply(handler, (65,)) File "sleepy:develop:Python 1.5.2c1:mine:TAText.py", line 194, in do_char ok, text, sel = self.TryNewTEText('Key', ord(ch)) TypeError: ord, argument 1: expected char, int found Let's put another element in the tuple: ok, t, s = apply(handler, ('A', 'B')) TypeError: unpack non-sequence Let's give it a longer string: ok, t, s = apply(handler, ('AB',)) File "sleepy:develop:Python 1.5.2c1:mine:TAText.py", line 194, in do_char ok, text, sel = self.TryNewTEText('Key', ord(ch)) TypeError: ord, argument 1: expected char, string found Ok, let's try an empty string: ok, t, s = apply(handler, ('',)) File "sleepy:develop:Python 1.5.2c1:mine:TAText.py", line 194, in do_char ok, text, sel = self.TryNewTEText('Key', ord(ch)) TypeError: ord, argument 1: expected char, string found How about two strings of different lengths: ok, t, s = apply(handler, ('A', 'BC')) TypeError: unpack non-sequence ok, t, s = apply(handler, ('AB', 'C')) File "sleepy:develop:Python 1.5.2c1:mine:TAText.py", line 194, in do_char ok, text, sel = self.TryNewTEText('Key', ord(ch)) TypeError: ord, argument 1: expected char, string found Conclusion: It checks the number of args first. If it gets past that, it will try to unpack the tuple. It can do that for (65,) or ('AB',) or ('',) or ('AB', 'C'), but not for ('A',) or ('A', 'B') or ('A', 'BC'). It's starting to seem that a tuple consisting of strings is considered to be a sequence unless the first string has exactly one character. Could this be something wrong with the Python interpreter itself? (1.5.2c1) That's all I can figure out on my own. I'd be forever grateful if some of you guys could help me out of this one. Just in case you're wondering why I would write something like that in the first place, the real line of code is apply(handler, rest), where *rest appears in the arg list of the current function. This started as a nice general solution that could call any of a bunch of handlers. But this is killing it. (I think I stole the idea from the Framework.) Thanks ------------------------------------------------------------- Jimmy Wilkinson | Perfesser of Computer Science jimmy@cs.CofC.edu | The College of Charleston (843) 953-8160 | Charleston SC 29424 If there is one word to describe me, that word would have to be "profectionist". From just@letterror.com Mon Jul 24 08:52:05 2000 From: just@letterror.com (Just van Rossum) Date: Mon, 24 Jul 2000 08:52:05 +0100 Subject: [Pythonmac-SIG] Can someone tell me why ('A',) isn't a sequence? In-Reply-To: References: <20000623182849.55170.qmail@hotmail.com> Message-ID: At 7:55 PM -0400 23-07-2000, James B. Wilkinson wrote: >This doesn't have anything to do with the Mac, but you guys are the only >Python folks I know. > > >In what follows "handler" is bound to this method in another class. > > def do_char(self, ch, *rest): #ch must be a character > # *rest is just for this debugging session > > > > >Here's the end of the traceback: > > ok, t, s = apply(handler, ('A',)) >TypeError: unpack non-sequence My first guess is that your handler doesn't _return_ a 3-tuple. The rest of your story seems to confirm that, as you seem to get the above error in all cases where the first element of your args tuple is a length 1 string, which is the only proper arg for the ord() function, and the code looks ok. So I think your conclusion is wrong... Just From fgranger@altern.org Mon Jul 24 11:28:53 2000 From: fgranger@altern.org (Francois Granger) Date: Mon, 24 Jul 2000 12:28:53 +0200 Subject: [Pythonmac-SIG] rfc822 lib In-Reply-To: <14715.23824.614973.222951@ghostwheel.rmore.net> Message-ID: on 23/07/00 23:01, Rod Morehead at rmore@rmore.net wrote: > I would guess that this is because if you open a file in text mode on > the Mac CR and LF are swapped and CR-LF become LF-CR which confuses > the code (if you open it in binary mode they aren't, but then '\n' > isn't a mac newline '\r' is). I did not thought of this. If the rfc library can work with this, it will not be a big issue since I never access the file directly. Only the content of the message may be with wrong lines ending ? >=20 > If performance isn't too important an easy workaround would be to try > opening the file in binary mode ('rb') and then if that fails fall > back to text mode. If that still fails then I would suspect something > else is the problem. I'll give it a try tonight. In the mean time I got the quick and dirty solution of: 1) test for end of file 2) make a backup of the file 3) replace all '\r\n' by '\n' 4) write this to the file 5) close the file 6) reopen it in 'r' mode. Somewhat ugly. --=20 Fran=E7ois Granger fgranger@altern.org From jack@oratrix.nl Mon Jul 24 15:05:55 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 24 Jul 2000 16:05:55 +0200 Subject: [Pythonmac-SIG] Toolbox modules - Incompatible change Message-ID: <20000724140556.472A837186D@snelboot.oratrix.nl> Folks, in a recent release (I'm not sure whether it was 1.5.2 or 1.6a) I introduced a new feature in the toolbox modules, so that objects inherited methods from each other. As an example, all Mac C programmers knew they could pass a DialogPtr to any routine that expected a WindowPtr, so I put some hooks in the toolbox modules so that all Window methods were also available on Dialog objects. Of course, this has broken as of Carbon: even the C programmers are now required to do win = GetDialogWindow(dlg); BringToFront(win); I would prefer to do the same for Python, although there you can of course do dlg.GetDialogWindow().BringToFront() and not worry about backward compatibility, i.e. code that has been written recently and does dlg.BringToFront() will break. If anyone has a problem with this please let me know, -- 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 loredo@spacenet.tn.cornell.edu Mon Jul 24 23:09:22 2000 From: loredo@spacenet.tn.cornell.edu (Tom Loredo) Date: Mon, 24 Jul 2000 18:09:22 -0400 (EDT) Subject: [Pythonmac-SIG] ZORB for MacOS? Message-ID: <200007242209.SAA14829@laplace.tn.cornell.edu> Hi folks- Has anyone out there built ZORB (the object database for Zope) for the Mac? If not, does anyone know of any obstacles to a Mac build of just this part of Zope? If not, I'll give it a go. But if someone already knows that it relies on system calls not available on the Mac, I'd rather not spend the time rediscovering this for myself! Thanks, Tom Loredo From gwrx@mac.com Tue Jul 25 03:25:15 2000 From: gwrx@mac.com (gwrx) Date: Tue, 25 Jul 2000 10:25:15 +0800 Subject: [Pythonmac-SIG] about BuildApplication Message-ID: Hi When I use BujildApplication to compile a program, always appear the error message: Searching for modules... shift: no mem in addchild Traceback (innermost last): File "flap:jack:Python:Mac:scripts:BuildApplication.py", line 145, in ? File "flap:jack:Python:Mac:scripts:BuildApplication.py", line 49, in main File "flap:jack:Python:Mac:scripts:BuildApplication.py", line 86, in buildapplication File "Macintosh :Python 1.5.2c1:Mac:Tools:macfreeze:macgen_bin.py", line 25, in generate module_dict = macmodulefinder.process(input, [], [], 1) File "Macintosh :Python 1.5.2c1:Mac:Tools:macfreeze:macmodulefinder.py", line 81, in process modfinder.run_script(program) File "Macintosh :Python 1.5.2c1:Tools:freeze:modulefinder.py", line 94, in run_script self.load_module('__main__', fp, pathname, stuff) File "Macintosh :Python 1.5.2c1:Tools:freeze:modulefinder.py", line 260, in load_module self.scan_code(co, m) File "Macintosh :Python 1.5.2c1:Tools:freeze:modulefinder.py", line 280, in scan_code self.import_hook(name, m) File "Macintosh :Python 1.5.2c1:Tools:freeze:modulefinder.py", line 106, in import_hook q, tail = self.find_head_package(parent, name) File "Macintosh :Python 1.5.2c1:Tools:freeze:modulefinder.py", line 147, in find_head_package q = self.import_module(head, qname, parent) File "Macintosh :Python 1.5.2c1:Tools:freeze:modulefinder.py", line 232, in import_module m = self.load_module(fqname, fp, pathname, stuff) File "Macintosh :Python 1.5.2c1:Tools:freeze:modulefinder.py", line 247, in load_module co = compile(fp.read()+'\n', pathname, 'exec') MemoryError Please help me to solve the problem thanks in advance Junghua From savageb@pacbell.net Tue Jul 25 18:41:13 2000 From: savageb@pacbell.net (Bob Savage) Date: Tue, 25 Jul 2000 10:41:13 -0700 Subject: [Pythonmac-SIG] ZORB for MacOS? In-Reply-To: <200007242209.SAA14829@laplace.tn.cornell.edu> Message-ID: on 7/24/00 3:09 PM, Tom Loredo wrote: > Has anyone out there built ZORB (the object database for Zope) for > the Mac? Hi, Tom. I caught the Zope Object Database (I think its referred to as ZODB) session last week and it looked very interesting. As far as I know, no one has tried to build just that part, but there was an issue with building Zope in general on MacOS-9. I believe there is no such limitation on MacOS-X. This is related to threading. Bob From cbarker@jps.net Tue Jul 25 21:04:54 2000 From: cbarker@jps.net (Chris Barker) Date: Tue, 25 Jul 2000 13:04:54 -0700 Subject: [Pythonmac-SIG] Build Application problems Message-ID: <397DF2E6.35B92DC3@jps.net> This is a multi-part message in MIME format. --------------B5B2CA026E6B1919117C0784 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I'm back again, still with a BuildApplication problem. When I use BuildApplication to build an application that used tkinter and ftplib, it works fine, but it brings up an output window when It getes to the ftp routine. I did a test, and it seems to be related to opening files, but I'm not totally surea about that. When I drop the script on the interpreter, it works just fine, and there is no output window, only when I use BuildApplication. Yes, I have used EditPythonPrefs to set the preferences so a window should not open. I sent the script to someone else (Russell Owen, thanks for your help Russell), and he could Build an Application with the script and have it run fine. He sent me the application he built, and I can't run it on my machine. I get the error: "Python preferences file appears corrupt: Python home folder incorrect. Please remove it and restart python" I then tied to run an application build on may machine on aother machine, and got the same error. It would run after that error, but it still brought up the unwanted output window. What is the deal here? I am getting very frustrated. I tried 1.6a2, but ftplib appears to broken there, so that won't do it. I tried to enclosed a stuffed and binhex'd version of the application, but it was too big, and got bounced by the listserve, so I enclosed the script I built it from, if anyone else want to try it. It is a prototype for an application that would let the user upload a file to an ftp site, along with a formatted text file that contains information about the file that the user inputs. All the fields must have something in them, and a file must be selected in order to upload. I've hard coded it to upload to our anonymous ftp site, so feel free to try it, but please use sparingly. Note to Jack: If you are now focusing your efforts on 1.6, perhaps I should try to figure out what is wrong with ftplib in 1.6, rather than trying to figure out what is wrong with the 1.5 BuildApplication. Also, at some point you suggested that I send you the contents of the unwanted output window. There are no contents. I tried select all, and copy and paste were still disabled. I assumed that this means that there was nothing in the selection, even whitespace characters. -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ --------------B5B2CA026E6B1919117C0784 Content-Type: text/plain; charset=us-ascii; name="ftp_tool.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ftp_tool.py" #!/usr/bin/env python # The first line is required by Linux to make this executable import sys, string,os from Tkinter import * from tkFileDialog import askopenfilename from tkMessageBox import showinfo, showwarning from cStringIO import StringIO Data_Fields = ["First data item:","Second data item:","Third data item:","Fourth data item:"] Data_Entry_Boxes = [] def ftp_files(file_list): """ file list is a list of files that are to be transfered. Each item in the list is a tuple with the following members: (infile,outfilename,type) infile is an open file object (or someting with a read() method for binary files, and a readline() method for text files. outfilename is the name you want the file to have on the ftp server. type is one of 'text' or 'binary' """ from ftplib import FTP password = 'cbarker@jps.net' ORR = FTP('home.orr.noaa.gov','anonymous',password) ORR.cwd('/FTP_ORR/to_orr/Test_ftp_tool/') for (file,outfilename,type) in file_list: if type == 'binary': ORR.storbinary('STOU '+outfilename,file,1024) elif type == 'text': ORR.storlines('STOU '+outfilename,file) else : raise "Unknown file type for transfer" file.close() ORR.quit() class App_Window: def __init__(self, master): self.Filename = "" main_frame = Frame(master) main_frame.pack() enter_frame = Frame(main_frame) enter_frame.pack() for i in range(len(Data_Fields)): Label(enter_frame,text=Data_Fields[i],width = 20).grid(row = i, column = 0, sticky = W) Data_Entry_Boxes.append(Entry(enter_frame,width = 30)) Data_Entry_Boxes[i].grid(row = i, column = 1) Label(enter_frame,text="Selected File is:",width = 20).grid(row = len(Data_Fields), column = 0, sticky = W) self.file_name = Message(enter_frame,text=self.Filename,width = 300) self.file_name.grid(row = len(Data_Fields), column = 1) button_frame = Frame(main_frame) button_frame.pack() self.quit_button = Button(button_frame, text="QUIT", fg="red", command=self.quit) self.quit_button.pack(side=LEFT) self.file_button = Button(button_frame, text="Choose a File",command=self.choose_file) self.file_button.pack(side=LEFT) self.apply_button = Button(button_frame, text="Upload", command=self.apply) self.apply_button.pack(side=LEFT) def apply(self): data = [] for box in Data_Entry_Boxes: data.append(box.get()) error = 0 for item in data: if not string.strip(item): error = 1 if not self.Filename: error = 2 if not error: text_file = StringIO() text_file.write("An Official Hazmat data file (Tab delimited)\n") text_file.write("field1\tfield2\tfield3\tfield4\n") text_file.write(string.join(data,'\t')+'\n') text_file.seek(0) basename = os.path.basename(self.Filename) bin_file = open(self.Filename,'r') try: ftp_files([(text_file,basename+'.data','text'), (bin_file,basename,'binary')]) showinfo("FTP done", "Your data has been Transfered") except: showwarning("FTP Error", "There was some kind of error "+ "in FTPing, some of your data probably didn't"+ "get there") else: if error == 1: showinfo("Data Error", "All fields must contain some data") elif error == 2: showinfo("Data Error", "You must specify a file to upload") def choose_file(self): self.Filename = askopenfilename() self.file_name["text"] = self.Filename def quit(self): sys.exit() root = Tk() window = App_Window(root) root.mainloop() --------------B5B2CA026E6B1919117C0784-- From jack@oratrix.nl Wed Jul 26 09:54:19 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 26 Jul 2000 10:54:19 +0200 Subject: [Pythonmac-SIG] ZORB for MacOS? In-Reply-To: Message by Bob Savage , Tue, 25 Jul 2000 10:41:13 -0700 , Message-ID: <20000726085420.424B737186D@snelboot.oratrix.nl> > Hi, Tom. I caught the Zope Object Database (I think its referred to as ZODB) > session last week and it looked very interesting. As far as I know, no one > has tried to build just that part, but there was an issue with building Zope > in general on MacOS-9. I believe there is no such limitation on MacOS-X. > This is related to threading. MacPython 1.6a2 has threading, so if someone would like to give Zope a testrun and report the results back here that would be very helpful. -- 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 Jul 26 10:00:31 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 26 Jul 2000 11:00:31 +0200 Subject: [Pythonmac-SIG] Build Application problems In-Reply-To: Message by Chris Barker , Tue, 25 Jul 2000 13:04:54 -0700 , <397DF2E6.35B92DC3@jps.net> Message-ID: <20000726090031.BD75237186D@snelboot.oratrix.nl> > I'm back again, still with a BuildApplication problem. > > When I use BuildApplication to build an application that used tkinter > and ftplib, it works fine, but it brings up an output window when It > getes to the ftp routine. I did a test, and it seems to be related to > opening files, but I'm not totally surea about that. > > When I drop the script on the interpreter, it works just fine, and there > is no output window, only when I use BuildApplication. Yes, I have used > EditPythonPrefs to set the preferences so a window should not open. Very strange.... > I sent the script to someone else (Russell Owen, thanks for your help > Russell), and he could Build an Application with the script and have it > run fine. This makes it even stranger... Maybe you should reinstall your Python? > He sent me the application he built, and I can't run it on my > machine. I get the error: > > "Python preferences file appears corrupt: Python home folder incorrect. > Please > remove it and restart python" Ah, this is a known problem. Open the application (the one built by BuildApplication) and remove the "alis" resource in there. It shouldn't have been there in the first place, but it gets inserted occasionally. I'll try to do something about the error message. > What is the deal here? I am getting very frustrated. I tried 1.6a2, but > ftplib appears to broken there, so that won't do it. Uhm, what was broken in 1.6a2 ftplib again? > Note to Jack: If you are now focusing your efforts on 1.6, perhaps I > should try to figure out what is wrong with ftplib in 1.6, rather than > trying to figure out what is wrong with the 1.5 BuildApplication. I'll try and find the time to give it a go, but no promises. -- 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 Jul 26 10:19:31 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 26 Jul 2000 11:19:31 +0200 Subject: [Pythonmac-SIG] Build Application problems In-Reply-To: Message by Chris Barker , Tue, 25 Jul 2000 13:04:54 -0700 , <397DF2E6.35B92DC3@jps.net> Message-ID: <20000726091932.2D3A637186D@snelboot.oratrix.nl> This gets stranger and stranger. I did a BuildApplication on your script, and the good news is that ftplib works fine (what sort of problems were you seeing), but I did get the spurious console window when I pressed upload. So, I tried option-starting it and setting the "enter interpreter after script" option, to inspect things afterwards: no console window. The weird thing, however, is that since then I've been unable to get the console window again! I'm sorry, but I'm afraid I'm completely out of good ideas, -- 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 guzdial@cc.gatech.edu Wed Jul 26 16:18:10 2000 From: guzdial@cc.gatech.edu (Mark Guzdial) Date: Wed, 26 Jul 2000 11:18:10 -0400 Subject: [Pythonmac-SIG] Generating QuickTime from MacPython? Message-ID: Has anyone CREATED a QuickTime movie from MacPython? The docs are sparse (understatement :-) on the Qt module, so I'm not sure that it's possible or how. I tried my hand at building a QuickTime movie using a WYSIWYG editor, and I found myself desperate for a programming language for the task. Simple things (like "show this JPEG still image for a duration of 4 seconds") are such a pain to do in Avid's tools. Thanks! Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 Associate Professor - Learning Sciences & Technologies. Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/ (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html From erik@letterror.com Wed Jul 26 17:52:06 2000 From: erik@letterror.com (Erik van Blokland) Date: Wed, 26 Jul 2000 17:52:06 +0100 Subject: [Pythonmac-SIG] Generating QuickTime from MacPython? Message-ID: <200007261558.RAA25061@leidschenveen.denhaag.dataweb.net> Mark Guzdial, 7/26/00 4:18 PM: >Has anyone CREATED a QuickTime movie from MacPython? I think all the necessary toolbox calls are available from the Qt module. I made an attempt once but got lost somewhere in the bowels of quicktime. There are several layers that need python wrappers. Movie -> Track -> Media -> Data. Ugh. But I'd be just as intested to hear if someone got something useful :) Erik -- letterror From loredo@spacenet.tn.cornell.edu Wed Jul 26 19:20:33 2000 From: loredo@spacenet.tn.cornell.edu (Tom Loredo) Date: Wed, 26 Jul 2000 14:20:33 -0400 (EDT) Subject: [Pythonmac-SIG] ZORB for MacOS? Message-ID: <200007261820.OAA16615@laplace.tn.cornell.edu> Hi folks- > MacPython 1.6a2 has threading, so if someone would like to give Zope a testrun > and report the results back here that would be very helpful. I'm still using 1.5.2 at the moment, but I can report that the modules needed for ZODB appear to compile fine (with some minor changes to one source file that Jim Fulton helped me with). I still have to exercise it to make sure it's working, but once it is, I'll post the shared libraries (PPC only) and sample scripts for others to use. Zope itself is a web server and not of immediate use/interest to me, so I can't comment on what it would take to get it running. I have to confess that there doesn't appear to be much interest in the Zope world on getting it running on the Mac. Also, documentation for the "internals" is sorely lacking, which seems a shame because it looks like there's lots in Zope that could be used outside it if only it were better documented. -Tom Loredo From fgranger@altern.org Wed Jul 26 21:00:10 2000 From: fgranger@altern.org (Francois Granger) Date: Wed, 26 Jul 2000 22:00:10 +0200 Subject: [Pythonmac-SIG] ZORB for MacOS? In-Reply-To: <200007261820.OAA16615@laplace.tn.cornell.edu> References: <200007261820.OAA16615@laplace.tn.cornell.edu> Message-ID: At 14:20 -0400 26/07/00, in message Re: [Pythonmac-SIG] ZORB for MacOS?, Tom Loredo wrote: >Hi folks- > > > MacPython 1.6a2 has threading, so if someone would like to give >Zope a testrun > > and report the results back here that would be very helpful. > >I'm still using 1.5.2 at the moment, but I can report that the modules >needed for ZODB appear to compile fine (with some minor changes to one >source file that Jim Fulton helped me with). I still have to >exercise it to make sure it's working, but once it is, I'll post >the shared libraries (PPC only) and sample scripts for others to use. This look nice. We may have good use of such a tool. And I am not good enough to do such a thing. >Zope itself is a web server and not of immediate use/interest to me, >so I can't comment on what it would take to get it running. I have to >confess that there doesn't appear to be much interest in the Zope >world on getting it running on the Mac. Also, documentation for the >"internals" is sorely lacking, which seems a shame because it looks >like there's lots in Zope that could be used outside it if only it >were better documented. At this point of time I feel like the Mac is the "Parent pauvre" (forgotten side) of the Python community ??? Best regards, François -- "Computers are like horses; they can sense fear and will act based on that. Or, look at it like this. If you have a premonition of danger, maybe you're right." - Adam Engst From jack@oratrix.nl Wed Jul 26 22:24:49 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 26 Jul 2000 23:24:49 +0200 Subject: [Pythonmac-SIG] Generating QuickTime from MacPython? In-Reply-To: Message by Erik van Blokland , Wed, 26 Jul 2000 17:52:06 +0100 , <200007261558.RAA25061@leidschenveen.denhaag.dataweb.net> Message-ID: <20000726212454.8FAEDDB4D6@oratrix.oratrix.nl> I didn't create a quicktime movie, but I did manage to read and interpret one (i.e. pull the data out, as opposed to letting qt dump it on-screen). It was a fair bit of work, mainly in understanding the timebases and such and getting the Qdoffs module to do what it's meant to do. And some tracks, such as mpeg tracks, are weird. If someone wants it I can try and disentangle it from the module it's in, because the rest of the module is under NDA (it's a quicktime->RealVideo converter) if I remember correctly. Hmm, there were a few fixes needed to Qtmodule (timebase stuff mainly, according to the log) and Qdoffs (getting at the actual bits in the offscreen gworld), so you would probably need 1.6a2 to get this to work at all. -- 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 Chris_Barker@hazmat.noaa.gov Thu Jul 27 21:15:15 2000 From: Chris_Barker@hazmat.noaa.gov (Chris Barker) Date: Thu, 27 Jul 2000 13:15:15 -0700 Subject: [Pythonmac-SIG] ftplib with 1.6a2 Message-ID: This is a multi-part message in MIME format. ----=_--b5a5e66b.021c6195.00000162 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I have earlier refered to problems with ftplib in 1.6a2. Jack sent a note saying it worked for him, but it wasn't clear to me whether he meant 1.5 or 1.6 . Anyway, this is what I get when I try to use ftplib. It seems to connect tothe sever alright, but when I try to transfer I file, I get the following traceback: Traceback (most recent call last): File "CBarker- Main Drive:Projects:FTP_tool:simple_ftp_test.py", line 28, in ? server.storbinary('STOU testfile',file,1024) File "CBarker- Main Drive:Development:Python 1.6a2:Lib:ftplib.py", line 365, in storbinary conn = self.transfercmd(cmd) File "CBarker- Main Drive:Development:Python 1.6a2:Lib:ftplib.py", line 286, in transfercmd return self.ntransfercmd(cmd)[0] File "CBarker- Main Drive:Development:Python 1.6a2:Lib:ftplib.py", line 274, in ntransfercmd resp = self.sendcmd(cmd) File "CBarker- Main Drive:Development:Python 1.6a2:Lib:ftplib.py", line 229, in sendcmd return self.getresp() File "CBarker- Main Drive:Development:Python 1.6a2:Lib:ftplib.py", line 200, in getresp raise error_temp, resp ftplib.error_temp: 425 Data connection reset by client. I've enclosed a simple script that I am using for testing. I've hardcoded in our ftp server, but you can change that easily at the top to use a local one if you have it. thanks, -Chris ----=_--b5a5e66b.021c6195.00000162 Content-Type: multipart/appledouble; boundary="--=_--b5a5e66c.021c61c7.00000163"; x-mac-type="54455854"; x-mac-creator="522A6368" Content-Disposition: attachment; filename="simple_ftp_test.py" ----=_--b5a5e66c.021c61c7.00000163 Content-Type: application/applefile; name="simple_ftp_test.py" Content-Transfer-Encoding: base64 AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAADAAAASgAAABIAAAAIAAAAXAAA ABAAAAAJAAAAbAAAACAAAAACAAAAjAAAAf5zaW1wbGVfZnRwX3Rlc3QucHkBEZH+ ARLllQgAAAAIAAAAVEVYVFIqY2gBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAABvAAAALwAAABCfBOQAEGC9TQsDwAAQYIAVDozAAA4fAAAOJ0AADi+AAA43wAA S//02SwDAABAghPofBGQAECAE2Q4dAAAOJwAADiuAAA43wAASAAW6SwDAABBghNI f5xyFDoxAAFL//+4OfwAADozAABIAAAoOHQAADicAAA4rgAAON8AAEgAFrUsAwAA QYIAOH+cchQ6MQABfBGQAEGA/9hIAAAkOHwAADidAAA4vgAAON8AAEv/9FEsAwAA QIITYH+O4FB8HHhAQID/3EgAEtQoBQA5OcAAAECCABSAHwAULAAAAEGCAAg5wAAB Op0AAYydACEsBAA2AAAAuHtzBwAAAHRhYnNpemUoAgAAAGkIAAAAaQEAAABzDAAA AGZvbnRzZXR0aW5ncygEAAAAcwYAAABNb25hY29pAAAAAGkJAAAAKAMAAABpAAAA AGkAAAAAaQAAAABzDAAAAHdpbmRvd2JvdW5kcygEAAAAaWwBAABpTAAAAGmPAwAA aT8CAABzCwAAAHJ1bl9hc19tYWluaQAAAABzCQAAAHNlbGVjdGlvbigCAAAAaYgB AABpiAEAADAAAAEAAAABvAAAALwAAABCBc2QWDa4AAAAHAAyAABQeVdTAAAACgCA AAAAAAAABd1wZA93aW5kb3cgc2V0dGluZ3M= ----=_--b5a5e66c.021c61c7.00000163 Content-Type: text/plain; name="simple_ftp_test.py" Content-Transfer-Encoding: base64 IyEvdXNyL2Jpbi9lbnYgcHl0aG9uDQ1mcm9tIGZ0cGxpYiBpbXBvcnQgRlRQDQ0j IHNldCB1cCBzb21lIGZ0cHNpdGUgZGF0YToNDWZ0cF9zZXJ2ZXIgPSAnaG9tZS5v cnIubm9hYS5nb3YnDXVzZXJuYW1lID0gJ2Fub255bW91cycNcGFzc3dvcmQgPSAn Y2JhcmtlckBqcHMubmV0Jw1kaXJlY3RvcnkgPSAnL0ZUUF9PUlIvdG9fb3JyL1Rl c3RfZnRwX3Rvb2wvJw0NZmlsZW5hbWUgPSAnc2ltcGxlX2Z0cF90ZXN0LnB5Jw0N cHJpbnQgImFib3V0IHRvIHNlbmQgYSBhIGZpbGUgdG8gYW4gZnRwIHNlcnZlciIN cHJpbnQgIlNlcnZlciBOYW1lOiIsZnRwX3NlcnZlcg1wcmludCAidXNlcm5hbWU6 IiwgdXNlcm5hbWUNcHJpbnQgInBhc3N3b3JkOiIsIHBhc3N3b3JkDXByaW50ICJk aXJlY3Rvcnk6IiwgZGlyZWN0b3J5DQ1zZXJ2ZXIgPSBGVFAoZnRwX3NlcnZlcix1 c2VybmFtZSxwYXNzd29yZCkNcHJpbnQgImNvbm5lY3RlZCB0byBzZXJ2ZXIiDQ1z ZXJ2ZXIuY3dkKGRpcmVjdG9yeSkNcHJpbnQgImRpcmVjdG9yeSBjaGFuZ2VkIg0N ZmlsZSA9IG9wZW4oZmlsZW5hbWUpDQ1zZXJ2ZXIuc3RvcmJpbmFyeSgnU1RPVSB0 ZXN0ZmlsZScsZmlsZSwxMDI0KQ1wcmludCAiZmlsZSB0cmFuc2ZlcmVkIg1maWxl LmNsb3NlKCkNcHJpbnQgImNvbm5lY3Rpb24gY2xvc2VkIg1zZXJ2ZXIucXVpdCgp DQkNDQ0NDQ0NDQ0NDQ== ----=_--b5a5e66c.021c61c7.00000163-- ----=_--b5a5e66b.021c6195.00000162-- From Chris_Barker@hazmat.noaa.gov Thu Jul 27 22:04:01 2000 From: Chris_Barker@hazmat.noaa.gov (Chris Barker) Date: Thu, 27 Jul 2000 14:04:01 -0700 Subject: [Pythonmac-SIG] Build Application problem some more!! Message-ID: HI all, I know this must be getting annoying, but I've done a little bit more diagnostics, and I'm no further toward understanding what's going on, but I have a little more data. To remove any confusion about ftplib and Tkinter, modules I used originally that might have had something to do with the problem, I made a couple of very small test scripts that ilustrate the problem. What happens is that an unwanted output window pops up, it appears to happen when I do something with file access. I've enclosed two scripts that ilustrate. Pico-test.py simple builds a couple of lists, sleeps, and then exits. It works fine both dropped on the interpreter, and with BuildApplication. Micro-test.py, opens a file, writes a little bit to it, then sleeps, then closes it. When dropped on the interpreter, it works fine, with no output window. When used with BuildApplication, it brings up an output window with nothing in it. I put the time.sleep() in so that you could see the output window for a few seconds. without it, it just flashed on screen. 1.5.2c1 and 1.6a2 behave in exactly the same way. I put the weird import macfsn line in to accomidate a bug in 1.6a2 Build Application. What is the deal here? Does anyone else get the same results? I did re-install Python, both 1.5 and 1.6, with no change. By the way: Blue&white G3, MacOS 8.6 My little ftp app took about 2hrs to write on Linux (I was teaching myself Tkinter as I went), and now weeks to get a distributable application on the Mac. Having the users install Python really isn't an option. I'm trying to sell folks here on Python as a good way to produce small cross-platform apps. (Large ones too, but that's a harder sell). The Mac is an important platform, and I really need to be able to demo it without having unwanted text windows pop up. Mac users don't like that kind of thing! Please help!! -Chris From Chris_Barker@hazmat.noaa.gov Thu Jul 27 22:04:01 2000 From: Chris_Barker@hazmat.noaa.gov (Chris Barker) Date: Thu, 27 Jul 2000 14:04:01 -0700 Subject: [Pythonmac-SIG] Build Application problem some more!! Message-ID: This is a multi-part message in MIME format. ----=_--b5a5f229.021f23e9.00000169 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit OOOPS!, I forgot the atachments. here it is again. HI all, I know this must be getting annoying, but I've done a little bit more diagnostics, and I'm no further toward understanding what's going on, but I have a little more data. To remove any confusion about ftplib and Tkinter, modules I used originally that might have had something to do with the problem, I made a couple of very small test scripts that ilustrate the problem. What happens is that an unwanted output window pops up, it appears to happen when I do something with file access. I've enclosed two scripts that ilustrate. Pico-test.py simple builds a couple of lists, sleeps, and then exits. It works fine both dropped on the interpreter, and with BuildApplication. Micro-test.py, opens a file, writes a little bit to it, then sleeps, then closes it. When dropped on the interpreter, it works fine, with no output window. When used with BuildApplication, it brings up an output window with nothing in it. I put the time.sleep() in so that you could see the output window for a few seconds. without it, it just flashed on screen. 1.5.2c1 and 1.6a2 behave in exactly the same way. I put the weird import macfsn line in to accomidate a bug in 1.6a2 Build Application. What is the deal here? Does anyone else get the same results? I did re-install Python, both 1.5 and 1.6, with no change. By the way: Blue&white G3, MacOS 8.6 My little ftp app took about 2hrs to write on Linux (I was teaching myself Tkinter as I went), and now weeks to get a distributable application on the Mac. Having the users install Python really isn't an option. I'm trying to sell folks here on Python as a good way to produce small cross-platform apps. (Large ones too, but that's a harder sell). The Mac is an important platform, and I really need to be able to demo it without having unwanted text windows pop up. Mac users don't like that kind of thing! Please help!! -Chris ----=_--b5a5f229.021f23e9.00000169 Content-Type: multipart/appledouble; boundary="--=_--b5a5f22a.021f241b.0000016a"; x-mac-type="54455854"; x-mac-creator="522A6368" Content-Disposition: attachment; filename="micro-test.py" ----=_--b5a5f22a.021f241b.0000016a Content-Type: application/applefile; name="micro-test.py" Content-Transfer-Encoding: base64 AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAADAAAASgAAAA0AAAAIAAAAVwAA ABAAAAAJAAAAZwAAACAAAAACAAAAhwAABa5taWNyby10ZXN0LnB5ARL0fwES+9kI AAAACAAAAFRFWFRSKmNoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABWgA AARoAAAARhxgABw4YwAsSAVAuWAAAACQYQEIgAEBiIBhAQhXvQb4kAMAAIABAYyA YQEIgIEBBJADAASAYQEIOAAAAJADAAyAYQGMgAEBkIKkAACDwQGMg+EBjH+DAhRj vQADOmAAADtAAAA6wAAASAACvHwf8EBBgABMO98AAEgAADxXoAb3QIIAHIgeAAAs AAAKQYIAMIgeAAAsAAANQYIAJFegBzlAggAQiB4AACwAAAlBggAQO94AAXwe4EBB gP/EfB/wQDtgAABAgABogGEBiDifAAA4/QAAfL/wUHzagFA5AQEMS/zCQWAAAACA AQEMfHgbeQAAAEgACU1vbmFjbwA2vrAABmnQByxhkAcsaUcHLGlHBza/QAAAAAYA BADVAUMCuwPbANUBQwK7A9u1pe/ZAAABMwAAATMAAAAAAQAAAAQYUipjaACCAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEGTW9uYWNvAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAAECUhl bHZldGljYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAxDb25maWRlbnRpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAEBAACAAAAAgAAA AIAAAACAAAAAAAAAAQEAAQAAAQAAAAEASAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAVoAAAEaAAAAEYH LJtQMTYAAAAcAEYAAU1QU1IAAAASQkJTVAAAAB4D7f//AAAAAAAAAAAAgP//AAAA TAcsl6w= ----=_--b5a5f22a.021f241b.0000016a Content-Type: text/plain; name="micro-test.py" Content-Transfer-Encoding: base64 IyBtaWNyby10ZXN0LnB5DSMgdmVyeSBzaW1wbGUgdGVzdCBzY3JpcHQNDWltcG9y dCB0aW1lICwgc3lzDWlmIHN5cy52ZXJzaW9uID09ICcxLjZhMiAoIzU0LCBNYXkg IDYgMjAwMCwgMDA6MjY6MjkpICBbQ1cgUFBDIHcvR1VTSTIgdy9USFJFQURTXSc6 DQlpbXBvcnQgbWFjZnNuICMgYWRkZWQgdG8gbGV0IEJ1aWxkQXBwbGljYXRpb24g KHYuMS42YTIpIGtub3cgdGhhdCBpdCBpcyBuZWVkZWQNDWZpbGUgPSBvcGVuKCdq dW5rLnR4dCcsJ3d0JykNDWZpbGUud3JpdGUoJ1NvbWUgcmFuZG9tIHN0dWZmXG4n KjEwMCkNDXRpbWUuc2xlZXAoNSkNDWZpbGUuY2xvc2UNDQ== ----=_--b5a5f22a.021f241b.0000016a-- ----=_--b5a5f229.021f23e9.00000169 Content-Type: multipart/appledouble; boundary="--=_--b5a5f22d.021f24cb.0000016b"; x-mac-type="54455854"; x-mac-creator="522A6368" Content-Disposition: attachment; filename="pico-test.py" ----=_--b5a5f22d.021f24cb.0000016b Content-Type: application/applefile; name="pico-test.py" Content-Transfer-Encoding: base64 AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAADAAAASgAAAAwAAAAIAAAAVgAA ABAAAAAJAAAAZgAAACAAAAACAAAAhgAABa5waWNvLXRlc3QucHkBEvhrARL6vwgA AAAIAAAAVEVYVFIqY2gBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAFaAAA BGgAAABGgAEAWDghAFB/4/t4fAgDpoPh//yDwf/4ToAAIAAN03R8CAKmk+H//JPB //h8niN4k6H/9Hx9G3iAYpcMkAEACJQh/7BIAABxfH8beUGCABCTvwAIk98ADEgA AAx/o+t4S/6qPYABAFg4IQBQf+P7eHwIA6aD4f/8g8H/+IOh//ROgAAgAA3R0HwI AqZ8ZBt4kAEACJQh/8CAYqSQS/ySoYABAEg4IQBAfAgDpk6AACAADdLAfAgCppPh //x8fxt4kAEACJQh/7CAYwAQS/vUzZBhADyAYQA8KAMAAECCAAxL/JLRSAAAEJPj AAQ4AAABAAAASAAJTW9uYWNvADa+oAAGadAYA2MsByxpRwAAAAoABmnQAIYABgAE ARcBDAJqAnoBFwEMAmoCerWl7r8AAAANAAAADQAAAAABAAAABBhSKmNoAIIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQZNb25hY28AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAAQJSGVs dmV0aWNhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADENvbmZpZGVudGlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAQEAAIAAAACAAAAA gAAAAIAAAAAAAAABAQABAAABAAAAAQBIAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABWgAAARoAAAARgcs m1AxNgAAABwARgABTVBTUgAAABJCQlNUAAAAHgPt//8AAAAAAAAAAACA//8AAABM ByyX8A== ----=_--b5a5f22d.021f24cb.0000016b Content-Type: text/plain; name="pico-test.py" Content-Transfer-Encoding: base64 I3BpY28tdGVzdC5weQ0jIHNpbXBsZSB0ZXN0IHdpdGggbm8gZmlsZSBJTw0NaW1w b3J0IHRpbWUgLCBzeXMNaWYgc3lzLnZlcnNpb24gPT0gJzEuNmEyICgjNTQsIE1h eSAgNiAyMDAwLCAwMDoyNjoyOSkgIFtDVyBQUEMgdy9HVVNJMiB3L1RIUkVBRFNd JzoNCWltcG9ydCBtYWNmc24gIyBhZGRlZCB0byBsZXQgQnVpbGRBcHBsaWNhdGlv biAodi4xLjZhMikga25vdyB0aGF0IGl0IGlzIG5lZWRlZA0NDWEgPSBbXQ1mb3Ig aSBpbiByYW5nZSgyMDApOg0JYS5hcHBlbmQoaSkNDWIgPSBbXQ1mb3IgaSBpbiBy YW5nZSgxMDApOg0JYi5hcHBlbmQoYSkNDXRpbWUuc2xlZXAoNSkN ----=_--b5a5f22d.021f24cb.0000016b-- ----=_--b5a5f229.021f23e9.00000169-- From i.caven@ieee.org Fri Jul 28 07:21:32 2000 From: i.caven@ieee.org (Ian Caven) Date: Thu, 27 Jul 2000 23:21:32 -0700 Subject: [Pythonmac-SIG] Build Application problem some more!! Message-ID: Chris: I tried your test programs and here are the results: First, I am running MacPython version 1.5.2c1 on a G4, OS 8.6. I built both applications using BuildApplication, with one change: I had to comment out the "import macfsn" line (replaced it with a pass statement), since BuildApplication reported that it couldn't find the module. I ran each program and *both* of them put up an output window. Then I dropped each application onto EditPythonPrefs and checked the "Delay console window until needed" checkbox in the interpreter options dialog. I then ran each program again and this time *neither* of them put up a console window. I also copied both programs to my (much slower) 8100, OS 8.1 and got the same results (no console). A couple of more details in case they are relevant: 1. When I run BuildApplication it asks me where PythonCore is and I point it to the shared library in the Python folder. (I don't know why it can't find it.) 2. As far as I know, the only modification that I have made to any code that could affect BuildApplication is to change $(PYTHON):Mac:Tools:macfreeze:macmodulefinder.py where I added a few module names to the MAC_MAYMISS_MODULES list. (A few months ago, I was having some problems with BuildApplication reporting some modules (org.python.core, SOCKS, and os.path) as missing but I wasn't using them, and adding their names to the list removed the error messages). I realize that this probably doesn't explain what is happening on your machine, but I thought that I would let you know. Ian. --- Ian Caven i.caven@ieee.org From jack@oratrix.nl Fri Jul 28 11:02:03 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 28 Jul 2000 12:02:03 +0200 Subject: [Pythonmac-SIG] ftplib with 1.6a2 In-Reply-To: Message by Chris_Barker@hazmat.noaa.gov (Chris Barker) , Thu, 27 Jul 2000 13:15:15 -0700 , Message-ID: <20000728100208.01098D2CC0@oratrix.oratrix.nl> Recently, Chris_Barker@hazmat.noaa.gov (Chris Barker) said: > I have earlier refered to problems with ftplib in 1.6a2. Jack sent a note > saying it worked for him, but it wasn't clear to me whether he meant 1.5 > or 1.6 . Anyway, this is what I get when I try to use ftplib. > [...] > ftplib.error_temp: 425 Data connection reset by client. Are you behind some strange type of firewall? ftplib tries to discover firewalls, but it does not always succeed (you can use set_pasv(1) to always make it do its firewall-circumvention tricks). The error you get here is not a bug but a genuine error returned by the FTP-server: the client (i.e. your program) has closed the data connection. -- 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 Fri Jul 28 18:00:42 2000 From: cbarker@jps.net (Chris Barker) Date: Fri, 28 Jul 2000 10:00:42 -0700 Subject: [Pythonmac-SIG] ftplib with 1.6a2 References: <20000728100208.01098D2CC0@oratrix.oratrix.nl> Message-ID: <3981BC3A.EFDF42A8@jps.net> Jack Jansen wrote: > Recently, Chris_Barker@hazmat.noaa.gov (Chris Barker) said: > > I have earlier refered to problems with ftplib in 1.6a2. Jack sent a note > > saying it worked for him, but it wasn't clear to me whether he meant 1.5 > > or 1.6 . Anyway, this is what I get when I try to use ftplib. > > [...] > > ftplib.error_temp: 425 Data connection reset by client. > > Are you behind some strange type of firewall? Maybe, but when I run it, I'm on the same side of any firewall as the ftp server. The main issue here is that the exact same code works with the exact same ftp server with the exact same setting from the exact same client machine, running 1.5.2c1 rather than 1.6a2, so something MUST have changed in ftplib. does anyone know what? By the way it also works with 1.5.2 uhder linux I don't have 1.6 for linux, so I havn't tried that. > ftplib tries to discover > firewalls, but it does not always succeed (you can use set_pasv(1) to > always make it do its firewall-circumvention tricks). I'll try that, and I'll try using set_debuglevel as well, to try and get more info. > The error you get here is not a bug but a genuine error returned by > the FTP-server: the client (i.e. your program) has closed the data > connection. Well, yes, but as I read it, the server is complaining that the client has closed the connection, not the other way around. Doesn't this mean that ftplib has closed the connection when I didn't ask it to? That would be a bug (or some wierd firwall thing). Granted I know nothing about the ftp protocalls, but something must have changed in ftplib, because the behaviour is changing. I have run this A LOT of times, with very consitent results, so it's not a temporary networking glitch. I'll post again if I get any info from setting a higher debug level. -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cbarker@jps.net Fri Jul 28 19:03:54 2000 From: cbarker@jps.net (Chris Barker) Date: Fri, 28 Jul 2000 11:03:54 -0700 Subject: [Pythonmac-SIG] Build Application problem SOLVED!!!!! References: Message-ID: <3981CB0A.2219951E@jps.net> OK, I was tearing my hair out trying ot figure out what the heck was going on here. No one else seemed to be having the problems I was having. Thanks to all of you that helped me out (esp. Jack, Russel,and Ian). I finally got a clue when I read Ian's message: >Then I dropped each >application onto EditPythonPrefs and checked the "Delay console window >until needed" checkbox in the interpreter options dialog. I then ran each >program again and this time *neither* of them put up a console window Well, I checked for the twentieth time, and "Delay console window until needed" was already checked. but, a lightbulb went off, so I unchecked it, closed EditPythonPrefs, then opened it again, and checked it again. After this it works right. So it appears that if "Delay console window until needed" is set on your main interpreter, BuildApplication sets the check box, but doesn't actaully set it where it needs to be set (although the window didn't come up if I didn't opena file, hmmm). In conclusion, it is probably a bug, but one with a very easy work-around! YEA!!! Thanks to everyone for putting up with my repeated frustrated posts. -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From Chris_Barker@hazmat.noaa.gov Fri Jul 28 21:22:51 2000 From: Chris_Barker@hazmat.noaa.gov (Chris Barker) Date: Fri, 28 Jul 2000 13:22:51 -0700 Subject: [Pythonmac-SIG] more ftplib problems/info Message-ID: HI all, Well, I looked a little more into the ftplib problems I was having, and I have some more info. I may have found a bug, but I know so little about the FTP protocall (and TCP-IP in general) that I'm not the least but sure. The synopsis: Under 1.5, ftplib appears to work, but mangles uploaded binary files (linefeed wierdness?) Under 1.6, ftplib won't upload a file at all, it appears to send an incorrect PORT command. The long story: I ran a test script (included at the end of this post) which uploads a binary file with debugging turned on (fill in valid data for your server, etc), and I got the following results: OUTPUT running under 1.5.2c1: --------------------------- *cmd* 'CWD junk' *put* 'CWD junk\015\012' *get* '250 CWD command successful.\015\012' *resp* '250 CWD command successful.' directory changed *cmd* 'TYPE I' *put* 'TYPE I\015\012' *get* '200 Type set to I.\015\012' *resp* '200 Type set to I.' *cmd* 'PORT 161,55,66,73,8,65' *put* 'PORT 161,55,66,73,8,65\015\012' *get* '200 PORT command successful.\015\012' *resp* '200 PORT command successful.' *cmd* 'STOU TheBarkers.JPG' *put* 'STOU TheBarkers.JPG\015\012' *get* '150 Opening BINARY mode data connection for TheBarkers.JPG.\015\012' *resp* '150 Opening BINARY mode data connection for TheBarkers.JPG.' All appears to be well, except the file got corrupted. It looks like it might be line-ending translation, which shouldn't be happening with a binary transfer, but it looked that way when I looked at the pre- and post- corrupted files in a text editor. I then did another test, and transfered a text file in binary mode, and the mac line endings were converted to unix line endings, which should not happen!, so that's the problem, finding it is another matter. This makes me wonder: Has anyone actaully used ftplib on the mac before?? Under 1.6, it didn't work at all: OUTPUT running under 1.6a2: --------------------------- *cmd* 'CWD junk' *put* 'CWD junk\015\012' *get* '250 CWD command successful.\015\012' *resp* '250 CWD command successful.' directory changed *cmd* 'TYPE I' *put* 'TYPE I\015\012' *get* '200 Type set to I.\015\012' *resp* '200 Type set to I.' *cmd* 'PORT 0,0,0,0,8,58' *put* 'PORT 0,0,0,0,8,58\015\012' *get* '500 Illegal PORT Command\015\012' *resp* '500 Illegal PORT Command' Now I have found a problem: the PORT command is sending totally different data than it did under 1.5. Looks like a bug to me. NOTE: I have had both of these problems with two different ftp servers: one a Linux box that is just a hub away form my Mac, and one a mac, that is on the same subnet, so I don't think it's firewall or networking problems. By the way, when 1.6a2 exits out with this error, I have to command+option+esc to kill it. Thanks for any help anyone can give me. -Chris #### TEST SCRIPT ##### from ftplib import FTP # set up some ftpsite data: ftp_server = 'your server' username = 'your username' password = 'your password' directory = 'your directory' filename = 'filename to download' server = FTP(ftp_server,username,password) server.set_debuglevel(2) server.cwd(directory) file = open(filename,'r') server.storbinary('STOU '+filename,file,1024) file.close() server.quit() From i.caven@ieee.org Fri Jul 28 22:51:25 2000 From: i.caven@ieee.org (Ian Caven) Date: Fri, 28 Jul 2000 14:51:25 -0700 Subject: [Pythonmac-SIG] more ftplib problems/info Message-ID: Chris_Barker@hazmat.noaa.gov Fri Jul 28 21:22:51 2000 wrote: > >This makes me wonder: Has anyone actaully used ftplib on the mac before?? > Yes, we have used it extensively for binary transfers under version 1.5.2c1. > >#### TEST SCRIPT ##### [] > >server.storbinary('STOU '+filename,file,1024) > I haven't seen this form of the command before. We use: server.storbinary('STOR '+filename,file,1024) > >file = open(filename,'r') > This line should read: file = open(filename,'rb') for binary transfers. (I have made this mistake several times). --- Ian Caven i.caven@ieee.org From jack@oratrix.nl Fri Jul 28 23:26:26 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 29 Jul 2000 00:26:26 +0200 Subject: [Pythonmac-SIG] ftplib with 1.6a2 In-Reply-To: Message by Chris Barker , Fri, 28 Jul 2000 10:00:42 -0700 , <3981BC3A.EFDF42A8@jps.net> Message-ID: <20000728222631.60069D8392@oratrix.oratrix.nl> Recently, Chris Barker said: > Maybe, but when I run it, I'm on the same side of any firewall as the > ftp server. The main issue here is that the exact same code works with > the exact same ftp server with the exact same setting from the exact > same client machine, running 1.5.2c1 rather than 1.6a2, so something > MUST have changed in ftplib. does anyone know what? By the way it also > works with 1.5.2 uhder linux I don't have 1.6 for linux, so I havn't > tried that. Bingo! Sorry, I should have thought of this: 1.6a2 is built with a slightly older version of GUSI (the I/O and socket library) than what I'm using right now, and one of the bugs with it was that there were occasional problems with tcp/ip connections. So the short answer is that you should stick with 1.5.2, and I can use your script to check that the tcp/ip bug is actually gone from gusi (I'm masking it currently by using gusi with mactcp in stead of with open transport, but OT is better in the long run because of better performance). Now the only problem remaining is the console window that opens, and unfortunately I have no idea about how to figure out what is happening. My usual course of action would be to run everything under the MetroWerks debugger, but I'm afraid that won't work because the BuildApplication-generated application bears little or no resemblence to the original shared libraries, so I don't think I can debug it:-) Any good idea, anyone? -- 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 Jul 28 23:35:26 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 29 Jul 2000 00:35:26 +0200 Subject: [Pythonmac-SIG] Build Application problem SOLVED!!!!! In-Reply-To: Message by Chris Barker , Fri, 28 Jul 2000 11:03:54 -0700 , <3981CB0A.2219951E@jps.net> Message-ID: <20000728223531.D910ED8392@oratrix.oratrix.nl> Recently, Chris Barker said: > Well, I checked for the twentieth time, and "Delay console window until > needed" was already checked. but, a lightbulb went off, so I unchecked > it, closed EditPythonPrefs, then opened it again, and checked it again. > After this it works right. So it appears that if "Delay console window > until needed" is set on your main interpreter, BuildApplication sets the > check box, but doesn't actaully set it where it needs to be set > (although the window didn't come up if I didn't opena file, hmmm). Hmm, this could have something to do with the defaulting scheme for MacPython's runtime options. They can be gotten from three places, in order of precedence 1) an override 'Popt' recource from the application 2) a normal 'Popt' resource from the prefs file 3) a normal 'Popt' resource form the application (factory defaults) If you don't change anything it won't write a resource. But apparently that scheme needs rethinking for applications, because they don't look at the preferences file (but EditPythonPrefs doesn't know this). I'll ponder on this, does anyone have any bright ideas about how I could see the difference between an application and an applet? -- 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 just@letterror.com Sat Jul 29 01:14:16 2000 From: just@letterror.com (Just van Rossum) Date: Sat, 29 Jul 2000 01:14:16 +0100 Subject: [Pythonmac-SIG] Build Application problem SOLVED!!!!! In-Reply-To: <20000728223531.D910ED8392@oratrix.oratrix.nl> References: Message by Chris Barker , Fri, 28 Jul 2000 11:03:54 -0700 , <3981CB0A.2219951E@jps.net> Message-ID: At 12:35 AM +0200 29-07-2000, Jack Jansen wrote: >I'll ponder on this, does anyone have any bright ideas about how I >could see the difference between an application and an applet? Look whether there is a preferences filename resource available; if it's empty it won't look at the prefs file (or so you told me a long time ago ;-). If I remember correctly, BuildApplication explicitly adds an empty pref filename resource to achieve this... (EditPythonPrefs still needs rethinking, though; I don't really like the fact that it doesn't tell you what exactly you're looking at: even for an applet I might want to set an option that happens to be the same as the current global setting. Even worse: the way to set your prefs once and for all when building apps or applets is to drop its' resource file on EditPythonPrefs; what would you do then? It's not an applet, it's not an app, there's probably no pref file name resource, it's... confusing...) Just From owen@astro.washington.edu Sat Jul 29 00:28:42 2000 From: owen@astro.washington.edu (Russell E Owen) Date: Fri, 28 Jul 2000 16:28:42 -0700 Subject: [Pythonmac-SIG] State of BBPy? More general Tkinter development question. Message-ID: I have gotten BBPy to work with Pyton 1.6a2 (but not 1.5.2) by changing "from Types.py import *" to "from types.py import *" (i.e. types must be lower case) in PythonSlave.py. One simple script I tried ran fine. However, when I tried to run a Tkinter script I'm working on Python hung and so did BBEdit. (In general BBEdit seems susceptible to hanging if Python hangs when using BBPy). Is this a known limitation in BBPy, that it fails with Tkinter scripts? Or did I just get unlucky and have something fail, or what? Any suggestions for a good environment in which to build Tkinter applications would be very much appreciated. It doesn't have to be on the Mac. The present business of editing the file, dropping it onto PythonInterpreter, having it choke, analyzing the output and doing it all over again is pretty painful. Also, any suggestions on ways to interact with a Tkinter script while building it would be appreciated. I'd like to start things up and then be able to talk to my widgets and generally exercise my code interactively. Regards, -- Russell From cbarker@jps.net Sat Jul 29 00:33:19 2000 From: cbarker@jps.net (Chris Barker) Date: Fri, 28 Jul 2000 16:33:19 -0700 Subject: [Pythonmac-SIG] more ftplib problems/info References: Message-ID: <3982183F.201B536C@jps.net> Ian Caven wrote: > >This makes me wonder: Has anyone actaully used ftplib on the mac before?? > > Yes, we have used it extensively for binary transfers under version 1.5.2c1. I had expected so, but I was getting so frustrated, I was beginning to wonder. > >server.storbinary('STOU '+filename,file,1024) > > > > I haven't seen this form of the command before. We use: > > server.storbinary('STOR '+filename,file,1024) I got this from: Network Working Group Request for Comments: 959 FILE TRANSFER PROTOCOL (FTP) STORE UNIQUE (STOU) This command behaves like STOR except that the resultant file is to be created in the current directory under a name unique to that directory. The 250 Transfer Started response must include the name generated. So, it works just like STOR, but won't write over an existing file with the same name. > >file = open(filename,'r') > > > > This line should read: > > file = open(filename,'rb') Of course it should! STUPID,STUPID,STUPID,STUPID,STUPID,STUPID,STUPID. I had of course thought of that, and had managed to convince myself that the default was binary, rather than text. It worked on Linux, because there is no difference. I didn't just stick the 'b' in there, because I was once been chastised for using 'rt' to indicate a text file on the python newsgroup (I got that from MATLAB, where binary is the default) Thanks for clearing this up for me, my simple little app now works fine, after two hours of coding, and over a week of debugging! -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cbarker@jps.net Sat Jul 29 00:35:48 2000 From: cbarker@jps.net (Chris Barker) Date: Fri, 28 Jul 2000 16:35:48 -0700 Subject: [Pythonmac-SIG] ftplib with 1.6a2 References: <20000728222631.60069D8392@oratrix.oratrix.nl> Message-ID: <398218D4.82A64B50@jps.net> > So the short answer is that you should stick with 1.5.2, and I can use > your script to check that the tcp/ip bug is actually gone from gusi > (I'm masking it currently by using gusi with mactcp in stead of with > open transport, but OT is better in the long run because of better > performance). Sounds good, you are calling 1.6 an alpha release, after all. Thanks for all your help. -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cbarker@jps.net Sat Jul 29 00:42:54 2000 From: cbarker@jps.net (Chris Barker) Date: Fri, 28 Jul 2000 16:42:54 -0700 Subject: [Pythonmac-SIG] Build Application problem SOLVED!!!!! References: <20000728223531.D910ED8392@oratrix.oratrix.nl> Message-ID: <39821A7E.E40D584C@jps.net> Jack Jansen wrote: > If you don't change anything it won't write a resource. But apparently > that scheme needs rethinking for applications, because they don't look > at the preferences file (but EditPythonPrefs doesn't know this). I'm still confused by all this Mac resource stuff, but it seems to me the obvious choice is to put a 'Popt' resource into EVERY application, regardless of whether it has been changed or not. The idea of an application (rather than an applet) is that it will act just like any other application, and should never be influenced by the users Python installation, or lack thereof. In any case, for the moment, all we have to do is make sure we change something in EditPythonPrefs after building an app. Not a big deal. Thanks for your help on this as well, -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From gwrx@mac.com Mon Jul 31 10:39:08 2000 From: gwrx@mac.com (junghua) Date: Mon, 31 Jul 2000 17:39:08 +0800 Subject: [Pythonmac-SIG] Any ftpd wrote in MacPython? Message-ID: Hi I find som ftpd programming with Python http://melkor.dnp.fmph.uniba.sk/~garabik/pyftpd.html but I find it can not work under Mac Any ftpd in MacPython? Please help me thanks. From sales@lookelu.com Mon Jul 31 10:07:15 2000 From: sales@lookelu.com (The Western Web) Date: Mon, 31 Jul 2000 09:07:15 Subject: [Pythonmac-SIG] The Western Web Newsletter Message-ID: <20000731160513.A561F1CF5D@dinsdale.python.org> THE WESTERN WEB WEEKLY NEWS LETTER Week of July 24, 2000 Serving Over 75000 Recipients With your assistance "The Western Web" continues to improve and your input is helpful.Our goal is to make "The Western Web" THE one place stop for all your Horse, Livestock and Western Life Style needs. If You have added your site to our search engine, please make sure everything is correct. If you haven't noticed we have upgraded the look and capabilities of The Western Web search engine. You can now type in your search word and find all related site links. Don't forget to add your Web Site to our search engine too. http://www.searchthewesternweb.com This week you might take a look at our "Events Calendar" in our Classified Ad section. You can post your upcoming events in subcategories such as: Events, Shows, Cuttings, Team Roping, Gymkhana, Clinics, Trail, Auctions, Rodeos, Reining, Barrel Racing, Team Penning and Performance & Halter. We also have a subcategory for "Other" to place any event not categorized. These ads are free and you can add pictures, video and audio. A note to our subscribers who have posted ads, with you User Name and Password you can update your events. http://www.westernwebclassified.com/cgi-bin/classifieds/classifieds.cgi At last, an online service available with the horse lover in mind, The Sale Barn.Com (www.thesalebarn.com). The Sale Barn offers an online auction specifically for horse-related items, whether you are buying or selling. The Sale Barn auctions off 100s of items daily with many items in the Hot Items Listing starting at $1.00! Usually there are from 150 to 200 items starting at only $1.00. From saddles, bridles, bits, spurs and unique gift items. Register now to qualify for our weekly drawing. The current prize is a 34 x 36 Wool Blend Show Blanket with wear leathers and silver conchos valued at $99.95! This item is featured on our Home Page at www.thesalebarn.com. Registration is free on our secure site with no credit card necessary. The Sale Barn is amongst the top 10 visited horse sites on the Internet with over 10,000 hits a day. A perfect opportunity to turn unneeded horse related items in to cash. The Sale Barn is the ebay of the horse world with categories directed to specific items such as saddles, headstalls, bits, spurs, ropes, gift items, horse trailers, etc. http://www.thesalebarn.com We appreciate you patronizing our sponsors. You to can have your web site on our front page along with Banks Power, Roo-hyde Saddlery, GMC, Bootbarn.com,Truckloads.net, Zig Zigler, Comforce, The Gaited Horse, Cowboy Tack, Painted Acres Ranch,The ShawnOshine,Tom Balding Bits & Spurs, Centenary of Federation and Stoxrus.com. You can find our reasonable rates at: http://www.thewesternweb.com/Advertising/Advertising.htm While at The Western Web site take a look at our message board: http://www.westernmessageboard.com/cgi-bin/Ultimate.cgi We can Design & Host your web site. Check out our low domain name registration prices at: http://www.thewesternweb.com/Web_Design/Domain_Name_Registration.htm For you convenience, there are links to these sites and more, from The Western Web Home Page. http://www.thewesternweb.com/ If you receive this message in error or want us to remove you from our newsletter e-mail list, please reply to this email address with the word "Remove" in the subject line. Thank You, http://www.thewesternweb.com