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

Re: [Pythonmac-SIG] MacPython 2.2b1 is out
by Jack Jansen Oct. 26, 2001

Oct. 26, 2001

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(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

MacPython 2.2b1 is out
by Jack Jansen Oct. 26, 2001

Oct. 26, 2001

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(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

1 0

Problems with new features introduced during beta, anyone?
by Jack Jansen Oct. 26, 2001

Oct. 26, 2001

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(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

3 2

RE: [Pythonmac-SIG] Problems with new features introduced during beta, anyone?
by Schollnick, Benjamin Oct. 24, 2001

Oct. 24, 2001

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(a)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(a)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(a)python.org http://mail.python.org/mailman/listinfo/pythonmac-sig

1 0

MacPython on multiprocessor OSX 10.1
by Jack Jansen Oct. 24, 2001

Oct. 24, 2001

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(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

4 4

Re: [Pythonmac-SIG] AE quit() ?
by Jack Jansen Oct. 24, 2001

Oct. 24, 2001

... 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(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Re: [Pythonmac-SIG] tkinter question
by Jack Jansen Oct. 24, 2001

Oct. 24, 2001

> 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(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] AE quit() ?
by Vincent Marchetti Oct. 23, 2001

Oct. 23, 2001

-- 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

1 0

Re: [Pythonmac-SIG] tkinter question
by Jack Jansen Oct. 23, 2001

Oct. 23, 2001

Recently, Chris Scott <kaffeen(a)mac.com> said: > Traceback (most recent call last): > File "<stdin>", 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(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Difficult problem for MacPython on X
by Alexandre Parenteau Oct. 23, 2001

Oct. 23, 2001

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

2 1