From mday@mac.com Mon Oct 1 03:01:24 2001 From: mday@mac.com (Mark Day) Date: Sun, 30 Sep 2001 19:01:24 -0700 Subject: [Pythonmac-SIG] Problems compiling Python 2.2a4 (unix) on X.1 In-Reply-To: <20010929164242-r01010800-ce7a6bbe-0911-010c@129.21.139.101> Message-ID: on 9/29/01 1:42 PM, Ryan Wilcox at ryanwilcox@mac.com wrote: > [successful build stuff... no patches patched, just ./configure; make] > > cc -u __dummy -u _PyMac_Error -framework System -framework Carbon -framework > Foundation -o python \ > Modules/python.o \ > libpython2.2.a -lpthread > /usr/bin/ld: can't create output file: python (Is a directory, errno = 21) You're building on an HFS or HFS Plus volume, which is case insensitive. The build wants to put the "python" executable in the same directory as the "Python" directory. You need to use the --with-suffix option to configure: ./configure --with-suffix=.exe -Mark From Benjamin.Schollnick@usa.xerox.com Mon Oct 1 15:35:37 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Mon, 01 Oct 2001 10:35:37 -0400 Subject: [Pythonmac-SIG] WxPython, OpenRPG, & Macintosh Message-ID: Folks, This isn't exactly the best place to ask, but it's certainly high on the list. I was glancing over the OPENRPG project.... Which uses wxpython, wxwindows, and so forth to allow for network RPG games.... Since it uses wxpython, it doesn't (*yet*) seem to be available for the macintosh yet... Has anyone examined this package (OPENRPG), and does anyone have a working wxpython for the macintosh? - Benjamin From joerg@kantel.de Mon Oct 1 16:09:12 2001 From: joerg@kantel.de (=?iso-8859-1?Q?J=F6rg?= Kantel) Date: Mon, 1 Oct 2001 17:09:12 +0200 Subject: [Pythonmac-SIG] New Entry in my Python How To Collections Message-ID: To whom of you who can read German after a little bit playing around with piddle and PIL I entered a new section in my growing collection of Python How To's: How to made a Mandelbrot Set with Python and piddleQD (alternatively piddleTK) and PIL. Enjoy it. J"org (aka Der Schockwellenreiter) -- -- email: joerg@kantel.de # jkantel@mac.com www : http://www.schockwellenreiter.de/ - (m)ein Weblog http://www.rollberg.de/ - all the news you want http://www.kantel.de/ From jwight_lists@mac.com Mon Oct 1 23:25:47 2001 From: jwight_lists@mac.com (Jonathan Wight) Date: Mon, 01 Oct 2001 17:25:47 -0500 Subject: [Pythonmac-SIG] Mac OS X Python 2.2a4 Bug (_not_ Mac Python) In-Reply-To: Message-ID: For anyone interested in this... Turns out there is a bug in the documentation -- the README that in the Python build directory states that you ought to use '--without-toolbox-glue' to turn off the Mac toolbox stuff. You should actually use '--disable-toolbox-glue'. This will allow you to make python but 'make all' will fail. Fortunately the python executable has already been built by that point and can be copied to /usr/local/bin and used. It looks to me that Mac OS X 'Unix' (Darwin?) Python and Classic Mac Python are intermingling too much. I'd like to see a the Unix Python be totally independent of the Mac. All the toolbox glue stuff should be in separate shared libraries and only loaded as needed. IMHO the Mac OS X Unix Python should be totally pure. Jon On 09/28/2001 14:28, "Jonathan Wight" wrote: > Hey, > > I've downloaded and compiled the latest version of ('Unix') Python (2.2a4) > on a Mac OS X 10.1 (5G64) and have discovered a rather serious bug. > > Basically you cannot have more than one version of Python running at any > time. Try it. From Terminal.app you can launch one copy but when launching > the second you get a Bus Error. Every time. > > I'm seeing this with 2.2a4 on a PowerMac G4 and with 2.2a3 on a Powerbook G4 > both with 5G64. > > I've tried compiling Python without the carbon libraries (--without-xxx-yyy) > and that didn't help matters much (the odd thing is that it allowed me to > run 2 instances without crashing - but the 3rd killed it). > > Also - if you login to Mac OS X via the console it is impossible to launch > an interactive Python session (and probably impossible to just launch > oneshot scripts too). When I try I get the following console errors: > > KCGErrorFailure: CGSNewConnection cannot connect to server > KCGErrorFailure: CGSNewConnection cannot connect to server > KCGErrorInvalidConnection: CGSGetEventPort: Invalid connection > > Which look to me like Core Graphics errors. Why should a command line Python > (compiled without the carbon cruft) need access to the Core Graphics Server. > > Something REALLY strange is going on... > > I'd really like to see Python for Mac OS X (not Jack's Mac Python) be a pure > unix implementation of Python with any Mac specific stuff in shared > libraries. I would have assumed this would have been the case but it doesn't > look like it is. > > Cheers for any insight on the matter. > > Jon. > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From jbradley@whiplashmedia.com Wed Oct 3 18:39:33 2001 From: jbradley@whiplashmedia.com (Jon Bradley) Date: Wed, 03 Oct 2001 13:39:33 -0400 Subject: [Pythonmac-SIG] Embedding Python invisibly In-Reply-To: Message-ID: Hey everyone, In a current project I'm working on, we're embedding Python into a 3d application. Things seem to be going right along, but I ran into an issue that I have no idea about, nor experience. I thought I would pass the question on to all you knowledgeable folks out there to see if you might know of any resources or examples I might be able to get a hold of. Embedding Python is cool and all - but what if I wanted to embed Python in an invisible manner? Meaning, in this 3D application, a user creates an extension that's compiled, somehow. That extension is written in Python, or C or C++ but is recognized by the application as just another extension. I want to find a mechanism whereby Python code in that extension is sent to the 'invisible' Python interpreter (if Python code is found to be used in that extension) and whatever is needed to be done is executed or arguments are returned in the manner they need to be. Example : 1. Python is embedded in the application (invisibly?) 2. User uses an SDK (which would probably be Python) to compile an extension that's written in Python (or uses Python to write the extension). 3. The extension shows up in an extension palette and the user can click on it and execute away. 4. Say this extension ... oh, modifies some selected geometry in a current context. 5. How the heck can it be done without an interpreter ever being visible or opened??!? The reasons for doing this are all over the place. For one, we want to have Python embedded so that the user can interface with the interpreter and do whatever needs to be done. BUT, I'd also like them to be able to compile modules (I'll just call them extensions) that the application, or Python will recognize that don't require a interpreter session to be visible to the user - a behind-the-scenes approach. The good thing about being able to do this is that we'd be able to have Python in the application running tools, extensions, animation things, etc. without the user ever having to touch code or type anything (I would love to enable this brainless approach). Just click and go. Also, it would be much easier to expand and work with as the application grows. 'Power users' would have the ability to actually get down to the core of any found 'extension' and import them into the interpreter and execute specific functional elements in that extension (module of course). This method would be very very useful for all sorts of good reasons. Now ... question is ... can it be done, and does anyone have a clue how? Thanks everyone!! Jon From paul@fxtech.com Wed Oct 3 18:52:46 2001 From: paul@fxtech.com (Paul Miller) Date: Wed, 03 Oct 2001 12:52:46 -0500 Subject: [Pythonmac-SIG] Embedding Python invisibly In-Reply-To: References: Message-ID: <5.1.0.14.2.20011003124632.02c94658@cedar.he.net> Jon, Yep - you can do everything you want to do. But it'll take some work... >1. Python is embedded in the application (invisibly?) Just link with the Python library and initialize it normally. The main issue here with making it "invisible" is on Mac it wants to open a Console no matter what you do. If anyone has figured out how to avoid this, I'd love to hear about it! >2. User uses an SDK (which would probably be Python) to compile an extension >that's written in Python (or uses Python to write the extension). You probably won't compile anything. Just have the user put their "extensions" (with .py extension) in your extensions directory and have Python look there for them (by modifying Python's path list). >3. The extension shows up in an extension palette and the user can click on >it and execute away. Couple of ways to do this - you could scan the directory yourself, pick out all files with .py extension, and use the base name as the extension name. You could also have your code "import" each extension and query it for the name it wants to be displayed as. >4. Say this extension ... oh, modifies some selected geometry in a current >context. You'll need to "extend" your C/C++ interfaces with Python interfaces, so you can use them in your "extension scripts". >5. How the heck can it be done without an interpreter ever being visible or >opened??!? You don't use the interpreter directly. When you want to run an extension, you just import it (using Python API calls), and call functions in it. You will want to look into the Python extending/embedding APIs on python.org. It wouldn't hurt to get Lutz's original Programming Python book - it had a pretty large chapter on this. All this stuff is pretty straightforward (one of the reasons Python makes such a nice extension language), but it's non-trivial. >The good thing about being able to do this is that we'd be able to have >Python in the application running tools, extensions, animation things, etc. >without the user ever having to touch code or type anything (I would love to >enable this brainless approach). Just click and go. Also, it would be much >easier to expand and work with as the application grows. We are working on a product that does exactly this (with the Power User extension approach you mention). It takes a bit of effort, but you can make a really nice environment out of this. >Now ... question is ... can it be done, and does anyone have a clue how? Hopefully my pointers above will get you started. Sorry I don't have time to go into more detail. A couple of days of research and playing around with the extension mechanism should get you going though! -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From karl@elemtech.com Wed Oct 3 21:25:03 2001 From: karl@elemtech.com (Karl G. Merkley) Date: Wed, 03 Oct 2001 14:25:03 -0600 Subject: [Pythonmac-SIG] MacPython/Tk problems Message-ID: <3BBB741F.3080802@elemtech.com> I installed MacPython on an OS 9 machine this morning and got a warning message about Tk not being compatible with Carbon. This is a machine in an elementary school and the teacher is excited about using Python as a tool for teaching some basic programming at the grade school level, but he would really like to use some of the tools that have been developed using Tk (turtle being one of them). The OS cannot be upgraded. Is there anyway to get Python working with Tk in this configuration? Thanks! From mdunn@cantares.on.ca Wed Oct 3 21:30:07 2001 From: mdunn@cantares.on.ca (Michael Dunn) Date: Wed, 3 Oct 2001 16:30:07 -0400 Subject: [Pythonmac-SIG] Applet/compilation oddities? Message-ID: Hi all. I'm not sure how "Mac-only" this is, but I'd like to better understand some "compilation" behaviour. When I compile or save as applet, WITHOUT optimization on, I get a file with, in one particular case, about 700 bytes of data, and ~30K in the resource fork. This works great on the Mac, but is not portable bytecode! If I turn optimization ON, I get a 10K file -- no resource fork, and I'm guessing IS portable. Somewhat odd, but my main concern is that I assumed the optimization would strip comments. However, looking at the file, I still see multi-line comments (not #comments), as well as docstrings! Is this odd, or what...? thx Michael From mday@mac.com Wed Oct 3 22:14:25 2001 From: mday@mac.com (Mark Day) Date: Wed, 3 Oct 2001 14:14:25 -0700 Subject: [Pythonmac-SIG] MacPython/Tk problems In-Reply-To: <3BBB741F.3080802@elemtech.com> Message-ID: <9F7B3552-B843-11D5-B417-00039354009A@mac.com> On Wednesday, October 3, 2001, at 01:25 PM, Karl G. Merkley wrote: > The OS cannot be upgraded. Is there anyway to get Python > working with Tk in this configuration? Yes. Just run the ConfigurePythonClassic application that's in the Python folder. I will change the Python interpretter, IDE, and other applets to use the non-Carbon interfaces, which *are* compatible with Tk. -Mark From karl@elemtech.com Wed Oct 3 22:59:00 2001 From: karl@elemtech.com (Karl G. Merkley) Date: Wed, 03 Oct 2001 15:59:00 -0600 Subject: [Pythonmac-SIG] MacPython/Tk problems References: <9F7B3552-B843-11D5-B417-00039354009A@mac.com> Message-ID: <3BBB8A24.2010904@elemtech.com> Mark Day wrote: > On Wednesday, October 3, 2001, at 01:25 PM, Karl G. Merkley wrote: > >> The OS cannot be upgraded. Is there anyway to get Python >> working with Tk in this configuration? > > > Yes. Just run the ConfigurePythonClassic application that's in the > Python folder. I will change the Python interpretter, IDE, and other > applets to use the non-Carbon interfaces, which *are* compatible with Tk. > > -Mark > That was the second thing I did (after doing the vanilla install and finding that it didn't work)! Either the ConfigurePythonClassic didn't take or I only thought I actually executed it. Is there a way to verify that this has been done (I guess from Tkinter import * would probably work ;-) ) Karl From mday@mac.com Thu Oct 4 00:20:23 2001 From: mday@mac.com (Mark Day) Date: Wed, 3 Oct 2001 16:20:23 -0700 Subject: [Pythonmac-SIG] MacPython/Tk problems In-Reply-To: <3BBB8A24.2010904@elemtech.com> Message-ID: <389C76CE-B855-11D5-B417-00039354009A@mac.com> On Wednesday, October 3, 2001, at 02:59 PM, Karl G. Merkley wrote: > Is there a way to verify that this has been done When you launch the IDE or interpreter, take a look at the first few lines it spits out. When it is configured to run in Carbon, you'll see something like: Python 2.1.1 (#97, Aug 2 2001, 21:53:31) [CW CARBON GUSI2 THREADS] Notice the word "CARBON". If it is configured as classic (non-Carbon), it will say "PPC" instead. > (I guess from Tkinter import * would probably work ;-) ) Yes, that would be good experimental evidence. :-) If you're running the classic (PPC) version, but you can't import from Tkinter, I would guess that something is wrong with your installation or configuration. But since I haven't tried Tk from MacPython, I probably can't help further. -Mark From jbradley@whiplashmedia.com Thu Oct 4 12:33:13 2001 From: jbradley@whiplashmedia.com (Jon Bradley) Date: Thu, 04 Oct 2001 07:33:13 -0400 Subject: [Pythonmac-SIG] Invisible Embedding? In-Reply-To: Message-ID: Hey everyone, In a current project I'm working on, we're embedding Python into a 3d application. Things seem to be going right along, but I ran into an issue that I have no idea about, nor experience. I thought I would pass the question on to all you knowledgeable folks out there to see if you might know of any resources or examples I might be able to get a hold of. Embedding Python is cool and all - but what if I wanted to embed Python in an invisible manner? Meaning, in this 3D application, a user creates an extension that's compiled, somehow. That extension is written in Python, or C or C++ but is recognized by the application as just another extension. I want to find a mechanism whereby Python code in that extension is sent to the 'invisible' Python interpreter (if Python code is found to be used in that extension) and whatever is needed to be done is executed or arguments are returned in the manner they need to be. Example : 1. Python is embedded in the application (invisibly?) 2. User uses an SDK (which would probably be Python) to compile an extension that's written in Python (or uses Python to write the extension). 3. The extension shows up in an extension palette and the user can click on it and execute away. 4. Say this extension ... oh, modifies some selected geometry in a current context. 5. How the heck can it be done without an interpreter ever being visible or opened??!? The reasons for doing this are all over the place. For one, we want to have Python embedded so that the user can interface with the interpreter and do whatever needs to be done. BUT, I'd also like them to be able to compile modules (I'll just call them extensions) that the application, or Python will recognize that don't require a interpreter session to be visible to the user - a behind-the-scenes approach. The good thing about being able to do this is that we'd be able to have Python in the application running tools, extensions, animation things, etc. without the user ever having to touch code or type anything (I would love to enable this brainless approach). Just click and go. Also, it would be much easier to expand and work with as the application grows. 'Power users' would have the ability to actually get down to the core of any found 'extension' and import them into the interpreter and execute specific functional elements in that extension (module of course). This method would be very very useful for all sorts of good reasons. Now ... question is ... can it be done, and does anyone have a clue how? Thanks everyone!! Jon From jack@oratrix.nl Thu Oct 4 23:06:29 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 05 Oct 2001 00:06:29 +0200 Subject: [Pythonmac-SIG] Applet/compilation oddities? In-Reply-To: Message by Michael Dunn , Wed, 3 Oct 2001 16:30:07 -0400 , Message-ID: <20011004220634.927981162D9@oratrix.oratrix.nl> Michael, I'm not sure what you mean by "compiling with optimization on" in this context. Could you give a recipe of what you're doing? Also, Python version info would be welcome. And also: does your problem occur with every script (i.e. also with the trivial print "hello world" script)? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Oct 5 12:38:36 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 05 Oct 2001 13:38:36 +0200 Subject: [Pythonmac-SIG] Embedding Python invisibly In-Reply-To: Message by Paul Miller , Wed, 03 Oct 2001 12:52:46 -0500 , <5.1.0.14.2.20011003124632.02c94658@cedar.he.net> Message-ID: <20011005113841.398DC1162D8@oratrix.oratrix.nl> Recently, Paul Miller said: > Jon, > > Yep - you can do everything you want to do. But it'll take some work... > > >1. Python is embedded in the application (invisibly?) > > Just link with the Python library and initialize it normally. Well, almost normally. You should call PyMac_Initialize(), not Py_Initialize(). There may be some issues currently if your toolboxes are already initialized, Alexandre Parenteau is looking at this. Or was I going to do it? I don't remember anymore... Alexandre, could you enlighten me again? > The main > issue here with making it "invisible" is on Mac it wants to open a Console > no matter what you do. If anyone has figured out how to avoid this, I'd > love to hear about it! The easiest way to do this is to drop your application on EditPythonPrefs and set the "no console until needed" option. What EditPythonPrefs does for applets also works for applications embedding Python. This is explained in :Mac:Demo:embedding.html, but it may need to be a bit more verbose. Suggestions as to a better text for the single line in there are hereby requested. Actually, the whole embedding.html could use more detail, but I've never really embedded MacPython myself, so maybe someone else wants to pick this up? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Oct 5 12:55:57 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 05 Oct 2001 13:55:57 +0200 Subject: [Pythonmac-SIG] Mac OS X Python 2.2a4 Bug (_not_ Mac Python) In-Reply-To: Message by Jonathan Wight , Fri, 28 Sep 2001 14:28:49 -0500 , Message-ID: <20011005115602.681241162D8@oratrix.oratrix.nl> Recently, Jonathan Wight said: > Hey, > > I've downloaded and compiled the latest version of ('Unix') Python (2.2a4) > on a Mac OS X 10.1 (5G64) and have discovered a rather serious bug. > > Basically you cannot have more than one version of Python running at any > time. Try it. From Terminal.app you can launch one copy but when launching > the second you get a Bus Error. Every time. I just tried this on 10.0.4 and there it works fine. So either it is a problem with 10.1 (which I'll install some time next week, hopefully) or it is a problem with your setup. Could you try starting the pythons with -vv and/or under gdb and/or with the dyld debugging turned on to see where exactly the problem occurs? > Also - if you login to Mac OS X via the console it is impossible to launch > an interactive Python session (and probably impossible to just launch > oneshot scripts too). When I try I get the following console errors: > > KCGErrorFailure: CGSNewConnection cannot connect to server > KCGErrorFailure: CGSNewConnection cannot connect to server > KCGErrorInvalidConnection: CGSGetEventPort: Invalid connection Again, on my 10.0.4 there's no problem, even in a Python with toolbox support. I get this message only as soon as I start actually importing Carbon modules. You didn't incidentally change your site.py or sitecustomize.py to import macfsn or some such (I had that originally, I had to revert to the distribution state to be able to run Python in console mode)? > I'd really like to see Python for Mac OS X (not Jack's Mac Python) be a pure > unix implementation of Python with any Mac specific stuff in shared > libraries. I would have assumed this would have been the case but it doesn't > look like it is. I am unsure about this. Originally I thought that I would also want that, i.e. have Python be completely untainted by any MacPython stuff, but when I put in the few hooks (mactoolboxglue.c only, really) it appeared to have absolutely no detrimental effects. And for me it still doesn't (yet:-). If we can get command line Python to work consistently for unix work with the few hooks left in I would now prefer that setup. The hooks have to be shared by all Carbon modules, they contain the glue code and some common things like an exception, and while they could conceivable be put into another shared library shared between the Carbon modules this would make the whole architecture more hairy again. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From joanca@typerware.com Fri Oct 5 14:51:21 2001 From: joanca@typerware.com (JoanCarles =?iso-8859-1?Q?Casas=EDn?=) Date: Fri, 5 Oct 2001 15:51:21 +0200 Subject: [Pythonmac-SIG] Clipboard Message-ID: <20011005155213-r01010600-3703867f@195.77.107.66> Hi all, An easy one: Is possible to copy something (a string, is the case) to the clipboard, a= nd then go away and paste it somewhere? --- p.e. s =3D "I want to paste this in Simpletext" xxx.copytoclipboard(s) --- I suppose it can be done with the Scrap module, but as it's not documente= d I couldn't get anything. I suppose it will be easy for most of you... Thanks, Joancarles, Typerware=AE From Benjamin.Schollnick@usa.xerox.com Fri Oct 5 15:06:29 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 05 Oct 2001 10:06:29 -0400 Subject: [Pythonmac-SIG] Tkinter on Mac Message-ID: Is there any good documentation and/or starting point for Tkinter / Python programming on the Mac? - Benjamin From jack@oratrix.nl Fri Oct 5 15:59:04 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 05 Oct 2001 16:59:04 +0200 Subject: [Pythonmac-SIG] Clipboard In-Reply-To: Message by JoanCarles =?iso-8859-1?Q?Casas=EDn?= , Fri, 5 Oct 2001 15:51:21 +0200 , <20011005155213-r01010600-3703867f@195.77.107.66> Message-ID: <20011005145910.0CD331162D8@oratrix.oratrix.nl> Recently, JoanCarles =?iso-8859-1?Q?Casas=EDn?= said: > Hi all, > > An easy one: > Is possible to copy something (a string, is the case) to the clipboard, a= > nd then > go away and paste it somewhere? Indeed, the Scrap module is what you want. But: it doesn't work in Carbon MacPython, only in Classic MacPython (the Carbon scrap manager is completely different). Just did a workaround using calldll for Carbon, if I remember correctly. The documentation for the Scrap Manager is in Inside Mac (either "toolbox" or "more toolbox", I think), but you could also have a look at the sample code in Mac:Demo or in the IDE sources. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From alexp@strata.com Fri Oct 5 16:34:22 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Fri, 5 Oct 2001 08:34:22 -0700 Subject: [Pythonmac-SIG] Embedding Python invisibly References: <20011005113841.398DC1162D8@oratrix.oratrix.nl> Message-ID: <003301c14db3$35442e30$4000a8c0@veropc> Jack, Jon, > Well, almost normally. You should call PyMac_Initialize(), not > Py_Initialize(). There may be some issues currently if your toolboxes > are already initialized, Alexandre Parenteau is looking at > this. Or was I going to do it? I don't remember anymore... Alexandre, > could you enlighten me again? Gary Bringhurst suggested we could use a specific call of Sioux to avoid opening the console. However I was thinking to write a specialized GUSISioux.cpp for MacPython, both for providing an API entry to make MacPython quiet and to adjust with the current implementation of the delayed console. I was busy with other things, I might have a look again today hopefully. Jon I understand what you want to do, I do pretty much the same thing in MacCvs now. The Python interpreters are running quietly and have the stdout/stderr redirected to the app console. But to do that, I needed to hack MacPython for now and make the console quiet. Jack is there a chance you get on CW7 soon ? This way it would be easier to debug on OSX. Thanks, alex. > > > The main > > issue here with making it "invisible" is on Mac it wants to open a Console > > no matter what you do. If anyone has figured out how to avoid this, I'd > > love to hear about it! > > The easiest way to do this is to drop your application on > EditPythonPrefs and set the "no console until needed" option. What > EditPythonPrefs does for applets also works for applications embedding > Python. > > This is explained in :Mac:Demo:embedding.html, but it may need to be a > bit more verbose. Suggestions as to a better text for the single line > in there are hereby requested. Actually, the whole embedding.html > could use more detail, but I've never really embedded MacPython > myself, so maybe someone else wants to pick this up? > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From paul@fxtech.com Fri Oct 5 16:40:40 2001 From: paul@fxtech.com (Paul Miller) Date: Fri, 05 Oct 2001 10:40:40 -0500 Subject: [Pythonmac-SIG] Embedding Python invisibly In-Reply-To: <003301c14db3$35442e30$4000a8c0@veropc> References: <20011005113841.398DC1162D8@oratrix.oratrix.nl> Message-ID: <5.1.0.14.2.20011005103948.01d19e88@cedar.he.net> >Jack is there a chance you get on CW7 soon ? This way it would be easier to >debug on OSX. The more people on CW7 the better - I couldn't get any Python or GUSI stuff to build using CW7. Fortunately, I was able to get the pre-built PythonCoreCarbon to work with my app - but I still can't step into it. :-( -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From mdunn@cantares.on.ca Fri Oct 5 18:25:35 2001 From: mdunn@cantares.on.ca (Michael Dunn) Date: Fri, 5 Oct 2001 13:25:35 -0400 Subject: [Pythonmac-SIG] Applet/compilation oddities? In-Reply-To: <20011004220634.927981162D9@oratrix.oratrix.nl> References: <20011004220634.927981162D9@oratrix.oratrix.nl> Message-ID: At 12:06 AM +0200 2001/10/5, Jack Jansen wrote: >Michael, >I'm not sure what you mean by "compiling with optimization on" in this >context. Could you give a recipe of what you're doing? Run EditPythonPrefs and select Optimize Bytecode. IDE's Save as Applet and running BuildApplet are unaffected, but using compile() (from py_compile) results in the smaller .pyo file, yet still containing docstrings and multiline comments. Yet I'm sure I read somewhere that this option's main function is to remove docstrings. I just assumed that comments would also be removed!!! But neither are. > Also, Python >version info would be welcome. 2.1 > And also: does your problem occur with >every script (i.e. also with the trivial print "hello world" script)? yes. I also just discovered that every Mac applet I create (eg from the IDE) has a data fork of 772 bytes! Seems all the "data" is in the resource fork. How strange. ----------------------------------------------------------------- Michael Dunn | Surround Sound Decoder & Stereo Enhancer Cantares | Self-Amplified Speakers, Test Equipment 74 George St. | Ambisonic Surround Sound CDs and Recording Waterloo, Ont. | (519) 744-9395 (fax: 744-7129) N2J 1K7 | mdunn@cantares.on.ca Canada | http://www.cantares.on.ca/ ----------------------------------------------------------------- From jack@oratrix.nl Fri Oct 5 21:39:01 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 05 Oct 2001 22:39:01 +0200 Subject: [Pythonmac-SIG] file.read() after file.readline() problem Message-ID: <20011005203906.664B1EDD23@oratrix.oratrix.nl> Folks, I'm running into a problem that seems to have been around for some time: I've now seen it in MacPython 2.1.1 and the (current CVS) 2.2a4+. If people with older Pythons could look at the following scenario and tell me how far it goes back that would be helpful. The problem is that if you have a file bigger than 4KB and you do first a readline() and then a read() the read does not return all the data: it returns only the first 4KB of the file (minus the bit that has been read by the readline). To make matters more mysterious: after a seek() the file behaves normally again. A reasonable file to test this with is probably the installer log file in the Python directory: >>> fp = open('installer log file') >>> d0 = fp.read() >>> print 'real length', len(d0) >>> fp = open('installer log file') >>> d1 = fp.readline() >>> d2 = fp.read() >>> print len(d1), len(d2) On my machine d2 does not contain all the data in the rest of the file. The following code does work correctly: >>> fp = open('installer log file') >>> fp.seek(0) >>> d1 = fp.readline() >>> d2 = fp.read() >>> print len(d1), len(d2) If you can help me find out around which time this bug was introduced (and/or whether other people also see it, and it's not something specific to my machine) that would help me a lot in tracing it. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From jack@oratrix.nl Fri Oct 5 22:11:02 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 05 Oct 2001 23:11:02 +0200 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message by Chris Barker , Fri, 05 Oct 2001 09:11:08 -0700 , <3BBDDB9C.2D747F7E@home.net> Message-ID: <20011005211107.EA877EDD23@oratrix.oratrix.nl> Chris, Yes, I read your message yesterday, it's just that I hadn't gotten around to replying yet. Some comments off the top of my head - I think this class should use the new inheritance-from-builtin-types to be a subclass of the builtin file type eventually, but I'm not sure yet how easy that would be. And maybe this doesn't even buy us all that much, so it's only my overly-striving-for-elegance that say this. - I don't like all the various ways to specify line endings (with 'mac', 'Mac' and '\r' all being equivalent), I think I'd go with a simple '\r' (maybe with a symbolic constant mac='\r' somewhere). The argument checking should also be made more robust, as you've noted yourself. - Mixed lineendings are important, for the reason Guido specified, and also for things like socket connections (an http server will reply with internet-standard \r\n lineendings, but the documents it serves may have unix-style \n). - Interactive input is important, and the lookahead for \n should be tackled. I think the way to do it is different than what Guido suggests, I think that in stead of peeking ahead for a \n if you see a \r you should set a flag (self.return_seen_skip_initial_newline) that will eat the newline upon the next read/readline. But: this has implications for tell(), as tell() _will_ have to do the peek to return the correct position for the beginning of the next line. And seek() should reset the flag. - I have the feeling that readline() could use the underlying file.readline() so that the \n and \r\n cases are already handled halfway automatically. On the other hand: factoring out common code in read() and readline() might also be a good idea (and seem to forestall the former. Hmm, unless file.readline() is really the underlying I/O operation you should use: file.read() doesn't buy us any performance because we're going the hack the result into little linesized bits anyway to put in the correct linefeeds). But: the seek() you're doing in readline() is unsafe (won't work on sockets/terminals). - As you're probably aware the API of your sample code is incomplete: there's no xreadlines(), no optional arg to readline(), etc. A wild idea (and basically why I added Guido to the cc list): file objects could make our life a lot simpler if there was a call file.readtoterminator(termchars, max), where termchars is a string, which would read data up to and including a character in termchars (or until 'max' bytes have been read). It would have to be implemented as a getc() loop in C, but as we're going to do that looping anyway at some point we might as well do it in C and not in Python... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido@python.org Fri Oct 5 22:18:15 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 05 Oct 2001 17:18:15 -0400 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Your message of "Fri, 05 Oct 2001 23:11:02 +0200." <20011005211107.EA877EDD23@oratrix.oratrix.nl> References: <20011005211107.EA877EDD23@oratrix.oratrix.nl> Message-ID: <200110052118.RAA04280@cj20424-a.reston1.va.home.com> > A wild idea (and basically why I added Guido to the cc list): file > objects could make our life a lot simpler if there was a call > file.readtoterminator(termchars, max), where termchars is a string, which > would read data up to and including a character in termchars (or until > 'max' bytes have been read). It would have to be implemented as a > getc() loop in C, but as we're going to do that looping anyway at some > point we might as well do it in C and not in Python... Hm, that makes sense. I'm missing some context (didn't see Chris Barker's msg) but feel free to propose a patch for such a method. --Guido van Rossum (home page: http://www.python.org/~guido/) From alexp@strata.com Fri Oct 5 22:46:28 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Fri, 05 Oct 2001 14:46:28 -0700 Subject: [Pythonmac-SIG] file.read() after file.readline() problem In-Reply-To: <20011005203906.664B1EDD23@oratrix.oratrix.nl> Message-ID: Jack, I think this is due to fileobject.c:526 : pos = lseek(fileno(f->f_fp), 0L, SEEK_CUR); If you replace that by : pos = fseek(f->f_fp, 0L, SEEK_CUR); It works. I think it not safe to mix buffered calls (fseek, fread, fgets) with non-buffered ones (lseek), because you don't get the expected result (the buffered one take into account the number of bytes in the buffer, while the other one only ask the physical device). I even wonder how that can work on a Posix system. Hope it helps, Alex. > Folks, > I'm running into a problem that seems to have been around for some > time: I've now seen it in MacPython 2.1.1 and the (current CVS) > 2.2a4+. If people with older Pythons could look at the following > scenario and tell me how far it goes back that would be helpful. > > The problem is that if you have a file bigger than 4KB and you do > first a readline() and then a read() the read does not return all the > data: it returns only the first 4KB of the file (minus the bit that > has been read by the readline). To make matters more mysterious: after > a seek() the file behaves normally again. > > A reasonable file to test this with is probably the installer log file > in the Python directory: >>>> fp = open('installer log file') >>>> d0 = fp.read() >>>> print 'real length', len(d0) >>>> fp = open('installer log file') >>>> d1 = fp.readline() >>>> d2 = fp.read() >>>> print len(d1), len(d2) > On my machine d2 does not contain all the data in the rest of the > file. > > The following code does work correctly: >>>> fp = open('installer log file') >>>> fp.seek(0) >>>> d1 = fp.readline() >>>> d2 = fp.read() >>>> print len(d1), len(d2) > > If you can help me find out around which time this bug was introduced > (and/or whether other people also see it, and it's not something > specific to my machine) that would help me a lot in tracing it. > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From jack@oratrix.nl Fri Oct 5 23:16:18 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 06 Oct 2001 00:16:18 +0200 Subject: [Pythonmac-SIG] Embedding Python invisibly In-Reply-To: Message by "Alexandre Parenteau" , Fri, 5 Oct 2001 08:34:22 -0700 , <003301c14db3$35442e30$4000a8c0@veropc> Message-ID: <20011005221623.BB85EEDD23@oratrix.oratrix.nl> Recently, "Alexandre Parenteau" said: > However I was thinking to write a specialized GUSISioux.cpp for MacPython, > both for providing an API entry to make MacPython quiet and to adjust with > the current implementation of the delayed console. [Jack wanders off towards Guido's time machine] Poof! As of 2.1 MacPython has it's own replacement for GUSISioux.cpp, pyGUSISioux.cpp. It handles delayed console already. I think we can add an API PyMac_SetConsoleHandler(readcharsfunc, writecharsfunc) that embedding apps can use to redirect console output to their own code. We could also provide PyMac_NullReadChars() and PyMac_NullWriteChars() to make console i/o get lost forever. These functions should be callable before PyMac_Initialize(). Alexandre, do you want to tackle this? > Jack is there a chance you get on CW7 soon ? This way it would be easier to > debug on OSX. It may be a while, I'm afraid. With Oratrix our short-term focus is on Windows, and in the current cost-cutting atmosphere that means that updating CW is non-essential. And I'll have to do a bit of soul-searching to decide whether I want to pay it out of my own pocket, the price-vs-expected-income ratio is on the high side:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From alexp@strata.com Fri Oct 5 23:21:48 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Fri, 05 Oct 2001 15:21:48 -0700 Subject: [Pythonmac-SIG] Embedding Python invisibly In-Reply-To: <20011005221623.BB85EEDD23@oratrix.oratrix.nl> Message-ID: Jack, > I think we can add an API > PyMac_SetConsoleHandler(readcharsfunc, writecharsfunc) > that embedding apps can use to redirect console output to their own > code. We could also provide PyMac_NullReadChars() and > PyMac_NullWriteChars() to make console i/o get lost forever. These > functions should be callable before PyMac_Initialize(). > > Alexandre, do you want to tackle this? Yes, I can help and do it if you let me. That was exactly what I wanted to expose, except it is more like : oldreadcharsfunc PyMac_SetStdinHandler(readcharsfunc) oldwritecharsfunc PyMac_SetStdoutHandler(writecharsfunc) olderrorcharsfunc PyMac_SetStderrHandler(errorcharsfunc) Setting to nil gives to control to Sioux. I think an application which wants to handle itself the console can use that, and then later on execute a python code to override sys.stdin, sys.stderr, sys.stdout. After what (if the the python code to do that finishes gracefully), it has the choice to set the old values back (it won't get there anymore anyway). Regards, Alex. > >> Jack is there a chance you get on CW7 soon ? This way it would be easier to >> debug on OSX. > > It may be a while, I'm afraid. With Oratrix our short-term focus is on > Windows, and in the current cost-cutting atmosphere that means that > updating CW is non-essential. And I'll have to do a bit of > soul-searching to decide whether I want to pay it out of my own > pocket, the price-vs-expected-income ratio is on the high side:-) > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > From jack@oratrix.nl Fri Oct 5 23:33:49 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 06 Oct 2001 00:33:49 +0200 Subject: [Pythonmac-SIG] file.read() after file.readline() problem In-Reply-To: Message by Alexandre Parenteau , Fri, 05 Oct 2001 14:46:28 -0700 , Message-ID: <20011005223355.0B7D6EDD23@oratrix.oratrix.nl> First: thanks to all the people who did the tests on old Pythons. I now know the bug was introduced between 1.5.2 and 2.0. Recently, Alexandre Parenteau said: > Jack, > > I think this is due to fileobject.c:526 : > > pos = lseek(fileno(f->f_fp), 0L, SEEK_CUR); > > If you replace that by : > > pos = fseek(f->f_fp, 0L, SEEK_CUR); > > It works. Alexandre Holmes, thanks a lot! That looks like a very likely candidate for the trouble spot. But unfortunately your fix won't work, and the real problem must be somewhere deeper down (in GUSI?). The lseek() is intentional: as the comment above that code fragment shows some stdio implementations flush the buffer on an fseek(), even if the underlying file is unseekable (and fseek() should be a noop). Moreover, this specific lseek() call is a no-op, so even though stdio doesn't know about us doing it it should harm it either. I have this very vague memory of problems with GUSI and seek() and it messing up the GUSI buffering mechanism, but I think that that was a long time ago. That 1.5.2 works fine also points that way (152 was GUSI1 based, 2.0 was the first GUSI2 based MacPython. Also, the bug is probably a general GUSI2 problem: 2.0 didn't use the hacked up CarbonGUSI yet). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Oct 5 23:41:07 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 06 Oct 2001 00:41:07 +0200 Subject: [Pythonmac-SIG] Embedding Python invisibly In-Reply-To: Message by Alexandre Parenteau , Fri, 05 Oct 2001 15:21:48 -0700 , Message-ID: <20011005224112.522E6EDD23@oratrix.oratrix.nl> Recently, Alexandre Parenteau said: > Yes, I can help and do it if you let me. That was exactly what I wanted to > expose, except it is more like : > > oldreadcharsfunc PyMac_SetStdinHandler(readcharsfunc) > oldwritecharsfunc PyMac_SetStdoutHandler(writecharsfunc) > olderrorcharsfunc PyMac_SetStderrHandler(errorcharsfunc) > > Setting to nil gives to control to Sioux. I don't think we can distinguish between stdout and stderr. By the time we're in pyGUSISioux.cpp it's all the console output window. Or did you want to intercept things elsewhere? I'm not sure about resetting at the end: the embedding app can't be sure about what it really means as stuff may still be buffered in stdio buffers or GUSI buffers, and resetting might cause the darn console window during stdio cleanup in exit(). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Oct 5 23:49:59 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 06 Oct 2001 00:49:59 +0200 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message by Guido van Rossum , Fri, 05 Oct 2001 17:18:15 -0400 , <200110052118.RAA04280@cj20424-a.reston1.va.home.com> Message-ID: <20011005225004.950EAEDD23@oratrix.oratrix.nl> Recently, Guido van Rossum said: > > A wild idea (and basically why I added Guido to the cc list): file > > objects could make our life a lot simpler if there was a call > > file.readtoterminator(termchars, max), where termchars is a string, which > > would read data up to and including a character in termchars (or until > > 'max' bytes have been read). It would have to be implemented as a > > getc() loop in C, but as we're going to do that looping anyway at some > > point we might as well do it in C and not in Python... > > Hm, that makes sense. I'm missing some context (didn't see Chris > Barker's msg) but feel free to propose a patch for such a method. Chris: would this method help you? If it would I can put in a patch for the C code, but I'll leave the Python stuff to you. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Oct 5 23:59:56 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 06 Oct 2001 00:59:56 +0200 Subject: [Pythonmac-SIG] Applet/compilation oddities? In-Reply-To: Message by Michael Dunn , Fri, 5 Oct 2001 13:25:35 -0400 , Message-ID: <20011005230001.A12C7EDD23@oratrix.oratrix.nl> Recently, Michael Dunn said: > At 12:06 AM +0200 2001/10/5, Jack Jansen wrote: > >Michael, > >I'm not sure what you mean by "compiling with optimization on" in this > >context. Could you give a recipe of what you're doing? > > Run EditPythonPrefs and select Optimize Bytecode. IDE's Save as > Applet and running BuildApplet are unaffected, but using compile() > (from py_compile) results in the smaller .pyo file, yet still > containing docstrings and multiline comments. Ah. A few things: - "optimize bytecode" affects the underlying interpreter, not so much the IDE. And apparently the IDE doesn't look at this setting when it generates applets. Just: what do you think, is this your problem or my problem? :-) > Yet I'm sure I read > somewhere that this option's main function is to remove docstrings. No, on Unix there's an option -OO to do that, but there's no UI to set that for MacPython yet. Please put in a feature request (assigned to me) in the sourceforge tracker for this and I'll get to it eventually. By the way, I assume that by "multiline comments" you mean things in triple quotes? These are really strings (just like docstrings) and hence end up in the code. For comments you should really use #. > yes. I also just discovered that every Mac applet I create (eg > from the IDE) has a data fork of 772 bytes! Seems all the "data" is > in the resource fork. How strange. That's right. The data fork only contains a tiny CFM code fragment that calls out to PythonCore or PythonCoreCarbon. The resource for contains your .pyc code (in a 'PYC ' resource) plus standard things like icons, size and cfrg resources and other stuff. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From alexp@strata.com Fri Oct 5 23:57:50 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Fri, 05 Oct 2001 15:57:50 -0700 Subject: [Pythonmac-SIG] Embedding Python invisibly In-Reply-To: <20011005224112.522E6EDD23@oratrix.oratrix.nl> Message-ID: Jack, > I don't think we can distinguish between stdout and stderr. By the > time we're in pyGUSISioux.cpp it's all the console output window. Or > did you want to intercept things elsewhere? It think you can, I would do the submission in this direction : the trick is to create not one SIOUX socket, but three : GUSISIOUXSocket * SIOUX = GUSISIOUXSocket::Instance(); table->InstallSocket(SIOUX); table->InstallSocket(SIOUX); table->InstallSocket(SIOUX); Now replaced by : table->InstallSocket(GUSISIOUXSocket::Instance(0)); table->InstallSocket(GUSISIOUXSocket::Instance(1)); table->InstallSocket(GUSISIOUXSocket::Instance(2)); And modify GUSISIOUXSocket:: GUSISIOUXSocket(int fd) to get a file descriptor. This way the socket knows what it is (stdin, stderr, stdout). But for the rest you're right obviously ! Restoring the console is not an option as it could lead to some nasty clean up problems... I still continue to play with it, my problem is to understand the existing delaying mechanism and the side effects. Alex. > > I'm not sure about resetting at the end: the embedding app can't be > sure about what it really means as stuff may still be buffered in > stdio buffers or GUSI buffers, and resetting might cause the darn > console window during stdio cleanup in exit(). > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From jack@oratrix.nl Sat Oct 6 00:07:25 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 06 Oct 2001 01:07:25 +0200 Subject: [Pythonmac-SIG] Embedding Python invisibly In-Reply-To: Message by Alexandre Parenteau , Fri, 05 Oct 2001 15:21:48 -0700 , Message-ID: <20011005230730.81F46EDD23@oratrix.oratrix.nl> Recently, Alexandre Parenteau said: > oldreadcharsfunc PyMac_SetStdinHandler(readcharsfunc) > oldwritecharsfunc PyMac_SetStdoutHandler(writecharsfunc) > olderrorcharsfunc PyMac_SetStderrHandler(errorcharsfunc) Reversing my previous position I now think that my interface (with a single function to set both handlers) is better. There's other Sioux functions that need to be called if and only if the user hasn't overridden either stdin or stdout (InstallConsole(), PyMac_InitMenuBar(), event handler setting). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From alexp@strata.com Sat Oct 6 00:30:17 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Fri, 05 Oct 2001 16:30:17 -0700 Subject: [Pythonmac-SIG] file.read() after file.readline() problem In-Reply-To: <20011005223355.0B7D6EDD23@oratrix.oratrix.nl> Message-ID: Jack, > But unfortunately your fix won't work, and the real problem must be > somewhere deeper down (in GUSI?). Yes you're right, I was a little fast to conclude. Something goes wacky anyway when calling GUSI's lseek, that's all I can tell so far. Could be a mixed up in the GUSI buffering mechanism. In fact lseek does purge its own cache, so may be it should not (see GUSIMacFileSocket::lseek and then GUSIMacFileSocket::SyncRead) Alex. > > The lseek() is intentional: as the comment above that code fragment > shows some stdio implementations flush the buffer on an fseek(), even > if the underlying file is unseekable (and fseek() should be a noop). > Moreover, this specific lseek() call is a no-op, so even though stdio > doesn't know about us doing it it should harm it either. > > I have this very vague memory of problems with GUSI and seek() and it > messing up the GUSI buffering mechanism, but I think that that was a > long time ago. That 1.5.2 works fine also points that way (152 was > GUSI1 based, 2.0 was the first GUSI2 based MacPython. Also, the bug is > probably a general GUSI2 problem: 2.0 didn't use the hacked up > CarbonGUSI yet). > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > From chrishbarker@home.net Sat Oct 6 01:41:52 2001 From: chrishbarker@home.net (Chris Barker) Date: Fri, 05 Oct 2001 17:41:52 -0700 Subject: [Pythonmac-SIG] Re: MacPython and line-endings References: <20011005211107.EA877EDD23@oratrix.oratrix.nl> <200110052118.RAA04280@cj20424-a.reston1.va.home.com> Message-ID: <3BBE5350.E9183AA6@home.net> Jack Jansen wrote: > Yes, I read your message yesterday, it's just that I hadn't gotten > around to replying yet. Some comments off the top of my head I didn't meant o rush you, and thanks for your input. > - I think this class should use the new inheritance-from-builtin-types > to be a subclass of the builtin file type eventually, but I'm not > sure yet how easy that would be. And maybe this doesn't even buy us > all that much, so it's only my overly-striving-for-elegance that say > this. That would be more elegant. I'll keep it in mind when I move to a version of Python that supports it. > - I don't like all the various ways to specify line endings (with > 'mac', 'Mac' and '\r' all being equivalent), I think I'd go with a > simple '\r' (maybe with a symbolic constant mac='\r' somewhere). I wanted the interface to be easy to use. I suppose if you are a programmer, you should know what a Mac line ending looks like, but that may not fit with CP4E. If you were to define a constant somewhere, where would you define it??? > The argument checking should also be made more robust, as you've > noted yourself. I'll beef it up. > - Mixed lineendings are important, for the reason Guido specified, and > also for things like socket connections (an http server will reply > with internet-standard \r\n lineendings, but the documents it serves > may have unix-style \n). Yet another good reason! > - Interactive input is important, and the lookahead for \n should be > tackled. I think the way to do it is different than what Guido > suggests, I think that instead of peeking ahead for a \n if you see > a \r you should set a flag (self.return_seen_skip_initial_newline) > that will eat the newline upon the next read/readline. But: this has > implications for tell(), as tell() _will_ have to do the peek to > return the correct position for the beginning of the next > line. And seek() should reset the flag. Also read(). There just isn't a simple way to do this. I really hadn't been thinking of interactive input...how important is it to support arbitrary line ending in interactive input? How often would it be coming from an unknown source? Not that it wouldn't be nice for completeness' sake in any case. > - I have the feeling that readline() could use the underlying > file.readline() so that the \n and \r\n cases are already handled > halfway automatically. But what about \r by itself?? (or would it just read in a whole lot if there were no \n..which is what I am doing anyway...hmm, I'll think about it, that may make sense. > On the other hand: factoring out common code > in read() and readline() might also be a good idea (and seem to > forestall the former. Hmm, unless file.readline() is really the > underlying I/O operation you should use: file.read() doesn't buy us > any performance because we're going the hack the result into little > linesized bits anyway to put in the correct linefeeds). But: the > seek() you're doing in readline() is unsafe (won't work on > sockets/terminals). I hadn't thought about that at all. I think to support something without a seek() like that would mean that you would have to read it in byte by byte, which I thought would be unbearably slow in Python (I admit I haven't tried it) > - As you're probably aware the API of your sample code is incomplete: > there's no xreadlines(), no optional arg to readline(), etc. I started working on this before xreadlines() existed. I'll look into adding it. > A wild idea (and basically why I added Guido to the cc list): file > objects could make our life a lot simpler if there was a call > file.readtoterminator(termchars, max), where termchars is a string, which > would read data up to and including a character in termchars (or until > 'max' bytes have been read). It would have to be implemented as a > getc() loop in C, but as we're going to do that looping anyway at some > point we might as well do it in C and not in Python... Yes, I think it should be in C. Guido van Rossum wrote: > Hm, that makes sense. I'm missing some context (didn't see Chris > Barker's msg) but feel free to propose a patch for such a method. Actually, you did. I know because you gave a couple of encouraging replies. At the time you said you didn't have time to look at my prototype code, so you probably never got a chance. Jack Jansen wrote: > Chris: would this method help you? If it would I can put in a patch > for the C code, but I'll leave the Python stuff to you. well, we need to resolve the "peek ahead" vs "set a flag" method discussion in order to do it, and the "set a flag" method would require changes to a number of the other methods, so I'm not sure. You also make a good case for the flag approach, for interactive an streaming input. Maybe I'm missing something. In any case, my goal is that something like this would become part of the built-in file object. If that is going to happen, I don't know that I need the readtoterminator() method on it's own. On the other hand, it would be a start, and would make it much easier to make a nice robust and fast Python version while I'm waiting around for the built-in one to be written. HMMM. One reason it needs to be built in is that it could then be used for imports and execs() and all that, which is really where this all started. Jack, you had mentioned that you had some version of cross platform importing working with MacPython. What do you have now? My plan at the moment is to improve my python version with your suggestions, and work my comments up into a draft PEP, and then put it out to the world. None of this will happen for a couple of weeks, because I'm about to go on vacation. I really appreciate everyone's help with this. -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From guido@python.org Sat Oct 6 03:20:55 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 05 Oct 2001 22:20:55 -0400 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Your message of "Fri, 05 Oct 2001 17:41:52 PDT." <3BBE5350.E9183AA6@home.net> References: <20011005211107.EA877EDD23@oratrix.oratrix.nl> <200110052118.RAA04280@cj20424-a.reston1.va.home.com> <3BBE5350.E9183AA6@home.net> Message-ID: <200110060220.WAA04896@cj20424-a.reston1.va.home.com> (Butting in but still without knowing the context :-) > I wanted the interface to be easy to use. I suppose if you are a > programmer, you should know what a Mac line ending looks like, but that > may not fit with CP4E. If you were to define a constant somewhere, where > would you define it??? Just one thing: for the Python programmer, a line end should *always* appear as \n. Files in text mode are supposed to maintain this abstraction. You should *not* have to know that on Windows it's really \r\n, nor that on Mac it's really \r. (BTW what is it on MacOS X, which is Unix based?) --Guido van Rossum (home page: http://www.python.org/~guido/) From tom@othermedia.com Sat Oct 6 10:51:34 2001 From: tom@othermedia.com (tom smith) Date: Sat, 06 Oct 2001 10:51:34 +0100 Subject: [Pythonmac-SIG] Tkinter on Mac In-Reply-To: Message-ID: > Is there any good documentation and/or starting point for Tkinter / Python > programming on the Mac? If you mean OSX, then here it is... tom :-) p.s I'm anxiously waiting someone to port Tk to OSX (I even braved jPython for a few days... swing IS nice) From jack@oratrix.nl Sat Oct 6 14:39:46 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 06 Oct 2001 15:39:46 +0200 Subject: [Pythonmac-SIG] Tkinter on Mac In-Reply-To: Message by tom smith , Sat, 06 Oct 2001 10:51:34 +0100 , Message-ID: <20011006133951.346F3FB04B@oratrix.oratrix.nl> Recently, tom smith said: > p.s I'm anxiously waiting someone to port Tk to OSX (I even braved jPython > for a few days... swing IS nice) Work on a Tk/Aqua port is underway, if I interpret the comments on on the mactcl mailing list correctly, but I haven't seen any timeline yet. But there's another option: if I read the announcement of the new xfree86 for OSX correctly it now supports rootless usage (previously the free X11 implementation had all the X windows within another window, like Virtual PC, and if you wanted X windows as first class citizens you needed a commercial X server), so if you really want Tkinter this may be a solution. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Sat Oct 6 16:11:32 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 06 Oct 2001 17:11:32 +0200 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message by Chris Barker , Fri, 05 Oct 2001 17:41:52 -0700 , <3BBE5350.E9183AA6@home.net> Message-ID: <20011006151137.9EA551162D8@oratrix.oratrix.nl> Recently, Chris Barker said: > > - I don't like all the various ways to specify line endings (with > > 'mac', 'Mac' and '\r' all being equivalent), I think I'd go with a > > simple '\r' (maybe with a symbolic constant mac='\r' somewhere). > > I wanted the interface to be easy to use. I suppose if you are a > programmer, you should know what a Mac line ending looks like, but that > may not fit with CP4E. If you were to define a constant somewhere, where > would you define it??? Hmm. I agree with your thinking that newbies won't know about \r\n. But on the other hand newbees wil never use the parameter in the first place: they'll read files with any line ending and wite files with the local lineending. But this isn't really all that important a point, feel free to do what you like. > > - Interactive input is important, and the lookahead for \n should be > > tackled. I think the way to do it is different than what Guido > > suggests, I think that instead of peeking ahead for a \n if you see > > a \r you should set a flag (self.return_seen_skip_initial_newline) > > that will eat the newline upon the next read/readline. But: this has > > implications for tell(), as tell() _will_ have to do the peek to > > return the correct position for the beginning of the next > > line. And seek() should reset the flag. > Also read(). > > There just isn't a simple way to do this. I really hadn't been thinking > of interactive input...how important is it to support arbitrary line > ending in interactive input? How often would it be coming from an > unknown source? Not that it wouldn't be nice for completeness' sake in > any case. Maybe it isn't all that important. We can assume that sys.stdin conforms to the local convention, I guess. And for interactive input coming in over sockets (think of things like a Python MUD server connected to via telnet) we'll probably get a known convention. But: I don't think it's all that difficult either, I think my flag proposal shoul handle all cases fairly easily. Or do you see problems with it? I'm skipping the read()/readline() stuff, the more I think about it the more I think that the readtoterminator() solution is the right one. And if we want backward compatibility to Python versions that don't have the readtoterminator() file object method we can add a workaround to the class. We'd still have only a single place in the code where we would have to look at every byte. Read and readline would become really simple: def readline(self, count=0): data = self.fp.readtoterminator('\r\n', count) if not data: return data if self.skipinitialnewline and data[0] == '\n': data = data[1:] self.skipinitialnewline = (data[-1] == '\r') if data[-1] == '\r': data = data[:-1] + '\n' return data def read(self, count=0): data = '' while 1: next = self.readline(count) if not next: return data data = data + next if count: count = count - len(next) if count <= 0: return data > In any case, my goal is that something like this would become part of > the built-in file object. > [...] > One reason it needs to be built in is that it could then be used for > imports and execs() and all that, which is really where this all > started. This is a whole different can of worms. And I think that putting the crossplatform newline functionality in the file objects isn't going to get us closer to a solution:-( The lowlevel import code uses stdio FILE * parameters all over the place, so unless newline conversion is implemented at the stdio level we will have to replace te whole import machinery by a re-implementation in Python. This is doable, all the hooks are there and there's prior art too if I'm not mistaken (IIRC someone did imports from zip files or so). > Jack, you had mentioned that you had some version of cross platform > importing working with MacPython. What do you have now? A very simple and efficient hack, for input only. The MSL stdio, that MacPython uses, always calls a lowlevel internal routine to do \r->\n mapping. MacPython now has a modified version of that routine that will pass both \r and \n as \n. No support for \r\n, though. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jwblist@olympus.net Sat Oct 6 23:48:49 2001 From: jwblist@olympus.net (John W Baxter) Date: Sat, 6 Oct 2001 15:48:49 -0700 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: <200110060220.WAA04896@cj20424-a.reston1.va.home.com> References: <20011005211107.EA877EDD23@oratrix.oratrix.nl> <200110052118.RAA04280@cj20424-a.reston1.va.home.com> <3BBE5350.E9183AA6@home.net> <200110060220.WAA04896@cj20424-a.reston1.va.home.com> Message-ID: >Just one thing: for the Python programmer, a line end should *always* >appear as \n. Files in text mode are supposed to maintain this >abstraction. You should *not* have to know that on Windows it's >really \r\n, nor that on Mac it's really \r. (BTW what is it on MacOS >X, which is Unix based?) > >--Guido van Rossum (home page: http://www.python.org/~guido/) Decimal 10 in Unix tarball Python built on Mac OS X, which seems wrong, since the result then isn't a Macintosh text file. But that claim is somewhat weak. I haven't played with MacPython under Mac OS X. [fox:~] john% python Python 2.1 (#1, 04/22/01, 11:06:25) [GCC Apple DevKit-based CPP 6.0alpha] on darwin1 Type "copyright", "credits" or "license" for more information. >>> f=open('/tmp/test.txt', 'w') >>> f.write('\n\n') >>> f.close() >>> ^D [fox:~] john% hexdump /tmp/test.txt 0000000 0a0a 0000002 [fox:~] john% -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From doug@sonosphere.com Sun Oct 7 16:29:01 2001 From: doug@sonosphere.com (Doug Wyatt) Date: Sun, 7 Oct 2001 08:29:01 -0700 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: <200110060220.WAA04896@cj20424-a.reston1.va.home.com> Message-ID: <088223BF-BB38-11D5-829E-00039301A6E6@sonosphere.com> On Friday, October 5, 2001, at 07:20 , Guido van Rossum wrote: > Just one thing: for the Python programmer, a line end should *always* > appear as \n. Files in text mode are supposed to maintain this > abstraction. You should *not* have to know that on Windows it's > really \r\n, nor that on Mac it's really \r. (BTW what is it on MacOS > X, which is Unix based?) It's whatever the developer wants it to be ... :-/ It depends on the ancestry of the code that's reading and writing files. Traditional Mac apps continue to use \r. Pretty much everything else uses \n. Doug -- Doug Wyatt work: dwyatt@apple.com (CoreAudio) personal: doug@sonosphere.com http://www.sonosphere.com "It's kind of fun to do the impossible." -- Walt Disney From bfancher@mac.com Sun Oct 7 19:37:11 2001 From: bfancher@mac.com (bill fancher) Date: Sun, 7 Oct 2001 11:37:11 -0700 Subject: [Pythonmac-SIG] OSA Python 1.0.a4 testers wanted Message-ID: <5247D666-BB52-11D5-A754-0005029E8B13@mac.com> Please contact me off-list if you are willing to help. TIA -- bill From jwight_lists@mac.com Sun Oct 7 20:59:07 2001 From: jwight_lists@mac.com (Jonathan Wight) Date: Sun, 07 Oct 2001 14:59:07 -0500 Subject: [Pythonmac-SIG] Mac OS X Python 2.2a4 Bug (_not_ Mac Python) In-Reply-To: <20011005115602.681241162D8@oratrix.oratrix.nl> Message-ID: Hey Jack, On 10/5/01 6:55 AM, "Jack Jansen" wrote: > Recently, Jonathan Wight said: >> I've downloaded and compiled the latest version of ('Unix') Python (2.2a4) >> on a Mac OS X 10.1 (5G64) and have discovered a rather serious bug. >> >> Basically you cannot have more than one version of Python running at any >> time. Try it. From Terminal.app you can launch one copy but when launching >> the second you get a Bus Error. Every time. > > I just tried this on 10.0.4 and there it works fine. So either it is a > problem with 10.1 (which I'll install some time next week, hopefully) > or it is a problem with your setup. Could you try starting the pythons > with -vv and/or under gdb and/or with the dyld debugging turned on to > see where exactly the problem occurs? Will do (I've seen this behaviour on 2 machines running 5G64 so far). I have a totally fresh Mac OS X 10.1 (5G64) box (seems all my Macs have become boxes now that I run a unix on 'em) here right now and am doing a make from scratch. Okay, got a fresh build now. When I run python.exe (configured with '--with-suffix=.exe' only) twice I still get the bus error. When I run with DYLD_PREBIND_DEBUG set I still get the bus error and both instances of Python print out "dyld: 47 two-level prebound libraries used out of 47" before any other output. If I run python with the -vv flag I get lots of info on the first instance of python and absolutely nothin on the second instance - the bus error is the first thing (aside from the dyld line) output. >> Also - if you login to Mac OS X via the console it is impossible to launch >> an interactive Python session (and probably impossible to just launch >> oneshot scripts too). When I try I get the following console errors: >> >> KCGErrorFailure: CGSNewConnection cannot connect to server >> KCGErrorFailure: CGSNewConnection cannot connect to server >> KCGErrorInvalidConnection: CGSGetEventPort: Invalid connection > > Again, on my 10.0.4 there's no problem, even in a Python with toolbox > support. I get this message only as soon as I start actually importing > Carbon modules. You didn't incidentally change your site.py or > sitecustomize.py to import macfsn or some such (I had that originally, > I had to revert to the distribution state to be able to run Python in > console mode)? Nope in all cases these are plain Pythons. Download, configure, make & install. No tinkering anywhere. I received one e-mail from someone else who is seeing this problem (but didn't see the previous one). >> I'd really like to see Python for Mac OS X (not Jack's Mac Python) be a pure >> unix implementation of Python with any Mac specific stuff in shared >> libraries. I would have assumed this would have been the case but it doesn't >> look like it is. > > I am unsure about this. Originally I thought that I would also want > that, i.e. have Python be completely untainted by any MacPython stuff, > but when I put in the few hooks (mactoolboxglue.c only, really) it > appeared to have absolutely no detrimental effects. And for me it > still doesn't (yet:-). > > If we can get command line Python to work consistently for unix work > with the few hooks left in I would now prefer that setup. The hooks > have to be shared by all Carbon modules, they contain the glue code > and some common things like an exception, and while they could > conceivable be put into another shared library shared between the > Carbon modules this would make the whole architecture more hairy > again. If I try to compile Python with the '--without-toolbox-glue' flag set I get exactly the same results. I found that the 'without-toolbox-glue' flag isn't used at all in the configure script and that the flag should actually be 'disable-toolbox-glue'. Doing a grep of the configure script proves this: [localhost:~/Desktop/Python-2.2a4] schwa% grep toolbox-glue configure --enable-toolbox-glue disable/enable MacOSX glue code for extensions" echo $ac_n "checking for --enable-toolbox-glue""... $ac_c" 1>&6 echo "configure:2932: checking for --enable-toolbox-glue" >&5 # Check whether --enable-toolbox-glue or --disable-toolbox-glue was given. So either the readme is wrong (it mentions --without-toolbox-glue explicity) or the configure script/makefiles need to be fixed. If I do compile python with --disable-toolbox-glue then I get a link error in a library (it fails to find gestalt and a PuMac_XXX function). But I can successfully run the binary it produces multiple times from the Terminal.app and in a GUI-less session... Here's the error I get when I build with --disable-toolbox-glue: skipping 'gestalt' extension (up-to-date) dyld: ./python.exe Undefined symbols: _Gestalt _PyMac_Error make: *** [sharedmods] Error 67 Jon. From csmith@blakeschool.org Mon Oct 8 20:33:50 2001 From: csmith@blakeschool.org (Christopher Smith) Date: Mon, 08 Oct 2001 14:33:50 -0500 Subject: [Pythonmac-SIG] 2.2a3 problems Message-ID: Dear SIG, I'm running into a problem when i do the self tests on 2.2a3 on both a powermac 7600 running MacOS 8.5.1 and a iMac running OS 9.1. All goes as expected (I think) until the "thread" test or something soon after it is reached. At this point, Python quits with an error 2. I've been able to determine that if the file test_long_exp.py" is taken out of the test folder that the crash does not occur. Anyone else having this problem or know what my problem might be? Here is the NONCARBON run from the iMac running 9.1 without the test_longexp.py file in the test folder: Python 2.2a3 (#107, Sep 8 2001, 01:35:57) [CW PPC GUSI2 THREADS GC] Type "copyright", "credits" or "license" for more information. MacPython IDE 1.0.1 >>> import test.regrtest ; test.regrtest.main() test_grammar test_opcodes test_operations test_builtin test_exceptions test_types test_MimeWriter test_StringIO test___all__ test___future__ test_al test test_al skipped -- No module named al test_array test_asynchat test_atexit test_audioop test_augassign test_bastion test_binascii test_binhex test_binop test_bisect test_bsddb test test_bsddb skipped -- No module named bsddb test_bufio test_call test_capi test_cd test test_cd skipped -- No module named cd test_cfgparser test_cgi test_charmapcodec test_cl test test_cl skipped -- No module named cl test_class test_cmath test_codecs test_codeop test_coercion test_commands test test_commands skipped -- Not posix; skipping test_commands test_compare test_compile test_complex test_contains test_cookie test_copy_reg test_cpickle test_crypt test test_crypt skipped -- No module named crypt test_dbm test test_dbm skipped -- No module named dbm test_descr test_descrtut The actual stdout doesn't match the expected stdout. This much did match (between asterisk lines): ********************************************************************** test_descrtut ********************************************************************** Then ... We expected (repr): '' But instead we got: '*****************************************************************\n' test test_descrtut failed -- Writing: '*****************************************************************\n', expected: '' test_difflib test_dircache test_dl test test_dl skipped -- No module named dl test_doctest test_dospath test_dumbdbm test_errno test_extcall test_fcntl test test_fcntl skipped -- No module named fcntl test_file test_fileinput test_fnmatch test_fork1 test test_fork1 skipped -- os.fork not defined -- skipping test_fork1 test_format test_fpformat test_funcattrs test_future test_gc test_gdbm test_generators test_getopt test_gettext test_gl test test_gl skipped -- No module named gl test_glob test_global test_grp test test_grp skipped -- No module named grp test_gzip test_hash test_htmlparser test_httplib test_imageop test_imgfile test test_imgfile skipped -- No module named imgfile test_import test_inspect test_iter test_largefile test test_largefile skipped -- platform does not have largefile support test_linuxaudiodev test test_linuxaudiodev skipped -- No module named fcntl test_locale test test_locale skipped -- test locale en_US not supported test_long test_long_future test_mailbox test_marshal test_math test_md5 test_mhlib test_mimetools test_mimetypes test_minidom test_mmap test test_mmap skipped -- No module named mmap test_mutants test_new test_nis test test_nis skipped -- No module named nis test_ntpath test test_ntpath skipped -- No module named nt test_openpty test test_openpty skipped -- No openpty() available. test_operator test_os test_parser test_pickle test_pkg test_pkgimport test_poll test test_poll skipped -- select.poll not defined -- skipping test_poll test_popen2 test test_popen2 skipped -- cannot import name fork test_posixpath test_pow test_pprint test_pty test test_pty skipped -- No module named termios test_pwd test test_pwd skipped -- No module named pwd test_pyclbr test_pyexpat test_quopri test_re test_regex test_repr test_rfc822 test_rgbimg test_richcmp test_rotor test_sax test_scope test_select test_sgmllib test_sha test_signal test test_signal skipped -- No module named signal test_socket test test_socket crashed -- socket.herror: (3, 'host not found') test_socket_ssl test test_socket_ssl skipped -- Use of the `network' resource not enabled test_socketserver test test_socketserver skipped -- test_socketserver can only be run manually test_sre test_strftime test_string test_strop test_struct test_sunaudiodev test test_sunaudiodev skipped -- No module named sunaudiodev test_sundry test test_sundry skipped -- No module named bsddb test_symtable test_thread test_threaded_import test test_threaded_import skipped -- can't run when import lock is held test_threadedtempfile test_threading test_time test test_time crashed -- exceptions.TypeError: not enough arguments for format string test_timing test test_timing skipped -- No module named timing test_tokenize test_traceback test_ucn test_unary test_unicode test_unicode_file test test_unicode_file skipped -- No Unicode filesystem semantics on this platform. test_unicodedata test_unpack test_urllib test_urllib2 test_urlparse test_userdict test_userlist test_userstring test_uu test_wave test_weakref test_winreg test test_winreg skipped -- No module named _winreg test_winsound test test_winsound skipped -- No module named winsound test_xmllib test_xreadline test_zipfile test_zlib test test_zlib crashed -- exceptions.MemoryError: Out of memory while decompressing data 132 tests OK. 4 tests failed: test_descrtut test_socket test_time test_zlib 34 tests skipped: test_al test_bsddb test_cd test_cl test_commands test_crypt test_dbm test_dl test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile test_linuxaudiodev test_locale test_mmap test_nis test_ntpath test_openpty test_poll test_popen2 test_pty test_pwd test_signal test_socket_ssl test_socketserver test_sunaudiodev test_sundry test_threaded_import test_timing test_unicode_file test_winreg test_winsound 1 skip unexpected on mac: test_threaded_import Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Local Apps:Python 2.2a3:Lib:test:regrtest.py", line 238, in main sys.exit(len(bad) > 0) SystemExit: 1 >>> From csmith@blakeschool.org Mon Oct 8 23:03:41 2001 From: csmith@blakeschool.org (Christopher Smith) Date: Mon, 08 Oct 2001 17:03:41 -0500 Subject: [Pythonmac-SIG] Re: 2.2a3 problems Message-ID: cjl@physics.otago.ac.nz writes: > >The long_exp and a couple of others fail due to MacOS memory management >so that is expected (see the Readme with regards to which tests) it >sounds to me like Python is running out of memory while doing the tests. >I have had this happen when Python was running on a seperate partition >from that of the OS. So if you haven't done it already try increasing >Pythons memory partition. Thanks. I thought it was something more exotic. I increased the memory from 4 M to 10 M and got the following: test test_threaded_import skipped -- can't run when import lock is held 131 tests OK. 6 tests failed: test_descrtut test_longexp test_sha test_socket test_time test_zlib 34 tests skipped: test_al test_bsddb test_cd test_cl test_commands test_crypt test_dbm test_dl test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile test_linuxaudiodev test_locale test_mmap test_nis test_ntpath test_openpty test_poll test_popen2 test_pty test_pwd test_signal test_socket_ssl test_socketserver test_sunaudiodev test_sundry test_threaded_import test_timing test_unicode_file test_winreg test_winsound 1 skip unexpected on mac: test_threaded_import Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Local Apps:Python 2.2a3:Lib:test:regrtest.py", line 238, in main sys.exit(len(bad) > 0) SystemExit: 1 It looks fine except that the test_threaded_import was skipped. /c From dpreston@intersight.com Tue Oct 9 02:24:06 2001 From: dpreston@intersight.com (Donovan Preston) Date: Mon, 8 Oct 2001 18:24:06 -0700 Subject: [Pythonmac-SIG] Grokking bgen and the toolbox modules In-Reply-To: <20011009002136.F3AE9FB04A@oratrix.oratrix.nl> Message-ID: <54D98400-BC54-11D5-999D-003065B33450@intersight.com> Hi, I'm trying to figure out how best to program some functionality which will heavily rely on the Mac OS Toolbox. I'd like to do some things with creating a QuickTime movie, adding tracks to it, etc, as well as managing controls created by Carbon from a Carbon Nib file. First off, I was looking at the sample code provided by Apple on OS X in /Developer/Examples/Carbon/AppearanceSample. It looks like they are using two toolbox calls to get a reference to a control by ID and then get it's data. It looks like this: GetControlByID( GetWindowRef(), &kChoosePopup, &fChoosePopup ); GetControlData( fChoosePopup, 0, kControlPopupButtonMenuRefTag, sizeof ( menu ), &menu, &actual ); How would I go about converting this to Python code that calls bgen generated functions? I note that there is a module named Ctl, and also that there is a function GetControlByID in there. So far so good. I note by looking at Apple's developer documentation that the parameter types are WindowRef, ControlID, and ControlRef (is there a better way to find out parameter types, like a docstring on a method? Is there a way to find this out interactively in python?) How do I generate a window reference which I can pass to this function, as well as a ControlID record? I know from looking at some other bgen code that the final parameter is actually being returned to me and python will return a nice object with the Control. I also can guess from looking at some other bgen generated code that GetControlData will be a method of the Control object which is returned. I am assuming that because I don't see GetControlData in dir(Ctl) and GetControlData takes a ControlRef as the first parameter. Am I wrong? I guess what I am asking, is how exactly is bgen generated code produced? How does it know to be so smart as to turn some things into return values and some returned data into objects? And how does one go about using bgen generated code from Python, as far as having any sort of reference or documentation, besides reading the code? (Which isn't too hard, really...) Also, Jack, you mentioned in passing a while back that you would like for some of the CarbonNib functions I had written to be generated automatically by bgen. How exactly would one go about doing that, and how would someone know what functions have and have not been done? Finally, when I was trying to create a QuickTime movie earlier, some of the parameters needed to be set to NULL, but Python wouldn't allow me to pass None. Here's the code: (resRefNum, myMovie) = Qt.CreateMovieFile(fsspec, "TVOD", smSystemScript, 0) myTrack = myMovie.NewMovieTrack(170 << 16, 85 << 16, Sound.kNoVolume); kSpriteMediaTimeScale = 600 myMedia = myTrack.NewTrackMedia("SPRT", kSpriteMediaTimeScale, None, None); I need to pass None as the final two parameters, but Python won't let me. I fixed the NewTrackMedia function by setting the third parameter conversion function (right terminology?) from ResObj_Convert, which won't accept Python's None, to OptResObj_Convert, which accepts Python's None object and returns NULL to the C code. However, the fourth parameter, which uses the conversion function PyMac_GetOSType, doesn't allow me to pass None, and I can't seem to find one that does. I gave up on trying to get the above code to work. Is it even possible? I'd like to help out maintaining these toolbox modules so I can use them in my code, but I need help understanding them first. Sorry for asking so many questions, but I feel like there's so much power there that I just can't use because I don't quite understand it! Donovan From moehl@akaflieg.extern.tu-berlin.de Tue Oct 9 12:55:55 2001 From: moehl@akaflieg.extern.tu-berlin.de (Torsten Sadowski) Date: Tue, 9 Oct 2001 13:55:55 +0200 (CEST) Subject: [Pythonmac-SIG] Tkinter on Mac In-Reply-To: Message-ID: Hi Benjamin, you should definitely look at "An Introduction to Tkinter" here: http://www.pythonware.com/library/index.htm also the tutorial files in the Python dist are a good source. Or simply get a book on Tkinter at a library. Don=B4t buy computer books. They are outdated too fast for the price. Torsten On Fri, 5 Oct 2001, Schollnick, Benjamin wrote: > Is there any good documentation and/or starting point for Tkinter / Pytho= n > programming on the Mac? >=20 > =09=09- Benjamin >=20 > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig >=20 From jack@oratrix.nl Tue Oct 9 21:44:20 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 09 Oct 2001 22:44:20 +0200 Subject: [Pythonmac-SIG] Enabling os.system() and os.popen() in MacPython on OSX Message-ID: <20011009204425.C2D4FE2677@oratrix.oratrix.nl> Folks, I just saw a message on the carbon-dev mailing list that apparently the CarbonLib SDK from Apple contains an example program called "MiniShell" that shows how to call system() (and maybe popen()?) from CFM Carbon applications on OSX. Anyone willing to look into this? It would allow us to have system() and popen() in MacPython, even if only on OSX. I don't have time to work on it, but I'll gladly accept any patches... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From jbradley@whiplashmedia.com Wed Oct 10 15:27:46 2001 From: jbradley@whiplashmedia.com (Jon Bradley) Date: Wed, 10 Oct 2001 10:27:46 -0400 Subject: [Pythonmac-SIG] Boost Python on a Mac In-Reply-To: Message-ID: Has anyone had any experience in using Booth Python to wrap C++ (large scale) and expose the underlying code? I'm working right now, as some of you know, to wrap a ton of code for embedded Python and am looking at some better means of doing it. Right now I'm using SWIG, which seems to be a pain in the arse ... to say the least. Any suggestions or examples are more than welcome. Thanks, Jon From owen@astro.washington.edu Thu Oct 11 00:47:33 2001 From: owen@astro.washington.edu (Russell E Owen) Date: Wed, 10 Oct 2001 17:47:33 -0600 Subject: [Pythonmac-SIG] Re: MacPython and line-endings Message-ID: > A wild idea (and basically why I added Guido to the cc list): file > objects could make our life a lot simpler if there was a call > file.readtoterminator(termchars, max), where termchars is a string, which > would read data up to and including a character in termchars (or until > 'max' bytes have been read). It would have to be implemented as a > getc() loop in C, but as we're going to do that looping anyway at some > point we might as well do it in C and not in Python... Wouldn't it make more sense to modify readline with a named keyword argument, e.g. "terminator"? The default would be "none" and would result in using the current platform's favorite terminator. I personally feel that judicious use of named keyword arguments can result in a nice simple structure of flexible, powerful methods, avoiding a plethora of similar-but-not-quite-the-same methods. -- Russell From doug@sonosphere.com Thu Oct 11 06:11:06 2001 From: doug@sonosphere.com (Doug Wyatt) Date: Wed, 10 Oct 2001 22:11:06 -0700 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message-ID: <60070CAE-BE06-11D5-AB20-00039301A6E6@sonosphere.com> Apologies if I'm beating a dead horse, but given that: [a] Mac OS X is a bit remarkable in that it's common to encounter all three flavors of newlines (\n created by Unix and Next-derived software, \r from traditional MacOS software, \r\n on ISO-9660 CD's, DOS floppies and Zip disks, etc.) [b] it is programmatically simple to properly read any of these three formats [c] all high-class text editors on Mac OS X (e.g. BBEdit, CodeWarrior, Project Builder) do so I think it would be best if Python were to: [1] make readline() and all other read methods on text files transparently translate \r or \r\n to \n [2] write newlines to text files using either a string member of the file object, or a global member of whatever module is appropriate (os?), defaulted to whatever is native. The implementation could always open the files in binary mode, save a flag to remember if the user had actually specified text mode, and use the flag to determine whether to perform the above translations on read and write. There might be a catch I haven't thought of ... in seek and tell? ... but that must have already been dealt with for OS's that translate \r\n to \n for text files? Doug On Wednesday, October 10, 2001, at 04:47 , Russell E Owen wrote: >> A wild idea (and basically why I added Guido to the cc list): file >> objects could make our life a lot simpler if there was a call >> file.readtoterminator(termchars, max), where termchars is a string, >> which >> would read data up to and including a character in termchars (or until >> 'max' bytes have been read). It would have to be implemented as a >> getc() loop in C, but as we're going to do that looping anyway at some >> point we might as well do it in C and not in Python... > > Wouldn't it make more sense to modify readline with a named keyword > argument, e.g. "terminator"? The default would be "none" and would > result in using the current platform's favorite terminator. > > I personally feel that judicious use of named keyword arguments can > result in a nice simple structure of flexible, powerful methods, > avoiding a plethora of similar-but-not-quite-the-same methods. -- Doug Wyatt work: dwyatt@apple.com (CoreAudio) personal: doug@sonosphere.com http://www.sonosphere.com "When you discard arrogance, complexity, and a few other things that get in the way, sooner or later you will discover that simple, childlike, and mysterious secret known to those of the Uncarved Block: Life is Fun." -- The Tao of Pooh From paul@fxtech.com Thu Oct 11 14:23:54 2001 From: paul@fxtech.com (Paul Miller) Date: Thu, 11 Oct 2001 08:23:54 -0500 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: <60070CAE-BE06-11D5-AB20-00039301A6E6@sonosphere.com> References: Message-ID: <5.1.0.14.2.20011011082151.03f1c410@cedar.he.net> >I think it would be best if Python were to: And... I missed out on the reasons why MacPython doesn't execute scripts with various flavors of line-endings, but whatever they are, I am not sure they are good enough. As a "typical user" I expect this to just work. -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From steele@alphamask.com Thu Oct 11 14:24:09 2001 From: steele@alphamask.com (Oliver Steele) Date: Thu, 11 Oct 2001 09:24:09 -0400 Subject: [Pythonmac-SIG] Re: MacPython and line-endings Message-ID: <001301c15258$032bb400$0401000a@ALPHASOLO> When I was doing a lot of cross-platform Python development a few years ago, I solved the line ending problem with a file-like wrapper class that normalized line endings into '\n', regardless of the platform you were running on and of the line ending convention that the file used. For example >>> from textopen import textopen >>> file1 = textopen(pathname) is equivalent to >>> file2 = open(pathname) except that file1.readline() will return the first line that's terminated by any of '\n' (UNIX), '\r' (MacOS), or '\r\n' (PC), whereas file2.readline() will look for a different line separator depending on the execution platform (and won't generally work for files that use a different convention). The file is at http://www.cs.brandeis.edu/~steele/sources/textopen.py. I haven't used it in several years, but it worked then :-). Oliver Steele steele@osteele.com From jakob.spies@spmtechnologies.com Thu Oct 11 15:32:50 2001 From: jakob.spies@spmtechnologies.com (Jakob Spies) Date: Thu, 11 Oct 2001 16:32:50 +0200 Subject: [Pythonmac-SIG] folder aliases Message-ID: Let x be anything that can be contained in a folder, e.g. gotten by calling os.listdir(). Is there a recommended way (on Mac OS X _and_ Classic Mac OS) of determining whether x is an alias? The difficult case is when isdir(x) is true. The function I arrived at is attached below and does not look very convincing: #parm f path #pre f is not a regular file #return whether f is an alias (which is equivalent to not being a regular folder) def isAlias(f): result = 0 try: fss = macfs.FSSpec(f) inf = fss.GetFInfo() result = inf.Flags & MACFS.kIsAlias except MacOS.Error, msg: err = msg[0] if err == macerrors.fnfErr or err == macerrors.bdNamErr: # file "does not exist" or has a bad name: # seems to be a folder pass else: raise MacOS.Error, msg return result From just@letterror.com Thu Oct 11 16:06:12 2001 From: just@letterror.com (Just van Rossum) Date: Thu, 11 Oct 2001 17:06:12 +0200 Subject: [Pythonmac-SIG] folder aliases In-Reply-To: Message-ID: <20011011170617-r01010800-5095b828-0910-010c@10.0.0.23> Jakob Spies wrote: > Let x be anything that can be contained in a folder, e.g. gotten by calling > os.listdir(). Is there a recommended way (on Mac OS X _and_ Classic Mac OS) > of determining whether x is an alias? The difficult case is when isdir(x) is > true. The function I arrived at is attached below and does not look very > convincing: I think you should use macfs.ResolveAliasFile(). Just From dpennell@guardnet.com Thu Oct 11 21:42:14 2001 From: dpennell@guardnet.com (David Pennell) Date: Thu, 11 Oct 2001 13:42:14 -0700 Subject: [Pythonmac-SIG] What slows down python? (OS X python question) In-Reply-To: Message-ID: What can make command-line python slow down? Is it simply too many modules in the home library? How can you tell what's going on with python, if it's your build? From nathan@vividworks.com Thu Oct 11 21:47:41 2001 From: nathan@vividworks.com (Nathan Heagy) Date: Thu, 11 Oct 2001 14:47:41 -0600 (CST) Subject: [Pythonmac-SIG] What slows down python? (OS X python question) In-Reply-To: Message-ID: I'm not sure, but it sure does take me a while to get python started: % time python -c "pass" 0.350u 0.160s 0:01.89 26.9% 0+0k 69+2io 0pf+0w % uname Darwin Nathan On Thu, 11 Oct 2001, David Pennell wrote: > What can make command-line python slow down? > > Is it simply too many modules in the home library? > > How can you tell what's going on with python, if it's your build? > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From sdm7g@Virginia.EDU Thu Oct 11 21:55:52 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Thu, 11 Oct 2001 16:55:52 -0400 (EDT) Subject: [Pythonmac-SIG] What slows down python? (OS X python question) In-Reply-To: Message-ID: On Thu, 11 Oct 2001, Nathan Heagy wrote: > I'm not sure, but it sure does take me a while to get python started: > > % time python -c "pass" > 0.350u 0.160s 0:01.89 26.9% 0+0k 69+2io 0pf+0w > % uname Same here: I haven't noticed that python is slow (haven't done any benchmarks either!) running, but 2.2* definitely has a much slower startup compared to either 2.0* or 2.1*. Size of the executables is significantly different: -rwxr-xr-x 1 root wheel 1807160 Jul 20 17:53 /usr/local/bin/python2.1.x -rwxr-xr-x 1 root wheel 3363136 Oct 2 14:33 /usr/local/bin/python2.2.x I don't know if that is enough in itself to explain the slow startup. Have other platforms had the same degree of bloat moving to 2.2 ? ( If not, maybe we're doing something wrong in how it's linked. ) -- Steve Majewski From nathan@vividworks.com Thu Oct 11 21:59:57 2001 From: nathan@vividworks.com (Nathan Heagy) Date: Thu, 11 Oct 2001 14:59:57 -0600 (CST) Subject: [Pythonmac-SIG] What slows down python? (OS X python question) In-Reply-To: Message-ID: > Same here: I haven't noticed that python is slow (haven't done any > benchmarks either!) running, but 2.2* definitely has a much slower > startup compared to either 2.0* or 2.1*. I wonder how much faster a statically linked python would be... Nathan From jack@oratrix.nl Thu Oct 11 22:16:45 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 11 Oct 2001 23:16:45 +0200 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message by Paul Miller , Thu, 11 Oct 2001 08:23:54 -0500 , <5.1.0.14.2.20011011082151.03f1c410@cedar.he.net> Message-ID: <20011011211650.27A6A1162D8@oratrix.oratrix.nl> Recently, Paul Miller said: > I missed out on the reasons why MacPython doesn't execute scripts with > various flavors of line-endings, but whatever they are, I am not sure they > are good enough. As a "typical user" I expect this to just work. This, indeed, is the problem we're trying to solve:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Thu Oct 11 22:15:58 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 11 Oct 2001 23:15:58 +0200 Subject: [Pythonmac-SIG] What slows down python? (OS X python question) In-Reply-To: Message by Nathan Heagy , Thu, 11 Oct 2001 14:59:57 -0600 (CST) , Message-ID: <20011011211603.A2B1DEDD23@oratrix.oratrix.nl> Recently, Nathan Heagy said: > > Same here: I haven't noticed that python is slow (haven't done any > > benchmarks either!) running, but 2.2* definitely has a much slower > > startup compared to either 2.0* or 2.1*. > > I wonder how much faster a statically linked python would be... This could well be a pointer in the right direction: OSX has this dynamic library prebinding stuff that I don't understand, and therefore ignored. ("don't understand" is a bit too strong, really, but from the documentation I didn't get a clear picture of how I should use it). I someone wants to look into this: please do so. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From donn@u.washington.edu Thu Oct 11 22:28:52 2001 From: donn@u.washington.edu (Donn Cave) Date: Thu, 11 Oct 2001 14:28:52 -0700 Subject: [Pythonmac-SIG] What slows down python? (OS X python question) Message-ID: <200110112128.f9BLSqP07325@mailhost1.u.washington.edu> Quoth "David Pennell" : | What can make command-line python slow down? | | Is it simply too many modules in the home library? | | How can you tell what's going on with python, if it's your build? I have found problems there by tracing system calls. NetBSD has a ktrace command, which you'd use most conveniently with the PID of the python process. One way to start tracing the PID ahead of time is to use something like this shell script to exec your program: runit: echo -n "$$: OK? " read junk exec "$@" $ sh runit python -c 'print "hello"' 384: OK? hello $ $ kdump The system calls cover all the I/O, which surely accounts for the vast majority of startup time. If you don't have ktrace, or something with "trace" in the name, look for something with "truss" in the name. (Obviously I haven't been near MacOS X yet.) You can probably get time stamps, with the right kdump flags. For an actual example, that turned up an unnecessary excursion through the Unicode modules no one had really intended, in a 2.0 beta that was mysteriously much slower than 1.5.2. Donn Cave, donn@u.washington.edu From jack@oratrix.nl Thu Oct 11 22:38:54 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 11 Oct 2001 23:38:54 +0200 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message by Doug Wyatt , Wed, 10 Oct 2001 22:11:06 -0700 , <60070CAE-BE06-11D5-AB20-00039301A6E6@sonosphere.com> Message-ID: <20011011213859.F1315EDD23@oratrix.oratrix.nl> The more I think about the problem the more I think it should be handled at the stdio level or slightly above it. With the current proposal of Chris Barker we get a platform independent solution with only minimal extra C code in the core, but we pay for that by having to re-implement the import logic in Python (which will again, at least for MacPython introduce new machine dependencies if we don't want to lose PYC resources and such). Suggestion: we implement a Py_UniversalFgets(char *, int, FILE *) and a Py_UniversalFread(char *, int, int, FILE *). These are then used everywhere in Python (mainly fileobject.c and the parser, I think, and I think these are the only ones used). There are now three possible implementations of these: - depending on a configure option they can be #defined as fgets() and fread() for maximal performance. - there is a machine-independent implementation using fgetc. - there may be a machine-dependent (or, actually, stdio-implementation-dependent) implementation that does horrible things like peeking into stdio data structures and doing something almost as fast as what fgets() and fread() would do. Actually the machine-dependent implementation needn't be all that dependent: you need routines that are really machine dependent for getting at the buffer pointer and the number of valid bytes there, and possibly one for getting at the pushback (ungetc) buffer, all non-destructive. The universal routines can then examine those buffers, call fread() upto buffer-end or newline and possibly convert the latter, and possibly repeat. This method would enable universal newlines for all text files, however, which may be seen as a drawback (but which I would personally see as an advantage). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido@python.org Thu Oct 11 22:39:45 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 11 Oct 2001 17:39:45 -0400 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Your message of "Thu, 11 Oct 2001 23:38:54 +0200." <20011011213859.F1315EDD23@oratrix.oratrix.nl> References: <20011011213859.F1315EDD23@oratrix.oratrix.nl> Message-ID: <200110112139.RAA00515@cj20424-a.reston1.va.home.com> > The more I think about the problem the more I think it should be > handled at the stdio level or slightly above it. > > With the current proposal of Chris Barker we get a platform > independent solution with only minimal extra C code in the core, but > we pay for that by having to re-implement the import logic in Python > (which will again, at least for MacPython introduce new machine > dependencies if we don't want to lose PYC resources and such). > > Suggestion: we implement a Py_UniversalFgets(char *, int, FILE *) and > a Py_UniversalFread(char *, int, int, FILE *). These are then used > everywhere in Python (mainly fileobject.c and the parser, I think, and > I think these are the only ones used). > > There are now three possible implementations of these: > - depending on a configure option they can be #defined as fgets() and > fread() for maximal performance. > - there is a machine-independent implementation using fgetc. > - there may be a machine-dependent (or, actually, > stdio-implementation-dependent) implementation that does horrible > things like peeking into stdio data structures and doing something > almost as fast as what fgets() and fread() would do. > > Actually the machine-dependent implementation needn't be all that > dependent: you need routines that are really machine dependent for > getting at the buffer pointer and the number of valid bytes there, and > possibly one for getting at the pushback (ungetc) buffer, all > non-destructive. The universal routines can then examine those > buffers, call fread() upto buffer-end or newline and possibly convert > the latter, and possibly repeat. > > This method would enable universal newlines for all text files, > however, which may be seen as a drawback (but which I would personally > see as an advantage). +1 I think the presence or absence of the 'b' option on file open modes should be interpreted by Python; the stdio files are always opened in 'b' mode. What do you plan to do about the seek offset and interactive input? (I think I saw a proposal for a flag "skip following \n" which makes sense to me.) --Guido van Rossum (home page: http://www.python.org/~guido/) From jack@oratrix.nl Thu Oct 11 23:05:38 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 12 Oct 2001 00:05:38 +0200 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message by Guido van Rossum , Thu, 11 Oct 2001 17:39:45 -0400 , <200110112139.RAA00515@cj20424-a.reston1.va.home.com> Message-ID: <20011011220543.D8EE2EDD23@oratrix.oratrix.nl> Recently, Guido van Rossum said: > I think the presence or absence of the 'b' option on file open modes > should be interpreted by Python; the stdio files are always opened in > 'b' mode. Yes, you're right, I forgot about that one. This isn't really needed on the Mac (where \n and \r are simply reversed) but it is needed on windows, which would do unknown things to a lone \r or \n. > What do you plan to do about the seek offset [...] No problem: fseek returns a magic cookie by definition so we can just use the underlying fseek/ftell. > [...] and interactive input? Ouch:-( > (I think I saw a proposal for a flag "skip following \n" which makes > sense to me.) Yes, but so far my thinking has been a stateless implementation, and this flag would be to be in some per-FILE*-state. Now we can get that easily in the Python infrastructure, by creating a dictionary that maps FILE* addresses to our state structures, but it'll make the calls quite a bit more expensive. Hmm: maybe the problem isn't all that serious anyway: the only place where we can find unadorned \r as lineterminator on interactive input is the MacPython console, really. And we know exactly where that is (fileno()==1 and platform==MacPython). So we can define away the problem with one extra rule: \r isn't allowed as interactive lineending with the exception of MacPython. (Python run from the unix commandline on OSX will see normal \n). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido@python.org Thu Oct 11 23:11:03 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 11 Oct 2001 18:11:03 -0400 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Your message of "Fri, 12 Oct 2001 00:05:38 +0200." <20011011220543.D8EE2EDD23@oratrix.oratrix.nl> References: <20011011220543.D8EE2EDD23@oratrix.oratrix.nl> Message-ID: <200110112211.SAA00745@cj20424-a.reston1.va.home.com> > > What do you plan to do about the seek offset [...] > > No problem: fseek returns a magic cookie by definition so we can just > use the underlying fseek/ftell. Then whenever you see a \r you must read the next char and ungetc() it of it's not a \n (except on a Mac console). Right? Because if you read through end of line and then save the file position, and later return there, you don't want to be seeing the \n that followed the \r (since you can't know that). fseek() may return a magic cookie, but the file object's tell() returns a (long) int. > > (I think I saw a proposal for a flag "skip following \n" which makes > > sense to me.) > > Yes, but so far my thinking has been a stateless implementation, and > this flag would be to be in some per-FILE*-state. Now we can get that > easily in the Python infrastructure, by creating a dictionary that > maps FILE* addresses to our state structures, but it'll make the calls > quite a bit more expensive. Hm, why not put this in the file object structure? It already has the softspace flag and various other things. > Hmm: maybe the problem isn't all that serious anyway: the only place > where we can find unadorned \r as lineterminator on interactive input > is the MacPython console, really. And we know exactly where that is > (fileno()==1 and platform==MacPython). So we can define away the > problem with one extra rule: \r isn't allowed as interactive > lineending with the exception of MacPython. (Python run from the unix > commandline on OSX will see normal \n). Yup. --Guido van Rossum (home page: http://www.python.org/~guido/) From jack@oratrix.nl Thu Oct 11 23:18:08 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 12 Oct 2001 00:18:08 +0200 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message by Guido van Rossum , Thu, 11 Oct 2001 17:39:45 -0400 , <200110112139.RAA00515@cj20424-a.reston1.va.home.com> Message-ID: <20011011221813.74938EDD23@oratrix.oratrix.nl> Recently, Guido van Rossum said: > I think the presence or absence of the 'b' option on file open modes > should be interpreted by Python; the stdio files are always opened in > 'b' mode. Hmm, another potential problem that just occurred to me: will this work for fdopen()? On the mac it will (at least with MacPython/MSL/GUSI combo we're using), but I vaguely remember having seen some platform (could be widnows, therefore) where you also have a text flag to open() and where the open() mode should match the fdopen() mode. Ah, and another problem (if I can find two in a few minutes there's probably a lot more): if we're opening files in "b" mode we can't look at the stdio textmode flag anymore to determine whether our routines should simply call the underlying fgets/fread or do their magic. And this looks like a real showstopper:-( -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido@python.org Thu Oct 11 23:17:58 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 11 Oct 2001 18:17:58 -0400 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Your message of "Fri, 12 Oct 2001 00:18:08 +0200." <20011011221813.74938EDD23@oratrix.oratrix.nl> References: <20011011221813.74938EDD23@oratrix.oratrix.nl> Message-ID: <200110112217.SAA00818@cj20424-a.reston1.va.home.com> > Hmm, another potential problem that just occurred to me: will this > work for fdopen()? On the mac it will (at least with > MacPython/MSL/GUSI combo we're using), but I vaguely remember having > seen some platform (could be widnows, therefore) where you also have a > text flag to open() and where the open() mode should match the > fdopen() mode. If a stdio file is opened in text mode, the code searching for \r would not find any, if it really was a text file. So it wouldn't do any harm. > Ah, and another problem (if I can find two in a few minutes there's > probably a lot more): if we're opening files in "b" mode we can't look > at the stdio textmode flag anymore to determine whether our routines > should simply call the underlying fgets/fread or do their magic. And > this looks like a real showstopper:-( I'm missing something. Why does your function have to work on a bare FILE * rather than on a Python file object? --Guido van Rossum (home page: http://www.python.org/~guido/) From paul@fxtech.com Thu Oct 11 23:27:25 2001 From: paul@fxtech.com (Paul Miller) Date: Thu, 11 Oct 2001 17:27:25 -0500 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: <20011011221813.74938EDD23@oratrix.oratrix.nl> References: <200110112139.RAA00515@cj20424-a.reston1.va.home.com> Message-ID: <5.1.0.14.2.20011011172413.0363aeb8@cedar.he.net> >Hmm, another potential problem that just occurred to me: will this >work for fdopen()? On the mac it will (at least with >MacPython/MSL/GUSI combo we're using), but I vaguely remember having >seen some platform (could be widnows, therefore) where you also have a >text flag to open() and where the open() mode should match the >fdopen() mode. Please forgive my ignorance: Why can't we just replace the fgets call that reads the next line for script parsing with a function that does a buffered char-by-char read until any combination of \r, \n, or \n\r is found? Pretty much all cross-platform text-file reading code does it this way. The goal is to find a line-terminator - do we *really* care what it is? -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From jack@oratrix.nl Fri Oct 12 01:42:51 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 12 Oct 2001 02:42:51 +0200 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message by Guido van Rossum , Thu, 11 Oct 2001 18:17:58 -0400 , <200110112217.SAA00818@cj20424-a.reston1.va.home.com> Message-ID: <20011012004256.EC39FEDD23@oratrix.oratrix.nl> Recently, Guido van Rossum said: > I'm missing something. Why does your function have to work on a bare > FILE * rather than on a Python file object? Sorry, I'm being less than clear. [lemme check ... pompom...] Yes. All the routines in the import chain (both in the find pass and in the execute pass) send filenames and FILE*s around. Fileobjects are nowhere to be seen. That's really the main reason for my original impression that this should be done at stdio level: all the logic that is in import.c (and importdl.c, and probably in the source command, etc) knows nothing about Python objects and uses normal C conventions. So a Python based solution (or a solution on the level of fileobjects) won't cut it if you want this to work also for scripts and modules that are imported. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Oct 12 01:52:52 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 12 Oct 2001 02:52:52 +0200 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message by Paul Miller , Thu, 11 Oct 2001 17:27:25 -0500 , <5.1.0.14.2.20011011172413.0363aeb8@cedar.he.net> Message-ID: <20011012005257.BCAD7EDD23@oratrix.oratrix.nl> Recently, Paul Miller said: > Please forgive my ignorance: Forgiven:-) > Why can't we just replace the fgets call that reads the next line for > script parsing with a function that does a buffered char-by-char read until > any combination of \r, \n, or \n\r is found? Pretty much all cross-platform > text-file reading code does it this way. The goal is to find a > line-terminator - do we *really* care what it is? Well, this is part of the problem. We also want to give a consistent picture to the world. So if the parser understands newlines when you do "import foo", you should also see newlines if your python script does open("foo.py"). Moreover, this should work not only for fp.readline() but also for fp.read(). And things are again made more difficult by interactive input: in a file you can easily look ahead whether a \r is followd by a \n (so it's a DOS linefeed) but for interactive files you don't want to do this, because if you're on a Mac and \r is end-of-line your attempt to read ahead to check whether the next char is a \n and you have a DOS linefeed and seek back will mean the program won't continue until the user has typed the first char on the next line... As usual in programming this seems to be easy to solve for 80% of the cases but the remaining 20% is important too... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From oliver.wrede@web.de Fri Oct 12 08:30:06 2001 From: oliver.wrede@web.de (Oliver Wrede) Date: Fri, 12 Oct 2001 09:30:06 +0200 Subject: [Pythonmac-SIG] MacOS X & Python 2.1 & Zope 2.4.1 Message-ID: Hello. I tried to build Zope on MacOS 10.1 following the instructions on http://www.zope.org/Members/jshell/ZopeOnOSX with the pre-build Python release from http://tony.lownds.com/macosx/ But I get this error: [...] In file included from /usr/local/include/python2.1/pyport.h:84, from /usr/local/include/python2.1/Python.h:54, from ././../Components/ExtensionClass/src/ExtensionClass.h:114, from ././../Components/ExtensionClass/src/ExtensionClass.c:61: /usr/include/math.h:191: warning: function declaration isn't a prototype cc -bundle -undefined suppress ./ExtensionClass.o -o ./ExtensionClass.so /usr/bin/ld: -undefined error must be used when -twolevel_namespace is in effect make: *** [ExtensionClass.so] Fehler 1 Traceback (most recent call last): File "wo_pcgi.py", line 117, in ? File "wo_pcgi.py", line 105, in main File "/Library/Zope/inst/build_extensions.py", line 102, in ? make('lib','python') File "/Library/Zope/inst/do.py", line 135, in make do('make') File "/Library/Zope/inst/do.py", line 104, in do if i and picky: raise SystemError, i SystemError: 512 Does anyone have an idea what is wrong? Oliver Wrede -- From steve@spvi.com Fri Oct 12 11:48:03 2001 From: steve@spvi.com (Steve Spicklemire) Date: Fri, 12 Oct 2001 05:48:03 -0500 Subject: [Pythonmac-SIG] MacOS X & Python 2.1 & Zope 2.4.1 In-Reply-To: Message-ID: <9C6AF9D8-BEFE-11D5-B22E-0050E480B13C@spvi.com> Hi Oliver, You can patch the Makefile for Python-2.1.1 with: *** 2942,2952 **** hp*|HP*) LDSHARED="ld -b";; OSF*) LDSHARED="ld -shared -expect_unresolved \"*\"";; DYNIX/ptx*) LDSHARED="ld -G";; Darwin/*|next/*) if test "$ns_dyld" ! then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; fi if test "$with_next_framework" ; then LDSHARED="$LDSHARED \$(LDLIBRARY)" fi ;; --- 2942,2952 ---- hp*|HP*) LDSHARED="ld -b";; OSF*) LDSHARED="ld -shared -expect_unresolved \"*\"";; DYNIX/ptx*) LDSHARED="ld -G";; Darwin/*|next/*) if test "$ns_dyld" ! then LDSHARED='$(CC) $(LDFLAGS) -bundle -flat_namespace -undefined suppress' else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; fi if test "$with_next_framework" ; then LDSHARED="$LDSHARED \$(LDLIBRARY)" fi ;; There were some also autoconf patches on this list for 2.2. -steve On Friday, October 12, 2001, at 02:30 AM, Oliver Wrede wrote: > > Hello. > > I tried to build Zope on MacOS 10.1 following the instructions on > > http://www.zope.org/Members/jshell/ZopeOnOSX > > with the pre-build Python release from > > http://tony.lownds.com/macosx/ > > But I get this error: > > [...] > In file included from /usr/local/include/python2.1/pyport.h:84, > from /usr/local/include/python2.1/Python.h:54, > from > ././../Components/ExtensionClass/src/ExtensionClass.h:114, > from > ././../Components/ExtensionClass/src/ExtensionClass.c:61: > /usr/include/math.h:191: warning: function declaration isn't a prototype > cc -bundle -undefined suppress ./ExtensionClass.o -o > ./ExtensionClass.so > /usr/bin/ld: -undefined error must be used when -twolevel_namespace is > in effect > make: *** [ExtensionClass.so] Fehler 1 > Traceback (most recent call last): > File "wo_pcgi.py", line 117, in ? > File "wo_pcgi.py", line 105, in main > File "/Library/Zope/inst/build_extensions.py", line 102, in ? > make('lib','python') > File "/Library/Zope/inst/do.py", line 135, in make > do('make') > File "/Library/Zope/inst/do.py", line 104, in do > if i and picky: raise SystemError, i > SystemError: 512 > > > Does anyone have an idea what is wrong? > > > Oliver Wrede > > -- > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From guido@python.org Fri Oct 12 12:51:17 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 12 Oct 2001 07:51:17 -0400 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Your message of "Fri, 12 Oct 2001 02:42:51 +0200." <20011012004256.EC39FEDD23@oratrix.oratrix.nl> References: <20011012004256.EC39FEDD23@oratrix.oratrix.nl> Message-ID: <200110121151.HAA02503@cj20424-a.reston1.va.home.com> > Sorry, I'm being less than clear. [lemme check ... pompom...] > Yes. All the routines in the import chain (both in the find pass and > in the execute pass) send filenames and FILE*s around. Fileobjects are > nowhere to be seen. > > That's really the main reason for my original impression that this > should be done at stdio level: all the logic that is in import.c (and > importdl.c, and probably in the source command, etc) knows nothing > about Python objects and uses normal C conventions. So a Python based > solution (or a solution on the level of fileobjects) won't cut it if > you want this to work also for scripts and modules that are imported. Aha. But here we have a subset of the original problem: there's no interactive reading, and no seeking. --Guido van Rossum (home page: http://www.python.org/~guido/) From Benjamin.Schollnick@usa.xerox.com Fri Oct 12 13:06:34 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 12 Oct 2001 08:06:34 -0400 Subject: [Pythonmac-SIG] Re: Mac Python and line-endings Message-ID: Jack, I've got to slightly disagree... but only slightly. On the Mac console, you will only be receiving \r eol's, unless the user explicitly goes out of his way to "manually" prepend a \n .... Which I'm not even sure that there is a mechanism to allow that, but that's a different story. So, I don't see where a "universal" linefeed would help in the console window, which means we can safely work around any problems in the Mac console window.... And probably to a lesser degree in the MOX (Mac OS X) terminal windows. In other words, in the console/terminal mode, search for os.linesep as the line terminator, otherwise we fall back to the universal routines (assuming we're not in interactive mode). Can anyone think of a reasonable reason that the universal linesep routines would be needed in the interactive mode? Honestly, the only reason I can think of, is doing a cut 'n paste from BBEdit or another text editor. But it's just common sense that the interactive mode would require the OS level line separator... After all how would I type in \n\r into a interactive window from the Keyboard. (BTW-> I didn't forward this to Guido, just to Jack & Paul... so if this makes sense (I'm not claiming it does >g<), feel free to point it out to the others so that your conversation "thread" doesn't get to confused.) - Benjamin ("Hopefully making some sense here") -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Thursday, October 11, 2001 8:53 PM To: Paul Miller Cc: Jack Jansen; Guido van Rossum; Doug Wyatt; Russell E Owen; Mac Python mailing list Subject: Re: [Pythonmac-SIG] Re: MacPython and line-endings Recently, Paul Miller said: > Please forgive my ignorance: Forgiven:-) > Why can't we just replace the fgets call that reads the next line for > script parsing with a function that does a buffered char-by-char read until > any combination of \r, \n, or \n\r is found? Pretty much all cross-platform > text-file reading code does it this way. The goal is to find a > line-terminator - do we *really* care what it is? Well, this is part of the problem. We also want to give a consistent picture to the world. So if the parser understands newlines when you do "import foo", you should also see newlines if your python script does open("foo.py"). Moreover, this should work not only for fp.readline() but also for fp.read(). And things are again made more difficult by interactive input: in a file you can easily look ahead whether a \r is followd by a \n (so it's a DOS linefeed) but for interactive files you don't want to do this, because if you're on a Mac and \r is end-of-line your attempt to read ahead to check whether the next char is a \n and you have a DOS linefeed and seek back will mean the program won't continue until the user has typed the first char on the next line... As usual in programming this seems to be easy to solve for 80% of the cases but the remaining 20% is important too... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From paul@fxtech.com Fri Oct 12 14:32:59 2001 From: paul@fxtech.com (Paul Miller) Date: Fri, 12 Oct 2001 08:32:59 -0500 Subject: [Pythonmac-SIG] Re: Mac Python and line-endings In-Reply-To: Message-ID: <5.1.0.14.2.20011012083158.031a7518@cedar.he.net> > On the Mac console, you will only be receiving \r eol's, > unless the user explicitly goes out of his way to "manually" > prepend a \n .... Which I'm not even sure that there is a mechanism > to allow that, but that's a different story. I have to agree. I find it hard to imagine the problem really being as difficult as it sounds. Interactive console is a different beast than script parsing from a file, which I have to insist is also different from just seeking around in text files. The script parsing can be much more tightly controlled. -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From jack@oratrix.nl Fri Oct 12 15:41:57 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 12 Oct 2001 16:41:57 +0200 Subject: [Pythonmac-SIG] Re: Mac Python and line-endings In-Reply-To: Message by Paul Miller , Fri, 12 Oct 2001 08:32:59 -0500 , <5.1.0.14.2.20011012083158.031a7518@cedar.he.net> Message-ID: <20011012144158.558B6303181@snelboot.oratrix.nl> > > > On the Mac console, you will only be receiving \r eol's, > > unless the user explicitly goes out of his way to "manually" > > prepend a \n .... Which I'm not even sure that there is a mechanism > > to allow that, but that's a different story. > > I have to agree. I also completely agree. But: the original email discussed an implementation where we would globally replace the C fgets() and fread() functions, and on that level it seemed to be difficult. But it turned out not to be difficult (as I think I explained in a later email) because we can check for fileno(fp) == 1. Please keep the input coming, I'll try and find time to summarize and come up with a new proposal later tonight. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Oct 12 21:58:05 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 12 Oct 2001 22:58:05 +0200 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Message by Guido van Rossum , Fri, 12 Oct 2001 07:51:17 -0400 , <200110121151.HAA02503@cj20424-a.reston1.va.home.com> Message-ID: <20011012205810.B56E6FB04B@oratrix.oratrix.nl> Recently, Guido van Rossum said: > > That's really the main reason for my original impression that this > > should be done at stdio level: all the logic that is in import.c (and > > importdl.c, and probably in the source command, etc) knows nothing > > about Python objects and uses normal C conventions. So a Python based > > solution (or a solution on the level of fileobjects) won't cut it if > > you want this to work also for scripts and modules that are imported. > > Aha. But here we have a subset of the original problem: there's no > interactive reading, and no seeking. Ok, here's my strawman solution. char *Py_UniversalNewlineFgets(char *, int, FILE*, PyObject *); size_t Py_UniversalNewlineFread(void *, size_t, size_t, FILE *, PyObject *); The last argument can be either NULL or a PyObject, the FILE* should be opened in binary mode. If the routines encounter a \r they do one of two things. If the last argument is NULL they read the next char and either gobble it up if it's a \n or ungetc() it. If the FileObject is available they don't peek ahead but they set the skipinitialnewline flag in the file object in stead. Of course they also honour that flag in this case. Parser.c and the import code and any other interested party can use these routines to get universal newline support. fileobject.c always calls these routines with the object parameter. file.seek() also clears the flag, as does writing. BUT: if a FILE* is ever fseek()ed without our knowledge we are hosed. We could provide a Py_UniversalNewlineFseek(..., PyObject *) but if the FILE* from a FileObject is passed to, say, a third party library we're still hosed. I thought of storing the ftell() value in the skipinitialnewline flag (with -1 meaning "don't skip") but that won't fly because of interactive input. I think we'll just have to live with this, all fseek()s outside fileobject.c are on binary files, AFAICT. By having state in the FileObject we could add another feature I would like very much (but feel free to accuse me of feeping creaturism and shoot it down): a flag indicating what the newline convention was so far. The values would be unknown, cr, lf, crlf and mixed. (implementations of these values could well be 0, 1, 2, 4 and anything else:-). As was noted here previously Mac text editors tend to be "newline convention preserving" and this flag would make that easy to implement. Sigh, it looks like I've done a large part of the PEP already:-( -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido@python.org Fri Oct 12 21:59:16 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 12 Oct 2001 16:59:16 -0400 Subject: [Pythonmac-SIG] Re: MacPython and line-endings In-Reply-To: Your message of "Fri, 12 Oct 2001 22:58:05 +0200." <20011012205810.B56E6FB04B@oratrix.oratrix.nl> References: <20011012205810.B56E6FB04B@oratrix.oratrix.nl> Message-ID: <200110122059.QAA17292@cj20424-a.reston1.va.home.com> Looks like the next step is a patch to sourceforge, and a pointer to that posted to python-dev. --Guido van Rossum (home page: http://www.python.org/~guido/) From stephenm@humongous.com Mon Oct 15 18:05:35 2001 From: stephenm@humongous.com (Magladry, Stephen) Date: Mon, 15 Oct 2001 10:05:35 -0700 Subject: [Pythonmac-SIG] Re: MacPython and line-endings Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE589@sea-horse.humongous.com> It appears the solution seems to be aimed at per platform line-ending solution. As someone who works in a Window/Mac development environment, using Code Warrior on the Mac, I commonly get a warning when opening a file about inconsistent line endings. I would think this problem might become more prevalent as more platforms work on a common code base. Is this problem on inconsistent line endings within the same file being addressed with this solution? -----Original Message----- From: Guido van Rossum [mailto:guido@python.org] Sent: Friday, October 12, 2001 1:59 PM To: Jack Jansen Cc: Doug Wyatt; Russell E Owen; Mac Python mailing list Subject: Re: [Pythonmac-SIG] Re: MacPython and line-endings Looks like the next step is a patch to sourceforge, and a pointer to that posted to python-dev. --Guido van Rossum (home page: http://www.python.org/~guido/) From chrishbarker@home.net Mon Oct 15 22:07:10 2001 From: chrishbarker@home.net (Chris Barker) Date: Mon, 15 Oct 2001 14:07:10 -0700 Subject: [Pythonmac-SIG] Re: MacPython and line-endings References: <20011011213859.F1315EDD23@oratrix.oratrix.nl> Message-ID: <3BCB4FFE.5542D500@home.net> Jack Jansen wrote: > The more I think about the problem the more I think it should be > handled at the stdio level or slightly above it. > > With the current proposal of Chris Barker we get a platform > independent solution with only minimal extra C code in the core, but Actually, my current proposal was not about the implimentation, it was onlyh intended to be a proposal about what functionality should exist. the Python prototype is intended to provide a model for the proposed API for the new file type, and, in the meantime, provide a usefull class for users files. > we pay for that by having to re-implement the import logic in Python > (which will again, at least for MacPython introduce new machine > dependencies if we don't want to lose PYC resources and such). I am not the lest bit qualified to make judgments about this, I just want it to work one way or the other. The last time this was bandied about python-dev, the conclusion that we seemed to be arriving at was exactly what you say: a re-implimentation of part of stdio, which also seemed to be a larger project than anyone wanted to undertake? The only reason I recall for going that low level was performance, which I think is a secondary concern, but you seem to have found a new one. > This method would enable universal newlines for all text files, > however, which may be seen as a drawback (but which I would personally > see as an advantage). This is a problem for *nix code which opens a file as a text file (the default), but really intends it to be binary. For backward compatability, there needs to be a version of the regular old platform dependent text file around. (or maybe just for *nix, which would just be a binary file...) Paul Miller wrote: > Why can't we just replace the fgets call that reads the next line for > script parsing with a function that does a buffered char-by-char read until > any combination of \r, \n, or \n\r is found? Pretty much all cross-platform > text-file reading code does it this way. The goal is to find a > line-terminator - do we *really* care what it is? There may be other reasons, but one reason this was rejected a while ago was performance: Python has recently been performance tuned to be a lot faster for line oriented text file reading, and using the native fgets was part of this. Jack Jansen wrote: > Sigh, it looks like I've done a large part of the PEP already:-( Why the Sigh? This is great!!! I'm really glad you and Guido have taken some time to think about this!! Guido van Rossum wrote: > Looks like the next step is a patch to sourceforge, and a pointer to > that posted to python-dev. How about a draft PEP? Can I help with that?? (I'll be useless at helping with implimentation) "Magladry, Stephen" wrote: > I commonly get a warning when opening a file > about inconsistent line endings. I would think this problem might become > more prevalent as more platforms work on a common code base. Is this problem > on inconsistent line endings within the same file being addressed with this > solution? Probably. It has been brought up in the past, and there seems to be consensus that the universal text file reader should be able to handle mixed line endings as well. Jack and Guido: What can I do to help?? -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From sdm7g@minsky.med.virginia.edu Mon Oct 15 23:06:06 2001 From: sdm7g@minsky.med.virginia.edu (Steven D. Majewski) Date: Mon, 15 Oct 2001 18:06:06 -0400 (EDT) Subject: [Pythonmac-SIG] FYI: Aqua Tcl/Tk (fwd) Message-ID: ---------- Forwarded message ---------- Date: Mon, 15 Oct 2001 12:05:00 -0700 From: Jim Ingham To: darwin-development@lists.apple.com Subject: Aqua Tcl/Tk H, all, I am not sure it is entirely germane to this list, but since people have asked several times, I thought I would announce here that Apple has finished the first cut of a native Aqua port of Tcl/Tk for MacOS X. Of course, for those of you who use XFree in one form or another, Tk already compiles pretty trivially there. This is only for those who want a native Aqua version. The code and ongoing development will be hosted at the SourceForge Tcl/Tk repository. Apple's contributions are made under the same BSD license as the rest of Tcl/Tk. There are instructions on the main tcl page (tcl.sourceforge.net) for getting the code via cvs. The MacOS X port is currently on a branch (macosx-8-4-branch). I will work to get this accepted to the main line as quickly as I can. If you have a Source Forge account already, you just need to do: cvs -d :pserver:anonymous@cvs.tcl.sourceforge.net:/cvsroot/tcl co -r macosx-8-4-branch tcl and cvs -d :pserver:anonymous@cvs.tktoolkit.sourceforge.net:/cvsroot/tktoolkit co -r macosx-8-4-branch tk There are also binaries of the Wish application, and the Tcl & Tk libraries packaged as frameworks, look in the released files section of the Tcl page mentioned above. I posted some longer notes on how to compile & run the thing, both to comp.lang.tcl, and to the MacTcl mailing list (hosted also at SourceForge). I don't do any work on either PerlTk, or TkInter myself, but if there are folks out there who are interested in getting the Aqua port to work with either of these modules, I would be more than happy to help them. Enjoy, Jim _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Jim Ingham jingham@apple.com Developer Tools - gdb _______________________________________________ darwin-development mailing list darwin-development@lists.apple.com http://www.lists.apple.com/mailman/listinfo/darwin-development From nathan@vividworks.com Mon Oct 15 23:31:29 2001 From: nathan@vividworks.com (Nathan Heagy) Date: Mon, 15 Oct 2001 16:31:29 -0600 (CST) Subject: [Pythonmac-SIG] FYI: Aqua Tcl/Tk (fwd) In-Reply-To: Message-ID: This sounds really good =) Nathan On Mon, 15 Oct 2001, Steven D. Majewski wrote: > > > ---------- Forwarded message ---------- > Date: Mon, 15 Oct 2001 12:05:00 -0700 > From: Jim Ingham > To: darwin-development@lists.apple.com > Subject: Aqua Tcl/Tk > > H, all, > > I am not sure it is entirely germane to this list, but since people have > asked several times, I thought I would announce here that Apple has > finished the first cut of a native Aqua port of Tcl/Tk for MacOS X. Of > course, for those of you who use XFree in one form or another, Tk > already compiles pretty trivially there. This is only for those who > want a native Aqua version. > > The code and ongoing development will be hosted at the SourceForge > Tcl/Tk repository. Apple's contributions are made under the same BSD > license as the rest of Tcl/Tk. There are instructions on the main tcl > page (tcl.sourceforge.net) for getting the code via cvs. The MacOS X > port is currently on a branch (macosx-8-4-branch). I will work to get > this accepted to the main line as quickly as I can. > > If you have a Source Forge account already, you just need to do: > > cvs -d :pserver:anonymous@cvs.tcl.sourceforge.net:/cvsroot/tcl co -r > macosx-8-4-branch tcl > > and > > cvs -d > :pserver:anonymous@cvs.tktoolkit.sourceforge.net:/cvsroot/tktoolkit co > -r macosx-8-4-branch tk > > There are also binaries of the Wish application, and the Tcl & Tk > libraries packaged as frameworks, look in the released files section of > the Tcl page mentioned above. > > I posted some longer notes on how to compile & run the thing, both to > comp.lang.tcl, and to the MacTcl mailing list (hosted also at > SourceForge). > > I don't do any work on either PerlTk, or TkInter myself, but if there > are folks out there who are interested in getting the Aqua port to work > with either of these modules, I would be more than happy to help them. > > Enjoy, > > Jim > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- > Jim Ingham > jingham@apple.com > Developer Tools - gdb > _______________________________________________ > darwin-development mailing list > darwin-development@lists.apple.com > http://www.lists.apple.com/mailman/listinfo/darwin-development > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From guido@python.org Tue Oct 16 01:50:04 2001 From: guido@python.org (Guido van Rossum) Date: Mon, 15 Oct 2001 20:50:04 -0400 Subject: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) Message-ID: <200110160050.UAA04855@cj20424-a.reston1.va.home.com> ------- Forwarded Message Date: Mon, 15 Oct 2001 17:55:21 -0500 From: Cameron Laird To: guido@python.org, nick.ing-simmons@elixent.com, lusol@Pandora.CC.Lehig h.ED cc: Subject: ANNOUNCE: Tcl/Tk for Mac OS X (fwd) Pass the word. - ------- start of forwarded message ------- From: jingham@apple.com (Jim Ingham) Newsgroups: comp.lang.tcl.announce,comp.lang.tcl Subject: ANNOUNCE: Tcl/Tk for Mac OS X Followup-To: comp.lang.tcl Date: 15 Oct 2001 12:31:10 -0700 Organization: Apple Computer, Inc. Lines: 208 Approved: tcl-announce@mitchell.org Message-ID: NNTP-Posting-Host: non.non.net X-Trace: maxwell.emf.net 1003174415 7402 205.217.47.130 (15 Oct 2001 19:33:35 G MT) X-Complaints-To: news@news2.emf.net NNTP-Posting-Date: 15 Oct 2001 19:33:35 GMT X-Original-Trace: news.apple.com 1003143020 5594 17.254.160.31 (15 Oct 2001 10: 50:20 GMT) X-Original-Complaints-To: usenet@news.apple.com X-Original-NNTP-Posting-Date: 15 Oct 2001 10:50:20 GMT User-Agent: NewsWatcher-X 2.2.3b1 X-Auth: PGPMoose V1.1 PGP comp.lang.tcl.announce iQCVAwUAO8s5dMVCYQpvzJ9ZAQFgvwP+NcUxI9hTf2V7kYrzKf4dxXq6Xs76y59w HYOPmwSE4W5bHNrttq56sx7H1EQpF6VFom8ffQJnoKI03B4OTUq1N1oznnXvqEAl 5ql/oC7SBkxEe6oN0TCgsCzb4mpL9JMLQLRVi9E+MUHrzJDsODAWouSCALVbqpEZ k3qW4C46+us= =JV3M Xref: news-f.iadfw.net comp.lang.tcl.announce:1932 comp.lang.tcl:191234 Hi, all... With a lot of support from Apple, I have at long last a fairly workable port of Tk for Mac OS X. The sources are currently on a branch off of the Tcl/Tk 8.4a4 branch, the branch name is: macosx-8-4-branch Go to the SourceForge Tcl headquarters for more details, at: http://tcl.sourceforge.net I also put a binary snapshot of Wish and the Tcl & Tk Frameworks in the SourceForge release, under the package name "Mac OS X Tk Snapshots". You can get to this by looking at the page: http://sourceforge.net/projects/tcl/ and look for Latest File Releases. Probably should have put this in the Tk site instead, Doh! I am just getting used to SourceForge. SO HOW DO I USE THIS STUFF: ======================================== First for the binaries... The snapshot is just a gzipped tar file, that has the structure: Applications/Wish Shell.app ... Library/Frameworks/Tcl.framework ... Library/Frameworks/Tk.framework ... So you can either untar this in / - to make an installation that is available to all users on your machine, or in ~ to make one useable only to you. In any case, just double-click on Wish Shell.app to get started. You will probably also want to change the files to make them owned by you... In fact, you can move things around even more than this. The Frameworks just need to be in one of the system paths (/Library/Frameworks, /System/Library/Frameworks, or ~/Library/Frameworks) to be found automatically by dyld. Or you can put them somewhere else and set DYLD_FRAMEWORK_PATH to point to that location. After that, you can put "Wish Shell.app" pretty much anywhere you want. One other little trick about the "Wish Shell.app" that may come in handy. If you put a file called "AppMain.tcl" inside the "Wish Shell.app" package, in the folder: Wish Shell.app/Contents/Resources/Scripts then that will be sourced in as if you had given it as the first argument on the command-line in Unix, or equivalently had made a D&D Tclet with that file on the Mac. The Mac OS X version goes one better, because the Scripts directory is also added to the auto_path, so you can put your script libraries there, and they will be found as well. The "Wish Shell.app" uses the same console that the Windows & Mac ports use. However, if you want to use a terminal console for some reason, then just do: $ ./Wish Shell.app/Contents/MacOS/Wish Shell" in Terminal.app, and it will use the Terminal window instead of the Tk based one. There is some support for the Custom MDEF that Tk used on MacOS X, but it is pretty rough right now, so I have turned it off by default. If you want to play with this, do: set ::tk::mac::useCustomMDEF 1 somewhere BEFORE you create your menus, it will only affect menus made after you change the setting. The default setting is done at the end of tk.tcl in the Resources/Scripts folder in the Tk framework, so you can also just reverse this setting there to make Wish always use the custom MDEF. These binaries were built on Mac OS X - 10.1. There is no obvious reason why they wouldn't run on 10.0, but I haven't run that in quite a long time, so I won't guarantee there aren't any little hitches. 10.1 is SO much nicer than 10.0, however, that I am not inclined to spend much time supporting it. ======================================== Next the source: As I said, the sources are on the SourceForge CVS repositories, the branch name is macosx-8-4-branch. The projects expect tcl & tk to be in the same folder, so like: ./source source/tcl source/tk If they are not set up like this, you will have to go muck with the include paths in the project. Tcl: On the Tcl side, there aren't many changes. I added a MacOS X directory, but all it contains at present is a Project Builder project that will build Tcl in the way that Wish currently expects it to be built. You can also build the Tcl in this distribution with the standard configure/make. But I haven't added the ability to auto-magically build the Framework from the Makefile. That is what the PB Project is for. The one special thing to note is that Wish requires that you build the --enable-thread version of Tcl. I haven't put in any checks to make sure you do this yet, but it will fail pretty much straight off the bat if you don't, so... This was required to wait on Tcl "select" based sources and still keep Carbon waiting on the App Main Thread as Ed intended. I also want to migrate the AppleScript and Resource goodies from the Classic Mac side to MacOS X, and also add an interface to the CFBundle API's (which I am now using hackily in tclUnixInit.c). But I haven't gotten around to that yet. Tk: Tk has the majority of the changes, as you would expect. There are not any really substantial changes in the generic folder, there are some in the library code, mostly because a lot of it assumes tcl_platform(platform) == unix means you are using X11, which is not the case for MacOS X. Other that that, the code in the macosx folder is the interesting bits. It is a pretty straight Carbonization of the Classic Mac code, but I also took advantage of the opportunity to toss alot of the cruft from supporting earlier versions of MacOS, and to rework the code to be a little more to my liking. I didn't try to rework the Unix Makefiles to support building Wish on MacOS X. In part this was because there weren't many similarities between the Unix & Mac OS X Makefiles, but mostly because I wanted to use Project Builder, since I actually like GUI development environments. If someone with the opposite bent wants to hack up some Makefiles, I would be happy to accept the changes. The only trick to building Tcl & Wish is to set the Product directories for the Tcl.pbproj and Wish.pbproj to the same directory (either in the PB Global preferences, or in the super-secret Project specific preferences that you find by selecting the Project entry in the File tree, and doing "Show Info".) Then build the topmost Tcl agregate target, and then build the Wish Target. In a couple of days I will get together a list of "current and future projects" in case anyone is interested in helping. There is a SourceForge task manager that should be a good venue for this. There is lots of fun stuff still to do, by the way, including converting from QuickDraw to CoreGraphics for the low-level drawing code - so we can get nice looking line drawing onthe canvas, finally... And using ATSUI, so we can get the sweet anti-aliased fonts. Extensions: To tell the truth, I only started playing around seriously with packaging all this stuff up in Frameworks & App Packages in the past couple of weeks. I think the structure offers a lot of promise, but I haven't worked on porting extensions yet, so there will probably be some refinements to make this easier as time goes on. If you have a standard Tcl (not Tk) extension, the way Tcl.pbproj builds things is a pretty good model. It shows how to build frameworks from a Makefile based approach without having to hack up your Makefiles too badly. I would like to figure out a way to do this more generally within the TEA structure, while still getting to use PB, and inflicting the least pain on other extension writers. But I've only just started thinking about this part. Well, there are probably a lot more little stumbling blocks that I am forgetting, but it is late, and I am sure you will all remind me of them in due course. One thing I can't omit, however, is a big THANKS to Apple, who let me work with this in spite of my having another day job, to Dave Payne, my manager, who supported this project even when gdb needed all the coddling we could give it, to Sergio Mello from Apple DTS who found the resources to hire Ian Reid to help out with this for the past 6 months, and to Ian, who did all the dog work while I mostly got to say "Well, I think it should work like..." Sometimes it even did... Jim Ingham Apple Computer, Inc. - -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Jim Ingham jingham@apple.com Developer Tools - gdb [[Send Tcl/Tk announcements to tcl-announce@mitchell.org Send administrivia to tcl-announce-request@mitchell.org Announcements archived at http://groups.yahoo.com/group/tcl_announce/ The primary Tcl/Tk archive is ftp://ftp.neosoft.com/pub/tcl/ ]] - ------- end of forwarded message ------- - -- Cameron Laird Business: http://www.Phaseit.net Personal: http://starbase.neosoft.com/~claird/home.html ------- End of Forwarded Message From tony@metanet.com Tue Oct 16 02:30:30 2001 From: tony@metanet.com (Tony Lownds) Date: Mon, 15 Oct 2001 18:30:30 -0700 Subject: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) In-Reply-To: <200110160050.UAA04855@cj20424-a.reston1.va.home.com> References: <200110160050.UAA04855@cj20424-a.reston1.va.home.com> Message-ID: --============_-1208926656==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I've had some initial success compiling Tkinter by following this recipe: 1. download and install as per below: > >I also put a binary snapshot of Wish and the Tcl & Tk Frameworks in >the SourceForge release, under the package name "Mac OS X Tk >Snapshots". You can get to this by looking at the page: > >http://sourceforge.net/projects/tcl/ > >and look for Latest File Releases. Probably should have put this in >the Tk site instead, Doh! I am just getting used to SourceForge. 2. sudo tar -zxf MacOSXTk8.4a4.tar.gz -C / 3. checkout the tk sources 4. cp -r tk/xlib/X11 /Library/Frameworks/Tk.framework/Headers/ 5. go to your freshly compiled CVS checkout of Python: cd python/dist/src I used ./configure --with-suffix=.exe --enable-framework 6. cat > Setup.local # Edit this file for local setup changes *shared* _tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \ -framework Tcl -framework Tk \ -I/Library/Frameworks/Tcl.framework/Headers/ \ -I/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders/ \ -I/Library/Frameworks/Tk.framework/Headers/ \ -I/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders/ ^D 7. make 8. ./python.exe Demo/tkinter/guido/hello.py I'm posting this in the hope that others can make the process better. -Tony > >SO HOW DO I USE THIS STUFF: > >======================================== >First for the binaries... > >The snapshot is just a gzipped tar file, that has the structure: > >Applications/Wish Shell.app > ... >Library/Frameworks/Tcl.framework > ... >Library/Frameworks/Tk.framework > ... > >So you can either untar this in / - to make an installation that is >available to all users on your machine, or in ~ to make one useable >only to you. In any case, just double-click on Wish Shell.app to get >started. You will probably also want to change the files to >make them owned by you... > >In fact, you can move things around even more than this. The Frameworks >just need to be in one of the system paths (/Library/Frameworks, >/System/Library/Frameworks, or ~/Library/Frameworks) to be found >automatically by dyld. Or you can put them somewhere else and set >DYLD_FRAMEWORK_PATH to point to that location. > >After that, you can put "Wish Shell.app" pretty much anywhere you >want. > >One other little trick about the "Wish Shell.app" that may come in >handy. If you put a file called "AppMain.tcl" inside the "Wish >Shell.app" package, in the folder: > >Wish Shell.app/Contents/Resources/Scripts > >then that will be sourced in as if you had given it as the first >argument on the command-line in Unix, or equivalently had made a D&D >Tclet with that file on the Mac. The Mac OS X version goes one >better, because the Scripts directory is also added to the auto_path, >so you can put your script libraries there, and they will be found as >well. > >The "Wish Shell.app" uses the same console that the Windows & Mac >ports use. However, if you want to use a terminal console for some >reason, then just do: > >$ ./Wish Shell.app/Contents/MacOS/Wish Shell" > >in Terminal.app, and it will use the Terminal window instead of the Tk >based one. > >There is some support for the Custom MDEF that Tk used on MacOS X, but >it is pretty rough right now, so I have turned it off by default. If >you want to play with this, do: > >set ::tk::mac::useCustomMDEF 1 > >somewhere BEFORE you create your menus, it will only affect >menus made after you change the setting. The default setting is done >at the end of tk.tcl in the Resources/Scripts folder in the Tk >framework, so you can also just reverse this setting there to make >Wish always use the custom MDEF. > >These binaries were built on Mac OS X - 10.1. There is no obvious reason >why they wouldn't run on 10.0, but I haven't run that in quite a long >time, so I won't guarantee there aren't any little hitches. 10.1 is SO >much nicer than 10.0, however, that I am not inclined to spend much time >supporting it. > >======================================== >Next the source: > >As I said, the sources are on the SourceForge CVS repositories, the >branch name is macosx-8-4-branch. The projects expect tcl & tk to be >in the same folder, so like: > >./source > source/tcl > source/tk > >If they are not set up like this, you will have to go muck with the >include paths in the project. > >Tcl: > >On the Tcl side, there aren't many changes. I added a MacOS X >directory, but all it contains at present is a Project Builder project >that will build Tcl in the way that Wish currently expects it to be >built. You can also build the Tcl in this distribution with the >standard configure/make. But I haven't added the ability to >auto-magically build the Framework from the Makefile. That is what >the PB Project is for. > >The one special thing to note is that Wish requires that you build >the --enable-thread version of Tcl. I haven't put in any checks to >make sure you do this yet, but it will fail pretty much straight off >the bat if you don't, so... This was required to wait on Tcl "select" >based sources and still keep Carbon waiting on the App Main Thread as >Ed intended. > >I also want to migrate the AppleScript and Resource goodies from the >Classic Mac side to MacOS X, and also add an interface to the CFBundle >API's (which I am now using hackily in tclUnixInit.c). But I haven't >gotten around to that yet. > >Tk: > >Tk has the majority of the changes, as you would expect. There are >not any really substantial changes in the generic folder, there are >some in the library code, mostly because a lot of it assumes >tcl_platform(platform) == unix means you are using X11, which is not >the case for MacOS X. > >Other that that, the code in the macosx folder is the interesting >bits. It is a pretty straight Carbonization of the Classic Mac code, >but I also took advantage of the opportunity to toss alot of the cruft >from supporting earlier versions of MacOS, and to rework the code to >be a little more to my liking. > >I didn't try to rework the Unix Makefiles to support building Wish on >MacOS X. In part this was because there weren't many similarities >between the Unix & Mac OS X Makefiles, but mostly because I wanted to >use Project Builder, since I actually like GUI development >environments. If someone with the opposite bent wants to hack up some >Makefiles, I would be happy to accept the changes. > >The only trick to building Tcl & Wish is to set the Product >directories for the Tcl.pbproj and Wish.pbproj to the same directory >(either in the PB Global preferences, or in the super-secret Project >specific preferences that you find by selecting the Project entry in >the File tree, and doing "Show Info".) Then build the topmost Tcl >agregate target, and then build the Wish Target. > >In a couple of days I will get together a list of "current and future >projects" in case anyone is interested in helping. There is a SourceForge >task manager that should be a good venue for this. There is lots of fun >stuff still to do, by the way, including converting from QuickDraw to >CoreGraphics for the low-level drawing code - so we can get nice looking >line drawing onthe canvas, finally... And using ATSUI, so we can get the >sweet anti-aliased fonts. > >Extensions: > >To tell the truth, I only started playing around seriously with >packaging all this stuff up in Frameworks & App Packages in the past >couple of weeks. I think the structure offers a lot of promise, but I >haven't worked on porting extensions yet, so there will probably be >some refinements to make this easier as time goes on. > >If you have a standard Tcl (not Tk) extension, the way Tcl.pbproj >builds things is a pretty good model. It shows how to build >frameworks from a Makefile based approach without having to hack up >your Makefiles too badly. > >I would like to figure out a way to do this more generally within the >TEA structure, while still getting to use PB, and inflicting the least >pain on other extension writers. But I've only just started thinking >about this part. > >Well, there are probably a lot more little stumbling blocks that I am >forgetting, but it is late, and I am sure you will all remind me of >them in due course. > >One thing I can't omit, however, is a big THANKS to Apple, who let me >work with this in spite of my having another day job, to Dave Payne, >my manager, who supported this project even when gdb needed all the >coddling we could give it, to Sergio Mello from Apple DTS who found >the resources to hire Ian Reid to help out with this for the past 6 >months, and to Ian, who did all the dog work while I mostly got to say >"Well, I think it should work like..." > >Sometimes it even did... > >Jim Ingham >Apple Computer, Inc. > >- -- >=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ >Jim Ingham jingham@apple.com >Developer Tools - gdb > >[[Send Tcl/Tk announcements to tcl-announce@mitchell.org > Send administrivia to tcl-announce-request@mitchell.org > Announcements archived at http://groups.yahoo.com/group/tcl_announce/ > The primary Tcl/Tk archive is ftp://ftp.neosoft.com/pub/tcl/ ]] > >- ------- end of forwarded message ------- > >- -- > >Cameron Laird >Business: http://www.Phaseit.net >Personal: http://starbase.neosoft.com/~claird/home.html > >------- End of Forwarded Message > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- --============_-1208926656==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd
I've had some initial success compiling Tkinter by following this recipe:


