From steele@cs.brandeis.edu Mon Nov 1 11:15:24 1999 From: steele@cs.brandeis.edu (Oliver Steele) Date: Mon, 01 Nov 1999 06:15:24 -0500 Subject: [Pythonmac-SIG] Problem with SpaceTranslationPatch Message-ID: If you open a file with mixed tab and space indentation with SpaceTranslationPatch.py installed, the patch will silently change the indentation so that the indentation no longer works. (It does this in the buffer, and then if you save the buffer the file is messed up too.) This happens because some lines are indented one level with ' ' and others are indented two levels with '\t', and it changes the ' ' lines to '\t' so that they read the same to the interpreter. (I posted that SpaceTranslationPatch didn't handle mixed spaces and tabs, but I didn't think through the failure mode.) This shows up with the recent platform.py module posted to python-announce. I recommend you remove the patch until I have a chance to update it, so it won't bite you. If you won't be editing any files with a different pedigree than what you've been using the patch with, it's still harmless on those, of course. From me@mrmann.com Tue Nov 2 15:03:21 1999 From: me@mrmann.com (Chris,Mann) Date: Tue, 02 Nov 1999 10:03:21 -0500 Subject: [Pythonmac-SIG] os.linesep? Message-ID: easy question: I'm parsing thru a file and then putting the lines back together using os.linesep, but when I open the new text file with either the IDE or BBEdit, it's showing up as Unix linefeeds (or at least that's the message I'm getting). os.linesep is equal to '\015' or '\r' on my mac, which I thought was the Macintosh linefeed. But it seems like '\n' is what both BBEdit and the IDE like. What am I missing here? thanks -chris From andres@corrada.com Tue Nov 2 16:44:54 1999 From: andres@corrada.com (Andres Corrada) Date: Tue, 02 Nov 1999 11:44:54 -0500 Subject: [Pythonmac-SIG] os.linesep? References: Message-ID: <381F1506.1AF5463C@corrada.com> I remembered being hit by this some months. If I remembered correctly, the IDE makes all files have UNIX line terminators (\n). Am I right pythoneers? ------------------------------------------------------ Andres Corrada-Emmanuel Email: andres@corrada.com Owner http://www.corrada.com/mamey Mamey Phone: (413) 587-9595 ------------------------------------------------------ From just@letterror.com Tue Nov 2 18:54:20 1999 From: just@letterror.com (Just van Rossum) Date: Tue, 2 Nov 1999 19:54:20 +0100 Subject: [Pythonmac-SIG] os.linesep? In-Reply-To: <381F1506.1AF5463C@corrada.com> References: Message-ID: At 11:44 AM -0500 11/2/99, Andres Corrada wrote: >I remembered being hit by this some months. If I remembered correctly, >the IDE makes all files have UNIX line terminators (\n). Am I right >pythoneers? No. The IDE reads and writes Mac (\r) files. The latest version of the IDE (the one that shipped with 1.5.2c) will alert the user if it encounders a Unix or Dos file, and can convert to Mac. I think the original poster is confused by the behavior of files opened in text mode: \r and \n will be exchanged so an oridinary Mac text file will *look* like a Unix file as far as the program is concerned, but it's still a Mac file on disk. So: if you're opening files in text mode, you should always assume \n, and not use os.linesep... Just From me@mrmann.com Tue Nov 2 19:04:09 1999 From: me@mrmann.com (Chris,Mann) Date: Tue, 02 Nov 1999 14:04:09 -0500 Subject: [Pythonmac-SIG] os.linesep? In-Reply-To: Message-ID: on 11/2/99 1:54 PM, Just van Rossum at just@letterror.com wrote: > I think the original poster is confused by the behavior of files opened in > text mode: \r and \n will be exchanged so an oridinary Mac text file will > *look* like a Unix file as far as the program is concerned, but it's still > a Mac file on disk. > > So: if you're opening files in text mode, you should always assume \n, and > not use os.linesep... No, here's the bit of code that's writing out to a file: file = file + '.all' fileID = open(file, 'w') for bug in self.bugs: if not bug.err: fileID.write(bug.summary(delimiter)) fileID.write(linesep) iBugCount = iBugCount + 1 fileID.close() basically it's a list of strings that i'm writing to the file one line at a time. But if I use os.linesep and then open that text file with BBEdit, it says it's a Unix formatted file, not Mac. I would assume that it would be Mac formatted since I'm using os.linesep. -c From just@letterror.com Tue Nov 2 19:10:40 1999 From: just@letterror.com (Just van Rossum) Date: Tue, 2 Nov 1999 20:10:40 +0100 Subject: [Pythonmac-SIG] os.linesep? In-Reply-To: References: Message-ID: At 2:04 PM -0500 11/2/99, Chris,Mann wrote: >No, here's the bit of code that's writing out to a file: > file = file + '.all' > fileID = open(file, 'w') > for bug in self.bugs: > if not bug.err: > fileID.write(bug.summary(delimiter)) > fileID.write(linesep) > iBugCount = iBugCount + 1 > fileID.close() > >basically it's a list of strings that i'm writing to the file one line at a >time. But if I use os.linesep and then open that text file with BBEdit, it >says it's a Unix formatted file, not Mac. I would assume that it would be >Mac formatted since I'm using os.linesep. - you're opening your file in text mode ('w' and not 'wb') - \r and \n will be echanged upon write as well as read - os.linesep == \r - so: your file will be indeed be a unix file So: use \n when in text mode or os.linesep when in binary mode, and you're set. Just From joe@strout.net Tue Nov 2 19:50:09 1999 From: joe@strout.net (Joseph J. Strout) Date: Tue, 2 Nov 1999 11:50:09 -0800 Subject: [Pythonmac-SIG] os.linesep? In-Reply-To: References: Message-ID: At 2:04 PM -0500 11/2/99, Chris,Mann wrote: >No, here's the bit of code that's writing out to a file: > file = file + '.all' > fileID = open(file, 'w') > for bug in self.bugs: > if not bug.err: > fileID.write(bug.summary(delimiter)) > fileID.write(linesep) > iBugCount = iBugCount + 1 > fileID.close() This is fine as long as linesep is '\n', not os.linesep. As Just explained, files opened in text mode (like the above) swap '\n' and '\r' when reading and writing. So always use '\n'. Note that this could be written more concisely as: fileID.writelines(map(lambda x,d=delimiter:x.summary(d), self.bugs)) in place of the "for" loop. Oh, and then do iBugCount = iBugCount + len(self.bugs). Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From andres@corrada.com Tue Nov 2 19:30:41 1999 From: andres@corrada.com (Andres Corrada) Date: Tue, 02 Nov 1999 14:30:41 -0500 Subject: [Pythonmac-SIG] os.linesep? References: Message-ID: <381F3BE1.1F221659@corrada.com> Just van Rossum wrote: > > - \r and \n will be echanged upon write as well as read > > > So: use \n when in text mode or os.linesep when in binary mode, and you're set. > Doesn't that make the code operating system dependent? Do I have to use \n in text mode and os.linesep in binary mode if the script ran in Unix? ------------------------------------------------------ Andres Corrada-Emmanuel Email: andres@corrada.com Owner http://www.corrada.com/mamey Mamey Phone: (413) 587-9595 ------------------------------------------------------ From just@letterror.com Tue Nov 2 20:52:51 1999 From: just@letterror.com (Just van Rossum) Date: Tue, 2 Nov 1999 21:52:51 +0100 Subject: [Pythonmac-SIG] os.linesep? In-Reply-To: <381F3BE1.1F221659@corrada.com> References: Message-ID: I wrote: > So: use \n when in text mode or os.linesep when in binary mode, and >you're set. Andres Corrada wrote: >Doesn't that make the code operating system dependent? Do I have to use >\n in text mode and >os.linesep in binary mode if the script ran in Unix? No. If you're working with text files, just use \n, and make sure to open them in text mode. This works correctly on all platforms. The conversion between \r and \n is a Mac thing. Similarly, under Windows, Python will convert \r\n to \n and vice versa. Under Unix, there is no conversion, and therefore there is no difference between text and binary mode. Just From andres@corrada.com Tue Nov 2 20:08:49 1999 From: andres@corrada.com (Andres Corrada) Date: Tue, 02 Nov 1999 15:08:49 -0500 Subject: [Pythonmac-SIG] os.linesep? References: Message-ID: <381F44D1.D7EC6F75@corrada.com> Just van Rossum wrote: > > No. If you're working with text files, just use \n, and make sure to open > them in text mode. This works correctly on all platforms. The conversion > between \r and \n is a Mac thing. Similarly, under Windows, Python will > convert \r\n to \n and vice versa. Under Unix, there is no conversion, and > therefore there is no difference between text and binary mode. > Sorry to show my green python coils but I have a couple of more questions. Why does Python convert line endings in Windows and Mac? Is this all going back to whether the underlying OS distinguishes between text and binary files? The reason why I want to know is that I'm trying to diagnose my surprise at seeing this behavior. Am I being a lazy Unix-style coder, ignorant of the wonders of Mac OS or Windows? ------------------------------------------------------ Andres Corrada-Emmanuel Email: andres@corrada.com Owner http://www.corrada.com/mamey Mamey Phone: (413) 587-9595 ------------------------------------------------------ From joe@strout.net Tue Nov 2 21:38:02 1999 From: joe@strout.net (Joseph J. Strout) Date: Tue, 2 Nov 1999 13:38:02 -0800 Subject: [Pythonmac-SIG] os.linesep? In-Reply-To: <381F44D1.D7EC6F75@corrada.com> References: <381F44D1.D7EC6F75@corrada.com> Message-ID: At 3:08 PM -0500 11/2/99, Andres Corrada wrote: >Sorry to show my green python coils but I have a couple of more >questions. Why does Python convert line endings in Windows and Mac? Because otherwise, you couldn't read or write text files in a platform-independent way. >Is this all going back to whether the underlying OS distinguishes between >text and binary files? Not whether it distinguishes or not, but rather, what is used to separate lines. You have to separate lines with something. Mac uses \r, Unix uses \n, and DOS uses (for some weird reason) \r\n. One's not better than the other (well, OK, DOS is worse because it uses two characters), but you have to deal with it. Python deals with it by defining '\n' as the line separator as far as Python is concerned, and this is translated transparently to whatever the underlying OS uses. >The reason why I want to know is that I'm trying to diagnose my surprise >at seeing this behavior. Am I being a lazy Unix-style coder, ignorant of >the wonders of Mac OS or Windows? Apparently. ;) But consider this: if Python had been written on the Mac first, then we'd all be using '\r' to separate lines, and the Unix version would be converting these to '\n' on the fly. Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From savageb@pacbell.net Wed Nov 3 02:50:47 1999 From: savageb@pacbell.net (savageb) Date: Tue, 02 Nov 1999 18:50:47 -0800 Subject: [Pythonmac-SIG] x-platform md5 (endian?) In-Reply-To: <381F44D1.D7EC6F75@corrada.com> Message-ID: Hi all, (and welcome back, Joe), The recent discussion of line-endings reminded me of a problem I ran into last week: I did a little experiment with the MD5 module: I created an md5 digest for a file on a Windows machine and then created an md5 digest for the same file on a Mac and it turned out the digests do not match. Might this be because of the "endian-ism" of the two platforms? What I was hoping to do was create a script that would read in a *binary* file and create an md5 digest for it that could be archived with the original file to use as a test later for file corruption. Bob From jack@oratrix.nl Wed Nov 3 09:56:23 1999 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 03 Nov 1999 10:56:23 +0100 Subject: [Pythonmac-SIG] x-platform md5 (endian?) In-Reply-To: Message by savageb , Tue, 02 Nov 1999 18:50:47 -0800 , Message-ID: <19991103095624.6C76835BB1E@snelboot.oratrix.nl> > I did a little experiment with the MD5 module: I created an md5 digest for a > file on a Windows machine and then created an md5 digest for the same file > on a Mac and it turned out the digests do not match. Might this be because > of the "endian-ism" of the two platforms? I've done cross-platform MD5s, and they worked. But it could be that I tried it on a big-endian unix box and a big-endian mac. Still, I'd expect MD5 to be byte-based. Maybe you should ask this in a general Python forum (and report back here)? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From just@letterror.com Wed Nov 3 10:42:39 1999 From: just@letterror.com (Just van Rossum) Date: Wed, 3 Nov 1999 11:42:39 +0100 Subject: [Pythonmac-SIG] x-platform md5 (endian?) In-Reply-To: <19991103095624.6C76835BB1E@snelboot.oratrix.nl> References: Message by savageb , Tue, 02 Nov 1999 18:50:47 -0800 , Message-ID: At 10:56 AM +0100 11/3/99, Jack Jansen wrote: >> I did a little experiment with the MD5 module: I created an md5 digest for a >> file on a Windows machine and then created an md5 digest for the same file >> on a Mac and it turned out the digests do not match. Might this be because >> of the "endian-ism" of the two platforms? > >I've done cross-platform MD5s, and they worked. But it could be that I tried >it on a big-endian unix box and a big-endian mac. Still, I'd expect MD5 to be >byte-based. > >Maybe you should ask this in a general Python forum (and report back here)? Quick test: it works. Bob, maybe it's the text/binary issue once more? [just@rietveld just]$ python Python 1.5.1 (#1, Mar 21 1999, 22:49:36) [GCC egcs-2.91.66 19990314/Li on linux -i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import md5 >>> d = md5.new() >>> d.update("abcdefghijkl") >>> d.digest() '\237\311\326\006\221 0\334\250e\202\355bY\\\367' >>> import struct >>> struct.pack("h", 1) '\001\000' >>> Python 1.5.2+ (#43, Mar 9 1999, 13:06:43) [CW PPC w/GUSI w/MSL] Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import md5 >>> d = md5.new() >>> d.update("abcdefghijkl") >>> d.digest() '\237\311\326\006\221 0\334\250e\202\355bY\\\367' >>> >>> import struct >>> struct.pack("h", 1) '\000\001' >>> From guido@CNRI.Reston.VA.US Wed Nov 3 12:30:10 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 03 Nov 1999 07:30:10 -0500 Subject: [Pythonmac-SIG] os.linesep? In-Reply-To: Your message of "Wed, 03 Nov 1999 01:04:08 EST." <199911030604.BAA21631@python.org> References: <199911030604.BAA21631@python.org> Message-ID: <199911031230.HAA09569@eric.cnri.reston.va.us> > No. If you're working with text files, just use \n, and make sure to open > them in text mode. This works correctly on all platforms. The conversion > between \r and \n is a Mac thing. Similarly, under Windows, Python will > convert \r\n to \n and vice versa. Under Unix, there is no conversion, and > therefore there is no difference between text and binary mode. Let me chime in with one more explanation. None of this is done by Python -- it's all behavior defined in the C standard I/O library. I think Andres Corrada was the victim of his own attention of detail: he thought he had to use os.linesep when manipulating text files, while in fact Python (like C) lets (and requires that!) you use '\n' as the line separator as long as you open your files in text mode. One more nit: the Mac is the only platform that *swaps* the native separator with \n. On Windows, if you write \r\n, the \r will be written unchanged, and the stdio library (which has very little memory :) will translate the \n to \r\n, so your file will contain \r\r\n. And on Unix, the file will contain exactly what you write. Advice: don't worry about it, it all -- by magic -- just works! --Guido van Rossum (home page: http://www.python.org/~guido/) From andres@corrada.com Wed Nov 3 16:47:02 1999 From: andres@corrada.com (Andres Corrada) Date: Wed, 03 Nov 1999 11:47:02 -0500 Subject: [Pythonmac-SIG] os.linesep? References: <381F44D1.D7EC6F75@corrada.com> Message-ID: <38206706.302748F3@corrada.com> "Joseph J. Strout" wrote: > > Apparently. ;) But consider this: if Python had been written on the > Mac first, then we'd all be using '\r' to separate lines, and the > Unix version would be converting these to '\n' on the fly. > So this thread would only appear in the Pythonunix mailing list? ------------------------------------------------------ Andres Corrada-Emmanuel Email: andres@corrada.com Owner http://www.corrada.com/mamey Mamey Phone: (413) 587-9595 ------------------------------------------------------ From giorgio@dimi.uniud.it Wed Nov 3 15:53:32 1999 From: giorgio@dimi.uniud.it (Giorgio Brajnik) Date: Wed, 3 Nov 1999 16:53:32 +0100 Subject: [Pythonmac-SIG] Q: emulating os.system() on macs? Message-ID: <199911031553.QAA01426@du010119.cc.uniud.it> Hi. I'm in the process of planning to port a Python application that is being developed on Linux to the Mac. One of the many questions I have is how to emulate in Python/Mac something like: def doit(infile, outfile, errfile, exefile): """ execute "exefile" on "infile" and write "outfile" and "errfile" """ cmd = '%s < "%s" > "%s" 2> "%s"'%(exefile, infile, outfile, errfile) os.system(cmd) return (outfile, errfile) Any suggestion? Giorgio Brajnik ______________________________________________________________________ Dip. di Matematica e Informatica | voice: +39 (432) 55.8445 Universita` di Udine | fax: +39 (432) 55.8499 Via delle Scienze, 206 | email: giorgio@dimi.uniud.it Loc. Rizzi -- 33100 Udine -- ITALY | http://www.dimi.uniud.it/~giorgio From andres@corrada.com Wed Nov 3 19:27:15 1999 From: andres@corrada.com (Andres Corrada) Date: Wed, 03 Nov 1999 14:27:15 -0500 Subject: [Pythonmac-SIG] os.linesep? References: <199911030604.BAA21631@python.org> <199911031230.HAA09569@eric.cnri.reston.va.us> <38206943.D5084903@corrada.com> <199911031821.NAA09977@eric.cnri.reston.va.us> Message-ID: <38208C93.5538EC77@corrada.com> Guido van Rossum wrote: > > > > So would this thread be started in the JPython mailing list? > > I don't understand your question. Java's I/O system has line > separator translations too, as far as I know the JPython user can use > \n for line separators in text files on all platforms. If you want > to, I can ask Barry Warsaw. I guess I'm asking all these questions to figure out why this thread starts in Pythonmac and not in a Pythonunix list. Your answer seems to imply that Python uses \n as a line separator because C does. And me and Chris are surprised at Python's behavior because we were not aware of the use of \n in C to "define" the line separator independently of platform. Thus my question about whether this issue also appears in JPython. ------------------------------------------------------ Andres Corrada-Emmanuel Email: andres@corrada.com Owner http://www.corrada.com/mamey Mamey Phone: (413) 587-9595 ------------------------------------------------------ From savageb@pacbell.net Thu Nov 4 00:16:47 1999 From: savageb@pacbell.net (Bob Savage) Date: Wed, 03 Nov 1999 16:16:47 -0800 Subject: [Pythonmac-SIG] x-platform md5 (endian?) In-Reply-To: Message-ID: > From: Just van Rossum >>> I did a little experiment with the MD5 module: I created an md5 digest for a >>> file on a Windows machine and then created an md5 digest for the same file >>> on a Mac and it turned out the digests do not match. Might this be because >>> of the "endian-ism" of the two platforms? > > Quick test: it works. Bob, maybe it's the text/binary issue once more? > Just, thanks for your response. I must've mixed my binary & non-binary reads. Thanks! - Bob From noel@burton-krahn.com Thu Nov 4 00:49:25 1999 From: noel@burton-krahn.com (Noel Burton-Krahn) Date: 4 Nov 1999 00:49:25 -0000 Subject: [Pythonmac-SIG] HTTP and CGI on Mac Message-ID: <19991104004925.10438.qmail@burton-krahn.com> I would like to write a web app with CGI scripts to run on the Macintosh. I need: (a) a web server (I'm looking at Medusa) (b) some way to call CGI scripts. How does one capture stdin/stdout on a Mac? Is there a python library for this? How does one exec() a program on the Mac and feed stdin/read stdout? Any help would be muchly appreciated. --Noel From jack@oratrix.nl Fri Nov 5 13:14:32 1999 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 05 Nov 1999 14:14:32 +0100 Subject: [Pythonmac-SIG] Multithreaded MacPython Message-ID: <19991105131433.707CF35BB1E@snelboot.oratrix.nl> Folks, there is more and more interest in a multithreaded MacPython. As CWGUSI 2.0, which has pthreads support, has now gone final and the MW C library has been thread-safe for a few years already I think that now all the infrastructure needed for a multithreaded MacPython is available. One issue remains: programmer time. I'd really like to look into this, but it will be a while before I have the time. So, if someone is willing to take this up: please speak up. What you'd need is the latest CW compiler, a MacPython source distribution (preferrably through CVS, but this isn't really necessary) and a CWGUSI 2 distribution. What you'd need to do is (a) figure out what needs to be done to Python and/or CWGUSI 2 to make them work together (CWGUSI 1.5 needed some mods to make various Python things work better, but these aren't really essential) and (b) figure out how to enable multiple threads and do the switching, especially in the light of the Python main event loop. Note that even only (a) was done it would already make my life a lot simpler. -- 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 Fri Nov 5 17:44:48 1999 From: chriss@dnastar.com (chriss@dnastar.com) Date: Fri, 5 Nov 1999 11:44:48 -0600 Subject: [Pythonmac-SIG] Multithreaded MacPython In-Reply-To: <19991105131433.707CF35BB1E@snelboot.oratrix.nl> Message-ID: <19991105114448.030679@artemis.dnastar.com> On Fri, Nov 5, 1999, Jack Jansen wrote: > What you'd need to do is >(a) figure out what needs to be done to Python and/or CWGUSI 2 to make them > work together >(b) figure out how to enable multiple threads and do the switching, especially >in the light of the Python main event loop. I've been working with GUSI2 a bit. I think I'm close on (a) - I should have something that runs sometime next week. Note under GUSI2's os.path.islink() considers mac alias files to be symlinks. Currently it alway returns false. I assume this isn't problem for anyone - mac specific code presumably dosn't call a function that always returns 0. But let me know if anyone sees a problem with this. Christopher Stern DNAStar 1228 South Park Madison, WI 53715, USA ph: 608.258.7420 ext. 25 fax: 608.258.7439 From orla_redbird@crosswinds.net Fri Nov 5 22:37:41 1999 From: orla_redbird@crosswinds.net (Gordon Worley) Date: Fri, 5 Nov 1999 17:37:41 -0500 (EST) Subject: [Pythonmac-SIG] Where is Python-Sans Message-ID: I don't remeber seeing a message about this on the list, but the current version of MacPython (1.5.2c1) does not include Python-Sans anymore. Sure, I've already got it, but what about all the newbies and people who've lost it. Was this just an oversight, or was it done on purpose? Which reminds me: why is the IDE now strewn around the Python folder rather than in one place? This seems odd to me (like something one of those Windows guys would do). So as not to complain the whole time, 1.5.2c1 is great! - Gordon Worley http://www.crosswinds.net/~orla_redbird/ mailto:orla_redbird@crosswinds.net From just@letterror.com Fri Nov 5 23:11:19 1999 From: just@letterror.com (Just van Rossum) Date: Sat, 6 Nov 1999 00:11:19 +0100 Subject: [Pythonmac-SIG] Where is Python-Sans In-Reply-To: Message-ID: At 5:37 PM -0500 11/5/99, Gordon Worley wrote: >I don't remeber seeing a message about this on the list, but the current >version of MacPython (1.5.2c1) does not include Python-Sans anymore. Sure, >I've already got it, but what about all the newbies and people who've lost >it. Was this just an oversight, or was it done on purpose? A bit of both ;-) I included the Python Sans font when the IDE was still a separate package, and later that package just went in the distribution as it was. Now it is more integrated (the IDE lives on the top level, yay!), but there is not a clear place where to put additional stuff. The default font for windows/buttons is more sensible now: it takes geneva 9 instead of monaco. (Btw.: has anyone noticed the "Set default window font" preference menu?) Another oversight are the IDE readme and manual, which are not in the distribution currently. Shame on me. But I still don't know _where_ I should put them.... >Which reminds >me: why is the IDE now strewn around the Python folder rather than in one >place? This seems odd to me (like something one of those Windows guys >would do). All of the IDE sources live in :Mac:Tools:IDE: and the IDE scripts live in :Mac:IDE scripts:. So that's two places... The idea was to put the scripts in an easy-to-find place and let the sources live somewhat deeper in the tree, since they are interesting for less people. Just From joe@strout.net Tue Nov 9 17:35:30 1999 From: joe@strout.net (Joseph J. Strout) Date: Tue, 9 Nov 1999 09:35:30 -0800 Subject: [Pythonmac-SIG] isShared bit on Python IDE? Message-ID: We've run into a bit of a problem because the Python IDE refuses to allow more than one copy of itself to be run from a server. This is because its "isShared" Finder flag is not set. Is there a reason this flag isn't set? TN 1126 (Checklist for Building Apps) sez: "You need to set the isShared bit in the Finder flags to allow your application to be launched multiple times across a network... If you set the isShared bit, check that your application does not try to write to its own resource or data fork. In addition, check that your application does not try to write to any locations other than its preference file in the Preferences folder in the System Folder, which can be found and created using FindFolder." I doubt the IDE writes to itself, but it does write to other folders (i.e., when compiling various Python source files). But we have another app (Mac Common Lisp) which does the same thing, with its Shared bit set, and it's never been a problem. (Probably only a problem if two people try to compile the same file at exactly the same time.) So: any reason I can't safely set the "shared" bit on Python IDE? Thanks, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From managan@llnl.gov Tue Nov 9 17:55:34 1999 From: managan@llnl.gov (Rob Managan) Date: Tue, 9 Nov 1999 09:55:34 -0800 Subject: [Pythonmac-SIG] isShared bit on Python IDE? In-Reply-To: References: Message-ID: >We've run into a bit of a problem because the Python IDE refuses to >allow more than one copy of itself to be run from a server. This is >because its "isShared" Finder flag is not set. > >Is there a reason this flag isn't set? TN 1126 (Checklist for >Building Apps) sez: "You need to set the isShared bit in the Finder >flags to allow your application to be launched multiple times across >a network... If you set the isShared bit, check that your >application does not try to write to its own resource or data fork. >In addition, check that your application does not try to write to >any locations other than its preference file in the Preferences >folder in the System Folder, which can be found and created using >FindFolder." > >I doubt the IDE writes to itself, but it does write to other folders >(i.e., when compiling various Python source files). But we have >another app (Mac Common Lisp) which does the same thing, with its >Shared bit set, and it's never been a problem. (Probably only a >problem if two people try to compile the same file at exactly the >same time.) > >So: any reason I can't safely set the "shared" bit on Python IDE? > >Thanks, >-- Joe I bet it has to do with one user changing the default directory behind your back. That is you could suddenly find that the current directory had changed due to action by another user. This can be protected against I suppose but I am not real clear on how all this is done on the Mac. *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan LLNL ph: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From joe@strout.net Tue Nov 9 17:53:32 1999 From: joe@strout.net (Joseph J. Strout) Date: Tue, 9 Nov 1999 09:53:32 -0800 Subject: [Pythonmac-SIG] isShared bit on Python IDE? In-Reply-To: References: Message-ID: At 6:50 PM +0100 11/9/99, Just van Rossum wrote: >(Or, even better: you set it and tell me if all goes well, and then I'll >check it in...) OK, that's what I'll do... Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From just@letterror.com Tue Nov 9 17:50:15 1999 From: just@letterror.com (Just van Rossum) Date: Tue, 9 Nov 1999 18:50:15 +0100 Subject: [Pythonmac-SIG] isShared bit on Python IDE? In-Reply-To: Message-ID: At 9:35 AM -0800 11/9/99, Joseph J. Strout wrote: >We've run into a bit of a problem because the Python IDE refuses to >allow more than one copy of itself to be run from a server. This is >because its "isShared" Finder flag is not set. > >Is there a reason this flag isn't set? TN 1126 (Checklist for >Building Apps) sez: "You need to set the isShared bit in the Finder >flags to allow your application to be launched multiple times across >a network... If you set the isShared bit, check that your application >does not try to write to its own resource or data fork. In addition, >check that your application does not try to write to any locations >other than its preference file in the Preferences folder in the >System Folder, which can be found and created using FindFolder." > >I doubt the IDE writes to itself, but it does write to other folders >(i.e., when compiling various Python source files). But we have >another app (Mac Common Lisp) which does the same thing, with its >Shared bit set, and it's never been a problem. (Probably only a >problem if two people try to compile the same file at exactly the >same time.) > >So: any reason I can't safely set the "shared" bit on Python IDE? Can't think of any... Shall I set it and check it in for the next release? (Or, even better: you set it and tell me if all goes well, and then I'll check it in...) Just From craig@osa.att.ne.jp Wed Nov 10 13:50:49 1999 From: craig@osa.att.ne.jp (Craig Hagerman) Date: Wed, 10 Nov 1999 22:50:49 +0900 (JST) Subject: [Pythonmac-SIG] (no subject) Message-ID: I have been learning Python with the O'Reilly books recently on my Macintosh. While their examples are done on Linux and often outside my experience (like server-side scripting), I have found the core language quite easy to understand. However, the documentation for Mac specific capabilities of Python seems to be sparse (both in print and on the web -- PLEASE correct me if I am wrong here). I have three simple (newbie) Mac - Python related questions if anyone can answer one or all. 1. The Mac pdf documentation doesn't make it clear to me what Pythons capabilities and limitations are for Mac specific programming. Perhaps someone could help clarify this for me with a comparison. I know that AppleScript and Python are different beasts but it would be helpful to understand ways that they are similar; as in what kinds of things could I do with either language, and how they are different; ie. what kinds of things could I do in AppleScript and NOT in Python? 2. I don't mind learning at the command line but I would be far more comfortable dealing with a GUI as the end result. I understand that Tkinter has some issues on the Mac. At the risk of asking a really stupid question... would it be possible to use RealBasic to create a GUI but use Python for the scripting and Apple Events to communicate between the two. I suspect the answer is no but I think it would be great if I could. 3. My understanding is that it is possible to use Python to create simple applications on the Mac. (Or is this a misunderstanding - it is possible to create applications with Python AND C together ??) I am interested in doing this to learn more about (a) OO programming and (b) Mac programming. (Python was the OVERWHELMING recommendation when I asked sources what to learn as a first step into OOP.) As I have said I have found the "mac.pdf" documentation of the Mac Modules a bit minimalistic for my understanding and can't find much else. The "Toolbox" (pdf download) of "Inside Macintosh" helps but not that much for a beginner like me. It is a big question but I want to know HOW to program Python on a Macintosh to create a simple application. I am assuming a GUI creation here - drawing Windows, Buttons and other controls, interacting with other applications, catching events etc. Is there any other books, documentation, sources, whatever that can help me with this quest?? I suppose that non-Python Mac instruction sources would be better than nothing. There just doesn't seem to be that much Mac specific literature out there so... As another avenue of learning I am wondering if there are any (Mac)Python Wizards out there who have made such Mac applications and would allow me to pour over their source code for some examples???? If so please email me. If I got enough example code I would be willing to set up a web site dedicated to hosting (and growing) those examples. Thanks for your patience with this long email, Craig Hagerman From cwebster@nevada.edu Wed Nov 10 22:10:46 1999 From: cwebster@nevada.edu (Corran Webster) Date: Wed, 10 Nov 1999 14:10:46 -0800 (PST) Subject: [Pythonmac-SIG] (no subject) In-Reply-To: Message-ID: On Wed, 10 Nov 1999, Craig Hagerman wrote: > I have been learning Python with the O'Reilly books recently on my > Macintosh. While their examples are done on Linux and often outside my > experience (like server-side scripting), I have found the core language > quite easy to understand. However, the documentation for Mac specific > capabilities of Python seems to be sparse (both in print and on the web -- > PLEASE correct me if I am wrong here). I think this is probably a fair observation, sadly. > I have three simple (newbie) Mac - Python related questions if anyone > can answer one or all. OK. > 1. The Mac pdf documentation doesn't make it clear to me what Pythons > capabilities and limitations are for Mac specific programming. Perhaps > someone could help clarify this for me with a comparison. I know that > AppleScript and Python are different beasts but it would be helpful to > understand ways that they are similar; as in what kinds of things could I > do with either language, and how they are different; ie. what kinds of > things could I do in AppleScript and NOT in Python? There is additional HTML documentation in the :Mac:Demo folder of the distribution which will answer some of your questions. But yes, the documentation could be better, particularly for newbies. To answer your particular questions: * The limitations of Mac Python tend to come from the differences in the underlying operating system - anything on Unix which would call an external command, or open a pipe, or the like, will not work on the Mac without serious modification. Also thread support has not been incorporated yet (but is now on the horizon as a possibility). This tends to limit Python's applicability as a "glue" language between other, separate programs, which is one of the uses of Python in Unix. * Applescript is such a "glue" language on the Mac, but without extra add-ons, is fairly limited to that role. Python is a much more general-purpose language than Applescript. Of course, pretty much anything Applescript can do, Python can as well, since it has the hooks into the Apple Event system of the OS, but it's not as natural as doing it in Applescript. And with the right plug-ins, Applescript can probably do anything Python can do. Basically it's just a question of differences in focus. With python you can do just about anything a regular Mac application can do, and you can do it more easily than you could using C or C++. Unfortunately, it's still not easy. > 2. I don't mind learning at the command line but I would be far more > comfortable dealing with a GUI as the end result. I understand that Tkinter > has some issues on the Mac. At the risk of asking a really stupid > question... would it be possible to use RealBasic to create a GUI but use > Python for the scripting and Apple Events to communicate between the two. I > suspect the answer is no but I think it would be great if I could. If you like learning with a GUI, I'd suggest working with the Python IDE. It has a nice widget set which is accessible from Python. Unfortunately it isn't well documented. You might look into the PIDDLE graphics system since the QuickDraw module allows you to draw graphics in an IDE window interactively. On a more general level, the following commands in the IDE will get you started: import W w = W.Window((600, 400), "Hello!", minsize = (240, 200)) def buttonCallback(): print "Hello World!" w.button = W.Button((20,20,100,50), "Hello World!", buttonCallback) w.open() More complex examples can be found in the IDE's Scripts menu - the source code of the examples should be easy to follow.. It'd prolly be a good idea if these were better advertised, because it does make the IDE quite a nice learning environment. > 3. My understanding is that it is possible to use Python to create simple > applications on the Mac. (Or is this a misunderstanding - it is possible to > create applications with Python AND C together ??) I am interested in doing > this to learn more about (a) OO programming and (b) Mac programming. > (Python was the OVERWHELMING recommendation when I asked sources what to > learn as a first step into OOP.) It's actually possible to create quite complex applications on the Mac using Python - the IDE is written entirely in Python, for example. > As I have said I have found the "mac.pdf" documentation of the Mac > Modules a bit minimalistic for my understanding and can't find much else. > The "Toolbox" (pdf download) of "Inside Macintosh" helps but not that much > for a beginner like me. It is a big question but I want to know HOW to > program Python on a Macintosh to create a simple application. I am assuming > a GUI creation here - drawing Windows, Buttons and other controls, > interacting with other applications, catching events etc. The starting point for a Mac application is the Framework module documented in the "mac.pdf" documentation. The "W" extensions to Framework used in the IDE are a better starting point, but aren't documented yet. But if you want to program a GUI application on the Macintosh, you have two options: either you will need to learn about the underlying Macintosh GUI commands via Inside Macintosh (and Python is as good a place as any to do this, since it has a nice interface to the Toolbox calls and you can work interactively); or you will have to use Tkinter, which is fine for learning, but I'd hesitate to create a full-blown mac application with it. > Is there any other books, documentation, sources, whatever that can > help me with this quest?? I suppose that non-Python Mac instruction sources > would be better than nothing. There just doesn't seem to be that much Mac > specific literature out there so... As another avenue of learning I am > wondering if there are any (Mac)Python Wizards out there who have made such > Mac applications and would allow me to pour over their source code for some > examples???? If so please email me. If I got enough example code I would be > willing to set up a web site dedicated to hosting (and growing) those > examples. Check in the :Mac:Demo folder of the distribution - many of your questions may be answered there, and there are some simple demo applications which you can poke around inside and work out what makes them tick. For a more complex example, you can have a look at the IDE's source code in the :Mac:Tools:IDE folder. For Tkinter examples, have a look at the :Demo:tkinter folder of the distribution for examples - some of them don't work because they rely on Unix features or threads, but some do, and looking at how they work could be enlightening. For documentation, check for various guides to Tkinter - most stuff is standard cross-platform. You might also like to subscribe to the Python Tutor mailing list - it's not mac-specific, but it may help you with basic questions you come up with when learning Python. I hope this has helped answer some of your questions. Regards, Corran From jack@oratrix.nl Wed Nov 10 22:55:24 1999 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 10 Nov 1999 23:55:24 +0100 Subject: [Pythonmac-SIG] Looking for a documentation volunteer Message-ID: <19991110225529.DC682EA117@oratrix.oratrix.nl> Folks, as you are all undoubtedly aware the MacPython documentation is in a very sorry state. This is (as usual:-) mainly my fault, as I don't have the time to keep it up-to-date. But as it looks as if I won't have the time to update even the most glaring omissions in the near time (or even near-to-middle-term) I would be very happy if some people could step in and help here. Things that need to be done are mainly taking inventory of what is documented and what isn't, and then (preferrably) writing the documentation or prodding the author of the undocumented module for enough information. The documentation is currently in rather an esoteric TeX format, incorporated into the main Python documentation, and in the HTML files in the Mac:Demo folder. While the TeX format has the advantage that Guido and his CNRI buddies have lots of tools to convert that to PDF and HTML and such I'd be willing to drop that, if the choice is between having (a) very outdated documentation and (b) having up-to-date documentation that may be a little less platform-independent. After all, the PythonWin documentation also isn't in the main doc tree, so we're in good company:-) -- 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 peter.sommerfeld@gmx.de Wed Nov 10 23:32:50 1999 From: peter.sommerfeld@gmx.de (Peter Sommerfeld) Date: Thu, 11 Nov 1999 00:32:50 +0100 Subject: [Pythonmac-SIG] Beginner's Q 's Message-ID: <199911102329.SAA21012@python.org> Hi Craig, I'll bite :) Craig Hagerman wrote: [lots snipped] > 1. The Mac pdf documentation doesn't make it clear to me what Pythons > capabilities and limitations are for Mac specific programming. Very few limitations if it is fast enough. Most MacOS toolbox calls are available for nearly each and everything. Look into the Mac-Folder and into Mac:PlugIns. The latter are shared libraries. If you really miss something you can write it as shared library in C/C++ and add it to python. Will rarely be neccesary. > I know that AppleScript and Python are different beasts but it would be > helpful to understand ways that they are similar; as in what kinds of > things could I do with either language, and how they are different; > ie. what kinds of things could I do in AppleScript and NOT in Python? Dunno much about AppleScript. It's main goal is to handle applications from your desktop and not a general purpose language like Python. It's not platform-independent and (probably) much slower. > 2. I don't mind learning at the command line but I would be far more > comfortable dealing with a GUI as the end result. Start PythonIDE instead of the interpreter and you'll feel comfortable. Later you can write your own GUI. > I understand that Tkinter has some issues on the Mac. At the risk of > asking a really stupid question... would it be possible to use RealBasic > to create a GUI but use Python for the scripting and Apple Events to > communicate between the two. I suspect the answer is no but I think it > would be great if I could. Should be possible. But using mac-toolbox is probably better because the AppleEvents layer adds additional overhead and complexity and is slow. Forget TKinter on mac. May be wxPython or Amulet will someday arrive at the Mac as portable GUI-Toolkit. But at first and now, stick with the mac-toolbox (imho, of course). > 3. My understanding is that it is possible to use Python to create simple > applications on the Mac. (Or is this a misunderstanding - it is possible to > create applications with Python AND C together ??) Python is a full fledged programming language, not a tool for simple applications only. You can make applications out of a mixture of C/C++ and Python or any other language. Presently the Metrowerks compiler is used but you can add shared MPW-libs. The bottom-line is to porototype everything in Python first, than profile it, improve your algorithms, profile it again and then add a few C-modules at hot-spots. But most can be done in Python. > I am interested in doing > this to learn more about (a) OO programming and (b) Mac programming. > (Python was the OVERWHELMING recommendation when I asked sources what to > learn as a first step into OOP.) Nice to hear :) Read the sources !!! Python often is like pseudo-code. Start with one of the simple examples and extend it. Look at http://developer.apple.com/macos/intro.html for an intro and more informations about the Mac. There is somewhere on python.org a link for a beginners mailing-list (not Mac-Specific). -- Peter BTW: use a subject line in your mail please. From billpy@mousa.demon.co.uk Thu Nov 11 09:23:33 1999 From: billpy@mousa.demon.co.uk (Bill Bedford) Date: Thu, 11 Nov 1999 09:23:33 +0000 Subject: [Pythonmac-SIG] Beginner's Q 's In-Reply-To: <199911102329.SAA21012@python.org> References: <199911102329.SAA21012@python.org> Message-ID: At 12:32 am +0100 11/11/99, Peter Sommerfeld wrote: >Craig Hagerman wrote: >[lots snipped] > > >> I know that AppleScript and Python are different beasts but it would be >> helpful to understand ways that they are similar; as in what kinds of >> things could I do with either language, and how they are different; >> ie. what kinds of things could I do in AppleScript and NOT in Python? > >Dunno much about AppleScript. It's main goal is to handle applications >from your desktop and not a general purpose language like Python. It's >not platform-independent and (probably) much slower. > Applescript's main goal is to be an user interface to appleevents. It has an advantage over Python in one respect, because the scripts are compiled applescript is available at all times without the overhead of starting a new application. So for small scripts and for scripts where the process needs to running constantly (e.g. cgi's, ADD scripts) applescript is the better choice. Python could be made into an OSA compliant language to work in the same way as applescripts, but the work wouldn't be trivial, and attempts to make tcl and perl OSA languages have not met with a great deal of success. The though occurs that maybe Apple wrote MacOS X because it was easier than trying to make Java into a OSA language........ -- Bill Bedford mailto://billb@mousa.demon.co.uk "I'm a cat person, myself," she said, vaguely. A low-level voice said: "Yeah? Yeah? Wash in your own spit, do you?" From billpy@mousa.demon.co.uk Thu Nov 11 09:34:52 1999 From: billpy@mousa.demon.co.uk (Bill Bedford) Date: Thu, 11 Nov 1999 09:34:52 +0000 Subject: [Pythonmac-SIG] documentation In-Reply-To: <19991110225529.DC682EA117@oratrix.oratrix.nl> References: <19991110225529.DC682EA117@oratrix.oratrix.nl> Message-ID: At 11:55 pm +0100 10/11/99, Jack Jansen wrote: >Folks, >as you are all undoubtedly aware the MacPython documentation is in a >very sorry state. > >The documentation is currently in rather an esoteric TeX format, >incorporated into the main Python documentation, and in the HTML files >in the Mac:Demo folder. While the TeX format has the advantage that >Guido and his CNRI buddies have lots of tools to convert that to PDF >and HTML and such I'd be willing to drop that, if the choice is >between having (a) very outdated documentation and (b) having >up-to-date documentation that may be a little less >platform-independent. The esotericness of the documentation doesn't stop there. I though it would be neat to put the main doc tree into the Apple help viewer so that it would be always available from the help menu and search able. But there is so much IE specific code in the doc's html that it proved to be impossible. -- Bill Bedford mailto://billb@mousa.demon.co.uk "I'm a cat person, myself," she said, vaguely. A low-level voice said: "Yeah? Yeah? Wash in your own spit, do you?" From jack@oratrix.nl Thu Nov 11 15:36:03 1999 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 11 Nov 1999 16:36:03 +0100 Subject: [Pythonmac-SIG] Re: documentation In-Reply-To: Message by Bill Bedford , Thu, 11 Nov 1999 09:34:52 +0000 , Message-ID: <19991111153604.A475F35BB1E@snelboot.oratrix.nl> > The esotericness of the documentation doesn't stop there. I though it > would be neat to put the main doc tree into the Apple help viewer so > that it would be always available from the help menu and search able. > But there is so much IE specific code in the doc's html that it > proved to be impossible. Bill, which HTML files are you referring to here? The ref/lib/tut guides in their HTML form, or the HTML files in Mac:Demo? I had a quick look at both and they appear to be 100% standard HTML with no funny browser-specifics whatsoever... -- 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 billpy@mousa.demon.co.uk Thu Nov 11 17:05:46 1999 From: billpy@mousa.demon.co.uk (Bill Bedford) Date: Thu, 11 Nov 1999 17:05:46 +0000 Subject: [Pythonmac-SIG] Re: documentation In-Reply-To: <19991111153604.A475F35BB1E@snelboot.oratrix.nl> References: <19991111153604.A475F35BB1E@snelboot.oratrix.nl> Message-ID: At 4:36 pm +0100 11/11/99, Jack Jansen wrote: >> The esotericness of the documentation doesn't stop there. I though it >> would be neat to put the main doc tree into the Apple help viewer so >> that it would be always available from the help menu and search able. >> But there is so much IE specific code in the doc's html that it >> proved to be impossible. > >Bill, >which HTML files are you referring to here? The ref/lib/tut guides in their >HTML form, or the HTML files in Mac:Demo? The ref/lib/tut files, most of the problems were with tables and code samples. But a quick check in the Help.SDK shows that the help viewer is limited to HTML 3.2, while the Python documentation is HTML 4.0. So this would be the problem. Any one know if OS 9 has an updated help viewer? -- Bill Bedford mailto://billb@mousa.demon.co.uk "I'm a cat person, myself," she said, vaguely. A low-level voice said: "Yeah? Yeah? Wash in your own spit, do you?" From chriss@dnastar.com Sat Nov 13 00:43:47 1999 From: chriss@dnastar.com (chriss@dnastar.com) Date: Fri, 12 Nov 1999 18:43:47 -0600 Subject: [Pythonmac-SIG] Multithreaded MacPython Message-ID: <19991112184347.014869@artemis.dnastar.com> Well this week has come and gone, MacPython/GUSI2 is up and running but there are still some socket problems I need to look at. (Actualy the problem is getting Open Transport to work at all - it keeps failling with that OT could not allocate memory err (-1135?) ). All the the problems I've seen in GUSI2 were acknolged as bug and so sould be fixed eventualy in the std GUSI2 distribution (hopefuly we can get away with as few GUSI-mods as possible this time. Till next week- Christopher Stern DNAStar 1228 South Park Madison, WI 53715, USA ph: 608.258.7420 ext. 25 fax: 608.258.7439 From sean@digitalharmony.com Sat Nov 13 01:13:03 1999 From: sean@digitalharmony.com (Sean Hummel) Date: Fri, 12 Nov 1999 17:13:03 -0800 Subject: [Pythonmac-SIG] Multithreaded MacPython In-Reply-To: <19991112184347.014869@artemis.dnastar.com> Message-ID: <000101bf2d74$3c7dd900$cf00a8c0@digitalharmony.com> There is a hidden function in OpenTransport, which allows you set the amount of memory it allocates for itself, at startup time. I can't remember the name of the function, but I know it exists. -----Original Message----- From: pythonmac-sig-admin@python.org [mailto:pythonmac-sig-admin@python.org] On Behalf Of chriss@dnastar.com Sent: Friday, November 12, 1999 4:44 PM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] Multithreaded MacPython Well this week has come and gone, MacPython/GUSI2 is up and running but there are still some socket problems I need to look at. (Actualy the problem is getting Open Transport to work at all - it keeps failling with that OT could not allocate memory err (-1135?) ). All the the problems I've seen in GUSI2 were acknolged as bug and so sould be fixed eventualy in the std GUSI2 distribution (hopefuly we can get away with as few GUSI-mods as possible this time. Till next week- Christopher Stern DNAStar 1228 South Park Madison, WI 53715, USA ph: 608.258.7420 ext. 25 fax: 608.258.7439 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://www.python.org/mailman/listinfo/pythonmac-sig From bsayer@home.msen.com Sun Nov 14 00:42:37 1999 From: bsayer@home.msen.com (Ben Sayer) Date: Sat, 13 Nov 1999 19:42:37 -0500 Subject: [Pythonmac-SIG] IDE font preferences Message-ID: <19991113194237.023176@home.msen.com> I've been trying to change the default font for the console window and editor windows in the IDE but have experienced mixed results. After launching PythonIDE, selecting "Python|Preferences|Set default window font" from the menu, and changing the font to "Geneva" and the size to "14," I still get tiny (it still looks 9 point to me) text that is certainly not 14 point and doesn't resemble the sample displayed in the dialog box. This is true for any new script window that I open and the console when I close and launch PythonIDE again. Can anyone enlighten me on what I need to change to set the font to 14 point? --Ben Sayer From just@letterror.com Mon Nov 15 17:10:27 1999 From: just@letterror.com (Just van Rossum) Date: Mon, 15 Nov 1999 18:10:27 +0100 Subject: [Pythonmac-SIG] IDE font preferences In-Reply-To: <19991113194237.023176@home.msen.com> Message-ID: At 7:42 PM -0500 11/13/99, Ben Sayer wrote: >I've been trying to change the default font for the console window and >editor windows in the IDE but have experienced mixed results. After >launching PythonIDE, selecting "Python|Preferences|Set default window >font" from the menu, and changing the font to "Geneva" and the size to >"14," I still get tiny (it still looks 9 point to me) text that is >certainly not 14 point and doesn't resemble the sample displayed in the >dialog box. This is true for any new script window that I open and the >console when I close and launch PythonIDE again. > >Can anyone enlighten me on what I need to change to set the font to 14 point? Ah, I see you're confused by the user interface. That's not your fault: I admit it's quite unclear. There are three distinct ways of changing fonts: - The "Set default window font" dialog sets the font for all windows, affecting all widgets *except* those which have their own font prefs. - To change the default font for new script windows, use the "Editor default settings" menu under Preferences. - To change the font for an existing script, the output window or the interactive console, go to the popupmenu at the top right of that window (the little black arrow) and choose "Font settings". I guess I'll have to rethink how all this works... Just From scottrharris@earthlink.net Wed Nov 17 05:21:13 1999 From: scottrharris@earthlink.net (Scott Harris) Date: Wed, 17 Nov 1999 01:21:13 -0400 Subject: [Pythonmac-SIG] QD3D, OpenGL, VTK, and the mac Message-ID: Has anyone worked on hooking QuickDraw3D to Python? Even though Apple no longer supports it, it looks like it will live on in Quesa. I really liked it much better than OpenGL. What about OpenGL, I understand work is underway to hook it up to Python. At this point I'll be pragmatic and take what I can get. Finally, since OpenGL is on the Mac now, is anyone working on getting VTK ported? I'm new to Python, but I'm excited about moving my project to it. All I need is a 3D graphics capability. Hopefully others are interested in gettting QD3D and/or OpenGL and Python together. Is there any way I can contribute to these efforts? -Scott Harris From joe@strout.net Wed Nov 17 15:51:06 1999 From: joe@strout.net (Joseph J. Strout) Date: Wed, 17 Nov 1999 07:51:06 -0800 Subject: [Pythonmac-SIG] QD3D, OpenGL, VTK, and the mac In-Reply-To: References: Message-ID: At 1:21 AM -0400 11/17/99, Scott Harris wrote: >Has anyone worked on hooking QuickDraw3D to Python? Even though Apple no >longer supports it,it looks like it will live on in Quesa. I really >liked it much better than OpenGL. They're really different beasts -- Quesa will live on top of OpenGL, as a higher level. (I like it better too.) I don't know if anybody's made an interface to QD3D yet. But as I understand it, Jack has a tool he uses to automatically generate Python bindings from header files. One could also use SWIG. QD3D's headers are straight C, nothing tricky about them, so it should be pretty straightforward. Heck, for that matter, you could probably hack together an interface using only calldll, accessing the QD3D (or Quesa) library directly. That might even be the best way to go, because then you've got a solution in pure Python, no extra shared library required. As for OpenGL, yes, there are Python bindings for it, but I don't think they've been ported to the Mac yet. Sounds harder to me, but I'm not sure about that. >Is there any way I can contribute to these efforts? Sure! Continue your research, see if anybody's done it yet; if not, do it yourself and make up a nice web page about it. I can get you started with the calldll module, and with QD3D. How familiar are you with each of these? Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From managan@llnl.gov Wed Nov 17 16:53:27 1999 From: managan@llnl.gov (Rob Managan) Date: Wed, 17 Nov 1999 08:53:27 -0800 Subject: [Pythonmac-SIG] QD3D, OpenGL, VTK, and the mac In-Reply-To: References: Message-ID: At 1:21 AM -0400 11/17/99, Scott Harris wrote: > >What about OpenGL, I understand work is underway to hook it up to Python. >At this point >I'll be pragmatic and take what I can get. > I can say that there is a rudimentary Mac version of PyOpenGL. What we need now is to get a port of the ToGL widget for Tk since that is what most people on the Unix side use for OpenGL work. Michael Ferraro has been actively working on OpenGl stuff with the Mac. *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- 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 Wed Nov 17 22:03:30 1999 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 17 Nov 1999 23:03:30 +0100 Subject: [Pythonmac-SIG] Applications written in MacPython Message-ID: <19991117220335.E3A33EA119@oratrix.oratrix.nl> I'd like to add a section to the MacPython webpage listing real-world applications and projects using MacPython. Of course I'll add GRiNS, but as a single entry may not have the awe-inspiring effect on newcomers that I'm aiming at please send me your URLs with a 1-paragraph description. -- 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 joe@strout.net Thu Nov 18 16:33:54 1999 From: joe@strout.net (Joseph J. Strout) Date: Thu, 18 Nov 1999 08:33:54 -0800 Subject: [Pythonmac-SIG] calldll: float values? Message-ID: I'm trying to use calldll to make an interface to the QD3D library. (Actually, my evil plan is to get it started and then turn it over to Scott Harris.) I've run into a hitch: calldll doesn't seem to understand floats, and QD3D uses floats all over the place -- both as parameters, and as return values. Is there some way I can hack around this limitation? E.g., if I tell calldll that the return type is in fact "long", that should be the same size as a "float" (at the moment anyway), so it shouldn't crash. But then I'll have a long instead of a float. Perhaps I can pack this into a string, and then unpack it to a float... but this seems hideous, and I'm not at all positive some important bits won't get dropped in the process. Is there any other way? Thanks, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From jack@oratrix.nl Fri Nov 19 10:29:18 1999 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 19 Nov 1999 11:29:18 +0100 Subject: [Pythonmac-SIG] MacPython 1.5.2 Installer (fwd) Message-ID: <19991119102919.915E435BB1E@snelboot.oratrix.nl> Sak, I haven't seen this problem myself, so I'm forwarding the question to the pythonmac-sig mailing list to see if this rings a bell with anyone. Pythonmac-sig members, has anyone seen a problem similar to this one? Any idea what might cause it? ------- Forwarded Message Date: Thu, 18 Nov 1999 13:06:17 -0800 Subject: MacPython 1.5.2 Installer From: "Stefan Keel" Jack, I apologize if I'm directing my query incorrectly, but since this is a MacPython specific issue, I thought you might be the best source for help. I've been downloading and attempting to use the MacPython 1.5.2 Installer, and receiving this error... 1008:17,-23 An unexpected error occurred while installing "EditPythonPrefs" I've sent a message to help@python.org, but I'm not sure if that's the right place. I'm new to learning programming, and wanted to get started on the system that I'm currently most comfortable with. I also have a Debian GNU/Linux machine, but since I'm still also in the process of learning bash, and GNU Emacs, I didn't want to wait to get started learning a good solid language. I'm using a Mac PowerBook G3, 400Mhz, with OS 8.6. I've downloaded the .sit.hqx Installer twice now, with the same error. Any suggestions or comments to get me off and running would be of great help. Thanks, Sak. ------- End of Forwarded Message From sak@pop.nwlink.com Fri Nov 19 21:03:23 1999 From: sak@pop.nwlink.com (Stefan Keel) Date: Fri, 19 Nov 1999 13:03:23 -0800 Subject: [Pythonmac-SIG] Re: MacPython 1.5.2 Installer (fwd) Message-ID: <199911192105.NAA08819@smtp.nwlink.com> Jack and PythonMac SIG members, Thank you for your response to my installer error. Had I just read more of Jack's PythonMac page, I would have discovered that the problem came from a particular extension. I ignored the iMac issue, because I'm not using one, but later came to discover that running the installer with the Extensions disabled is the trick. Now that I'm off and running, I'll be lurking around the list for a while. Thanks again everyone. Sak. From managan@llnl.gov Fri Nov 19 21:28:16 1999 From: managan@llnl.gov (Rob Managan) Date: Fri, 19 Nov 1999 13:28:16 -0800 Subject: [Pythonmac-SIG] Re: PyOpenGL In-Reply-To: References: Message-ID: For the brave of heart I have submitted a Mac version of PyOpenGL to the PyOpenGL CVS server. Instructions for CVS access are at: http://starship.python.net:9673/crew/da/Code/PyOpenGL/cvs.html These are of course for Unix. I used MacCVS Pro which I also use with the main Python source and Jack's MacPython stuff. I am not sure whether everything you need is there yet so try it out. To compile you will need a copy of Apples OpenGL distribution. This was tested with version 1.0. You also need to set up a few aliases in the Mac folder. Namely _glu.ppc.slb _glut.ppc.slb _opengl_num.ppc.slb openglutil_num.ppc.slb should all point to _opengl.ppc.slb I should really set up a python script to make these just like we used to do with Numeric. Either that or change the project to have 4 subprojects; one to make each module. I hacked MacGlutInit to remove various CodeWarrior console defaults. This may no longer be necessary. We could also use a ToGL widget for Tk if you want to use most of the examples from the UNIX world. *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan LLNL ph: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From btcoburn@oberlin.edu Fri Nov 19 22:08:23 1999 From: btcoburn@oberlin.edu (Ben Coburn) Date: Fri, 19 Nov 1999 17:08:23 -0500 (EST) Subject: [Pythonmac-SIG] Re: MacPython 1.5.2 Installer (fwd) In-Reply-To: <199911192105.NAA08819@smtp.nwlink.com> Message-ID: On Fri, 19 Nov 1999, Stefan Keel wrote: > Jack and PythonMac SIG members, > > Thank you for your response to my installer error. Had I just read more of > Jack's PythonMac page, I would have discovered that the problem came from a > particular extension. I ignored the iMac issue, because I'm not using one, > but later came to discover that running the installer with the Extensions > disabled is the trick. > > I also had the fun of trobleshooting this cryptic error (with out having read about it). Though turning all the extensions off was about the 3rd thing I tryed (after reinstaling & redownloading) I think it might make MacPython more user-friendly if that error messages requested the user to turn off the extensions. This might save many people significant troble esspecialy if thay are not at university with a nice T1 (up) LAN. Regards, Ben Coburn ----------------------------------------------------------------------- Ben Coburn "Black holes are where God divided by zero." -Anon. btcoburn@oberlin.edu Offsite Paradox Associate Biology Major {CS & Chemistry Minor} Arcosanti Paradox Project Oberlin College http://www.arcosanti.org/paradox/ ----------------------------------------------------------------------- From cwebster@nevada.edu Sun Nov 21 22:19:15 1999 From: cwebster@nevada.edu (Corran Webster) Date: Sun, 21 Nov 1999 14:19:15 -0800 Subject: [Pythonmac-SIG] W Widget Tutorial and Reference Message-ID: Hi all, following Jack's request for documentation, and some earlier comments I made about the ease of working with widgets interactively in the IDE, I decided to go through and write a tutorial/HOWTO and reference manual for the "W widgets" used in the IDE. It's reached the point where the tutorial is largely complete - it could do with more examples of complete applications, but it's otherwise fairly comprehensive. The reference still has a couple of areas which need more work (the Wapplication.application class being the main one), but I think it's at least useful now. Given this, I thought it would be a good idea to make it available, and to solicit comments (particularly from Just, since I may have misinterpreted the purpose of some features). You can find it at: http://www.nevada.edu/~cwebster/Python/WWidgets/ There are likely errors, however, possibly even major ones, as there are parts of the W Widget interface which I have just read, and not directly tested. Once any errors or ommissions have been fixed, I'll see what can be done about announcing it more widely (presumably c.l.py.announce and the documentation pages at www.python.org would be the logical places). In the longer run, I'd like to see the W widgets become more widely used - at the moment, given the shakiness of Tkinter, they're the easiest way into GUI programming on the mac, which is an important thing. I could see the usefulness of a "widget repository" where people can contribute extensions to the base widget set (like syntax-colouring PyEditors or Appearance Manager control widgets), and I'd be willing to host something like this if there is interest (at least within the constraints of my quota). On a slightly related note, there has been discussion of the new "Vaults of Parnassus" guide to Python resources (http://www.vex.net/~x/parnassus/) on c.l.py; but I notice that there is nothing there for the Mac. It'd probably be a good idea to submit Jack's Mac Python page there, at the very least (I know it's not hard to find from www.python.org, but it can't hurt); and it might be a good idea for other folks who have Mac Python related stuff to submit things also. Corran From jwblist@olympus.net Mon Nov 22 04:16:05 1999 From: jwblist@olympus.net (John W Baxter) Date: Sun, 21 Nov 1999 20:16:05 -0800 Subject: [Pythonmac-SIG] Re: "Build Applet" not Drag and drop anymore? In-Reply-To: <19991019221227.E3DDDEA119@oratrix.oratrix.nl> References: <19991019221227.E3DDDEA119@oratrix.oratrix.nl> Message-ID: MacPerl builds the icon family for its "droplets" into each droplet, with the icons being resource ID 128. Python (the applet builder) copies the three icons from the interpreter into the applet. But, the icon family ID 128 is still the interpreter, not the applet, and the FREF ID 128 is still for the APPL. Somewhere in there is likely the problem...it would probably be better to copy the applet icon family into the applet as ID 128, not 129, and either omit the icon family for the interpreter, or give it a different number. But it's been a long time since I had to deal with this stuff--in particular, I've forgotten how the "local IDs" work (if I ever knew for sure). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jwblist@olympus.net Mon Nov 22 04:52:40 1999 From: jwblist@olympus.net (John W Baxter) Date: Sun, 21 Nov 1999 20:52:40 -0800 Subject: [Pythonmac-SIG] Is the menu enabled? In-Reply-To: References: Message-ID: At 9:51 -0700 10/12/99, Joseph J. Strout wrote: >Go it a step further. Start with "inspect(Menu)" rather than >"dir(Menu)", as you'll have easy access to the docstrings for each >function this way. Then do "foo = GetMenuHandle()" (passing >whatever it needs passed to get this step to work), and then >"inspect(foo)", which will show you the methods and members of foo. > >Now, foo is a resource object (resources and handles are the same >thing in MacPython, for some odd reason). You can get its data (it's >just a member, IIRC). That data is of the same format as documented >in your favorite toolbox reference (i.e., whatever a MenuHandle >refers to). You can use the struct module to unpack this and get >whatever you need out of it. That sounds like an impending "Carbon" problem (or an already-solved Carbon problem, perhaps, if the Python object's accessors have been taught about Carbon). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From craig@osa.att.ne.jp Mon Nov 22 07:44:28 1999 From: craig@osa.att.ne.jp (Craig Hagerman) Date: Mon, 22 Nov 1999 16:44:28 +0900 (JST) Subject: [Pythonmac-SIG] interslip module problems in mac tutorial Message-ID: I want to thank the people who earlier gave me some great responses to my beginner questions (and apologise for forgetting the subject line DUH!). I have been reading through the html tutorial contained in the Mac distribution, and also some of the Inside Macintosh books. But I have found myself stumped with "part one" of the tutorial - a simple program that allows you to control InterSLIP. In brief I have a problem with interSLIP - I can find no way of getting the module to load (and can't find such a module on my system) and so always get the "file not found" error returned from the Python Interpretor. In the tutorial it says that there is still a slight problem wiht the Python interslip module and the workaround is to load the driver first. I had never heard of interSLIP before (I have used nothing but PPP since using macs 5 years ago) and didn't have a copy. After a short online hunt I downloaded a copy and installed it, hit connect, and then quit and then tried the "Part One" example again ( InterslipControl-1.py ) ... to no effect. After that I read the interSLIP documentation and realised I have to change the TCP/IP control panel, and discovered interSLIP had been attempting to dial N.American phone numbers before (I am in Japan). I changed all of this... and again keep getting the same error messages. My wonder if I am not setting up the interSLIP program correctly (don't really know too much about PPP, SLIP or TCP other than I have been told PPP is a better transfer protocol). Just in case the problem really is with the interslip module (as the error says) I did a search for it, and found no such module. Could it be that this just isn't in the Python distribution I downloaded?? Can anyone explain to me what is going on, and how to get this tutorial example to work?? Thanks, Craig Hagerman From btcoburn@oberlin.edu Mon Nov 22 08:22:00 1999 From: btcoburn@oberlin.edu (Ben Coburn) Date: Mon, 22 Nov 1999 03:22:00 -0500 (EST) Subject: [Pythonmac-SIG] Toolbox calls? Message-ID: I may be looking at things the "wrong way around" but I was wondering if there is any object that will execute arbitrary mac toolbox calls that are passed to it? In other words, is there any way I can make a toolbox call that is not wraped up in a C++ extension to Python? I was trying to re-write a little clock program in Python and don't see a way to set the computers clock from Python.... Regards, Ben Coburn ----------------------------------------------------------------------- Ben Coburn "Black holes are where God divided by zero." -Anon. btcoburn@oberlin.edu Offsite Paradox Associate Biology Major {CS & Chemistry Minor} Arcosanti Paradox Project Oberlin College http://www.arcosanti.org/paradox/ ----------------------------------------------------------------------- From jack@oratrix.nl Wed Nov 24 16:15:23 1999 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 24 Nov 1999 17:15:23 +0100 Subject: [Pythonmac-SIG] MacPython 1.5.2 Installer (fwd) In-Reply-To: Message by Jack Jansen , Fri, 19 Nov 1999 11:29:18 +0100 , <19991119102919.915E435BB1E@snelboot.oratrix.nl> Message-ID: <19991124161524.EAF6235BB1E@snelboot.oratrix.nl> > 1008:17,-23 An unexpected error occurred while installing "EditPythonPrefs" Stefan/Ben, as you both experienced this problem: did you find out exactly _which_ extension caused the problem? In that case we can list it in the installer or somewhere specifically warning people to disable it... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From dillera@isc.upenn.edu Wed Nov 24 16:21:28 1999 From: dillera@isc.upenn.edu (Andrew Diller) Date: Wed, 24 Nov 1999 11:21:28 -0500 Subject: [Pythonmac-SIG] MacPython 1.5.2 Installer Message-ID: Error -23 always seem to have to do with an open system file. Boot with no extensions (hold shift-key down when booting) and it will install ok. from the TIL: http://til.info.apple.com/techinfo.nsf/artnum/n9805 I/O System Errors -23   openErr         Requested read/write permission doesn't match                      driver's open permission, or                      Attempt to open RAM serial Driver failed From jack@oratrix.nl Wed Nov 24 16:29:58 1999 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 24 Nov 1999 17:29:58 +0100 Subject: [Pythonmac-SIG] Is the menu enabled? In-Reply-To: Message by John W Baxter , Sun, 21 Nov 1999 20:52:40 -0800 , Message-ID: <19991124162958.96DBC35BB1E@snelboot.oratrix.nl> > >Now, foo is a resource object (resources and handles are the same > >thing in MacPython, for some odd reason). You can get its data (it's > >just a member, IIRC). That data is of the same format as documented > >in your favorite toolbox reference (i.e., whatever a MenuHandle > >refers to). You can use the struct module to unpack this and get > >whatever you need out of it. > > That sounds like an impending "Carbon" problem (or an already-solved Carbon > problem, perhaps, if the Python object's accessors have been taught about > Carbon). John, as you seem to know more about Carbon than I do (I know little more than what I learned by running the carbon dating app on Python:-), maybe you can tell me whether the code needs fixing. Currently if X is a handle and you access X.data from Python what the C code does is lock the handle, create a new Python string object of the right size, copy the data and unlock the handle. Assigning to X.data does the same in reverse, with SetHandleSize() called to give the handle the right size. Is this something that will survive the Carbon transition? If not, where do I find out what I should do? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Wed Nov 24 16:33:31 1999 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 24 Nov 1999 17:33:31 +0100 Subject: [Pythonmac-SIG] interslip module problems in mac tutorial In-Reply-To: Message by Craig Hagerman , Mon, 22 Nov 1999 16:44:28 +0900 (JST) , Message-ID: <19991124163331.6439535BB1E@snelboot.oratrix.nl> > I have been reading through the html tutorial contained in the Mac > distribution, and also some of the Inside Macintosh books. But I have found > myself stumped with "part one" of the tutorial - a simple program that > allows you to control InterSLIP. In brief I have a problem with interSLIP - > I can find no way of getting the module to load (and can't find such a > module on my system) and so always get the "file not found" error returned > from the Python Interpretor. The bad news is that this tutorial doesn't really work anymore. InterSLIP and the InterSLIP module are long dead, and this tutorial should be replaced by one that explains this with another module as example. Could someone _please_ step in and change Example 1, Example 2 and the Plugins example to use something a bit more up to date? Please? Please?? Please??? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Wed Nov 24 16:34:21 1999 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 24 Nov 1999 17:34:21 +0100 Subject: [Pythonmac-SIG] Toolbox calls? In-Reply-To: Message by Ben Coburn , Mon, 22 Nov 1999 03:22:00 -0500 (EST) , Message-ID: <19991124163421.A4D2035BB1E@snelboot.oratrix.nl> > I may be looking at things the "wrong way around" but I was > wondering if there is any object that will execute arbitrary mac toolbox > calls that are passed to it? In other words, is there any way I can make > a toolbox call that is not wraped up in a C++ extension to Python? > I was trying to re-write a little clock program in Python and don't > see a way to set the computers clock from Python.... I think calldll is what you're looking for. -- 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 sak@pop.nwlink.com Wed Nov 24 18:32:18 1999 From: sak@pop.nwlink.com (Stefan Keel) Date: Wed, 24 Nov 1999 10:32:18 -0800 Subject: [Pythonmac-SIG] MacPython 1.5.2 Installer (fwd) Message-ID: <199911241834.KAA04094@smtp.nwlink.com> Jack wrote... > Stefan/Ben, > as you both experienced this problem: did you find out exactly _which_ > extension caused the problem? In that case we can list it in the installer or > somewhere specifically warning people to disable it... Andrew responded... > Error -23 always seem to have to do with an open system file. Boot with no > extensions (hold shift-key down when booting) and it will install ok. > > from the TIL: > http://til.info.apple.com/techinfo.nsf/artnum/n9805 My two bits... Although I do have Virex installed on my PowerBook, I also followed the disable extensions convention, so I can't pinpoint Virex as the culprit. I did notice on Jack's MacPython page the mention that Virex on the iMac was causing some installer problems, but it might be a good idea to simply recommend disabling all extensions - per Andrew's suggestion. It might also be a good idea to mention disabling extensions in the installer Read Me and other documentation. I have also noticed other installers providing a notice at install time that no other applications can be running during the install process. I don't know about building installers, or using Installer Lite as Just has for the Mac Python installer, but that may also be a feature to consider building into the next release. Thanks, Sak. From ryan_e@bellsouth.net Wed Nov 24 19:40:12 1999 From: ryan_e@bellsouth.net (Ryan D. Evans) Date: Wed, 24 Nov 1999 14:40:12 -0500 Subject: [Pythonmac-SIG] Greetings Message-ID: <383C3F1B.73094EAE@bellsouth.net> Hello to everyone at 'Python Mac'. I am a new user of Python and was just added to the mailing list. I would just like to let everyone know about myself. Thank you for your time. Ryan D. Evans From jwblist@olympus.net Thu Nov 25 06:30:40 1999 From: jwblist@olympus.net (John W Baxter) Date: Wed, 24 Nov 1999 22:30:40 -0800 Subject: [Pythonmac-SIG] Is the menu enabled? In-Reply-To: <19991124162958.96DBC35BB1E@snelboot.oratrix.nl> References: <19991124162958.96DBC35BB1E@snelboot.oratrix.nl> Message-ID: >> >Now, foo is a resource object (resources and handles are the same >> >thing in MacPython, for some odd reason). You can get its data (it's >> >just a member, IIRC). That data is of the same format as documented >> >in your favorite toolbox reference (i.e., whatever a MenuHandle >> >refers to). You can use the struct module to unpack this and get >> >whatever you need out of it. >> >> That sounds like an impending "Carbon" problem (or an already-solved Carbon >> problem, perhaps, if the Python object's accessors have been taught about >> Carbon). > >John, >as you seem to know more about Carbon than I do (I know little more than what >I learned by running the carbon dating app on Python:-), maybe you can tell me >whether the code needs fixing. Currently if X is a handle and you access >X.data from Python what the C code does is lock the handle, create a new >Python string object of the right size, copy the data and unlock the handle. >Assigning to X.data does the same in reverse, with SetHandleSize() called to >give the handle the right size. > >Is this something that will survive the Carbon transition? If not, where do I >find out what I should do? The above sequence should work...the problem is that, *probably*, the layout of the contents of a menu handle and a menu bar (handle) will be unknown in Carbon: they are likely examples of the opaque data structures. There should be accessor functions to replace direct access per the struct definition. Likewise, a WindowPeek no longer peeks into the structure of a window record, etc etc. Unfortunately, I know no details...my opportunity to attend a meeting in Seattle a couple of Saturdays ago where I would have learned something was foiled by the fact the the boss was in California...one of needs to be somewhat nearby to kick the servers if necessary (our main machine just passed one year of continuous operation today...we don't have to kick that one much...BSDi Unix. Unfortunately, a couple of days ago I accidentally killed the Apache process which had been running on the machine, but not doing much...the web servers are elsewhere, since December 8 1998). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From georges.martin@deboeck.be Thu Nov 25 10:49:46 1999 From: georges.martin@deboeck.be (Georges Martin) Date: Thu, 25 Nov 1999 11:49:46 +0100 Subject: [Pythonmac-SIG] calldll MAXARGS Message-ID: <1268588296-15053632@deboeck.be> I am currently trying to use calldll, but I ran into an annoying limitation: calldll.newcall() only accepts 8 arguments for the C function. I looked into the source and found the MAXARG constant in calldll.c, line 66: > /* Other constants */ > #define MAXNAME 31 /* Maximum size of names, for printing only */ > #define MAXARG 8 /* Maximum number of arguments */ I changed this constant and the following format and args at line 1073: > /* Note: the next format depends on MAXARG */ > if (!PyArg_ParseTuple(args, "O!O&|O&O&O&O&O&O&O&O&", &Cdrtype, &routine, > argparse_rvconv, &rvconv, > argparse_conv, &argconv[0], argparse_conv, &argconv[1], > argparse_conv, &argconv[2], argparse_conv, &argconv[3], > argparse_conv, &argconv[4], argparse_conv, &argconv[5], > argparse_conv, &argconv[6], argparse_conv, &argconv[7])) > return NULL; ...and recompiled but the result is crashing hard. I suppose it's not enough but C has never been one of my natural language, so if someone has a suggestion... :-) TIA, Georges Martin -- Georges Martin From dante@oz.net Fri Nov 26 01:50:15 1999 From: dante@oz.net (Dante) Date: Thu, 25 Nov 1999 17:50:15 -0800 Subject: [Pythonmac-SIG] droplet? Message-ID: I'm new to Python and looking for a way to get the path of a file I drop on to my python applet. Some simple sample code or pointer to documentation would be appreciated. Thanks! Dante "Here I stand with all my lore - Poor fool, no wiser than before." -Goethe, Faust From A.M.INGRALDI@larc.nasa.gov Fri Nov 26 13:22:53 1999 From: A.M.INGRALDI@larc.nasa.gov (Anthony M. Ingraldi) Date: Fri, 26 Nov 1999 08:22:53 -0500 Subject: [Pythonmac-SIG] droplet? In-Reply-To: Message-ID: On 11/25/99 8:50 PM, Dante wrote: > I'm new to Python and looking for a way to get the path of a file I > drop on to my python applet. The file paths of dropped files are available to droplets in sys.argv. Try this: import sys # the first arg will be the path to the droplet itself. for arg in sys.argv: print arg # this is just to keep the console from going away. sys.stdin.readline() -- Tony Ingraldi A.M.INGRALDI@LaRC.NASA.GOV Phone : (757) 864-3039 Fax : (757) 864-7892 From jack@oratrix.nl Fri Nov 26 15:44:43 1999 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 26 Nov 1999 16:44:43 +0100 Subject: [Pythonmac-SIG] calldll MAXARGS In-Reply-To: Message by Georges Martin , Thu, 25 Nov 1999 11:49:46 +0100 , <1268588296-15053632@deboeck.be> Message-ID: <19991126154443.B4524370CF2@snelboot.oratrix.nl> > I am currently trying to use calldll, but I ran into an annoying limitation: > calldll.newcall() only accepts 8 arguments for the C function. > > I looked into the source and found the MAXARG constant in calldll.c, line 66: > > > /* Other constants */ > > #define MAXNAME 31 /* Maximum size of names, for printing only */ > > #define MAXARG 8 /* Maximum number of arguments */ > > I changed this constant and the following format and args at line 1073: > > > /* Note: the next format depends on MAXARG */ > > if (!PyArg_ParseTuple(args, "O!O&|O&O&O&O&O&O&O&O&", &Cdrtype, &routine, > > argparse_rvconv, &rvconv, > > argparse_conv, &argconv[0], argparse_conv, &argconv[1], > > argparse_conv, &argconv[2], argparse_conv, &argconv[3], > > argparse_conv, &argconv[4], argparse_conv, &argconv[5], > > argparse_conv, &argconv[6], argparse_conv, &argconv[7])) > > return NULL; > > ...and recompiled but the result is crashing hard. At the very least you'll also have to change the various initializers for stackvariables (like c_arg in cdc_call() and argconv in cdll_newcall()), and of course the call of (*func) in cdc_call(). But I'm surprised that there are toolbox calls that have more than 8 arguments. What is the maximum number you have come across? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Nov 26 15:52:11 1999 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 26 Nov 1999 16:52:11 +0100 Subject: [Pythonmac-SIG] calldll: float values? In-Reply-To: Message by "Joseph J. Strout" , Thu, 18 Nov 1999 08:33:54 -0800 , Message-ID: <19991126155212.420D2370CF2@snelboot.oratrix.nl> > I'm trying to use calldll to make an interface to the QD3D library. > (Actually, my evil plan is to get it started and then turn it over to > Scott Harris.) I've run into a hitch: calldll doesn't seem to > understand floats, and QD3D uses floats all over the place -- both as > parameters, and as return values. I didn't do floats for calldll because the PPC calling convention for floating point arguments is different from that for integer arguments. If I remember correctly (but it's been some time) the float arguments are passed in floating registers in stead of in int registers. Or, in other words, if a routine has a float argument but I call it (without prototypes in scope, etc etc) with an int argument it will receive garbage, _not_ the bitpattern that happens to be in the integer. There are apparently ways around this (otherwise printf() couldn't be made to work), but I punted on it at the time. If someone understands the calling sequence (it's described somewhere in Inside Mac, I think it used to be called PowerPC Software or some such, and probably also in the CodeWarrior documentation) and explains it to me I'll happily add floating point support to calldll. -- 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 joe@strout.net Fri Nov 26 15:55:34 1999 From: joe@strout.net (Joseph J. Strout) Date: Fri, 26 Nov 1999 07:55:34 -0800 Subject: [Pythonmac-SIG] calldll MAXARGS In-Reply-To: <19991126154443.B4524370CF2@snelboot.oratrix.nl> References: Message by Georges Martin , Thu, 25 Nov 1999 11:49:46 +0100 , <1268588296-15053632@deboeck.be> Message-ID: At 7:44 AM -0800 11/26/99, Jack Jansen wrote: >But I'm surprised that there are toolbox calls that have more than 8 >arguments. What is the maximum number you have come across? While trying to convince my boss to switch from Lisp to Python, we ran into a need to call a shared library function with 11 arguments. Of course we couldn't do this from Python because of the 8-argument limitation of calldll. ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From georges.martin@ping.be Fri Nov 26 16:10:38 1999 From: georges.martin@ping.be (Georges Martin) Date: Fri, 26 Nov 1999 17:10:38 +0100 Subject: [Pythonmac-SIG] calldll MAXARGS In-Reply-To: <19991126154443.B4524370CF2@snelboot.oratrix.nl> Message-ID: <199911261611.RAA07411@bashir.belgium.eu.net> On 26/11/99 at 16:44, jack@oratrix.nl (Jack Jansen) wrote: > > I am currently trying to use calldll, but I ran into an annoying limitation: > > calldll.newcall() only accepts 8 arguments for the C function. [...] > At the very least you'll also have to change the various initializers for > stackvariables (like c_arg in cdc_call() and argconv in cdll_newcall()), and > of course the call of (*func) in cdc_call(). Grumpf... I missed this "call of (*func) in cdc_call()". I will try. > But I'm surprised that there are toolbox calls that have more than 8 > arguments. What is the maximum number you have come across? > -- > 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 This one comes from TextCommon.h: """ EXTERN_API_C( OSStatus ) GetTextEncodingName (TextEncoding iEncoding, TextEncodingNameSelector iNamePartSelector, RegionCode iPreferredRegion, TextEncoding iPreferredEncoding, ByteCount iOutputBufLen, ByteCount * oNameLength, RegionCode * oActualRegion, /* can be NULL */ TextEncoding * oActualEncoding, /* can be NULL */ TextPtr oEncodingName); """ GetTextEncodingName = calldll.newcall(\ TC.GetTextEncodingName, 'Long', \ 'InLong', 'InLong', 'InShort', 'InLong', 'InByte', \ 'OutByte', 'OutShort', 'OutLong', 'OutPstring'\ ) Thanks, Georges Martin From jwblist@olympus.net Fri Nov 26 18:49:42 1999 From: jwblist@olympus.net (John W Baxter) Date: Fri, 26 Nov 1999 10:49:42 -0800 Subject: [Pythonmac-SIG] calldll: float values? In-Reply-To: <19991126155212.420D2370CF2@snelboot.oratrix.nl> References: <19991126155212.420D2370CF2@snelboot.oratrix.nl> Message-ID: At 16:52 +0100 11/26/99, Jack Jansen wrote: >I didn't do floats for calldll because the PPC calling convention for floating >point arguments is different from that for integer arguments. If I remember >correctly (but it's been some time) the float arguments are passed in floating >registers in stead of in int registers. Almost: float registers in addition to int ones (inherited from IBM and POWER, and I suppose IBM had a reason...it seems pretty strange to this poor old country programmer). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From cbarker@jps.net Fri Nov 26 20:16:08 1999 From: cbarker@jps.net (Chris Barker) Date: Fri, 26 Nov 1999 12:16:08 -0800 Subject: [Pythonmac-SIG] Path of dropped file References: <199911261058.FAA25475@python.org> Message-ID: <383EEA88.35A91CF0@jps.net> HI, This should work (it does for me) import sys,os print 'Path of dropped file is:',os.path.split(sys.argv[1])[0] -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From dante@oz.net Sat Nov 27 06:52:32 1999 From: dante@oz.net (Dante) Date: Fri, 26 Nov 1999 22:52:32 -0800 Subject: [Pythonmac-SIG] silly variable evaluation question Message-ID: I'm beating my head into the monitor trying to do the following: import Res foo = dir(Res)[0] print Res.foo.__doc__ this throws an obvious error as foo isn't defined in Res. So how do I evaluate foo in context. In tcl I'd just throw some brackets around that puppy and problem solved but I appear to be missing something crucial here. Dante From savageb@pacbell.net Sat Nov 27 08:18:26 1999 From: savageb@pacbell.net (savageb) Date: Sat, 27 Nov 1999 00:18:26 -0800 Subject: [Pythonmac-SIG] silly variable evaluation question In-Reply-To: Message-ID: > I'm beating my head into the monitor trying to do the following: > > import Res > foo = dir(Res)[0] > print Res.foo.__doc__ > > this throws an obvious error as foo isn't defined in Res. So how do I > evaluate foo in context. In tcl I'd just throw some brackets around > that puppy and problem solved but I appear to be missing something > crucial here. > > Dante I think you are trying to do something like the following: import Res for i in dir(Res): try: print i; print '\t', exec( "print Res.%s.__doc__" % i ) except AttributeError: # prevent things like strings from raising exceptions print "no docstring" From jwblist@olympus.net Sat Nov 27 08:55:30 1999 From: jwblist@olympus.net (John W Baxter) Date: Sat, 27 Nov 1999 00:55:30 -0800 Subject: [Pythonmac-SIG] calldll: float values? In-Reply-To: References: <19991126155212.420D2370CF2@snelboot.oratrix.nl> Message-ID: At 10:49 -0800 11/26/99, John W Baxter wrote: >At 16:52 +0100 11/26/99, Jack Jansen wrote: >>I didn't do floats for calldll because the PPC calling convention for >>floating >>point arguments is different from that for integer arguments. If I remember >>correctly (but it's been some time) the float arguments are passed in >>floating >>registers in stead of in int registers. > >Almost: float registers in addition to int ones (inherited from IBM and >POWER, and I suppose IBM had a reason...it seems pretty strange to this >poor old country programmer). --John Actually, IBM did have a reason: K&R C, where the compiler can't tell what's going on. At least, I think that was it. --John (don't post answers to your own posts) Baxter -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From dante@oz.net Sat Nov 27 20:39:15 1999 From: dante@oz.net (Dante) Date: Sat, 27 Nov 1999 12:39:15 -0800 Subject: [Pythonmac-SIG] silly variable evaluation question In-Reply-To: References: Message-ID: > > I'm beating my head into the monitor trying to do the following: > > > > import Res > > foo = dir(Res)[0] > > print Res.foo.__doc__ > > > > this throws an obvious error as foo isn't defined in Res. So how do I > > evaluate foo in context. > >I think you are trying to do something like the following: > >import Res >for i in dir(Res): > try: > print i; print '\t', > exec( "print Res.%s.__doc__" % i ) > except AttributeError: > # prevent things like strings from raising exceptions > print "no docstring" That seems pretty extravagant, is that really the only way to do this? Where is the % behavior being exhibited in this documented? The python documentation appears to be lengthy but organized extremely poorly. Dante From joe@strout.net Sat Nov 27 20:55:56 1999 From: joe@strout.net (Joseph J. Strout) Date: Sat, 27 Nov 1999 12:55:56 -0800 Subject: [Pythonmac-SIG] silly variable evaluation question In-Reply-To: References: Message-ID: At 12:39 PM -0800 11/27/99, Dante wrote: >That seems pretty extravagant, is that really the only way to do >this? It's not extravagant, it's just embellished compared to your version, with niceties like error trapping, looping over all contents of the module, printing a header for each one, etc. The correct equivalent of what you wrote is simply: import Res foo = dir(Res)[0] print foo.__doc__ I.e., the only mistake you made is trying to write "Res.foo" -- as you noted, foo isn't defined in Res. It's defined in the current module (where the code above lives); the fact that it *refers* to something in another module doesn't matter. It's "foo" regardless of what it refers too, not "Res.foo" just because it happens to refer to something in "Res". >Where is the % behavior being exhibited in this documented? It's a string operator, and documented in the library reference under "More String Operations" (http://www.python.org/doc/current/lib/typesseq-strings.html). >The python documentation appears to be lengthy but organized extremely >poorly. I think this is unfair -- I have always found it to be very easy to find what I'm looking for. Perhaps it just requires a few moments to familiarize yourself with it. Cheers, -- Joe P.S. The python-tutor mailing list might be better suited for questions like these. ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From jack@oratrix.nl Mon Nov 29 11:29:42 1999 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 29 Nov 1999 12:29:42 +0100 Subject: [Pythonmac-SIG] calldll MAXARGS In-Reply-To: Message by "Joseph J. Strout" , Fri, 26 Nov 1999 07:55:34 -0800 , Message-ID: <19991129112942.95AE0370CF2@snelboot.oratrix.nl> > At 7:44 AM -0800 11/26/99, Jack Jansen wrote: > > >But I'm surprised that there are toolbox calls that have more than 8 > >arguments. What is the maximum number you have come across? > > While trying to convince my boss to switch from Lisp to Python, we ran into > a need to call a shared library function with 11 arguments. Of course we > couldn't do this from Python because of the 8-argument limitation of > calldll. Okay, I'll increase MAXARGS to 12. So: if you know of routines with more than 12 arguments please speak up now. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Mon Nov 29 11:33:02 1999 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 29 Nov 1999 12:33:02 +0100 Subject: [Pythonmac-SIG] silly variable evaluation question In-Reply-To: Message by Dante , Fri, 26 Nov 1999 22:52:32 -0800 , Message-ID: <19991129113302.D1B29370CF2@snelboot.oratrix.nl> > I'm beating my head into the monitor trying to do the following: > > import Res > foo = dir(Res)[0] > print Res.foo.__doc__ > > this throws an obvious error as foo isn't defined in Res. So how do I > evaluate foo in context. In tcl I'd just throw some brackets around > that puppy and problem solved but I appear to be missing something > crucial here. You want getattr: import Res foo = dir(Res)[0] print getattr(Res, foo).__doc__ Or, in short, "getattr(x, 'y')" is identical to "x.y". -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Mon Nov 29 11:36:59 1999 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 29 Nov 1999 12:36:59 +0100 Subject: [Pythonmac-SIG] calldll: float values? In-Reply-To: Message by John W Baxter , Sat, 27 Nov 1999 00:55:30 -0800 , Message-ID: <19991129113700.059C9370CF2@snelboot.oratrix.nl> > At 10:49 -0800 11/26/99, John W Baxter wrote: > >At 16:52 +0100 11/26/99, Jack Jansen wrote: > >>I didn't do floats for calldll because the PPC calling convention for > >>floating > >>point arguments is different from that for integer arguments. If I remember > >>correctly (but it's been some time) the float arguments are passed in > >>floating > >>registers in stead of in int registers. > > > >Almost: float registers in addition to int ones (inherited from IBM and > >POWER, and I suppose IBM had a reason...it seems pretty strange to this > >poor old country programmer). --John > > Actually, IBM did have a reason: K&R C, where the compiler can't tell > what's going on. At least, I think that was it. And printf again: the scheme given here means that all arguments, including floats, are passed in integer registers, so printf() can obtain any value from an int parameter. Unfortunately this doesn't solve our problem: how do we pass floats to routines via calldll. I would like to refrain from writing assembler (is anyone here familiar with PowerPC assembler?), but I can't see a way to trick this in C. All ideas are welcome... -- 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 jimmy@cs.cofc.edu Tue Nov 30 02:08:17 1999 From: jimmy@cs.cofc.edu (James B. Wilkinson) Date: Mon, 29 Nov 1999 21:08:17 -0500 Subject: [Pythonmac-SIG] Is the menu enabled? In-Reply-To: <19991124213956.1BBB1D3760@oratrix.oratrix.nl> References: Message by "James B. Wilkinson" , Wed, 24 Nov 1999 15:04:51 -0500 , Message-ID: >James, >as everything is replaced by routine access it'll automtically be >wrapped in Python, due to the way bgen works. So that's good news, I >guess:-) > >And it'd be very nice if you'd wrap the dcon stuff in Python, >definitely! That should be a learning experience!! I'll have a go at it as soon as I get this semester under control. That should be about the day that grades are due. :( I've got a trivial example of a plugin that I did for a project that has not yet materialized. All it does is translate back and forth between floats and integers with the same bit values. You were asking for example code for the tutorial page. Would that help? ------------------------------------------------------------- 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 peter.sommerfeld@gmx.de Tue Nov 30 02:17:50 1999 From: peter.sommerfeld@gmx.de (Peter Sommerfeld) Date: Tue, 30 Nov 1999 03:17:50 +0100 Subject: [Pythonmac-SIG] Menu ID's of Submenus. Message-ID: <199911300214.VAA24710@python.org> Folks, there was last year a short dicussion why Apple recommend using MenuID's between 136 and 255 in IM Toolbox Essentials 3-55. There is no difference to other ID's when using Python. I now stumbled again across this problem when using MPW and the Rez compiler. Rez takes the ID of the submenu as string and does not work with a value outside of this range. Not that importand but may be good to know. Peter