🌐 Mailman 3 September 2001 - Pythonmac-SIG - python.org

Error in BuildCGIApplet?
by Bob Heeter Sept. 24, 2001

Sept. 24, 2001

Python gurus - I think I have a fix for a year-old bug in BuildCGIApplet. While updating (finally) to Mac Python 2.1.1 from 1.5c2, I rediscovered this previously-reported bug in the BuildCGIApplet code: >Date: Tue, 24 Oct 2000 13:01:52 -0700 >From: Jacob Kaplan-Moss <jacobkm(a)cats.ucsc.edu> >Subject: [Pythonmac-SIG] MacPython 2.0 Final >[...] > >However, BuildCGIApplet bombs every time I use it with the following >traceback: > >Traceback (most recent call last): > File "1gb External HD:Jacobs Stuff Master: Programming:Python >2.0:Mac:Tools:CGI:BuildCGIApplet.py", line 76, in ? > main() > File "1gb External HD:Jacobs Stuff Master: Programming:Python >2.0:Mac:Tools:CGI:BuildCGIApplet.py", line 21, in main > buildcgiapplet() > File "1gb External HD:Jacobs Stuff Master: Programming:Python >2.0:Mac:Tools:CGI:BuildCGIApplet.py", line 54, in buildcgiapplet > buildone(template, wrapper, filename, dstfilename) > File "1gb External HD:Jacobs Stuff Master: Programming:Python >2.0:Mac:Tools:CGI:BuildCGIApplet.py", line 70, in buildone > py_resource.frompyfile(src, "CGI_MAIN", preload=1) > File "1gb external hd:jacobs stuff master: programming:python >2.0:mac:lib:py_resource.py", line 68, in frompyfile > return frompycfile(file, name, preload=preload, ispackage=ispackage) > File "1gb external hd:jacobs stuff master: programming:python >2.0:mac:lib:py_resource.py", line 59, in frompycfile > writemodule(name, id, data, preload=preload, ispackage=ispackage) > File "1gb external hd:jacobs stuff master: programming:python >2.0:mac:lib:py_resource.py", line 44, in writemodule > res.AddResource(type, id, name) >Mac OS Error: (-61, 'write permissions error') > >The resulting applet seems to work, however. I did a little code-surfing and I think the error is in the "buildone()" function in BuildCGIApplet.py: >def buildone(template, wrapper, src, dst): > buildtools.process(template, wrapper, dst, 1) > # write source as a PYC resource into dst > ref = Res.FSpOpenResFile(dst, 1) # <- should be (dst, 2) for write [...] Inspection of the other code being called suggests that the call to Res.FSpOpenResFile(dst,1) is attempting to open the file in read-only mode. That is, the "1" in "(dst,1)" is shorthand for "read" while "2" would be "write". I modified the code to use "2" instead of "1" and rebuilt BuildCGIApplet, and it works like a charm. (I wouldn't have had a clue, but someone was kind enough to enumerate the constants in a different module, so when I saw WRITE = 2 and a call elsewhere with (dst, WRITE) a big light bulb lit up and all my problems were solved...) The only other problem I've had with 2.1.1 vs. 1.5c2 is that every applet which terminates abnormally (either by coughing up an exception or via command-dot) goes into a menu-less mode where my only option is to force-quit. I know this misbehavior has already been reported, but I can't tell if it has been fixed yet? Finally, I feel compelled to emote about the vastly improved memory handling / garbage-collection in 2.1 vs. 1.5. I've been using Python to write a hobby-scale internet-based multiplayer strategy-diplomacy game which runs over my DSL line from an old 100 MHz PowerBook with very little free RAM, and one of my big bottlenecks has been memory usage. Switching to the new version of Python cuts my memory usage in half, which will allow me to support twice as many players (from 50 to 100) without doing any real work! http://www.heeter.net/games/ -- Bob Bob Heeter Livermore, California

2 1

Shelve objects with Python 2.1.1
by Josh English Sept. 22, 2001

Sept. 22, 2001

I just upgraded to Python 2.1.1 and a program I was working on using a shelve file with 2.1 that worked, doesn't. The first thing I noticed is that it creates two database files, one in the directory of the Python IDE and the other in the same directory as the script. I have no idea which one it's using at any given time. The objects that are in the shelve are based on the contents of a directory on my hard drive. If the database is empty, it is supposed to read those files and create objects for those files, then store them in the shelf. They get created, but subsequent editing fails. Have shelves been changed in 2.1.1? I read through the READ ME and recent changes, but there is nothing like this that I can find. The last really strange behavior is that it seems to be looping my code where there is no loop. It opens the shelve, then lists the keys to the standard output, then goes back 60 lines or so to try to open the database again instead of closing it, which is the very next line: Any help? -- Josh English english(a)spiritone.com The POV-Ray Cyclopedia http://www.spiritone.com/~english/cyclopedia/