1. download and install as per below:


I also put a binary snapshot of Wish and the Tcl & Tk Frameworks in
the SourceForge release, under the package name "Mac OS X Tk
Snapshots".  You can get to this by looking at the page:

http://sourceforge.net/projects/tcl/

and look for Latest File Releases.  Probably should have put this in
the Tk site instead, Doh!  I am just getting used to SourceForge.

2. sudo tar -zxf MacOSXTk8.4a4.tar.gz -C /

3. checkout the tk sources

4. cp -r tk/xlib/X11 /Library/Frameworks/Tk.framework/Headers/

5. go to your freshly compiled CVS checkout of Python: cd python/dist/src
I used ./configure --with-suffix=.exe --enable-framework

6. cat > Setup.local

# Edit this file for local setup changes

*shared*

_tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \
        -framework Tcl -framework Tk \
        -I/Library/Frameworks/Tcl.framework/Headers/ \
        -I/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders/ \
        -I/Library/Frameworks/Tk.framework/Headers/ \
        -I/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders/
^D

7. make

8. ./python.exe Demo/tkinter/guido/hello.py


I'm posting this in the hope that others can make the process better.

-Tony


SO HOW DO I USE THIS STUFF:

========================================
First for the binaries... 

The snapshot is just a gzipped tar file, that has the structure:

