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

Re: [Pythonmac-SIG] Please test the 2.2 installer
by Jack Jansen Dec. 25, 2001

Dec. 25, 2001

Recently, Stefan Witzgall <stefan.witzgall(a)online.de> said: > [cut some traceback] > File "archive_1_red:Python 2.2:Mac:Tools:IDE:Splash.py", line 51, in > UpdateSplash > splash.GetDialogWindow().ValidWindowRect(splash.GetDialogPort().portRect) > NotImplementedError: Not available in this shared library/OS version After some mailing back and forth with Jason I'm afraid this is unfixable. The current (Universal 3.4) version of CarbonAccessors.o does not have the ValidWindowRect call anymore (which the previous 3.3.2 version did have). I could hack something together with two versions of CarbonAccessors.o, but this would be a nightmare to people who want to build from source. I'm currently thinking that I'll release 2.2 as "partially MacOS 8.1 compatible" (the interpreter works, the IDE doesn't). We (me + the people who have access to 8.1) should then put together a patch set that can be overlayed onto a MacPython installation and that replaces all calls to ValidWindowRect() with GetPort()/SetPort()/ValidRect()/SetPort() sequences. -- 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

3 2

MacPython 2.2, MacOS 8.1, test_regtest.py: What works, what fails.
by Stefan Witzgall Dec. 24, 2001

Dec. 24, 2001