1 0

Suitability of using Python as an inteface to MS Excel on MacIntosh
by Patrick Hayes Sept. 19, 2001

Sept. 19, 2001

Greetings to all: I have been tasked to evaluate the suitabilty of using Python to interface (Reading and Writing) with Microsoft Excel running on the MacIntosh platform with development to be done on a Win32 platform). I would greatly appreciate any help and information that you may be able to provide. Patrick Hayes SAIC-El Paso

1 0

RE: [Pythonmac-SIG] Mac Python and line-endings
by Schollnick, Benjamin Sept. 19, 2001

Sept. 19, 2001

> Should a file being read be required to have a single line termination > type, or could they be mixed and matched? The prototype code allows mix > and match, but I'm not married to that idea. If it requires a single > terminator, then some performance could be gained by checking the > terminator type when opening the file, and using the existing native > text file code when it is a native file. I'm not aware of any type of text file, that supports switching line deliminators inside of the same file.... Now that doesn't mean it couldn't exist, but logically that would be a strange file.... I think it's a even bet that a file would have the same deliminator throughout the file. > My proposed solution to these problems is to have a new type of file: a > "Universal" text file. This would be a text file that would do line-feed > translation to the internal representation on the fly as the file was > being read (like the current text file type), but it would translate any > of the known text file formats automatically (\r\n, \r, \n Any > others???). That would be a interesting idea... I'm not sure how much of a performance hit we'd see, but that would certainly solve a PC / MAC issue I'm having.... (Any chance we could see the code?) Regarding your points on changing the default text file type.... There are several different ways to solve this. * Don't have the Universal be the default text file type, instead offer it as a different class, or as a open('garbage.txt', "r", universal), or some other optional switch. - Advantages being that this allows the programmer to control of the Universal usage. * Just the opposite, the programmer explicitly tells Python not to support universal... * Have the programmer subclass the File Type? * Add a global directive? * Specifically import a "universal" which will depreciate the "standard" text file IO routines... * Actually I think this sounds like the easiest and fastest way to deal with it. This way, you could add a extension library to speed it up, or whatever... (This idea is very much along the lines (??) of the STRING / STROP import) - Benjamin

6 8

MacPython 2.2a3 available
by Jack Jansen Sept. 18, 2001

Sept. 18, 2001

In an unprecedented move MacPython 2.2a3 is available only a scant 26 hours or so after the unix/windows distribution of 2.2a3. MacPython 2.2a3 is available via http://www.cwi.nl/~jack/macpython.html, as usual, and in hqx or macbinary form, as a full installer, an active installer and a source distribution (as usual:-). Aside from the general new 2.2a3 features there are three specific changes in MacPython that are worth mentioning: - The structure of the MacOS toolbox modules has changed. All the modules have been put into a "Carbon" package (which, despite the name, runs fine in the classic PPC runtime model). There is a backwards compatibility folder on sys.path that will keep imports with the old names working (with an obnoxious warning). - Plugin modules are now in :Lib:lib-dynload in stead of in :Mac:PlugIns, to make the installed tree look more like the unix tree. - On input, unix line-endings are now acceptable for all text files. This is an experimental feature (awaiting a general solution, for which a PEP has been promised but not started yet, the giulty parties know who they are:-), and it can be turned off with a preference. The downside of the quick release is that the installer has only been tested on MacOSX 10.0.4 and MacOS 9.1. Please report problems on older releases of MacOS asap. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 1

AIFC problem and applet bloat and ...
by Michael Dunn Sept. 15, 2001

Sept. 15, 2001

The python.org help address couldn't offer any suggestions re these problems. The problem: I think there's a bug in the aifc module. I've generated several 16 & 24 bit 44.1kHz stereo files, and although they play using quicktime, neither Toast, nor my audio editor (MOTU Audiodesk) recognize them as valid. (Python 2.1 (#92, Apr 24 2001, 23:59:23) [CW PPC GUSI2 THREADS] on mac) The later diagnosis: I've discovered the problem, though not a good fix. The audio file gets written with filetype AIFC, not AIFF!!! I can change this using resedit, and all my apps are then ok with the file. I *do* have 'file.aiff()' in my code, and I've also tried without (the docs are pretty unclear about this). Also, the filename extension *is* '.aiff'. The filetype always comes out as AIFC though. I was prepared to code around this by manually fixing the filetype using a Mac library function, but I couldn't find any to do this. p.s., Is there a reasonable way to make applets smaller? I mean - 1K of code - 30K of icons and stuff?!?!? Why so many? I hope these haven't been covered before, but downloading 12MB of archives is not my idea of fun searching... Thanks for any help you can provide. p.p.s., Is there any reason an applet generated on the Mac shouldn't run on other platforms? (of course, stripped of the resource fork)