Applications/Wish Shell.app
   ...
Library/Frameworks/Tcl.framework
   ...
Library/Frameworks/Tk.framework
   ...

So you can either untar this in / - to make an installation that is
available to all users on your machine, or in ~ to make one useable
only to you.  In any case, just double-click on Wish Shell.app to get
started.  You will probably also want to change the files to
make them owned by you...

In fact, you can move things around even more than this.  The Frameworks
just need to be in one of the system paths (/Library/Frameworks,
/System/Library/Frameworks, or ~/Library/Frameworks) to be found
automatically by dyld.  Or you can put them somewhere else and set
DYLD_FRAMEWORK_PATH to point to that location.

After that, you can put "Wish Shell.app" pretty much anywhere you
want.

One other little trick about the "Wish Shell.app" that may come in
handy.  If you put a file called "AppMain.tcl" inside the "Wish
Shell.app" package, in the folder:

Wish Shell.app/Contents/Resources/Scripts

then that will be sourced in as if you had given it as the first
argument on the command-line in Unix, or equivalently had made a D&D
Tclet with that file on the Mac.  The Mac OS X version goes one
better, because the Scripts directory is also added to the auto_path,
so you can put your script libraries there, and they will be found as
well.

The "Wish Shell.app" uses the same console that the Windows & Mac
ports use.  However, if you want to use a terminal console for some
reason, then just do:

$ ./Wish Shell.app/Contents/MacOS/Wish Shell"

in Terminal.app, and it will use the Terminal window instead of the Tk
based one.

There is some support for the Custom MDEF that Tk used on MacOS X, but
it is pretty rough right now, so I have turned it off by default.  If
you want to play with this, do:

set ::tk::mac::useCustomMDEF 1

somewhere BEFORE you create your menus, it will only affect
menus made after you change the setting.  The default setting is done
at the end of tk.tcl in the Resources/Scripts folder in the Tk
framework, so you can also just reverse this setting there to make
Wish always use the custom MDEF.

These binaries were built on Mac OS X - 10.1.  There is no obvious reason
why they wouldn't run on 10.0, but I haven't run that in quite a long
time, so I won't guarantee there aren't any little hitches.  10.1 is SO
much nicer than 10.0, however, that I am not inclined to spend much time
supporting it.

========================================
Next the source:

As I said, the sources are on the SourceForge CVS repositories, the
branch name is macosx-8-4-branch.  The projects expect tcl & tk to be
in the same folder, so like:

./source
    source/tcl
    source/tk

If they are not set up like this, you will have to go muck with the
include paths in the project.

Tcl:

On the Tcl side, there aren't many changes.  I added a MacOS X
directory, but all it contains at present is a Project Builder project
that will build Tcl in the way that Wish currently expects it to be
built.  You can also build the Tcl in this distribution with the
standard configure/make.  But I haven't added the ability to
auto-magically build the Framework from the Makefile.  That is what
the PB Project is for.