Hi all, as one could read in the parallel thread concerning the MacPython 2.2 installer the IDE doesn't work with MacOS 8.1 but the interpreter does. Ok, I let it do a test. Am I right, that so following results are quite nomral? What about the failing tests? Stefan interpreter output: =================== test_grammar [the first output line; cut many lines in the following] test test_al skipped -- No module named al test test_bsddb skipped -- No module named bsddb test test_cd skipped -- No module named cd test test_cl skipped -- No module named cl test test_commands skipped -- Not posix; skipping test_commands test test_crypt skipped -- No module named crypt test test_curses skipped -- No module named _curses test test_dbm skipped -- No module named dbm test test_dl skipped -- No module named dl test test_fcntl skipped -- No module named fcntl test test_fork1 skipped -- os.fork not defined -- skipping test_fork1 test test_frozen failed -- import __phello__.foo should have failed test test_gl skipped -- No module named gl test test_grp skipped -- No module named grp test test_imgfile skipped -- No module named imgfile test test_largefile skipped -- filesystem does not have largefile support test test_linuxaudiodev skipped -- No module named fcntl test test_locale skipped -- test locale en_US not supported test test_longexp crashed -- exceptions.MemoryError: test test_mmap skipped -- No module named mmap test test_nis skipped -- No module named nis test test_ntpath skipped -- No module named nt test test_openpty skipped -- No openpty() available. test test_poll skipped -- select.poll not defined -- skipping test_poll test test_popen2 skipped -- cannot import name fork test test_pty skipped -- No module named termios test test_pwd skipped -- No module named pwd test test_signal skipped -- No module named signal test test_socket_ssl skipped -- Use of the `network' resource not enabled test test_socketserver skipped -- Use of the `network' resource not enabled test test_sunaudiodev skipped -- No module named sunaudiodev test test_time failed -- Traceback (most recent call last): File "archive_1_red:Python 2.2:Lib:test:test_time.py", line 46, in test_mktime time.mktime, (999999, 999999, 999999, 999999, File "archive_1_red:Python 2.2:Lib:unittest.py", line 279, in failUnlessRaises raise self.failureException, excName AssertionError: OverflowError test test_timing skipped -- No module named timing test test_unicode_file skipped -- No Unicode filesystem semantics on this platform. test test_winreg skipped -- No module named _winreg test test_winsound skipped -- No module named winsound test test_zlib crashed -- exceptions.MemoryError: 149 tests OK. 4 tests failed: test_frozen test_longexp test_time test_zlib 33 tests skipped: test_al test_bsddb test_cd test_cl test_commands test_crypt test_curses 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_timing test_unicode_file test_winreg test_winsound Those skips are all expected on mac. <Stefan.Witzgall(a)online.de>

2 1

Re: [Pythonmac-SIG] Is it just me or...?
by Jack Jansen Dec. 24, 2001

Dec. 24, 2001

Recently, John W Baxter <jwblist(a)olympus.net> said: > At 10:20 +0100 12/19/01, Jack Jansen wrote: > >I will probably do a 2.2.1 release when it is solved. > > Er...may I suggest some other numbering? There may eventually be a > mainline Python 2.2.1 I'll try to usurp the 2.2.1 number. If I can't then it'll be called something else, but I hate versions like "2.2 build 125", unless it can't be helped. -- 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] MacPython 2.2, MacOS 8.1, test_regtest.py: What works, what fails.
by Jack Jansen Dec. 24, 2001

Dec. 24, 2001

Recently, Stefan Witzgall <stefan.witzgall(a)online.de> said: > 149 tests OK. > 4 tests failed: > test_frozen test_longexp test_time test_zlib > 33 tests skipped: > test_al test_bsddb test_cd test_cl test_commands test_crypt > test_curses 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_timing test_unicode_file > test_winreg test_winsound > Those skips are all expected on mac. Yes, this is the expected outcome. README explains why those four tests fail. -- 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] Is it just me or...?
by Jack Jansen Dec. 24, 2001

Dec. 24, 2001

> I've spent the better part of two days now trying to get MacPython (the CFM > app distribution not the command line interpreter) to install and run > natively on OS X (I'm running 10.1.1). Is it just something I'm not doing > or is this a futile process (i.e., it is know not to run)? There are some problems with MacPython on MacOS X. For one thing, it does not currently work on a MacOSX multiprocessor. And, since 10.1, it does not work on all single-processors anymore either. For some people (like myself) ti works fine, for others it doesn't. We are working hard to resolve this issue, but it now looks that it won't be solved before 2.2 :-( I will probably do a 2.2.1 release when it is solved. But, just to make sure that you're not seeing a different issue: could you post the symptoms you see when you try to use MacPython on OSX? -- 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

4 3

Re: [Pythonmac-SIG] Please test the 2.2 installer
by Jack Jansen Dec. 23, 2001

Dec. 23, 2001

Recently, Richard Gordon <richard(a)richardgordon.net> said: > Oddly enough, the installer got confused again when I reinstalled > even tho I had deleted all older stuff and all preference files, so I > still had to configure for Classic manually. Are you sure you don't have CarbonLib installed? There's quite a few packages nowadays that install it, and if you have Carbon then the installer will pick that as the preferred configuration.... -- 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] Please test the 2.2 installer
by Jack Jansen Dec. 23, 2001

Dec. 23, 2001

Recently, Mark Day <mday(a)mac.com> said: > I tried installing it on 9.2.2. It seemed to install fine until it got to > the point of launching the configure program. It launched > ConfigurePythonCarbon instead of ConfigurePythonClassic. That's normal: on 9.2.2 you have CarbonLib, so Carbon is the preferred configuration. > At that point, the > machine was hung, and I rebooted. After the reboot, I tried launching > ConfigurePythonClassic. That hung, too, but I was able to force quit it. That's not normal:-) > When I ran ConfigurePythonClassic again, it seemed to run and set things up > OK. Are other people seeing unexpected hangs? I've been having a similar one, where I installed 2.2 on a fresh system, which went fine, but the first time I ran the IDE it hung and I had to force-quit it. Next time: no problem. Re-installed: worked fine the first time. -- 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

Please test the 2.2 installer
by Jack Jansen Dec. 23, 2001

Dec. 23, 2001

Folks, I think MacPython 2.2 is ready. The first installer is in http://www.cwi.nl/ftp/jack/python/mac/MacPython22full.bin . All the other ones (hqx, active installer, source) will follow later. I'm announcing this one here early mainly for Jason or anyone else with access to MacOS 8.1: does this release work? But that shouldn't stop anyone else from trying it: I've only tried it on my own dev machine, not even on OSX. So: give it a go and let me know ehterh it works (I'm 99% sure it will). I'll post another note with much wider audience when the other installers are uploaded and I get a green light on 8.1. Or I'll refrain from doing so if I get a red light on any otherissue, of course:-) -- 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/ ++++

7 8

Using slash-seperated paths for creating FSSpecs (was: Mach-O MacPython IDE!!!)
by Donovan Preston Dec. 21, 2001

Dec. 21, 2001

On Friday, December 21, 2001, at 01:44 PM, Jack Jansen wrote: > > Recently, Donovan Preston <dp(a)ulaluma.com> said: >> Hmm. Well, I suppose the only way to get around this is to explicitly >> state which type of path is being used as Jack suggested, or to always >> assume slash-delimited paths on X and colon-delimited paths on 9. > > I assume you mean "MacPython" where you say 9 and "MachoPython" where > you say X, right? Pathname interpretation is more a function of the > runtime library than of the OS, in the case of Python. Yes, correct, sorry. So I should have said "Always assume slash-delimited paths on Mach-O Python and colon-delimited paths on CFM MacPython." >> Since os.path.join creates slash-delimited strings on X, all of the >> places in the IDE where there is code that looks like >> os.path.join(rootdir, 'my:subdir:etc') are going to have to be replaced >> anyway. I suggest replacing them with os.path.join(*[rootdir, 'my', >> 'subdir', 'etc']) which works no matter what OS you are running under. > > Or, alternatively, use macpath. Os.path is great to get rid of > platform dependencies, but only if you add single components. If > you're using my:subdir:etc you have a Mac dependency anyway, so > there's little to be gained from using os.path. Ah. I wasn't aware there was a macpath module which would do colon-delimiting even on X. Hmm. At first glance I thought that might work, but upon further inspection I recall why sticking to colon-delimited paths won't work on Mach-O MacPython: There are constructions throughout the IDE that look like this: widgetresfile = os.path.join(sys.exec_prefix, ":Mac:Tools:IDE:Widgets.rsrc") Since sys.exec_prefix is specified as a slash-delimited string, even macpath won't help here. And I am strongly opposed to making sys.exec_prefix return a colon-delimited string :-) And rather than convert any slash-delimited string such as sys.exec_prefix to a colon-delimited string prior to using macpath.join, I still contest that it's better to use os.path.join and construct your path segments in a platform agnostic way. Maybe this syntax will be a little more to your (non-obfuscated) liking ;-) pathsegments = [sys.exec_prefix, 'Mac', 'Tools', 'IDE'] path = os.path.join(*pathsegments) Then, the resulting path can be passed to the new FSSpec_New, after it's been updated to conform to your pseudocode, no matter what runtime you are running under and it will work. Donovan

1 0

Re: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs
by Jack Jansen Dec. 21, 2001

Dec. 21, 2001

> > > This isn't worth it. We discussed it about a year ago (both here and > > > on the GUSI list) and by getting the BSD sockets you would also get > > > (unless you do major surgery) all the rest of glibc, so you would get > > > Unix filenames, Sioux would go down the drain, etc. > > > > I think there's a bit of confusion as to why one would still want to > > load code from a CFM library EVEN on MachoPython. Of course, if a Mach-O > > library is available it should be used. However, there will be occasions > > where a Mach-O library will not be available. > > > > Probably the most obvious example would be closed-source VST plugins. If > > the plugin author even bothers to relink the plugin with Carbon, it will > > most definitely be as a CFM library, not a Mach-O library. Thus the > > necessity of loading and running code in a CFM library from a Mach-O > > binary. Ok, this is indeed a completely different situation. Depending on the API the plugin is provided with it could be either easy or impossible to put Python in between. If the plugin is in complete control it's easy, the only problem to solve is the CFM-MachO bridge. Although someone will have to take care to convert pathnames, if any go across the API. If the plugin API provided by the host application is sufficiently rich (as an Adobe plugin API I've glanced at happens to be, IIRC) there's a bit of a problem, but not too much, as you really have to only build a Python interpreter that refrains from doing its own I/O calls incorrectly. Linking against a cfm-bridged glibc should go a long way. If the API is just a couple of start/stop calls plus a long list of do's and don'ts (like the Netscape plugin API) there is a problem. > Donovan wrote: > > ...until CFM MacPython on OS X dies a horrible death. > > This especially concerns me because it sounds like the problem will > never be solved, even if we could wait a while for the GUSI > multi-tasking problem be worked out. I think that's too negative. First, it'll be a while until CFM MacPython dies (and why something that has served us so well for so long deserves a "horrible death".... well.... :-). Second, this problem isn't really Python-related. Every product that has a plugin architecture with a sufficient marketshare will have to face this problem when they decide to move the product to Mach-O. And I'm pretty sure everyone will move to Mach-O at some point... -- 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