2 1

running AppleScript from MacPython?
by Rob Saul Sept. 13, 2001

Sept. 13, 2001

Hi, I looked in the mail archives for AppleScript info ( the lack of a search function made this difficult ). I'm wondering if it's possible to run AppleScript from Python? If so, can someone point me to info about how to do it? Thank, ~Rob

3 2

Re: redefining builtin function
by Christopher Smith Sept. 12, 2001

Sept. 12, 2001

shalehperry(a)home.com writes: >Seems to work here. hmm...but not here. Here is my IDE header Python 2.1.1 (#97, Aug 2 2001, 21:56:33) [CW CARBON GUSI2 THREADS] Type "copyright", "credits" or "license" for more information. >>> I tried pasting the following script (now like yours) into a fresh script window of a fresh session and still get the AttributeError. #### def round(x,n=0): return __builtins__.round(x,n) print round(1.23,1) #### No problem in the interactive window, though. :-( /c

1 0

Re: [Pythonmac-SIG] A MachO Python application in 2.2a3 - please try it!
by Jack Jansen Sept. 11, 2001

Sept. 11, 2001

Donovan, thanks a lot, it works wonderfully! Your applet mods are now in the CVS repository, together with various other fixes I've made over the weekend (see below). I suggest that people wanting to experiment with OSX and Carbon and such check out a Python version from the sourceforge repository. I've made a couple of changes to your mods. A few cosmetic ones (comment style, added static, added a "length" parameter to the resource-finder routine) and one structural one. I've removed your runRawMain and runAppletMain routines and in stead always use Py_Main() to run the script. Py_Main now has an optional "script" parameter. This keeps sys.argv intact for rawmain applets, and it also solves the sys.path problem. I'm leaving your nib stuff alone for the time being. There's little point in putting it in the repository as I'm off for 3 weeks from tomorrow (which means getting changes into the repository will require asking someone else, such as Just or so). Moreover, I think I want to do the nib API interfaces more along the lines of the other toolbox modules, i.e. bgen-generated. That will save an incredible amount of maintainance work in the long run. As to the things I changed over the last few days: - Python.app now has resources: the standard MacPython dialog resources. This means that EasyDialogs works! <option>starting Python.app even works (to my surprise:-). - There's a rudimentary applesingle module. It is only used to create the datafork-based .rsrc file for Python.app right now, but this should also plug into macresource so that the various .rsrc-using modules can start to work under Macho. - fsspec.as_pathname() works, and returns unix pathnames. This means macfs.StandardGetFile() and friends now work. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Error 45 with Paos and setsockopt
by Stefan Witzgall Sept. 11, 2001

Sept. 11, 2001

Hi Jack, >I'm a bit surprised that SO_REUSEADDR isn't supported (but then, I never >tried >it:-). now, 1 day later, I tried it again... and strange, no error with SO_REUSEADDR. After fiddling with sys.arg related things I got server.py running. Hmm, running means it gives a message "server running and listening" and stalls the IDE, I must do a opt-cmd-esc kill. The interpreter did it right and didn't stall the machine. But trying to use a client related script I got an error about module pwd. And after the line with the import pwd call there comes one with import fcntl. Oh God, seems to be all Unix related... I gave up. This guy says his package is for "all platforms". He didn't do his homework. > >Anyway, you can safely take this out, usually. Setting SO_REUSEADDR is mostly >used to be able to quickly listen to a port again after the previous program >listening to that port has crashed. Normally there is a timeout of about a >minute. > >If you take out this option the only thing you may notice is that if your >program is aborted and you immedeately try to start it again you will get an >"Address in use" or something similar. Wait a minute and it will go away. >-- I didn't trie these ones, since I gave up earlier. Now I will play around with GadFly, which did run nearly out of the box and creats a database as expected. Things to do are then SQL related stuff. Thank you and all others for help and suggestions. Stefan <Stefan.Witzgall(a)online.de>

1 0