The one special thing to note is that Wish requires that you build
the --enable-thread version of Tcl.  I haven't put in any checks to
make sure you do this yet, but it will fail pretty much straight off
the bat if you don't, so...  This was required to wait on Tcl "select"
based sources and still keep Carbon waiting on the App Main Thread as
Ed intended.

I also want to migrate the AppleScript and Resource goodies from the
Classic Mac side to MacOS X, and also add an interface to the CFBundle
API's (which I am now using hackily in tclUnixInit.c).  But I haven't
gotten around to that yet.

Tk:

Tk has the majority of the changes, as you would expect.  There are
not any really substantial changes in the generic folder, there are
some in the library code, mostly because a lot of it assumes
tcl_platform(platform) == unix means you are using X11, which is not
the case for MacOS X. 

Other that that, the code in the macosx folder is the interesting
bits.  It is a pretty straight Carbonization of the Classic Mac code,
but I also took advantage of the opportunity to toss alot of the cruft
from supporting earlier versions of MacOS, and to rework the code to
be a little more to my liking.

I didn't try to rework the Unix Makefiles to support building Wish on
MacOS X.  In part this was because there weren't many similarities
between the Unix & Mac OS X Makefiles, but mostly because I wanted to
use Project Builder, since I actually like GUI development
environments.  If someone with the opposite bent wants to hack up some
Makefiles, I would be happy to accept the changes.

The only trick to building Tcl & Wish is to set the Product
directories for the Tcl.pbproj and Wish.pbproj to the same directory
(either in the PB Global preferences, or in the super-secret Project
specific preferences that you find by selecting the Project entry in
the File tree, and doing "Show Info".)  Then build the topmost Tcl
agregate target, and then build the Wish Target.

In a couple of days I will get together a list of "current and future
projects" in case anyone is interested in helping.  There is a SourceForge
task manager that should be a good venue for this.  There is lots of fun
stuff still to do, by the way, including converting from QuickDraw to
CoreGraphics for the low-level drawing code - so we can get nice looking
line drawing onthe canvas, finally...  And using ATSUI, so we can get the
sweet anti-aliased fonts.

Extensions:

To tell the truth, I only started playing around seriously with
packaging all this stuff up in Frameworks & App Packages in the past
couple of weeks.  I think the structure offers a lot of promise, but I
haven't worked on porting extensions yet, so there will probably be
some refinements to make this easier as time goes on. 

If you have a standard Tcl (not Tk) extension, the way Tcl.pbproj
builds things is a pretty good model.  It shows how to build
frameworks from a Makefile based approach without having to hack up
your Makefiles too badly.

I would like to figure out a way to do this more generally within the
TEA structure, while still getting to use PB, and inflicting the least
pain on other extension writers.  But I've only just started thinking
about this part.

Well, there are probably a lot more little stumbling blocks that I am
forgetting, but it is late, and I am sure you will all remind me of
them in due course.
One thing I can't omit, however, is a big THANKS to Apple, who let me
work with this in spite of my having another day job, to Dave Payne,
my manager, who supported this project even when gdb needed all the
coddling we could give it, to Sergio Mello from Apple DTS who found
the resources to hire Ian Reid to help out with this for the past 6
months, and to Ian, who did all the dog work while I mostly got to say
"Well, I think it should work like..." 

Sometimes it even did...

Jim Ingham
Apple Computer, Inc.

- --
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Jim Ingham                            jingham@apple.com
Developer Tools - gdb

[[Send Tcl/Tk announcements to tcl-announce@mitchell.org
  Send administrivia to tcl-announce-request@mitchell.org
  Announcements archived at http://groups.yahoo.com/group/tcl_announce/
  The primary Tcl/Tk archive is ftp://ftp.neosoft.com/pub/tcl/ ]]

- ------- end of forwarded message -------

- --

Cameron Laird <claird@NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html

------- End of Forwarded Message

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


--
--============_-1208926656==_ma============-- From jack@oratrix.nl Tue Oct 16 10:23:17 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 16 Oct 2001 11:23:17 +0200 Subject: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) In-Reply-To: Message by Tony Lownds , Mon, 15 Oct 2001 18:30:30 -0700 , Message-ID: <20011016092317.EA348303181@snelboot.oratrix.nl> > I've had some initial success compiling Tkinter by following this recipe: If you were a politician the snippet "some initial success" would have to be interpreted as "it failed utterly":-) Is that the intended meaning here too, or did the end product actually work? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tony@metanet.com Tue Oct 16 17:20:38 2001 From: tony@metanet.com (Tony Lownds) Date: Tue, 16 Oct 2001 09:20:38 -0700 Subject: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) In-Reply-To: <20011016092317.EA348303181@snelboot.oratrix.nl> References: <20011016092317.EA348303181@snelboot.oratrix.nl> Message-ID: Its not a success because: * The end product didn't behave well. * I had to put all of those -I directives that point into the framework instead of just using the framework. * Fixing that will require a patch to _tkinter.c (90% sure), a patch to makelocal so that -framework options are passed in compile steps as well as linking steps (70% sure) and maybe some changes from Jim Ingham (not very sure yet). But it compiled, import _tkinter worked, Demos/tkinter/guido/hello.py produced a window. It took ages to display, never grabbed focus correctly, and didn't quit when clicked but it did display. -Tony At 11:23 AM +0200 10/16/01, Jack Jansen wrote: > > I've had some initial success compiling Tkinter by following this recipe: > >If you were a politician the snippet "some initial success" would have to be >interpreted as "it failed utterly":-) Is that the intended meaning here too, >or did the end product actually work? > >-- >Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ >Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ >www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- From jack@oratrix.nl Tue Oct 16 21:48:53 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 16 Oct 2001 22:48:53 +0200 Subject: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) In-Reply-To: Message by Tony Lownds , Tue, 16 Oct 2001 09:20:38 -0700 , Message-ID: <20011016204858.30336EDD23@oratrix.oratrix.nl> [cc-ing Guido, as he asked me about whether I planned to do anything about Tk. Guido: Tony has done the work, and things are somewhat starting to work. Am I off the hook? :-)] Recently, Tony Lownds said: > * I had to put all of those -I directives that point into the > framework instead of just using the framework. This is the same discussion we had about Python (you were in that discussion as well, IIRC). To allow the use of "-framework Python" we would have to modify each and every python extension module in te world to do #include "Python/Python.h" in stead of the current #include "Python.h". For Python we decided (so far) not to do this. I think this is a problem for Apple to solve, possibly through a variant of -framework. The PrivateIncludes stuff does look like an error in the Tk setup, though. > But it compiled, import _tkinter worked, Demos/tkinter/guido/hello.py > produced a window. It took ages to display, never grabbed focus > correctly, and didn't quit when clicked but it did display. Well, that sounds about like how Tk behaves under MacPython, HAHA:-) BTW: I'm chatting to Jim at the moment to try and fix the "event loop problem" now that both Python and Tk are in their infancy on OSX. I'm referring here to the problem that the two event loops don't know about each other, therefore get very confused when they see update events (or other events) for each others windows, get in fights over the menu bar, etc. This is the basic problem that makes it impossible to run Tkinter programs from the IDE. I hope we can come up with an API that is general enough that other packages may also be tempted to adopt it. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From dpennell@guardnet.com Tue Oct 16 22:03:13 2001 From: dpennell@guardnet.com (David Pennell) Date: Tue, 16 Oct 2001 14:03:13 -0700 Subject: [Pythonmac-SIG] One last thing on the slow shell python In-Reply-To: Message-ID: <36830B50-C279-11D5-A2CC-0050E4054856@guardnet.com> I created a tcsh to call pyton -c 'pass' 100 times and 1000 times. Over the control of a simple $I = 999 line, the python -c 'pass' line took 1.7 seconds, each execution - 100 executions took almost 3 minutes. So this is a big problem if one is going to include python steps in a shell. From jack@oratrix.nl Tue Oct 16 22:11:02 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 16 Oct 2001 23:11:02 +0200 Subject: [Pythonmac-SIG] One last thing on the slow shell python In-Reply-To: Message by "David Pennell" , Tue, 16 Oct 2001 14:03:13 -0700 , <36830B50-C279-11D5-A2CC-0050E4054856@guardnet.com> Message-ID: <20011016211107.EC2EFEDD23@oratrix.oratrix.nl> Recently, "David Pennell" said: > I created a tcsh to call pyton -c 'pass' 100 times and 1000 times. > > Over the control of a simple $I = 999 line, the python -c 'pass' line > took 1.7 seconds, each execution - 100 executions took almost 3 minutes. Apple has a very nice new document (released last week, I think) on performance tuning OSX applications. There's an awesome set of tools available to do I/O call measurements, malloc traces and many more. Maybe someone can grab this and run the various tools on Python to see where it's losing the startup time? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tony@metanet.com Tue Oct 16 22:31:44 2001 From: tony@metanet.com (Tony Lownds) Date: Tue, 16 Oct 2001 14:31:44 -0700 Subject: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) In-Reply-To: <20011016204858.30336EDD23@oratrix.oratrix.nl> References: <20011016204858.30336EDD23@oratrix.oratrix.nl> Message-ID: > >This is the same discussion we had about Python (you were in that >discussion as well, IIRC). To allow the use of "-framework Python" we >would have to modify each and every python extension module in te >world to do #include "Python/Python.h" in stead of the current >#include "Python.h". For Python we decided (so far) not to do this. I >think this is a problem for Apple to solve, possibly through a variant >of -framework. Well, I was thinking that we could change _tkinter.c so that it does #include instead of #include when a new define TK_FRAMEWORK is set. Then, when a user wants to compile against Tk/Aqua, they would need to add a line like this to Setup.local: _tkinter _tkinter.c tkappinit.c -DWITH_APPINIT -DTK_FRAMEWORK \ -framework Tcl -framework Tk When a user wants to link against Tk/X11, they would add a line like: _tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \ -I/.../tcl -I/.../tk -I/.../X11 \ -ltcl -ltk -lX11 Do you think this is the right thing? -Tony -- From alexp@strata.com Tue Oct 16 23:11:56 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Tue, 16 Oct 2001 15:11:56 -0700 Subject: [Pythonmac-SIG] One last thing on the slow shell python In-Reply-To: <20011016211107.EC2EFEDD23@oratrix.oratrix.nl> Message-ID: Victory ! I hope I found something interesting about Python being slow when opening-up. I noticed that if I do (prior to call PyMacInitialize) : PyMacSchedParams scp; PyMac_GetSchedParams(&scp); scp.process_events = 0; PyMac_SetSchedParams(&scp); Then Python loads much faster. I suspect GUSI to yield too much time to the system due to the multiple calls to WaitNextEvent during start-up. Could someone verify this statement and elaborate ? Jack ? Alex. > > Recently, "David Pennell" said: >> I created a tcsh to call pyton -c 'pass' 100 times and 1000 times. >> >> Over the control of a simple $I = 999 line, the python -c 'pass' line >> took 1.7 seconds, each execution - 100 executions took almost 3 minutes. > > Apple has a very nice new document (released last week, I think) on > performance tuning OSX applications. There's an awesome set of tools > available to do I/O call measurements, malloc traces and many more. > > Maybe someone can grab this and run the various tools on Python to see > where it's losing the startup time? > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From paulm@avacadcam.com Wed Oct 17 09:41:13 2001 From: paulm@avacadcam.com (Paul Miller) Date: Wed, 17 Oct 2001 09:41:13 +0100 Subject: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) In-Reply-To: <20011016204858.30336EDD23@oratrix.oratrix.nl> Message-ID: Carbon Events look like they would be the solution to the event loop problem. Paul Miller > From: Jack Jansen > Date: Tue, 16 Oct 2001 22:48:53 +0200 > To: Tony Lownds > Cc: Jack Jansen , pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) > ... > > BTW: I'm chatting to Jim at the moment to try and fix the "event loop > problem" now that both Python and Tk are in their infancy on OSX. I'm > referring here to the problem that the two event loops don't know > about each other, therefore get very confused when they see update > events (or other events) for each others windows, get in fights over > the menu bar, etc. This is the basic problem that makes it impossible > to run Tkinter programs from the IDE. I hope we can come up with an > API that is general enough that other packages may also be tempted to > adopt it. > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From jack@oratrix.nl Wed Oct 17 10:22:55 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 17 Oct 2001 11:22:55 +0200 Subject: [Pythonmac-SIG] One last thing on the slow shell python In-Reply-To: Message by Alexandre Parenteau , Tue, 16 Oct 2001 15:11:56 -0700 , Message-ID: <20011017092255.A8D84303181@snelboot.oratrix.nl> > Victory ! > > I hope I found something interesting about Python being slow when > opening-up. > > I noticed that if I do (prior to call PyMacInitialize) : > > PyMacSchedParams scp; > > PyMac_GetSchedParams(&scp); > scp.process_events = 0; > PyMac_SetSchedParams(&scp); > > Then Python loads much faster. > > I suspect GUSI to yield too much time to the system due to the multiple > calls to WaitNextEvent during start-up. this is a very interesting find! I think that setting process_events to 0 is overkill (it would, for instance, also disable command-. handling while Python is importing the initial site.py and such modules), but it's definitely worth it to do event handling different during startup. But all that said, this find is also completely irrelevant to the previous post:-) This is a pure MacPython issue, while the previous messages were about OSX command-line-Python. BTW: since the last couple of months I'm consistently saying "MacPython" when I refer to MacPython. However, I don't have a fixed term yet for "the other Python on OSX", sometimes I say unix-Python, sometimes command-line-Python, sometimes something else altogether. I don't like "Python", because it can mean both and can lead to confusion (as shown here). Any suggestions for a term we could all start using when the distinction is important? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From Benjamin.Schollnick@usa.xerox.com Wed Oct 17 12:50:16 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Wed, 17 Oct 2001 07:50:16 -0400 Subject: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) Message-ID: Potentially silly question here... > discussion as well, IIRC). To allow the use of "-framework Python" we > would have to modify each and every python extension module in te > world to do #include "Python/Python.h" in stead of the current > #include "Python.h". For Python we decided (so far) not to do this. I Is there any reason that a symbolic (?) link couldn't be used to fix (or work around) this problem. for example: python.h -> ./python/python.h Sure it's not ideal.... But a simple installer should be able to make the symbolic link.... That should work... At least with informal testing that I just did in a telnet window, with a Unix (solaris) machine, leads me to believe it might work.... Since a link acts directly on the real file, I don't see why an import, or any other "compilier" access wouldn't work... Now, during your discussion (which I didn't really pay too much attention to), I may have missed an non-technical reason why a link wouldn't work... Feel free to use a 10t hammer to remind me... - Benjamin -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Tuesday, October 16, 2001 4:49 PM To: Tony Lownds Cc: Jack Jansen; pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) [cc-ing Guido, as he asked me about whether I planned to do anything about Tk. Guido: Tony has done the work, and things are somewhat starting to work. Am I off the hook? :-)] Recently, Tony Lownds said: > * I had to put all of those -I directives that point into the > framework instead of just using the framework. This is the same discussion we had about Python (you were in that discussion as well, IIRC). To allow the use of "-framework Python" we would have to modify each and every python extension module in te world to do #include "Python/Python.h" in stead of the current #include "Python.h". For Python we decided (so far) not to do this. I think this is a problem for Apple to solve, possibly through a variant of -framework. The PrivateIncludes stuff does look like an error in the Tk setup, though. > But it compiled, import _tkinter worked, Demos/tkinter/guido/hello.py > produced a window. It took ages to display, never grabbed focus > correctly, and didn't quit when clicked but it did display. Well, that sounds about like how Tk behaves under MacPython, HAHA:-) BTW: I'm chatting to Jim at the moment to try and fix the "event loop problem" now that both Python and Tk are in their infancy on OSX. I'm referring here to the problem that the two event loops don't know about each other, therefore get very confused when they see update events (or other events) for each others windows, get in fights over the menu bar, etc. This is the basic problem that makes it impossible to run Tkinter programs from the IDE. I hope we can come up with an API that is general enough that other packages may also be tempted to adopt it. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From jack@oratrix.nl Wed Oct 17 13:16:09 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 17 Oct 2001 14:16:09 +0200 Subject: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd) In-Reply-To: Message by "Schollnick, Benjamin" , Wed, 17 Oct 2001 07:50:16 -0400 , Message-ID: <20011017121610.49B38303181@snelboot.oratrix.nl> > Potentially silly question here... > > > discussion as well, IIRC). To allow the use of "-framework Python" we > > would have to modify each and every python extension module in te > > world to do #include "Python/Python.h" in stead of the current > > #include "Python.h". For Python we decided (so far) not to do this. I > > Is there any reason that a symbolic (?) link couldn't be used to fix > (or work around) this problem. > > for example: > > python.h -> ./python/python.h I think this wouldn't work, but I'm not sure. I get the impression that the "-framework Python" option to the compiler does some magic inside the C proprocessor, so that lines of the form #include "Python/xxxxx" will look for a file xxxx inside the Python framework Include directory. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From dpreston@intersight.com Wed Oct 17 17:11:41 2001 From: dpreston@intersight.com (Donovan Preston) Date: Wed, 17 Oct 2001 09:11:41 -0700 Subject: [Pythonmac-SIG] One last thing on the slow shell python In-Reply-To: <20011017092255.A8D84303181@snelboot.oratrix.nl> Message-ID: On Wednesday, October 17, 2001, at 02:22 AM, Jack Jansen wrote: > > BTW: since the last couple of months I'm consistently saying > "MacPython" when > I refer to MacPython. However, I don't have a fixed term yet for "the > other > Python on OSX", sometimes I say unix-Python, sometimes > command-line-Python, > sometimes something else altogether. I don't like "Python", because it > can > mean both and can lead to confusion (as shown here). Any suggestions > for a > term we could all start using when the distinction is important? > Mach-O Python is the term I like to use. From sdm7g@Virginia.EDU Wed Oct 17 18:05:34 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Wed, 17 Oct 2001 13:05:34 -0400 (EDT) Subject: [Pythonmac-SIG] [You know this already, but...] Tcl/Tk now available for Aqua/Mac OS X (fwd) Message-ID: You all know this already, but I though it was interesting that Apple sent out a somewhat more "official" announcement: -- Steve ---------- Forwarded message ---------- Date: Tue, 16 Oct 2001 16:57:58 -0700 From: WebObjects To: publicsource-announce@lists.apple.com Subject: Tcl/Tk now available for Aqua/Mac OS X Apple is pleased to announce a native port of TK version 8.4a4 for Mac OS X 10.1. TK is a rapid application GUI toolkit used by Tcl, Perl, and Python. The TK release allows script developers to run existing GUI applications with a native Aqua look and feel directly on Mac OS X v10.1. As part of Apple's ongoing commitment to Open Source, this port has been released under a BSD-style license. Apple's changes have been and will continue to be submitted to the main Tcl/Tk CVS repository at tcl.sourceforge.net. This initial port only supports Tk for use with Tcl; we are working on integrating this into the main branch of Tk, and from there we expect it to be integrated into the versions used with Perl and Python. If you'd like to help, please join the discussions on darwin- development@lists.apple.com. Sincerely, Ernest Prabhakar Open Source Product Manager admin@opensource.apple.com _______________________________________________ publicsource-announce mailing list publicsource-announce@lists.apple.com http://www.lists.apple.com/mailman/listinfo/publicsource-announce From Benjamin.Schollnick@usa.xerox.com Wed Oct 17 18:19:11 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Wed, 17 Oct 2001 13:19:11 -0400 Subject: [Pythonmac-SIG] PMW Error on the mac? Message-ID: Folks, I'm trying to get PMW (Python MegaWidget's) to work on the Mac... I've "bundled" the python code, but when I try to open a Dialog window with PMW, I get the following error message: Menu ID 256 is already in use!Fatal Python Error: Tcl/TK Panic Anyone have any idea on how to fix this? - Benjamin From jhrsn@pitt.edu Wed Oct 17 21:34:20 2001 From: jhrsn@pitt.edu (Jim Harrison) Date: Wed, 17 Oct 2001 16:34:20 -0400 Subject: [Pythonmac-SIG] BBEdit 6.5 and MacPython Message-ID: BBEdit 6.5 now comes with a Python text coloring language module, which = led me to try it out on OS 9.1 and MacPython 2.1.1 with the old 'Run as = Python' plug-in from 1999 and Just's PythonSlave.py script that's copyrighted = 1996. I had to comment out 'from Types import *' in PythonSlave, but after = that it ran fine for simple scripts. Pretty slick, actually. There are a few rough edges. PythonSlave must be started manually = before you can use Run as Python (the plug-in doesn=B9t initiate startup of the = script). PythonSlave also doesn't respond to Quit or Command-Q; you must hit Control-D to exit. PythonSlave's execution window is always open, so = it's not particularly aesthetic to leave it running in the background continuously. These seem minor issues and I haven't really exercised = this setup to see if additional problems might exist. I'm not expert enough to look through PythonSlave in detail and = recognize what might need updating but it doesn't look like it would be too much = of a job for someone who knew what was out of date and what was current. I = wonder if it would be worth thinking about updating the plug-in and = PythonSlave to work together smoothly in the current BBEdit environment? Jim Harrison University of Pittsburgh From Aureli.Soria_Frisch@ipk.fhg.de Thu Oct 18 11:29:37 2001 From: Aureli.Soria_Frisch@ipk.fhg.de (Aureli Soria Frisch) Date: Thu, 18 Oct 2001 12:29:37 +0200 Subject: [Pythonmac-SIG] One last thing on the slow shell python In-Reply-To: <20011017092255.A8D84303181@snelboot.oratrix.nl> References: Message by Alexandre Parenteau , Tue, 16 Oct 2001 15:11:56 -0700 , Message-ID: At 11:22 Uhr +0200 17.10.2001, Jack Jansen wrote: >BTW: since the last couple of months I'm consistently saying "MacPython" when >I refer to MacPython. However, I don't have a fixed term yet for "the other >Python on OSX", sometimes I say unix-Python, sometimes command-line-Python, >sometimes something else altogether. I don't like "Python", because it can >mean both and can lead to confusion (as shown here). Any suggestions for a >term we could all start using when the distinction is important? >-- XPython? Regards, Aureli ################################# Aureli Soria Frisch Fraunhofer IPK Dept. Pattern Recognition post: Pascalstr. 8-9, 10587 Berlin, Germany e-mail:aureli@ipk.fhg.de fon: +49 30 39006-150 fax: +49 30 3917517 web: http://vision.fhg.de/~aureli/web-aureli_en.html ################################# From aparente@adobe.com Thu Oct 18 23:41:48 2001 From: aparente@adobe.com (Alexandre Parenteau) Date: Thu, 18 Oct 2001 15:41:48 -0700 Subject: [Pythonmac-SIG] [Proposal] changing the preferences storage mechanism Message-ID: Jack, As described previously in this thread, I was proposing 2 changes to MacPython. The first one you did integrate (cool) and this is the second one. It is intended to replace the current mechanism to store the MacPython preferences. I detail in the patch the motivations for doing so. I didn't know if you wanted me to the implement this one. You told me you were concerned by how to do it since it goes deep inside MacPython. So I didn't do something complete, I just concentrated on making the under mechanism so you have "only" to hook it up and replace the current system. I posted it at SourceForge. Now in order to use it, you'll probably want to add that in macconfig.c : extern void initMacPersistent(); {"MacOS", initMacOS}, > {"MacPersistent", initMacPersistent}, {"regex", initregex}, Then add the file MacPersistent.cpp and then run the sample. Hope you like it, please tell me if I can help some more. Regards, Alex. P.s.: sorry for posting messages in the wrong thread (i.e. Mach-o Python and GUSI Yielding), but that's me :-) -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From alexp@strata.com Fri Oct 19 01:14:40 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Thu, 18 Oct 2001 17:14:40 -0700 Subject: [Pythonmac-SIG] [Proposal] changing the preferences storage mechanism Message-ID: [Repost, sorry if it appears twice, I didn't send it with the good account the first time] Jack, As described previously in this thread, I was proposing 2 changes to MacPython. The first one you did integrate (cool) and this is the second one. It is intended to replace the current mechanism to store the MacPython preferences. I detail in the patch the motivations for doing so. I didn't know if you wanted me to the implement this one. You told me you were concerned by how to do it since it goes deep inside MacPython. So I didn't do something complete, I just concentrated on making the under mechanism so you have "only" to hook it up and replace the current system. I posted it at SourceForge. Now in order to use it, you'll probably want to add that in macconfig.c : extern void initMacPersistent(); {"MacOS", initMacOS}, > {"MacPersistent", initMacPersistent}, {"regex", initregex}, Then add the file MacPersistent.cpp and then run the sample. Hope you like it, please tell me if I can help some more. Regards, Alex. P.s.: sorry for posting messages in the wrong thread (i.e. Mach-o Python and GUSI Yielding), but that's me :-) From Benjamin.Schollnick@usa.xerox.com Fri Oct 19 12:51:00 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Fri, 19 Oct 2001 07:51:00 -0400 Subject: [Pythonmac-SIG] RE: [Proposal] changing the preferences storage mechanism Message-ID: Sorry, I must of missed this thread previously... Is there any particular reason for changing from the current implementation? And maybe I'm just being a fool here... But is there some reason that the preferences could not be stored in a already python established configfile (ini style file)? That way, it's human readable, and modifiable? Plus, that also gives us a uniform method across Classic Mac Python & Mach-O Python. Now, since I'm not sure what preference(s) exactly we are talking about, I'm not sure if this is suitable. Plus, if these variables are required during startup of Mac Python, then a configfile probably isn't available, since Mac Python hasn't completed it's startup.... But, it's a thought.... (Geeez, how about tagging these conversations with a [dev] or [maybe interesting to ben] in the subject line, so that I'll be sure to pay attention... This is the second thread that I've entered at the *end* of it... ) - Benjamin -----Original Message----- From: Alexandre Parenteau [mailto:alexp@strata.com] Sent: Thursday, October 18, 2001 8:15 PM To: MacPython Subject: [Pythonmac-SIG] [Proposal] changing the preferences storage mechanism [Repost, sorry if it appears twice, I didn't send it with the good account the first time] Jack, As described previously in this thread, I was proposing 2 changes to MacPython. The first one you did integrate (cool) and this is the second one. It is intended to replace the current mechanism to store the MacPython preferences. I detail in the patch the motivations for doing so. I didn't know if you wanted me to the implement this one. You told me you were concerned by how to do it since it goes deep inside MacPython. So I didn't do something complete, I just concentrated on making the under mechanism so you have "only" to hook it up and replace the current system. I posted it at SourceForge. Now in order to use it, you'll probably want to add that in macconfig.c : extern void initMacPersistent(); {"MacOS", initMacOS}, > {"MacPersistent", initMacPersistent}, {"regex", initregex}, Then add the file MacPersistent.cpp and then run the sample. Hope you like it, please tell me if I can help some more. Regards, Alex. P.s.: sorry for posting messages in the wrong thread (i.e. Mach-o Python and GUSI Yielding), but that's me :-) _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From jack@oratrix.nl Fri Oct 19 13:14:29 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 19 Oct 2001 14:14:29 +0200 Subject: [Pythonmac-SIG] RE: [Proposal] changing the preferences storage mechanism In-Reply-To: Message by "Schollnick, Benjamin" , Fri, 19 Oct 2001 07:51:00 -0400 , Message-ID: <20011019121429.CABD7303181@snelboot.oratrix.nl> > Sorry, I must of missed this thread previously... > > Is there any particular reason for changing from the current implementation? Aside from Alexandre's reason (which I'm not totally clear about, I must admit) I have a very good reason to want this, and that is that it allows selective override. With the current scheme if you want to override one setting you have to override them all. An additional problem with the current scheme is the way the standard applets are built. They have their own .rsrc files, with not only their custom dialogs and icons but also their python prefs override, which has the "delay console until needed" flag set. The problem with this is that whenever I change the preference version I have to change all these resource files too. Bah. With each preference in a separate resource that would be fixed. (this could also be fixed with backward-compat code, as there is a version field in the prefs resource, but I'm usually too lazy for this too). > But is there some reason that the preferences could not be stored in a > already > python established configfile (ini style file)? Well, it would be difficult to do the defaulting with ini files. Currently a preference resource is looked for in 3 places, *in order*: - "Popt" resource with ID 229 in the current executable/library. - "Popt" resource with ID 228 in the preferences file. - "Popt" resource with ID 228 in the current executable/library. (In order these are the Applet override prefs, the system-wide prefs and the factory-default prefs). > Plus, that also gives us a uniform method across Classic Mac Python & Mach-O > Python. I don't think you really want that. Most of the options are MacPython-specific. And if it does turn out we want this at some point we should use the CoreServices preferences APIs, which store preferences as XML files, and do the right thing with respect to overriding prefs per user, per system, etc. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Oct 19 16:08:43 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 19 Oct 2001 17:08:43 +0200 Subject: [Pythonmac-SIG] MacPython 2.1.2, anyone? Message-ID: <20011019150844.20A64303181@snelboot.oratrix.nl> Folks, there's talk on python-dev about doing a Python 2.1.2 release, but I'm thinking of skipping on MacPython 2.1.2. The 2.1.1 release cost me quite some time, and while some people were happy with some of the bugs that were fixed there were also new ones introduced, if I remember correctly. If anyone else wants to work on 2.1.2: please jump in! If someone wants to try and convince me that I should put some time in this: do it now or you're too late. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From chrishbarker@home.net Fri Oct 19 18:19:23 2001 From: chrishbarker@home.net (Chris Barker) Date: Fri, 19 Oct 2001 10:19:23 -0700 Subject: [Pythonmac-SIG] MacPython 2.1.2, anyone? References: <20011019150844.20A64303181@snelboot.oratrix.nl> Message-ID: <3BD0609B.45B54597@home.net> Jack Jansen wrote: > If anyone else wants to work on 2.1.2: please jump in! If someone wants to try > and convince me that I should put some time in this: do it now or you're too > late. Where can we find a summary of what would be changed/fixed/improved in 2.1.2? Whithout that info, I have no idea whether I would want it. -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From jack@oratrix.nl Fri Oct 19 22:01:21 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 19 Oct 2001 23:01:21 +0200 Subject: [Pythonmac-SIG] MacPython 2.1.2, anyone? In-Reply-To: Message by Chris Barker , Fri, 19 Oct 2001 10:19:23 -0700 , <3BD0609B.45B54597@home.net> Message-ID: <20011019210126.CCE55E2677@oratrix.oratrix.nl> Recently, Chris Barker said: > Jack Jansen wrote: > > > If anyone else wants to work on 2.1.2: please jump in! If someone wants to > try > > and convince me that I should put some time in this: do it now or you're to > o > > late. > > Where can we find a summary of what would be changed/fixed/improved in > 2.1.2? Whithout that info, I have no idea whether I would want it. The work hasn't started yet. Anthony Baxter (at least, I think it was him) volunteered to do the work for the core. this means going through all the checkin messages on the 2.2 main trunk since 2.1.1, seeing whether they're bug fixes and relevant to 2.1.1 and if they are backporting them to 2.1.1. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From karl@elemtech.com Fri Oct 19 22:41:25 2001 From: karl@elemtech.com (Karl G. Merkley) Date: Fri, 19 Oct 2001 15:41:25 -0600 Subject: [Pythonmac-SIG] Quickdraw version of turtle.py Message-ID: <3BD09E05.90102@elemtech.com> Has anybody ever looked at creating something like a macturtle.py that would be Quickdraw based instead of Tk based? I would like to use turtle graphics as a tool to teach programming at an elementary school level and it would be _really_ nice to be able to use the IDE. Thanks, Karl From khk@uiah.fi Sat Oct 20 13:15:48 2001 From: khk@uiah.fi (Kari-Hans Kommonen) Date: Sat, 20 Oct 2001 15:15:48 +0300 Subject: [Pythonmac-SIG] MacPython and OSXPython or XPython In-Reply-To: <20011017092255.A8D84303181@snelboot.oratrix.nl> References: <20011017092255.A8D84303181@snelboot.oratrix.nl> Message-ID: how about OSXPython or XPython? At 11:22 +0200 17.10.2001, Jack Jansen wrote: >BTW: since the last couple of months I'm consistently saying "MacPython" when >I refer to MacPython. However, I don't have a fixed term yet for "the other >Python on OSX", sometimes I say unix-Python, sometimes command-line-Python, >sometimes something else altogether. I don't like "Python", because it can >mean both and can lead to confusion (as shown here). Any suggestions for a >term we could all start using when the distinction is important? From ryanwilcox@mac.com Sat Oct 20 15:41:38 2001 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Sat, 20 Oct 2001 10:41:38 -0400 Subject: [Pythonmac-SIG] MacPython and OSXPython or XPython In-Reply-To: Message-ID: <20011020104140-r01010800-f15202a9-0921-010c@129.21.139.101> On Saturday, October 20, 2001, at 3:15 PM, khk@uiah.fi (Kari-Hans Kommonen) wrote: >>BTW: since the last couple of months I'm consistently saying "MacPython" when >>I refer to MacPython. However, I don't have a fixed term yet for "the other >>Python on OSX", sometimes I say unix-Python, sometimes command-line-Python, >>sometimes something else altogether. I like MacPython vs CLIPython or MacPython vs DarwinPython/UnixPython My two cents, -Ryan Wilcox From sburr@home.com Sat Oct 20 18:20:38 2001 From: sburr@home.com (Steven Burr) Date: Sat, 20 Oct 2001 10:20:38 -0700 Subject: [Pythonmac-SIG] MacPython and OSXPython or XPython In-Reply-To: Message-ID: Can't put my finger on it, but there's something about the 'XP' in 'XPython" that I just don't like. On Saturday, October 20, 2001, at 05:15 AM, Kari-Hans Kommonen wrote: > how about OSXPython or XPython? > > At 11:22 +0200 17.10.2001, Jack Jansen wrote: >> BTW: since the last couple of months I'm consistently saying >> "MacPython" when >> I refer to MacPython. However, I don't have a fixed term yet for "the >> other >> Python on OSX", sometimes I say unix-Python, sometimes >> command-line-Python, >> sometimes something else altogether. I don't like "Python", because it >> can >> mean both and can lead to confusion (as shown here). Any suggestions >> for a >> term we could all start using when the distinction is important? > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From LouisDemers@mac.com Sat Oct 20 18:31:12 2001 From: LouisDemers@mac.com (Louis Demers) Date: Sat, 20 Oct 2001 13:31:12 -0400 Subject: [Pythonmac-SIG] MacPython and OSXPython or XPython In-Reply-To: References: <20011017092255.A8D84303181@snelboot.oratrix.nl> Message-ID: At 3:15 PM +0300 10/20/01, Kari-Hans Kommonen wrote: >how about OSXPython or XPython? or PythonX, it doesn't look MS XP related, sorts alphabetically next to Python... > >At 11:22 +0200 17.10.2001, Jack Jansen wrote: >>BTW: since the last couple of months I'm consistently saying "MacPython" when >>I refer to MacPython. However, I don't have a fixed term yet for "the other >>Python on OSX", sometimes I say unix-Python, sometimes command-line-Python, >>sometimes something else altogether. I don't like "Python", because it can >>mean both and can lead to confusion (as shown here). Any suggestions for a >>term we could all start using when the distinction is important? > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- Louis Demers ing. From erik@letterror.com Sat Oct 20 22:04:25 2001 From: erik@letterror.com (Erik van Blokland) Date: Sat, 20 Oct 2001 22:04:25 +0100 Subject: [Pythonmac-SIG] MacPython and OSXPython or XPython In-Reply-To: Message-ID: <20011020220437-r01010800-e0b1a8e2-0910-0108@192.168.128.6> LouisDemers@mac.com (Louis Demers): [10/20/01 at 1:31 PM] > or PythonX, it doesn't look MS XP related, sorts alphabetically next > to Python... Like Adobe Illustrator X, also for osX. But that also happens to be their release/version number. Erik -- www.letterror.com Type & Typography From Y.Benita@pharm.uu.nl Mon Oct 22 15:53:58 2001 From: Y.Benita@pharm.uu.nl (Yair Benita) Date: Mon, 22 Oct 2001 16:53:58 +0200 Subject: [Pythonmac-SIG] Urllib Message-ID: Hi all, When I use urlopen and read a file from the net I get a partial file. Is there an easy way to know when the url has finished loaded before I try to read it? Thanks, Yair -- Yair Benita Pharmaceutical Proteomics Utrecht University From karl@elemtech.com Mon Oct 22 16:09:53 2001 From: karl@elemtech.com (Karl G. Merkley) Date: Mon, 22 Oct 2001 09:09:53 -0600 Subject: [Pythonmac-SIG] wxPython Message-ID: <3BD436C1.8010108@elemtech.com> What is the status of wxPython for the Mac? Will it play nicely with the IDE? Thanks for the update, Karl From chrishbarker@home.net Mon Oct 22 18:02:19 2001 From: chrishbarker@home.net (Chris Barker) Date: Mon, 22 Oct 2001 10:02:19 -0700 Subject: [Pythonmac-SIG] wxPython References: <3BD436C1.8010108@elemtech.com> Message-ID: <3BD4511B.B3AB4326@home.net> "Karl G. Merkley" wrote: > What is the status of wxPython for the Mac? Still waiting after all these years..... AKAIK, no one with both the time and the required skills has stepped forward to do it. > Will it play nicely with the IDE? Probably not. Different event loops are always a problem with Python IDEs, so it will probably not work for the same reason the tkinter doesn't work. HOwever, you should get Boa constructor and/or PyCrust, so it won't be too big a loss. -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From alexp@strata.com Mon Oct 22 18:57:45 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Mon, 22 Oct 2001 10:57:45 -0700 Subject: [Pythonmac-SIG] AE quit() ? Message-ID: Hello, I'm trying to use the AppleEvent quit() method on CodeWarrior (or MPW) and I'm using the latest CVS build. MacPython complains this attribute ('quit') doesn't exist. Beside in fullbuild.py I found that line commented out : ## mgr.quit() Is-that a known issue/bug ? Is there a work around ? Thanks, Alex. From jbradley@whiplashmedia.com Mon Oct 22 20:14:48 2001 From: jbradley@whiplashmedia.com (Jon Bradley) Date: Mon, 22 Oct 2001 15:14:48 -0400 Subject: [Pythonmac-SIG] library file information In-Reply-To: Message-ID: Hey all - I know, this isn't the place to ask this, but, you've all been so helpful that I thought I would throw this one out there. An associate send me a shared library (.slb file I guess) that was integrated into an application he did. He modified the PythonCore for a previous version of Python (no idea which version) and send me the libary to check out. Unfortunately, I have no idea how to get this opened and working - as versions 1.5 through 2.2 don't want to recognize the libary in any way. I've tried putting it in all sorts of places - including replacing my core library with this one and also putting it in the extension folder. My associate is on vacation and I won't be able to get in touch with him for a few weeks - so if anyone is able to offer up some suggestions, I would be very appreciative. Basically, I want to be able to view the modules, attributes and strucutre of this library. Thanks in advance... Jon Bradley Multimedia Developer jbradley@whiplashmedia.com From tparker@amsuk.com Tue Oct 23 10:00:14 2001 From: tparker@amsuk.com (Tim Parker) Date: Tue, 23 Oct 2001 10:00:14 +0100 Subject: [Pythonmac-SIG] Tkinter on the MAC? and a Memory Error?? Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C15BA9.82A533F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have a couple of questions: 1. Is there a working version of Tkinter with Python for the MAC so that the IDLE console can be used? The python version we need this to work in is 1.5.2 due to the fact that this is the version we currently dynamically link with from our application. If this is not possible is there an alternative IDE for debugging scripts from within our product (so that internal functions and variables are available). 2. On another note I have a script to parse source files to modify the carriage return line feeds so that they are MAC compatible but after parsing just over half of them I get a Memory Error, so how do I increase the Memory for the PythonInterpreter or IDE or better how do I free/reallocate memory within my script as I loop through the files. Thanks in advance Tim Parker _____________________________________________________________________ This message has been checked for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. For further information visit http://www.uk.uu.net/products/security/virus/ ------=_NextPart_000_0000_01C15BA9.82A533F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a couple of questions:

 

1.       = Is there a working = version of Tkinter with Python for the MAC so that the IDLE console can be used? =  The python version we need this = to work in is 1.5.2 due to the fact that this is the version we currently = dynamically link with from our application.  If this is not possible is there an alternative IDE for debugging scripts from = within our product (so that internal functions and variables are = available).

2.       = On another note I = have a script to parse source files to modify the carriage return line feeds so = that they are MAC compatible but after parsing just over half of them I get a = Memory Error, so how do I increase the Memory for the PythonInterpreter or IDE = or better how do I free/reallocate memory within my script as I loop = through the files.

 

Thanks in advance

 

Tim Parker

Outgoing mail is certified Virus = Free.
Checked by AVG anti-virus system (www.grisoft.com).
Version: 6.0.282 / Virus Database: 150 - Release Date: = 25/09/2001
_____________________________________________________________________
This message has been checked for all known viruses by UUNET delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.uk.uu.net/products/security/virus/
------=_NextPart_000_0000_01C15BA9.82A533F0-- From jack@oratrix.nl Tue Oct 23 10:22:06 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 23 Oct 2001 11:22:06 +0200 Subject: [Pythonmac-SIG] AE quit() ? In-Reply-To: Message by Alexandre Parenteau , Mon, 22 Oct 2001 10:57:45 -0700 , Message-ID: <20011023092207.27A8B303181@snelboot.oratrix.nl> > Hello, > > I'm trying to use the AppleEvent quit() method on CodeWarrior (or MPW) and > I'm using the latest CVS build. MacPython complains this attribute ('quit') > doesn't exist. > > Beside in fullbuild.py I found that line commented out : > > ## mgr.quit() > > Is-that a known issue/bug ? Is there a work around ? That line is commented out because I got fed up with having to wait for the CW restart on the next fullbuild run:-) I don't know of any bugs here, could you give me a stack trace of the exact error? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Tue Oct 23 10:38:01 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 23 Oct 2001 11:38:01 +0200 Subject: [Pythonmac-SIG] library file information In-Reply-To: Message by Jon Bradley , Mon, 22 Oct 2001 15:14:48 -0400 , Message-ID: <20011023093801.ACA32303181@snelboot.oratrix.nl> > Hey all - I know, this isn't the place to ask this, but, you've all been so > helpful that I thought I would throw this one out there. > > An associate send me a shared library (.slb file I guess) that was > integrated into an application he did. He modified the PythonCore for a > previous version of Python (no idea which version) and send me the libary to > check out. > > Unfortunately, I have no idea how to get this opened and working - as > versions 1.5 through 2.2 don't want to recognize the libary in any way. If this is a replacement PythonCore you can check which Python it is by opening the file in ResEdit or Resourcerer and inspecting the "cfrg" resource. This resource has two fields "current version" and "old version", and these are the sys.hexversion of Python. So, for Python 2.2a3 the numbers are 0x020200a3. Final builds will have an f0 in the last byte, so for Python 2.2.1 the number will be (unless I messed up;-) 0x020201f0. If the number doesn't conform to this we're talking a really old Python, before 1.5.2 (if I remember correctly). If the library is a .ppc.slb or .carbon.slb and it has the two-hands-holding-the-16-ton-weight icon there's a good chance this is a dynamic module. Put it somewhere on sys.path and try to import it. If it's built for a different version of Python you'll get an error message to this effect, something about a newer or older version of a pef container. If it's a straight .slb and/or doesn't have the python icon it might still be a dynamic module, but the chances are slim. Still: why not try importing it. If it is called "foo.slb" and "import foo" gives an ImportError with a message like "Symbol initfoo not found" then it isn't a Python module after all. In that case it is a general shared library, and if this is the only thing your friend sent you you're missing some parts (the dynamic module that would connect Python to the shared library). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Tue Oct 23 10:44:22 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 23 Oct 2001 11:44:22 +0200 Subject: [Pythonmac-SIG] Tkinter on the MAC? and a Memory Error?? In-Reply-To: Message by "Tim Parker" , Tue, 23 Oct 2001 10:00:14 +0100 , Message-ID: <20011023094422.F06E7303181@snelboot.oratrix.nl> > 1. Is there a working version of Tkinter with Python for the MAC so > that the IDLE console can be used? The python version we need this to work > in is 1.5.2 due to the fact that this is the version we currently > dynamically link with from our application. If this is not possible is > there an alternative IDE for debugging scripts from within our product (so > that internal functions and variables are available). Hmm, 1.5.2 is a long time ago. I seem to remember that it was one of the releases in which Tkinter completely refused to work, but I'm not 100% sure. But: try using the IDE, the native MacPython integrated development environment. It has a much better chance of working, and i's much nicer than Idle anyway. > 2. On another note I have a script to parse source files to modify the > carriage return line feeds so that they are MAC compatible but after parsing > just over half of them I get a Memory Error, so how do I increase the Memory > for the PythonInterpreter or IDE or better how do I free/reallocate memory > within my script as I loop through the files. As soon as you clear all references to memory the memory is freed by Python. But beware of cycles (objects mutually referring to one another), these you have to break "by hand". But: MacPython 1.5.2 used a private malloc() which was a lot faster, but also tended to waste about 30% more memory. Increasing the memory for Python is the same as for other Mac applications: "get info" in the finder and increase the memory size. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Tue Oct 23 15:36:38 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 23 Oct 2001 16:36:38 +0200 Subject: [Pythonmac-SIG] MacPython on multiprocessor OSX 10.1 Message-ID: <20011023143643.092F6EDD23@oratrix.oratrix.nl> Folks, when 10.1 was still not officially out I got some notes that seemed to suggest that the problem with MacPython on a multiprocessor OSX machine (it would hang during I/O, usually already in ConfigurePythonCarbon) is gone in 10.1. Could someone with a 10.1 multiprocessor please give MacPython 2.2a3 a try, and tell me whether the problem has indeed been solved? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From alexp@strata.com Tue Oct 23 15:52:21 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Tue, 23 Oct 2001 07:52:21 -0700 Subject: [Pythonmac-SIG] MacPython on multiprocessor OSX 10.1 References: <20011023143643.092F6EDD23@oratrix.oratrix.nl> Message-ID: <002301c15bd2$525115b0$4000a8c0@veropc> Jack, > when 10.1 was still not officially out I got some notes that seemed to > suggest that the problem with MacPython on a multiprocessor OSX > machine (it would hang during I/O, usually already in > ConfigurePythonCarbon) is gone in 10.1. > > Could someone with a 10.1 multiprocessor please give MacPython 2.2a3 a > try, and tell me whether the problem has indeed been solved? I've sent such a note. But at least with MacCvs, it continues to hang sometimes (Gary ?), and not only for SMP. I'll give another try. alex. > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From alexp@strata.com Tue Oct 23 15:58:16 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Tue, 23 Oct 2001 07:58:16 -0700 Subject: [Pythonmac-SIG] AE quit() ? References: <20011023092207.27A8B303181@snelboot.oratrix.nl> Message-ID: <003d01c15bd3$2603b9d0$4000a8c0@veropc> Jack, Try : import CodeWarrior shell = CodeWarrior.CodeWarrior('CWIE', 1) shell.quit() It doesn't work for me. alex. ----- Original Message ----- From: "Jack Jansen" To: "Alexandre Parenteau" Cc: "MacPython" Sent: Tuesday, October 23, 2001 2:22 AM Subject: Re: [Pythonmac-SIG] AE quit() ? > > Hello, > > > > I'm trying to use the AppleEvent quit() method on CodeWarrior (or MPW) and > > I'm using the latest CVS build. MacPython complains this attribute ('quit') > > doesn't exist. > > > > Beside in fullbuild.py I found that line commented out : > > > > ## mgr.quit() > > > > Is-that a known issue/bug ? Is there a work around ? > > That line is commented out because I got fed up with having to wait for the CW > restart on the next fullbuild run:-) > > I don't know of any bugs here, could you give me a stack trace of the exact > error? > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > > > From chrishbarker@home.net Tue Oct 23 17:07:03 2001 From: chrishbarker@home.net (Chris Barker) Date: Tue, 23 Oct 2001 09:07:03 -0700 Subject: [Pythonmac-SIG] Tkinter on the MAC? and a Memory Error?? References: <20011023094422.F06E7303181@snelboot.oratrix.nl> Message-ID: <3BD595A7.FD6985AD@home.net> Jack Jansen wrote: > But: try using the IDE, the native MacPython integrated development > environment. It has a much better chance of working, and i's much nicer than > Idle anyway. True, but if the App uses TKinter itself, it won't work with the MacPythonIDE. -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From kaffeen@mac.com Tue Oct 23 17:37:36 2001 From: kaffeen@mac.com (Chris Scott) Date: Tue, 23 Oct 2001 12:37:36 -0400 Subject: [Pythonmac-SIG] tkinter question Message-ID: Hello from a total newbie, please forgive my utter lack of knowledge at this point... I'm running Python version 2.1.1 on a G4 under system 9.0 and trying to get started using the livewire tutorials. I figured out how to get the modules to load, but they won't work. When i try to import Tkinter, I get the following error: Traceback (most recent call last): File "", line 1, in ? ImportError: Tkinter not supported under Carbon (yet). Python help said this list was my best bet. Any ideas? Thanks. - kaffeen From joerg@kantel.de Tue Oct 23 20:47:05 2001 From: joerg@kantel.de (=?iso-8859-1?Q?J=F6rg?= Kantel) Date: Tue, 23 Oct 2001 21:47:05 +0200 Subject: [Pythonmac-SIG] Tkinter on the MAC? and a Memory Error?? In-Reply-To: <3BD595A7.FD6985AD@home.net> Message-ID: <20011023214729-r01010800-03c11230-0920-010c@192.168.1.75> Folks, forgotten? There is a short How To on my site, which shows how (Mac-) Python 1.5.2 works with Tkinter: (english version) (German version) HTH J"org Kantel -- mail: joerg@kantel.de # jkantel@mac.com visit: http://www.rollberg.de/ - die etwas anderen Nachrichten http://www.schockwellenreiter.de/ - (m)ein Weblog From jack@oratrix.nl Tue Oct 23 21:15:38 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 23 Oct 2001 22:15:38 +0200 Subject: [Pythonmac-SIG] Problems with new features introduced during beta, anyone? Message-ID: <20011023201543.89BAEEDD23@oratrix.oratrix.nl> Folks, I'm pretty far along with MacPython 2.2b1, but suddenly on my doorstep I find a couple of very nifty modules: CarbonEvents and a hfs+ API module. And there's mods I got to allow MacPython to use the OSX bundle format (so you can have an OS9/OSX bundle) that I can't enable right now. And there might be Alexandre's new preference stuff and/or my newline stuff. There are a few things I can do: 1. Forget about these for MacPython 2.2 and leave them for 2.3. 2. Forget about MacPython 2.2b1, incorporate these modules and pick up the release trail again at the time of Python 2.2b2. 3. Do MacPython 2.2b1 now, and sneak in the new features for 2.2b2 (labeled "experimental"). I'm tempted to do 3, but I'd like to hear what you all think, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From jack@oratrix.nl Tue Oct 23 21:37:21 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 23 Oct 2001 22:37:21 +0200 Subject: [Pythonmac-SIG] AE quit() ? In-Reply-To: Message by "Alexandre Parenteau" , Tue, 23 Oct 2001 07:58:16 -0700 , <003d01c15bd3$2603b9d0$4000a8c0@veropc> Message-ID: <20011023203726.87A27F58C3@oratrix.oratrix.nl> Recently, "Alexandre Parenteau" said: > Jack, > > Try : > > import CodeWarrior > shell = CodeWarrior.CodeWarrior('CWIE', 1) > shell.quit() It doesn't work for me either, but at least I know who to blame:-) Apple moved open/quit/print/reopen from the required suite to the standard suite. Codewarrior extends the required suite but completely overrides the standard suite. So, technically (according to their AEUT resource) codewarrior no longer supports the quit event. Nobody in the world cares, except Python. At least, that's what I think is happening. I've added a manual patch, replace the class declaration in CodeWarrior:Standard_suite.py by from StdSuites.Standard_Suite import * class Standard_Suite_Events(Standard_Suite_Events): -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Tue Oct 23 21:42:36 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 23 Oct 2001 22:42:36 +0200 Subject: [Pythonmac-SIG] tkinter question In-Reply-To: Message by Chris Scott , Tue, 23 Oct 2001 12:37:36 -0400 , Message-ID: <20011023204241.D9382F58C3@oratrix.oratrix.nl> Recently, Chris Scott said: > Traceback (most recent call last): > File "", line 1, in ? > ImportError: Tkinter not supported under Carbon (yet). The good news is that Tkinter does work under Classic. By running ConfigurePythonClassic you switch Python to use classic (and by running ConfigurePythonCarbon you switch back again). This question pops up fairly often, does anyone have a suggestion for a better error message, that points people in the right direction? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From dpreston@intersight.com Tue Oct 23 21:43:27 2001 From: dpreston@intersight.com (Donovan Preston) Date: Tue, 23 Oct 2001 13:43:27 -0700 Subject: [Pythonmac-SIG] Problems with new features introduced during beta, anyone? In-Reply-To: <20011023201543.89BAEEDD23@oratrix.oratrix.nl> Message-ID: <9C4E47AC-C7F6-11D5-BCA1-003065B33450@intersight.com> On Tuesday, October 23, 2001, at 01:15 PM, Jack Jansen wrote: > Folks, > I'm pretty far along with MacPython 2.2b1, but suddenly on my doorstep > I find a couple of very nifty modules: CarbonEvents and a hfs+ API > module. And there's mods I got to allow MacPython to use the OSX > bundle format (so you can have an OS9/OSX bundle) that I can't enable > right now. And there might be Alexandre's new preference stuff and/or > my newline stuff. > > There are a few things I can do: > 1. Forget about these for MacPython 2.2 and leave them for 2.3. > 2. Forget about MacPython 2.2b1, incorporate these modules and pick up > the release trail again at the time of Python 2.2b2. > 3. Do MacPython 2.2b1 now, and sneak in the new features for 2.2b2 > (labeled "experimental"). > > I'm tempted to do 3, but I'd like to hear what you all think, I vote for #2. Of course, I'm biased, I'd really like to see the new code in a release. It would also probably be less work for you if you didn't have to package up 2.2b1. But, if you've already done most of the work for 2.2b1 and don't mind finishing it up _and_ releasing a 2.2b2 with some new modules, that's cool too. 2.3? Sheesh... personally, I would prefer more spaced out, featurely releases, mostly because I get tired of upgrading 10 machines every couple of months (it seems like), but also because ISPs seem to get stuck behind the upgrade curve... most ISPs are still on 2.0, or even 1.5.2. Donovan From joerg@kantel.de Tue Oct 23 22:36:04 2001 From: joerg@kantel.de (=?iso-8859-1?Q?J=F6rg?= Kantel) Date: Tue, 23 Oct 2001 23:36:04 +0200 Subject: [Pythonmac-SIG] MacPython on multiprocessor OSX 10.1 In-Reply-To: <20011023143643.092F6EDD23@oratrix.oratrix.nl> Message-ID: <20011023233910-r01010800-56593de6-0920-010c@192.168.1.75> On 23.10.2001 at 16:36 Uhr, jack@oratrix.nl (Jack Jansen) wrote: >Folks, >when 10.1 was still not officially out I got some notes that seemed to >suggest that the problem with MacPython on a multiprocessor OSX >machine (it would hang during I/O, usually already in >ConfigurePythonCarbon) is gone in 10.1. > >Could someone with a 10.1 multiprocessor please give MacPython 2.2a3 a >try, and tell me whether the problem has indeed been solved? Sorry, I tried it but it still doesn't work. I downloaded a fresh copy of MacPython 2.2a3 (awfully slow) and run the Installer succesfull. But "Configure Python Carbon" still hangs by "Creating PythonCore aliases..." :-( Configuration: PowerMac G4 2 Processors 500 Mhz, Mac OS 10.1 Sorry, no better news... J"org -- mail: joerg@kantel.de # jkantel@mac.com visit: http://www.rollberg.de/ - die etwas anderen Nachrichten http://www.schockwellenreiter.de/ - (m)ein Weblog From alexp@strata.com Tue Oct 23 23:55:16 2001 From: alexp@strata.com (Alexandre Parenteau) Date: Tue, 23 Oct 2001 15:55:16 -0700 Subject: [Pythonmac-SIG] Difficult problem for MacPython on X Message-ID: Hello, This is about the SMP problem of MacPython on X Jack was talking about. In GUSI 2.0, the socket which manipulates the files do the read/write operations asynchronously. We already experienced a problem with the GUSIMacFile.cp module (namely the lseek problem previously described in this thread). By asynchronously, it really means that it calls PBReadAsync/PBWriteAsync with a completion function. Then there is a mechanism to manage 2 buffers (R/W) which are filled by the completion routines and flushed by the GUSIMacFileSocket read/write methods. Here is the problem : on Mac classic, these completions routines are called on an interruption. It means that we are guaranteed to be in a cooperative environment. But on OSX, these completion routines are called from pre-emptive threads directly by the kernel. The current GUSI code assumes completely we are in a cooperative environment, and thus it manipulates a simple integer counter to know if the buffer is currently being filled or flushed. When I first ported GUSI to Carbon I was not aware of this problem. Now I'm thinking that because of that, GUSI for Carbon on OSX is essentially broken and cannot work. Even on a single processor, a pre-emptive call is likely to break the buffers. This is bad for MacPython and bad for MacCvs. I wish we had a work around because both of the projects were kind of expecting to smoothly switch to OSX by first porting the existing application using GUSI carbon, and *then* getting rid of GUSI. Now it means that it is probably impossible to delay the port to mach-o. Unless Matthias helps, I think that we are stuck at this point. Regards, Alex. CC: Matthias From dpreston@intersight.com Wed Oct 24 01:53:58 2001 From: dpreston@intersight.com (Donovan Preston) Date: Tue, 23 Oct 2001 17:53:58 -0700 Subject: [Pythonmac-SIG] Difficult problem for MacPython on X In-Reply-To: Message-ID: <9B5A2F20-C819-11D5-81BF-0050E425C324@intersight.com> On Tuesday, October 23, 2001, at 03:55 PM, Alexandre Parenteau wrote: > Hello, > > This is about the SMP problem of MacPython on X Jack was talking about. > > In GUSI 2.0, the socket which manipulates the files do the read/write > operations asynchronously. We already experienced a problem with the > GUSIMacFile.cp module (namely the lseek problem previously described in > this > thread). > > By asynchronously, it really means that it calls > PBReadAsync/PBWriteAsync > with a completion function. Then there is a mechanism to manage 2 > buffers > (R/W) which are filled by the completion routines and flushed by the > GUSIMacFileSocket read/write methods. > > Here is the problem : on Mac classic, these completions routines are > called > on an interruption. It means that we are guaranteed to be in a > cooperative > environment. > > But on OSX, these completion routines are called from pre-emptive > threads > directly by the kernel. > > The current GUSI code assumes completely we are in a cooperative > environment, and thus it manipulates a simple integer counter to know > if the > buffer is currently being filled or flushed. There is a solution. If I understand correctly, the problem is that what was an interrupt-level function on OS 9 (that could not be interrupted) is being interrupted by a call to that _same_ function or a call to _some_other_ function which manipulates data the first function was using. This is, of course, a problem with any preemptive environment but wasn't a problem on Mac OS 9 _except_ when dealing with multiple processors. So apple's engineers gave us a solution, which is also present in Carbon. It's the Multiprocessing Services API: http://developer.apple.com/techpubs/macosx/Carbon/oss/MultiPServices/Multiprocessing_Services/ index.html It's possible to create a global mutex lock object with MPCreateCriticalRegion. This should be done during the initialization of GUSI and it should be a global, because only one should exist that every function that must be run exclusively should use. Then, when you enter your callback, you should attempt to acquire the lock with MPEnterCriticalRegion. Release it at the very end of the callback with MPExitCriticalRegion. Then, when GUSI is going away, delete the lock with MPDeleteCriticalRegion. Hopefully this is a solution. Jack, you may note that I used a lock of this type to allow the main python thread to continue running while RunApplicationEventLoop is blocked waiting for events. Donovan From kaffeen@mac.com Wed Oct 24 02:01:14 2001 From: kaffeen@mac.com (Chris Scott) Date: Tue, 23 Oct 2001 21:01:14 -0400 Subject: [Pythonmac-SIG] tkinter question References: <20011023204241.D9382F58C3@oratrix.oratrix.nl> Message-ID: <3BD612DA.5AF9C6D8@mac.com> Thanks for the reponse Jack, I appreciate the help. One thing of note, I'm actually running Mac OS 9, I don't even have OS X on my machine yet (waiting for a few more programs to be upgraded) and I'm still getting that error. I shouldn't be running Carbon, should I? - Chris Jack Jansen wrote: > Recently, Chris Scott said: > > Traceback (most recent call last): > > File "", line 1, in ? > > ImportError: Tkinter not supported under Carbon (yet). > > The good news is that Tkinter does work under Classic. By running > ConfigurePythonClassic you switch Python to use classic (and by > running ConfigurePythonCarbon you switch back again). > > This question pops up fairly often, does anyone have a suggestion for > a better error message, that points people in the right direction? > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From vincem@en.com Wed Oct 24 02:19:15 2001 From: vincem@en.com (Vincent Marchetti) Date: Tue, 23 Oct 2001 21:19:15 -0400 Subject: [Pythonmac-SIG] AE quit() ? Message-ID: -- Alexandre Parenteau wrote that the following doesn't work, in attempting to send AppleEvents to the CodeWarrior application: import CodeWarrior shell = CodeWarrior.CodeWarrior('CWIE', 1) shell.quit() giving an error indicating that shell has no 'quit' attribute. I think this is a result of ambiguous or incomplete "inheritance" rules in the aete dictionaries defining an applications OSA interface. The 'quit' event is supposed to be defined in the "Required Events" Suite (along with open, run, print. It isn't; though; it could also be defined in Standard Events; but it isn't defined there either; and since CodeWarrior; along with any app that uses PowerPlant,defines a non-standard identifier for the Standard Events (CoRe instead of core) the StdSuite.Standard_Suite module events are not being imported. The quickest solution, I think , is to go into the StdSuite package, module Standard_Suite.py; copy the quit method from the class Standard_Suite_Events; and paste it right into the CodeWarrior class in the __init__ module for the CodeWarrior package. Vince Marchetti From jack@oratrix.nl Wed Oct 24 09:41:28 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 24 Oct 2001 10:41:28 +0200 Subject: [Pythonmac-SIG] tkinter question In-Reply-To: Message by Chris Scott , Tue, 23 Oct 2001 21:01:14 -0400 , <3BD612DA.5AF9C6D8@mac.com> Message-ID: <20011024084128.A4BA4303181@snelboot.oratrix.nl> > Thanks for the reponse Jack, I appreciate the help. One thing of note, I'm > actually running Mac OS 9, I don't even have OS X on my machine yet (waiting for > a few more programs to be upgraded) and I'm still getting that error. I > shouldn't be running Carbon, should I? On OS9 you have the choice. On OS8 you can only run Classic (unless you install CarbonLib yourself, but lets skip that for the moment), on OSX you can only run Carbon (if we ignore the classic box for now) on OS9 you can run both. Carbon has a couple of modules Classic is missing, and it's on the path to the future, so that's why the Python installer configures Carbon by default if both are possible. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Wed Oct 24 09:46:18 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 24 Oct 2001 10:46:18 +0200 Subject: [Pythonmac-SIG] AE quit() ? In-Reply-To: Message by Vincent Marchetti , Tue, 23 Oct 2001 21:19:15 -0400 , Message-ID: <20011024084618.78E5B303181@snelboot.oratrix.nl> ... And I just noticed that Python isn't alone in missing the quit() command for CodeWarrior (and other PowerPlant apps, as Vince pointed out): Script Editor also doesn't know about it! I wonder why MetroWerks renamed the core suite to CoRe... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jwblist@olympus.net Wed Oct 24 16:29:13 2001 From: jwblist@olympus.net (John W Baxter) Date: Wed, 24 Oct 2001 08:29:13 -0700 Subject: [Pythonmac-SIG] AE quit() ? In-Reply-To: <20011024084618.78E5B303181@snelboot.oratrix.nl> References: <20011024084618.78E5B303181@snelboot.oratrix.nl> Message-ID: At 10:46 +0200 10/24/2001, Jack Jansen wrote: >I wonder why MetroWerks renamed the core suite to CoRe... This *could* have to do with issues of running applications under the debugger. (Someone with a nice collection of old CW could tell us if the change coincided with the--unwanted by me--incorporation of the debugger into the IDE.) As a horrible example of what can go wrong, years ago I was sending events to an application I was debugging under Think C (I said "years ago"). Then, with Think C running, but not my application, but with the app still open in Think C, I accidentally ran (or deliberately compiled...I'm not sure) the script again. AppleScript decided the tells went to Think C. Then I ran the script without Think C running, and it tried to launch the app's project file as if it were an application. The Process Manager got far enough into the launch to pass control to the non-code in the project file. Oops. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From dev@brotsky.com Wed Oct 24 16:25:18 2001 From: dev@brotsky.com (Daniel Brotsky) Date: Wed, 24 Oct 2001 08:25:18 -0700 Subject: [Pythonmac-SIG] MacPython on multiprocessor OSX 10.1 In-Reply-To: <20011023233910-r01010800-56593de6-0920-010c@192.168.1.75> References: <20011023233910-r01010800-56593de6-0920-010c@192.168.1.75> Message-ID: >On 23.10.2001 at 16:36 Uhr, jack@oratrix.nl (Jack Jansen) wrote: >>Folks, >>when 10.1 was still not officially out I got some notes that seemed to >>suggest that the problem with MacPython on a multiprocessor OSX >>machine (it would hang during I/O, usually already in >>ConfigurePythonCarbon) is gone in 10.1. Actually I get this on my Titanium (single-processor) G4 running under 9.2.1. After the "Copy or Alias" dialog (which I get because I installed 2.2.1 while booted under 10.1 on the OS X disk), if I choose "Copy" I get a hang almost every time, but if I choose "Alias" it always works. Does anyone else see this? dan From joerg@kantel.de Wed Oct 24 16:51:19 2001 From: joerg@kantel.de (=?iso-8859-1?Q?J=F6rg?= Kantel) Date: Wed, 24 Oct 2001 17:51:19 +0200 Subject: [Pythonmac-SIG] MacPython on multiprocessor OSX 10.1 In-Reply-To: References: <20011023233910-r01010800-56593de6-0920-010c@192.168.1.75> Message-ID: >>>when 10.1 was still not officially out I got some notes that seemed to >>>suggest that the problem with MacPython on a multiprocessor OSX >>>machine (it would hang during I/O, usually already in >>>ConfigurePythonCarbon) is gone in 10.1. > >Actually I get this on my Titanium (single-processor) G4 running >under 9.2.1. After the "Copy or Alias" dialog (which I get because >I installed 2.2.1 while booted under 10.1 on the OS X disk), if I >choose "Copy" I get a hang almost every time, but if I choose >"Alias" it always works. Yes, with my Titanium I've made the same experience. But I get it to work... :o) But on my Dual Processor G4 with Mac OS 10.1 it never works. For the test yesterday night I deleted nearly everything what could be disturb, downloaded a fresh copy and tried to install. Configure Python Carbon hangs... :-( J"org -- -- email: joerg@kantel.de # jkantel@mac.com www : http://www.schockwellenreiter.de/ - (m)ein Weblog http://www.rollberg.de/ - all the news you want http://www.kantel.de/ From Benjamin.Schollnick@usa.xerox.com Wed Oct 24 16:57:33 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Wed, 24 Oct 2001 11:57:33 -0400 Subject: [Pythonmac-SIG] Problems with new features introduced during beta, anyone? Message-ID: Jack, My feel on this is _almost_ simple: * Forget about the new features, and stay with baseline v2.2b1. or * Add the features as experimental, but ensure that it's simple to disable the features. (For example, they are in modules that have to be imported to add functionality). I still haven't seen a list of new features in v2.2, and I'm still using v2.0 (Macintosh), and v2.1 (PC).... As long as it's stable, and works, and doesn't have new features that I need to use (or bug fixes that I need) I generally don't upgrade... Python is unusual in the fact that it's mostly (95%+) backward comptiable.... The only thing that has "bitten" me is that in v1.52 (?) was that there was a bug in the socket code that allowed a non-tuple form to be used (in bind or connect?)... But that was simply fixed... I'm all for adding new features, but to me stablity and not having a "release of the week", is one of the features that I desire..... - Benjamin -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Tuesday, October 23, 2001 4:16 PM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] Problems with new features introduced during beta, anyone? Folks, I'm pretty far along with MacPython 2.2b1, but suddenly on my doorstep I find a couple of very nifty modules: CarbonEvents and a hfs+ API module. And there's mods I got to allow MacPython to use the OSX bundle format (so you can have an OS9/OSX bundle) that I can't enable right now. And there might be Alexandre's new preference stuff and/or my newline stuff. There are a few things I can do: 1. Forget about these for MacPython 2.2 and leave them for 2.3. 2. Forget about MacPython 2.2b1, incorporate these modules and pick up the release trail again at the time of Python 2.2b2. 3. Do MacPython 2.2b1 now, and sneak in the new features for 2.2b2 (labeled "experimental"). I'm tempted to do 3, but I'd like to hear what you all think, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From cpr@emsoftware.com Thu Oct 25 22:55:37 2001 From: cpr@emsoftware.com (Chris Ryland) Date: Thu, 25 Oct 2001 17:55:37 -0400 Subject: [Pythonmac-SIG] newbie question re W/Framework tools under MacPython Message-ID: <00df01c15d9f$da914020$6401a8c0@EM2> I'm new to the Python-Mac mailing list, and fairly new to Python, but am contemplating using it for some short-term real shippable data-publishing products under MacOS Classic and X (and also Win32). My basic question is: What is the concensus (if there is one) about using the W/Framework tools for creating native Mac apps? Is it a dead end? Even if so, is it a *reliable* dead end? ;-) Any comments appreciated. I realize it's something of a dead end by definition unless someone is planning a Carbonized version. -- Cheers! Chris Ryland Em Software, Inc. www.emsoftware.com From dpreston@intersight.com Thu Oct 25 23:50:04 2001 From: dpreston@intersight.com (Donovan Preston) Date: Thu, 25 Oct 2001 15:50:04 -0700 Subject: [Pythonmac-SIG] newbie question re W/Framework tools under MacPython In-Reply-To: <00df01c15d9f$da914020$6401a8c0@EM2> Message-ID: On Thursday, October 25, 2001, at 02:55 PM, Chris Ryland wrote: > I'm new to the Python-Mac mailing list, and fairly new to Python, but am > contemplating using it for some short-term real shippable > data-publishing > products under MacOS Classic and X (and also Win32). > > My basic question is: What is the concensus (if there is one) about > using > the W/Framework tools for creating native Mac apps? Is it a dead end? > Even > if so, is it a *reliable* dead end? ;-) > > Any comments appreciated. > > I realize it's something of a dead end by definition unless someone is > planning a Carbonized version. W is already carbonized. W is what the IDE is programmed in, after all. I suppose it depends how complex of an app you want to develop. If you are content to confine yourself to the types of widgets that are present in the Python IDE, text boxes, buttons, scrollable text areas, lists, and pop up menus, then it works great. Probably it's greatest deficiency is an almost utter lack of documentation. However, you can always just read the code, and it's not like it's the most complex framework in the world. Of course, it is not cross platform. My opinion is the most promising solution for cross platform GUI python apps would be wxPython, but there continues to not be a wxPython for the Mac, and probably won't be for quite some time. People have been bemoaning the lack of wxPython on the mac for quite a few years. There's my input! Donovan From jack@oratrix.nl Thu Oct 25 23:50:08 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 26 Oct 2001 00:50:08 +0200 Subject: [Pythonmac-SIG] newbie question re W/Framework tools under MacPython In-Reply-To: Message by "Chris Ryland" , Thu, 25 Oct 2001 17:55:37 -0400 , <00df01c15d9f$da914020$6401a8c0@EM2> Message-ID: <20011025225013.AFFF0DDDEB@oratrix.oratrix.nl> Recently, "Chris Ryland" said: > I'm new to the Python-Mac mailing list, and fairly new to Python, but am > contemplating using it for some short-term real shippable data-publishing > products under MacOS Classic and X (and also Win32). > > My basic question is: What is the concensus (if there is one) about using > the W/Framework tools for creating native Mac apps? Is it a dead end? Even > if so, is it a *reliable* dead end? ;-) W and Framework are used by the IDE, so it's definitely not a dead end. The API might change when we move to Carbon Events, though, especially the event-handling-override and event-routing code of Framework. I'd be interested to know how many people use this, to see how important backwards compatibility is (which may ultimately come in the form of two Framework versions, of which one continues to use old-style events). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From wddozier@mac.com Fri Oct 26 07:12:56 2001 From: wddozier@mac.com (Bill Dozier) Date: Fri, 26 Oct 2001 01:12:56 -0500 Subject: [Pythonmac-SIG] Problems with new features introduced during beta, anyone? In-Reply-To: <20011023201543.89BAEEDD23@oratrix.oratrix.nl> Message-ID: > > There are a few things I can do: > 1. Forget about these for MacPython 2.2 and leave them for 2.3. > 2. Forget about MacPython 2.2b1, incorporate these modules and pick up > the release trail again at the time of Python 2.2b2. > 3. Do MacPython 2.2b1 now, and sneak in the new features for 2.2b2 > (labeled "experimental"). I'll vote for 2 or 3. From ryanwilcox@mac.com Fri Oct 26 07:25:43 2001 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Fri, 26 Oct 2001 02:25:43 -0400 Subject: [Pythonmac-SIG] Bug in ConfigureCarbon In-Reply-To: <20011025225013.AFFF0DDDEB@oratrix.oratrix.nl> Message-ID: <20011026022545-r01010800-daf81080-0920-010c@129.21.139.101> [Note: If I had time I would fix this bug myself and submit changes. But right now time is at a premium, so I'm just going to report it] (On OS X MacPython) --------------------- ConfigurePythonCarbon fails on users that don't have admin privs. (It tries to write PythonCore to /Library/ and fails, for obvious reasons). I think it would be very useful to fix this bug. For example, at the office where I work I log in as a non-admin user. There's no way I can get admin access for this machine (read: lab machine). But today I wanted to install MacPython. But I couldn't do anything useful because ConfigurePythonCarbon failed, thus not building the IDE. And I couldn't seem to call the Interpreter via the command line (although I may have been doing it wrong). Thanks for looking into this!, -Ryan the Late Warrior Wilcox PGP key available on keyserver.pgg.com PGP fingerprint: 2B1D 8B69 318C F876 A6ED FE0B 6D83 B4A8 2F4E 9C31 From jack@oratrix.nl Fri Oct 26 10:22:37 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 26 Oct 2001 11:22:37 +0200 Subject: [Pythonmac-SIG] MacPython 2.2b1 is out Message-ID: <20011026092237.BE716303181@snelboot.oratrix.nl> Folks, MacPython 2.2b1 is finished. There are very little mac-dependent changes since 2.2a3, but quite a few in the machine-independent stuff. I'm only advertising this here for today, please send me "it works" notes so I know I can advertise it more widely. Oh yes, download via http://www.cwi.nl/~jack/macpython.html, as usual. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From jack@oratrix.nl Fri Oct 26 11:54:18 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 26 Oct 2001 12:54:18 +0200 Subject: [Pythonmac-SIG] MacPython 2.2b1 is out In-Reply-To: Message by Jack Jansen , Fri, 26 Oct 2001 11:22:37 +0200 , <20011026092237.BE716303181@snelboot.oratrix.nl> Message-ID: <20011026105418.B1884303181@snelboot.oratrix.nl> Oh yes, something else: as I'm busy with a gazillion things there is a very good chance that I have forgotten to include contributions that people sent me. If you contributed something and haven't heard back from me and don't find your contribution in 2.2b1: please let me know. I never intend to drop things on the floor without answer, but I'm only human. The contributions that are NOT in 2.2b1, but that I haven't forgotten about (so no need to bother me just yet) are - preference storage mods - Carbon Events module - IBCarbonRuntime - new file manager API module - bgen manual kickoff The OS9 bundle mods are in the sourcecode but disabled, unfortunately, because I didn't have time to upgrade my CodeWarrior or Universal Headers to a version that would allow inclusion. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From chrishbarker@home.net Fri Oct 26 21:15:03 2001 From: chrishbarker@home.net (Chris Barker) Date: Fri, 26 Oct 2001 13:15:03 -0700 Subject: [Pythonmac-SIG] wxMacPython status: References: Message-ID: <3BD9C447.500FAE95@home.net> Donovan Preston wrote: > Of course, it is not cross platform. My opinion is the most promising > solution for cross platform GUI python apps would be wxPython, but there > continues to not be a wxPython for the Mac, and probably won't be for > quite some time. People have been bemoaning the lack of wxPython on the > mac for quite a few years. It did sound like the OP was working with multiple platforms, so a cross platform solution would be best. The news on wxPython is a little better that jyou have made it sound. Here is an update as I understand it. Robin Dunn, the wxPython developer has been given a Mac by Apple, and is working on wxPython for the Mac. He has a whhole lot on his plate, and has little Mac experience, so it is slow going. Stefan Csomor, the C++ wxMac developer, also made a start at a wxMacPython, but has since decided to wait and see what Robin will come up with. Robin is primarily targeting OS-X, but Stefan has said that he will do the Classic version if need be, as many folks are still running Classic. It is Carbon based, so it will only work on versions with Carbonlib available (8.6 and up I believe) The C++ wxWindows has recently seen quite a lot of improvement, and, as I understand it, is pretty close in functionality to the MSW and GTK versions. MacPython's Jack Jansen has said that he has no time to work on wx, but is happy to answer questions and help out when he can. I recently got an offer from Apple to provide some level of support to the project. How much is yet to be determined, but they mentioned possibly lending hardware and tech support. At the moment, is seems everyone working on it is limited by time, and neither hardware nor tech support will help much. If, however, one of you has the time and skills to work on it, let me know. I am acting as the point of contact to Apple at the moment, and I might be able to get you a machine and some tech support. The short version is: wxMacPython is coming, we don't know when, and if you have time and C++, Python, and Mac Programming skills, you can help, and you might even get help from Apple. -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From cpr@emsoftware.com Sat Oct 27 15:42:52 2001 From: cpr@emsoftware.com (Chris Ryland) Date: Sat, 27 Oct 2001 10:42:52 -0400 Subject: [Pythonmac-SIG] ODBC under MacPython? Message-ID: <072401c15ef5$ba69f830$6401a8c0@EM2> Has anyone recently & successfully used ODBC (I suppose with the latest Merant drivers (3.5.1)) with MacPython? Just curious if there are pitfalls or other things for which to watch. Thanks in advance. -- Cheers! Chris Ryland Em Software, Inc. www.emsoftware.com From cwebster@unlv.edu Mon Oct 29 21:10:26 2001 From: cwebster@unlv.edu (Corran Webster) Date: Mon, 29 Oct 2001 13:10:26 -0800 Subject: [Pythonmac-SIG] newbie question re W/Framework tools under MacPython In-Reply-To: References: Message-ID: At 3:50 PM -0700 25/10/01, Donovan Preston wrote: >On Thursday, October 25, 2001, at 02:55 PM, Chris Ryland wrote: > >>I'm new to the Python-Mac mailing list, and fairly new to Python, but am >>contemplating using it for some short-term real shippable data-publishing >>products under MacOS Classic and X (and also Win32). >> >>My basic question is: What is the concensus (if there is one) about using >>the W/Framework tools for creating native Mac apps? Is it a dead end? Even >>if so, is it a *reliable* dead end? ;-) >> >>Any comments appreciated. >> >>I realize it's something of a dead end by definition unless someone is >>planning a Carbonized version. > >W is already carbonized. W is what the IDE is programmed in, after all. > >I suppose it depends how complex of an app you want to develop. If >you are content to confine yourself to the types of widgets that are >present in the Python IDE, text boxes, buttons, scrollable text >areas, lists, and pop up menus, then it works great. It's pretty easy to extend to other sorts of widgets. >Probably it's greatest deficiency is an almost utter lack of >documentation. However, you can always just read the code, and it's >not like it's the most complex framework in the world. It's probably about time to mention this again: http://www.nevada.edu/~cwebster/Python/WWidgets/index.html Far from complete, but hopefully more than enough to get people started with W. >Of course, it is not cross platform. My opinion is the most >promising solution for cross platform GUI python apps would be >wxPython, but there continues to not be a wxPython for the Mac, and >probably won't be for quite some time. People have been bemoaning >the lack of wxPython on the mac for quite a few years. I'm hoping that the anygui project will provide a good cross-platform environment, but the current release doesn't seem to have anything for the mac yet. Regards, Corran -- Corran Webster, Assistant Professor, Department of Mathematical Sciences, University of Nevada Las Vegas From lmeyn@mail.arc.nasa.gov Mon Oct 29 21:10:41 2001 From: lmeyn@mail.arc.nasa.gov (Larry Meyn) Date: Mon, 29 Oct 2001 13:10:41 -0800 Subject: [Pythonmac-SIG] A W backend for anygui In-Reply-To: <20011025225013.AFFF0DDDEB@oratrix.oratrix.nl> References: <20011025225013.AFFF0DDDEB@oratrix.oratrix.nl> Message-ID: I recently came across a notice about the "anygui" project at source forge, http://anygui.sourceforge.net/, which is trying to create a generic Python GUI interface to several existing GUI packages. The currently planned list of backend interfaces includes: BeOS native Dynamic HTML Java Swing PythonWin/win32all PyGTK Tkinter wxPython PyQt Curses It seems like an anygui backend for the W package could solve some cross-platform GUI needs. Is there anyone around with the time and expertise to do this? Or is this even worth doing right now? -- ------------------------------------------------------------------ Larry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center FAX: (650) 604-0222 Moffett Field, CA 94035-1000 email: lmeyn@mail.arc.nasa.gov ------------------------------------------------------------------ From kaffeen@mac.com Mon Oct 29 21:15:43 2001 From: kaffeen@mac.com (Chris Scott) Date: Mon, 29 Oct 2001 16:15:43 -0500 Subject: [Pythonmac-SIG] Learning on the mac Message-ID: Anyone have any suggestions on Mac-centric books on learning Python? From jhrsn@pitt.edu Mon Oct 29 21:24:43 2001 From: jhrsn@pitt.edu (Jim Harrison) Date: Mon, 29 Oct 2001 16:24:43 -0500 Subject: [Pythonmac-SIG] A W backend for anygui In-Reply-To: Message-ID: on 10/29/01 4:10 PM, Larry Meyn at lmeyn@mail.arc.nasa.gov wrote: > It seems like an anygui backend for the W package could solve some > cross-platform GUI needs. Is there anyone around with the time and expertise > to do this? Or is this even worth doing right now? Just to provide a bit of additional info, in the IBM description of anygui, there's a reference to a backend interface to Aqua (Mac OSX). Apparently this already has a project lead. This may not be useful for those who will be staying with 9.x for a while, but it would be a fantastic thing to have as we migrate to X. I suppose an interface to W would be a decent way to maintain some level of compatibility with the pre-X Mac OSs. Jim Harrison Univ. of Pittsburgh From erwinmann@raetselservice.de Tue Oct 30 11:03:23 2001 From: erwinmann@raetselservice.de (Erwin Mann) Date: Tue, 30 Oct 2001 12:03:23 +0100 Subject: [Pythonmac-SIG] debugging problem Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3087288203_407052_MIME_Part Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable hi folks! I just installed MacPython22b1 and run into a strange problem while trying to debug a little python program. After activating the debugger from the ID= E and clicking on the =B3run all=B2 button I got the following traceback: ------ TypeError: unbound method __init__() must be called with ClickableWidget instance as first argument (got HorizontalPanes instance instead) TZraceback (innermost last): File "Wapplication.py", line 35, in mainloop self.do1event(mask, wait) File "FrameWork.py", line 177, in do1event self.dispatch(event) File "FrameWork.py", line 210, in dispatch handler(event) File "FrameWork.py", line 269, in do_mouseDown handler(partcode, wid, event) File "FrameWork.py", line 788, in do_inContent self.do_contentclick(local, modifiers, event) File "Wwindows.py", line 338, in do_contentclick widget.click(point, modifiers) File "Wcontrols.py", line 87, in click Wbase.CallbackCall(self._callback, 0) File "Wbase.py", line 686, in CallbackCall return apply(callback, args) File "PyEdit.py", line 489, in run self._run() File "PyEdit.py", line 515, in _run self.execstring(pytext, globals, globals, file, modname) File "PyEdit.py", line 620, in execstring modname, self.profiling) File "PyEdit.py", line 1157, in execstring PyDebugger.postmortem(sys.exc_type, sys.exc_value, sys.exc_traceback) File "PyDebugger.py", line 845, in postmortem d.postmortem(exc_type, exc_value, tb) File "PyDebugger.py", line 115, in postmortem self.setupwidgets(self.title) File "PyDebugger.py", line 139, in setupwidgets w.panes =3D W.HorizontalPanes((8, 4, -8, -8), self.horpanes) File "Wbase.py", line 458, in __init__ ClickableWidget.__init__(self, possize) ----- Any ideas what caused this strange behaviour? I'm using a G4 with MacOS 9.2= . Any help appreciated!!! Thanks a lot Erwin Mann --MS_Mac_OE_3087288203_407052_MIME_Part Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable debugging problem hi folks!

I just installed MacPython22b1 and run into a strange problem while trying = to debug a little python program. After activating the debugger from the IDE= and clicking on the =B3run all=B2 button I got the following traceback:

------
TypeError: unbound method __init__() must be called with ClickableWidget instance as first argument (got HorizontalPanes instance instead)
TZraceback (innermost last):

File "Wapplication.py", line 35, in mainloop
    self.do1event(mask, wait)
File "FrameWork.py", line 177, in do1event
    self.dispatch(event)
File "FrameWork.py", line 210, in dispatch
    handler(event)
File "FrameWork.py", line 269, in do_mouseDown
    handler(partcode, wid, event)
File "FrameWork.py", line 788, in do_inContent
    self.do_contentclick(local, modifiers, event)
File "Wwindows.py", line 338, in do_contentclick
    widget.click(point, modifiers)
File "Wcontrols.py", line 87, in click
    Wbase.CallbackCall(self._callback, 0)
File "Wbase.py", line 686, in CallbackCall
    return apply(callback, args)
File "PyEdit.py", line 489, in run
    self._run()
File "PyEdit.py", line 515, in _run
    self.execstring(pytext, globals, globals, file, mo= dname)
File "PyEdit.py", line 620, in execstring
    modname, self.profiling)
File "PyEdit.py", line 1157, in execstring
    PyDebugger.postmortem(sys.exc_type, sys.exc_value,= sys.exc_traceback)
File "PyDebugger.py", line 845, in postmortem
    d.postmortem(exc_type, exc_value, tb)
File "PyDebugger.py", line 115, in postmortem
    self.setupwidgets(self.title)
File "PyDebugger.py", line 139, in setupwidgets
    w.panes =3D W.HorizontalPanes((8, 4, -8, -8), self.h= orpanes)
File "Wbase.py", line 458, in __init__
    ClickableWidget.__init__(self, possize)

-----

Any ideas what caused this strange behaviour? I'm using a G4 with MacOS 9.2= .

Any help appreciated!!!


Thanks a lot

Erwin Mann


 --MS_Mac_OE_3087288203_407052_MIME_Part-- From owen@astro.washington.edu Tue Oct 30 17:37:08 2001 From: owen@astro.washington.edu (Russell E Owen) Date: Tue, 30 Oct 2001 09:37:08 -0800 Subject: [Pythonmac-SIG] 2.2b1: test mysteries and import problems Message-ID: I installed MacPython 2.2b1 onto my G4 running MacOS 9.2.1. I used the active installer, for what it's worth. I then ran ConfigurePythonClassic, since I make heavy use of Tkinter. Running "from test import autotest" from the interpreter mostly worked, but one or two errors looked odd. 143 tests OK. 4 tests failed: test_longexp test_sha test_time test_zlib 34 tests skipped: test_al test_bsddb test_cd test_cl test_commands test_crypt test_dbm test_dl test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile test_linuxaudiodev test_locale test_mmap test_nis test_ntpath test_openpty test_poll test_popen2 test_pty test_pwd test_signal test_socket_ssl test_socketserver test_sunaudiodev test_sundry test_threaded_import test_timing test_unicode_file test_winreg test_winsound 1 skip unexpected on mac: test_threaded_import For what it's worth, test_threaded_import failed complaining about not need for or lack of an import lock. Relaunching the interpreter and running the tests again seemed to result in fewer tests being run -- quite strange. No sign of the mystery "test_threaded_import". 106 tests OK. 3 tests failed: test_longexp test_sha test_zlib 30 tests skipped: test_al test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gc test_gl test_grp test_imgfile test_largefile test_linuxaudiodev test_locale test_mmap test_nis test_openpty test_poll test_popen2 test_pty test_pwd test_signal test_socketserver test_sunaudiodev test_sundry test_timing test_winreg test_winsound I then tried to run my own code. The main code failed because I'd forgotten to set my paths. No problem, I ran EditPythonPrefs and added my directories. I then tried to run my code, but the situation was no better. Now I was getting worried. So I did a bit of investigating. If I run EditPythonPrefs or drag PythonInterpreter onto it I see the following correct info: $(PYTHON) $(PYTHON):Mac:Lib $(PYTHON):Mac:Lib:lib-compat $(PYTHON):Mac:Lib:lib-scriptpackages $(PYTHON):Lib:lib-dynload $(PYTHON):Lib $(PYTHON):Extensions:img:Mac $(PYTHON):Extensions:img:Lib $(PYTHON):Extensions:Imaging $(PYTHON):Lib:lib-tk $(PYTHON):Lib:site-packages $(PYTHON)::PythonRO $(PYTHON)::PythonRO:Util $(PYTHON)::PythonRO:TUI However, if I run PythonInterpreter, my PythonRO entries are missing: >>> import sys >>> for item in sys.path: ... print item ... RussMain:Applications (Mac OS 9):Python 2.2b1 RussMain:Applications (Mac OS 9):Python 2.2b1:Mac:Lib RussMain:Applications (Mac OS 9):Python 2.2b1:Mac:Lib:lib-compat RussMain:Applications (Mac OS 9):Python 2.2b1:Mac:Lib:lib-scriptpackages RussMain:Applications (Mac OS 9):Python 2.2b1:Lib:lib-dynload RussMain:Applications (Mac OS 9):Python 2.2b1:Lib RussMain:Applications (Mac OS 9):Python 2.2b1:Extensions:img:Mac RussMain:Applications (Mac OS 9):Python 2.2b1:Extensions:img:Lib RussMain:Applications (Mac OS 9):Python 2.2b1:Extensions:Imaging RussMain:Applications (Mac OS 9):Python 2.2b1:Lib:lib-tk RussMain:Applications (Mac OS 9):Python 2.2b1:Lib:site-packages RussMain:Applications (Mac OS 9):Python 2.2b1:lib:site-packages:Numeric I was able to run some of my own code that didn't rely on finding things in other directories, and the few things I tried ran fine. So...anybody else seeing this? Any ideas? 2.1.1 is working just fine for me. Regards, -- Russell P.S. is there a more recent version of Tkinter? From owen@astro.washington.edu Tue Oct 30 17:44:22 2001 From: owen@astro.washington.edu (Russell E Owen) Date: Tue, 30 Oct 2001 09:44:22 -0800 Subject: [Pythonmac-SIG] 2.2b1 import errors were a false alarm Message-ID: Sorry...I forgot to move Python 2.2b1 to my usual location before trying to run my code. Once I fixed that import errors went away. Apparently when the interpreter starts up, it sensibly ignores any paths that don't exist. I am seeing a new error in my code, but no idea at present what it might mean. I'll report again when I figure it out. (I'll append a traceback, but I doubt it's informative. I'd wait to diagnose it, but wanted to correct my earlier import error report.) -- Russell Traceback (most recent call last): File "RussMain:Languages:PythonRO:TUI:Interface1_3.py", line 55, in ? telWdg = TelStatusWdg.TelStatusWdg (telWin, dispatcher=dispatcher) File "RussMain:Languages:PythonRO:TUI:TelStatusWdg:TelStatusWdg.py", line 18, in __init__ self.miscWdg = MiscWdg.MiscWdg(master=self, dispatcher=dispatcher) File "RussMain:Languages:PythonRO:TUI:TelStatusWdg:MiscWdg.py", line 131, in __init__ self.updateClock() File "RussMain:Languages:PythonRO:TUI:TelStatusWdg:MiscWdg.py", line 139, in updateClock self.utcWdg.dataWdg.set("%s:%02i:%02i" % currUTCTuple[3:6]) SystemError: error return without exception set From owen@astro.washington.edu Tue Oct 30 18:02:14 2001 From: owen@astro.washington.edu (Russell E Owen) Date: Tue, 30 Oct 2001 10:02:14 -0800 Subject: [Pythonmac-SIG] Mysterious SystemError in MacPython 2.2b1 Message-ID: The following code fails (G4, MacOS 9.2.1) in Classic MacPython 2.2b1: import time currUTCTuple= time.gmtime(time.time()) print "currUTCTuple=%r" % (currUTCTuple,) print "currUTCTuple[3:6]=%r" % (currUTCTuple[3:6],) fmtTime = "%s:%02i:%02i" % currUTCTuple[3:6] print "formatted time = ", fmtTime It displays (, , ) for currUTCTuple[3:6], which is wrong, and then the fmtTime =... statement raises a SystemError. Sometimes the PythonInterpreter or Python IDE to exit to the debugger showing an unmapped memory exception (and I have a StdLog from that if anybody wants it). Anybody else seeing this? -- Russell From sdm7g@Virginia.EDU Tue Oct 30 18:25:35 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Tue, 30 Oct 2001 13:25:35 -0500 (EST) Subject: [Pythonmac-SIG] Carbon.Win on OSX Python Message-ID: I used to be able to do: >>> w = Win.NewCWindow( (100,100,400,400), "NewCWindow" , 1, 0, -1, 0, 0 ) with the initial Carbonmodule.so that I built on OSX. Now I got the error message: kCGSErrorNoneAvailable : CGSOrderFrontConditionally: Process not found Using the modules built under 2.2b1. I went back and rebuilt my old Carbonmodule.so under 2.1.1 and I got the same error message. That *DID* work at one time. Maybe this is due to changes in OSX since the public beta. ( I'm still running 10.0.4 as I'm waiting for my 10.1 CD to arrive. ) [ Since the Carbon support under OSX was pretty experimental, I didn't use it enough to notice exactly WHEN this broke! ] If I use something other than -1 for the 'behind' parameter, the NewCWindow call will return a window object, but when I try to do certain calls like BringToFront(), I get the same error: >>> w.BringToFront() kCGSErrorNoneAvailable : CGSOrderFrontConditionally: Process not found Can anyone else here sell me a Clue? (Please!) -- Steve Majewski From chrishbarker@home.net Tue Oct 30 19:27:55 2001 From: chrishbarker@home.net (Chris Barker) Date: Tue, 30 Oct 2001 11:27:55 -0800 Subject: [Pythonmac-SIG] A W backend for anygui References: <20011025225013.AFFF0DDDEB@oratrix.oratrix.nl> Message-ID: <3BDEFF3B.416016C0@home.net> Larry Meyn wrote: > I recently came across a notice about the "anygui" project at source forge, http://anygui.sourceforge.net/, which is trying to create a generic Python GUI interface to several existing GUI packages. This is entirely just my not-the-least-bit-humble opinion, and I wish the anygui folks the best of luck, but I really think it is a dead end. Trying to write a single interface to a wide variety of GUI libraries is very difficult because each of those libraries has a different set of widgets, different behaviour, and different event models. The only way to accomidate all that is to have a very thick wrapper that either: targets the least common denominator: only those things all the targeted back ends support or targets the super-set: all the things that are supported by any individual back end, in which case you have to write emulation code for each back end for each feature it doesn't support. The downside of the second option is two-fold: It is a lot of work, and you are likely to have major performance problems if it's all in Python. Another issue I see is that the final result will be a wrapper around a wrapper, around a wrapper, etc like this: anygui -> tkinter -> tcl -> tk -> Win32 | X | MacToolbox or anygui -> wxPython -> wxWindows -> Win32 | GTK | ... My question is: what's the point? People have a lot of need to write one program that will run on multiple platforms, and with multiple look&feels, but why would you want multiple toolkits? The reason I choose one toolkit over another is a combination of supported platforms, supported features, and how much I like the API. If someone comes up with a toolkit that supports all the platforms I want, has the features I need, with a nice API, I will want to use it. I couldn't care less what the back end is. If successfull, the anyGUI project will create a nice API and a complete feature set, and it will run on numerous platforms. This is good, but when I look at this: The currently planned list of backend interfaces includes: > > BeOS native > Dynamic HTML > Java Swing > PythonWin/win32all > PyGTK > Tkinter > wxPython > PyQt > Curses I wonder why you would you need to support wxPython if you are supporting GTK, Win32, and hopefully MacOS in one form or another. Being able to support DHTML and Curses would be nice, but you simply can't write a rich GUI in those, so I wonder what they have in mind. Supporting JAVA/SWING is nice too, so if they can really make this work, that might be a plus. Anyway, this is why my money is on wxPython: It is not quite complete (particularly on the Mac), but neither is anyGUI. Essentially, the goal of wxWindows is similar to the anygui project, but in C++. This is a good thing, because it eliminates one layer of wrappers, and has significant perfomance advantages. If it continues on its present course is will meet all of my requirements: Supports the platforms I need: Win32, *nix (GTK | Motif), OS/2, Mac Classic and OS-X Has the features I need: A pretty rich set, with more to come, and pretty good performance. A nice API: Well, honestly, this is its weakest link. The wxPython wrappers are fairly thin wrappers around the C++, so the API is very similar. This is three advantages: 1) It is easier to do, with SWIG doing most of the work (Robin never would have gotten it to where it is without taking that approach). 2) The wxWindows docs and wxPtyhon docs are merged. Without that, would barely have wxPython docs. 3) If you are using Python as a prototyping language, you can later translate some or all of your GUI code from Python to C++ without changing the structure at all. There is hope on the API front as well. Kevin Altis has begun a project to write a thicker wrapper layer around wxWindows, so that Python users can have a more Pythonesque interface. We'll see where this project goes, but it has a lot of promise. Another problem with wrappers around wrappers is that there is a large chain of different projects that you are dependent on. Right now, wxPython depends on Python and wxWindows. Python is as wonderful as we all know it is, and wxWindows is being actively developed and supported, and the developers are supportive of Python. Right now there is no good framework for writing cross-platform apps that include the Mac. I really think we need one, and I'm convinced that wxPython is the best option at this point. It is absolutely closest to what is needed. > It seems like an anygui backend for the W package could solve some cross-platform GUI needs. Is there anyone around with the time and expertise to do this? Or is this even worth doing right now? You now know my answer to whether it is worth it, so I encourage anyone with the time and expertise to contribute to the wxPython project instead. OK, I'm done with my rant now.... -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------ From fgranger@altern.org Mon Oct 29 22:50:35 2001 From: fgranger@altern.org (Francois Granger) Date: Mon, 29 Oct 2001 23:50:35 +0100 Subject: [Pythonmac-SIG] newbie question re W/Framework tools under MacPython In-Reply-To: References: Message-ID: At 13:10 -0800 29/10/01, in message Re: [Pythonmac-SIG] newbie question re W/Framework tool, Corran Webster wrote: >I'm hoping that the anygui project will provide a good >cross-platform environment, So do I ! > but the current release doesn't seem to have anything for the mac yet. I downloaded it today because they say that Mac is currently supported throught tk. I did not had time to test yet. From csmith@blakeschool.org Tue Oct 30 20:00:03 2001 From: csmith@blakeschool.org (Christopher Smith) Date: Tue, 30 Oct 2001 14:00:03 -0600 Subject: [Pythonmac-SIG] Re: Learning on the mac In-Reply-To: References: Message-ID: Chris Scott writes: > >Anyone have any suggestions on Mac-centric books on learning Python? > I only work on a mac and used the Python tutorials, documentation, this list, and the book "How to think Like a Computer Scientist" (the Python version) as my resources. After working the problems in the book and doing a few of the challenge problems listed at the Useless Python site I felt like I had a pretty good introduction. If you are using the standard libraries of Python then it is my impression that the learning will be about the same on any system. What in particular do you want to learn? /c From jack@oratrix.nl Tue Oct 30 22:18:06 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 30 Oct 2001 23:18:06 +0100 Subject: [Pythonmac-SIG] Carbon.Win on OSX Python In-Reply-To: Message by "Steven D. Majewski" , Tue, 30 Oct 2001 13:25:35 -0500 (EST) , Message-ID: <20011030221811.7B1FFFB04A@oratrix.oratrix.nl> Recently, "Steven D. Majewski" said: > > I used to be able to do: > > >>> w = Win.NewCWindow( (100,100,400,400), "NewCWindow" , 1, 0, -1, 0, 0 ) > > with the initial Carbonmodule.so that I built on OSX. > > Now I got the error message: > > kCGSErrorNoneAvailable : CGSOrderFrontConditionally: Process not found I think this has to do with your Python not being a fullblown application. 10.0 was pickier than public beta about this, and 10.1 is even more picky (there's bug reports about python crashing if no window server is available, I'm working on that right now). Look in Mac/OSX for some stuff to create a Python.app bundle. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From sdm7g@Virginia.EDU Tue Oct 30 22:24:02 2001 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Tue, 30 Oct 2001 17:24:02 -0500 (EST) Subject: [Pythonmac-SIG] Carbon.Win on OSX Python In-Reply-To: <20011030221811.7B1FFFB04A@oratrix.oratrix.nl> Message-ID: On Tue, 30 Oct 2001, Jack Jansen wrote: > Recently, "Steven D. Majewski" said: > > > > Now I got the error message: > > > > kCGSErrorNoneAvailable : CGSOrderFrontConditionally: Process not found > > I think this has to do with your Python not being a fullblown > application. 10.0 was pickier than public beta about this, and 10.1 is > even more picky (there's bug reports about python crashing if no > window server is available, I'm working on that right now). > That was my second guess, as that is similar to the behaviour I was getting trying to run Cocoa via pyobjc from the terminal. Specifically, some of the OrderFront message varieties did not work, while some others did ( I think I had to use :orderFrontIrregardless ). Thanks. -- Steve Majewski From jack@oratrix.nl Tue Oct 30 22:25:44 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 30 Oct 2001 23:25:44 +0100 Subject: [Pythonmac-SIG] slicing of structseq objects fails In-Reply-To: Message by Russell E Owen , Tue, 30 Oct 2001 10:02:14 -0800 , Message-ID: <20011030222549.4C74AFB04A@oratrix.oratrix.nl> Python-devvers, Russel Owen reported the following bug, and it turns out to be a general bug, not a MacPython one: slicing the structseq-style tuples returned by time.gmtime() returns a sequence with NULLs in it. Shortly afterwards Python crashes on my SGI. Any takers? Recently, Russell E Owen said: > The following code fails (G4, MacOS 9.2.1) in Classic MacPython 2.2b1: > > import time > > currUTCTuple= time.gmtime(time.time()) > print "currUTCTuple=%r" % (currUTCTuple,) > print "currUTCTuple[3:6]=%r" % (currUTCTuple[3:6],) > fmtTime = "%s:%02i:%02i" % currUTCTuple[3:6] > print "formatted time = ", fmtTime > > It displays (, , ) for currUTCTuple[3:6], > ... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Tue Oct 30 22:34:24 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 30 Oct 2001 23:34:24 +0100 Subject: [Pythonmac-SIG] debugging problem In-Reply-To: Message by Erwin Mann , Tue, 30 Oct 2001 12:03:23 +0100 , Message-ID: <20011030223429.82DD0FB04A@oratrix.oratrix.nl> Yes, this is a bug. Python 2.2b1 is much more critical that you're calling base class methods only with classes that are truly derived from that baseclass. And HorizontalPanes is a subclass of Widget, not of ClickableWidget. What seems to fix it for me is calling Widget.__init__ in stead of ClickableWidget.__init__, but it could well be that the correct fix is to inherit ClickableWidget in stead. Just, could you investigate this and commit a fix? Recently, Erwin Mann said: > I just installed MacPython22b1 and run into a strange problem while trying > to debug a little python program. After activating the debugger from the ID= > E > and clicking on the =B3run all=B2 button I got the following traceback: > > ------ > TypeError: unbound method __init__() must be called with ClickableWidget > instance as first argument (got HorizontalPanes instance instead) > TZraceback (innermost last): > > File "Wapplication.py", line 35, in mainloop > self.do1event(mask, wait) > File "FrameWork.py", line 177, in do1event > self.dispatch(event) > File "FrameWork.py", line 210, in dispatch > handler(event) > File "FrameWork.py", line 269, in do_mouseDown > handler(partcode, wid, event) > File "FrameWork.py", line 788, in do_inContent > self.do_contentclick(local, modifiers, event) > File "Wwindows.py", line 338, in do_contentclick > widget.click(point, modifiers) > File "Wcontrols.py", line 87, in click > Wbase.CallbackCall(self._callback, 0) > File "Wbase.py", line 686, in CallbackCall > return apply(callback, args) > File "PyEdit.py", line 489, in run > self._run() > File "PyEdit.py", line 515, in _run > self.execstring(pytext, globals, globals, file, modname) > File "PyEdit.py", line 620, in execstring > modname, self.profiling) > File "PyEdit.py", line 1157, in execstring > PyDebugger.postmortem(sys.exc_type, sys.exc_value, sys.exc_traceback) > File "PyDebugger.py", line 845, in postmortem > d.postmortem(exc_type, exc_value, tb) > File "PyDebugger.py", line 115, in postmortem > self.setupwidgets(self.title) > File "PyDebugger.py", line 139, in setupwidgets > w.panes =3D W.HorizontalPanes((8, 4, -8, -8), self.horpanes) > File "Wbase.py", line 458, in __init__ > ClickableWidget.__init__(self, possize) > > ----- > > Any ideas what caused this strange behaviour? I'm using a G4 with MacOS 9.2= > . > > Any help appreciated!!! > > > Thanks a lot > > Erwin Mann > > > > > --MS_Mac_OE_3087288203_407052_MIME_Part > Content-type: text/html; charset="ISO-8859-1" > Content-transfer-encoding: quoted-printable > > > > debugging problem > > > hi folks!
>
> I just installed MacPython22b1 and run into a strange problem while trying = > to debug a little python program. After activating the debugger from the IDE= > and clicking on the =B3run all=B2 button I got the following traceback:
>
> ------
> TypeError: unbound method __init__() must be called with ClickableWidget > > instance as first argument (got HorizontalPanes instance instead)
> TZraceback (innermost last):
>
> File "Wapplication.py", line 35, in mainloop
>     self.do1event(mask, wait)
> File "FrameWork.py", line 177, in do1event
>     self.dispatch(event)
> File "FrameWork.py", line 210, in dispatch
>     handler(event)
> File "FrameWork.py", line 269, in do_mouseDown
>     handler(partcode, wid, event)
> File "FrameWork.py", line 788, in do_inContent
>     self.do_contentclick(local, modifiers, event)
> File "Wwindows.py", line 338, in do_contentclick
>     widget.click(point, modifiers)
> File "Wcontrols.py", line 87, in click
>     Wbase.CallbackCall(self._callback, 0)
> File "Wbase.py", line 686, in CallbackCall
>     return apply(callback, args)
> File "PyEdit.py", line 489, in run
>     self._run()
> File "PyEdit.py", line 515, in _run
>     self.execstring(pytext, globals, globals, file, mo= > dname)
> File "PyEdit.py", line 620, in execstring
>     modname, self.profiling)
> File "PyEdit.py", line 1157, in execstring
>     PyDebugger.postmortem(sys.exc_type, sys.exc_value,= > sys.exc_traceback)
> File "PyDebugger.py", line 845, in postmortem
>     d.postmortem(exc_type, exc_value, tb)
> File "PyDebugger.py", line 115, in postmortem
>     self.setupwidgets(self.title)
> File "PyDebugger.py", line 139, in setupwidgets
>     w.panes =3D W.HorizontalPanes((8, 4, -8, -8), self.h= > orpanes)
> File "Wbase.py", line 458, in __init__
>     ClickableWidget.__init__(self, possize)
>
> -----
>
> Any ideas what caused this strange behaviour? I'm using a G4 with MacOS 9.2= > .
>
> Any help appreciated!!!
>
>
> Thanks a lot
>
> Erwin Mann
>
>
> > > > > > --MS_Mac_OE_3087288203_407052_MIME_Part-- > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tim@zope.com Tue Oct 30 23:51:11 2001 From: tim@zope.com (Tim Peters) Date: Tue, 30 Oct 2001 18:51:11 -0500 Subject: [Pythonmac-SIG] RE: [Python-Dev] slicing of structseq objects fails In-Reply-To: <20011030222549.4C74AFB04A@oratrix.oratrix.nl> Message-ID: [Jack Jansen] > Python-devvers, > Russel Owen reported the following bug, and it turns out to be a > general bug, not a MacPython one: slicing the structseq-style tuples > returned by time.gmtime() returns a sequence with NULLs in it. Shortly > afterwards Python crashes on my SGI. > > Any takers? Sure, it was a shallow bug in the new structseq code and has been fixed in current CVS. Next time, how about a bug report on SourceForge instead? From kaffeen@mac.com Wed Oct 31 02:18:57 2001 From: kaffeen@mac.com (Chris Scott) Date: Tue, 30 Oct 2001 21:18:57 -0500 Subject: [Pythonmac-SIG] Re: Learning on the Mac References: Message-ID: <3BDF5F91.8AF2EE23@mac.com> Thanks for the feedback Chris - That's the route I'm taking currently. I'm currently a shockwave game developer, so my focus is on games. I'm looking to python since it's easy to learn (so they say) and provides some serious speed enhancements over shockwave and it's free (unlike the $1200 for each platform Macromedia takes for Director). I was sort of hoping to skip the general file IO and string concatenation stuff, but I'm finding that there isn't much avaiable in the way of tutorials specific to graphics/sound/user interaction. Oh well, so I'll have to learn more:) If you run across anything the fits the bill for game tuts, let me know. Thanks! - Chris Subject: [Pythonmac-SIG] Re: Learning on the mac Date: Tue, 30 Oct 2001 14:00:03 -0600 From: "Christopher Smith" To: pythonmac-sig@python.org References: 1 Chris Scott writes: > >Anyone have any suggestions on Mac-centric books on learning Python? > I only work on a mac and used the Python tutorials, documentation, this list, and the book "How to think Like a Computer Scientist" (the Python version) as my resources. After working the problems in the book and doing a few of the challenge problems listed at the Useless Python site I felt like I had a pretty good introduction. If you are using the standard libraries of Python then it is my impression that the learning will be about the same on any system. What in particular do you want to learn? /c From mis@creazone.com Wed Oct 31 03:50:38 2001 From: mis@creazone.com (Michal Seta) Date: Tue, 30 Oct 2001 22:50:38 -0500 Subject: [Pythonmac-SIG] Re: Learning on the Mac In-Reply-To: <3BDF5F91.8AF2EE23@mac.com> Message-ID: On 10/30/01 9:18 PM, Chris Scott @ kaffeen@mac.com wrote: > but I'm finding that there isn't much avaiable > in the way of tutorials specific to graphics/sound/user interaction. Oh well, > so I'll have to learn more:) If you run across anything the fits the bill for > game tuts, let me know. Thanks! Have you tried pygame yet? Anyone for that matter? www.pygame.org and it needs SDL library (pygame site has a link). It runs on pretty much all platforms. Also, *** WARNING - off topic **** there's Blender (not Mac, though, yet) which is a 3D modeling/animation package and a game engine. It supports various physical aspects of game development problems (gravity, friction etc) and keyboard + mouse interaction and Python is their scripting language of choice! Head on to http://www.blender.nl/index_community.php and check it out if you have access to any other platform (pretty much all except MacOS). It's free (the editor/creator) and quite capable. ./MiS From jack@oratrix.nl Wed Oct 31 12:06:36 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 31 Oct 2001 13:06:36 +0100 Subject: [Pythonmac-SIG] Contributers wanted - jobs to be done Message-ID: <20011031120637.22E60303181@snelboot.oratrix.nl> Folks, if you want to contribute to MacPython: here's another chance. There's a couple of things I noted after reading Andrew Kuchling's "Whats new in Python 2.2" document (see it via www.python.org). I'll drop them here, if you want to take one of these on: let the mailing list know and go ahead. - There's a new builtin help() function to give all sorts of help on objects and such. It works rather badly in the IDE (worse there than in the raw interpreter). It would be nice if this functionality got integrated in the IDE, maybe as a help window, maybe otherwise. - The implementation of profiling has changed. Can someone check that the profile hooks in the IDE still work, please? - Passing of 8-bit filenames to open() has changed. Can someone on a non-MacRoman system test that filenames still work as expected? - For MachO-Python: on Windows Python not only understands the ".py" extension but also ".pyw". The latter is run with pythonw.exe, which is the "windows-aware" interpreter (python.exe fires up a dos-box to run your script). The situation on Windows is pretty similar to the situation on OSX with MachO-Python: we have the command line interpreter and the Python.app application. It would be nice if the latter took control over .pyw files. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From ianjones@purgatory.healthmedia.umich.edu Wed Oct 31 14:05:20 2001 From: ianjones@purgatory.healthmedia.umich.edu (Ian McLaury) Date: Wed, 31 Oct 2001 09:05:20 -0500 Subject: [Pythonmac-SIG] Re: Learning on the Mac In-Reply-To: References: Message-ID: At 10:50 PM -0500 10/30/01, Michal Seta wrote: > >Have you tried pygame yet? >Anyone for that matter? I've been following the pygame mailing list for a few months -- it looks like it would be a great replacement for something like Shockwave. Unfortunately it doesn't seem to work on OS X out of the box -- and I'm not much of a Unix build guru, so I haven't been able to do much with it. (It does run under OS 9 without difficulty.) Has anyone here had any luck? The pygame guy says he's aware of the problem and is waiting to hear back on some fixes and workarounds. Ian From kaffeen@mac.com Wed Oct 31 18:43:36 2001 From: kaffeen@mac.com (Chris Scott) Date: Wed, 31 Oct 2001 13:43:36 -0500 Subject: [Pythonmac-SIG] RE: Learning on the Mac Message-ID: I tried pygame, but had quite a bit of trouble getting the simple tutorial working. I never got a specific answer, but apparently there is a problem with fonts on the Mac? Would love to get it working... Do you have it running Carbonized? If not, where'd you get the non-Carbon files, because that's all they have on the site right now. From khk@uiah.fi Wed Oct 31 22:17:48 2001 From: khk@uiah.fi (Kari-Hans Kommonen) Date: Thu, 1 Nov 2001 00:17:48 +0200 Subject: [Pythonmac-SIG] Re: Learning on the Mac In-Reply-To: References: Message-ID: ...the Blender knowledgebase FAQ page says: "Blender for Macintosh OSX will be released in December 2001." http://helium.homeip.net/support/showitem.php?faq_id=31 At 22:50 -0500 30.10.2001, Michal Seta wrote: >Also, *** WARNING - off topic **** there's Blender (not Mac, though, yet) >which is a 3D modeling/animation package and a game engine. It supports >various physical aspects of game development problems (gravity, friction >etc) and keyboard + mouse interaction and Python is their scripting language >of choice! > >Head on to http://www.blender.nl/index_community.php and check it out if you >have access to any other platform (pretty much all except MacOS). >It's free (the editor/creator) and quite capable.