From jack@oratrix.nl Sat Sep 1 00:06:32 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 01 Sep 2001 01:06:32 +0200 Subject: [Pythonmac-SIG] Tkinter for 2.1 Carbon? In-Reply-To: Message by Russell E Owen , Fri, 31 Aug 2001 10:01:40 -0700 , Message-ID: <20010831230637.5656ADDDEB@oratrix.oratrix.nl> Recently, Russell E Owen said: > At the moment Tkinter does not work at all with Carbon (and has some issues w > ith Classic). > > If you are willing to do some programming, you may be able to help the effort > to get it "Carbonized". I don't know what's involved nor who might already b > e working on it. On the other side of the fence (on the mactcl mailing list) there's some reports that people are working on getting Tk to work on OSX with the native graphics there. (There is an OSX Tk, but it's pretty useless for the general public as it is just standard Unix Tk so it requires an X-Windows server). And for OS9 there's an option I pointed out earlier, but don't have the time to pursue: I think it might be possible to link a _Tkinter.carbon.slb that is linked against PythonCoreCarbon, InterfaceLib and the InterfaceLib Tk libraries. So if someone can put some time into investigating the latter it would give us back Tkinter in Carbon-MacPython on OS9, while the Tk folks wil at some point give us Tkinter for OSX. -- 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 dyoo@hkn.eecs.berkeley.edu Sat Sep 1 10:24:19 2001 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Sat, 1 Sep 2001 02:24:19 -0700 (PDT) Subject: [Pythonmac-SIG] Re: [Tutor] Re: Pythonica (symbolic algebra) In-Reply-To: Message-ID: On Thu, 30 Aug 2001, Joseph J. Strout wrote: > At 1:42 PM -0500 8/30/01, Christopher Smith wrote: > > >It looks like you had made some significant progress > >on Python and provided some useful tools (I am using > >the patched editor, for example). Thank you. > > Quite happy to have contributed; Python is great (as is the community). > > >Do you have a list of errors that have been reported for Pythonica? > > Sorry, I don't. > > >I passed along your comments to the tutor and mac lists. Hello! Have you had a chance to look at: http://hkn.eecs.berkeley.edu/~dyoo/python/pythonica/ I've been playing around with the Pythonica code, mostly to learn how to use the Spark parser generator tools. I think the parser bug with "2*3+2^2/3" is fixed, although I'm sure I've introduced new bugs everywhere... *grin* I'd like to get your input on the changes I've made; do they look ok? From mcclenon@cstone.net Sat Sep 1 13:29:23 2001 From: mcclenon@cstone.net (mcclenon) Date: Sat, 01 Sep 2001 08:29:23 -0400 Subject: [Pythonmac-SIG] change References: Message-ID: <3B90D4A3.F9A09D8@cstone.net> Please change my email address to mcclenon@adelphia.net pythonmac-sig-request@python.org wrote: > Send Pythonmac-SIG mailing list submissions to > pythonmac-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/pythonmac-sig > or, via email, send a message with subject or body 'help' to > pythonmac-sig-request@python.org > > You can reach the person managing the list at > pythonmac-sig-admin@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pythonmac-SIG digest..." > > ------------------------------------------------------------------------ > Today's Topics: > > 1. Re: Carbon events (Just van Rossum) > 2. Re: Carbon events (Paul Miller) > 3. Re: Carbon events (Doug Wyatt) > 4. Re: Announce: PythonCard 0.3.1 - need wxPython on > the Mac (Joel Bender) > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] Carbon events > Date: Tue, 14 Aug 2001 18:01:25 +0200 > From: Just van Rossum > To: Doug Wyatt > CC: Pythonmac-SIG@python.org > > Doug Wyatt wrote: > > > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox. > > framework/Versions/A/Headers/CarbonEvents.h > > > > but you'd just #include > > Is it not available under OS9? (I do have a machine running OSX, I'm just > wondering.) > > Just > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] Carbon events > Date: Tue, 14 Aug 2001 17:26:18 +0100 > From: Paul Miller > To: Just van Rossum > CC: > > >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox. > >> framework/Versions/A/Headers/CarbonEvents.h > >> > >> but you'd just #include > > > > Is it not available under OS9? (I do have a machine running OSX, I'm just > > wondering.) > > > Yes it is (from Carbon 1.2.5 onwards) - but you'll need to update to a later > version of Universal Headers than the ones in CW Pro 6. Use the ones in the > latest Carbon SDK. > > Paul Miller. > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] Carbon events > Date: Tue, 14 Aug 2001 09:33:39 -0700 > From: Doug Wyatt > To: Just van Rossum > CC: Pythonmac-SIG@python.org > > On Tuesday, August 14, 2001, at 09:01 , Just van Rossum wrote: > > Doug Wyatt wrote: > > > >> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox. > >> framework/Versions/A/Headers/CarbonEvents.h > >> > >> but you'd just #include > > > > Is it not available under OS9? (I do have a machine running OSX, I'm > > just > > wondering.) > > Hmm, the afore-mentioned header says the functions are available under 9 > with CarbonLib. > > Perhaps you need to have a separately downloaded Carbon SDK installed? > Please forgive my ignorance, I haven't done any development on 9 or with > CoreWarrior in about 18 months now. > > I thought of another possible approach, which would be to run a separate > cooperative (not preemptive) thread to do window refreshes and whatever > other limited set of tasks can be safely serviced while blocked on I/O > (watching for cancellation clicks/keys?), and then just use synchronous > I/O in the main thread. > > Doug > > -- > Doug Wyatt > work: dwyatt@apple.com (CoreAudio) > personal: doug@sonosphere.com http://www.sonosphere.com > > "Changing OS's is the corporate equivalent of molting -- you're very > vulnerable after you've done it but you have to do it to survive". > -- Ray Spears > > ------------------------------------------------------------------------ > > Subject: Re: [Pythonmac-SIG] Announce: PythonCard 0.3.1 - need wxPython on > the Mac > Date: Tue, 14 Aug 2001 15:12:11 -0400 > From: Joel Bender > To: pythonmac-sig@python.org > > Joe Graham wrote: > > >However in the spirit of changing gears, has anyone > >looked at the latest Qt Mac beta from trolltech? > > Is there a way to purchase an developers copy from them for the > purpose of developing PythonCard? $2925 is too rich for me (assuming > that a dual platform price will be the same for Qt/Unix and Qt/Mac). > > There are GUI projects that are built on OpenGL, perhaps PythonCard > can follow this direction? Can anyone with OpenGL experience on the > Mac speak to how easy it is/could be to keep an OpenGL engine cross > platform? > > Joel > > -- From steve@spvi.com Sat Sep 1 17:15:32 2001 From: steve@spvi.com (Steve Spicklemire) Date: Sat, 1 Sep 2001 11:15:32 -0500 Subject: [Pythonmac-SIG] Fwd: configure.in syntax to find python binary during build... Message-ID: <91522760-9EF4-11D5-BDE5-0050E480B13C@spvi.com> Hi Py-Mac folks, I tried this on the Python list, but no luck. In my eternal search for ways to avoid any *real* work, I thought I'd better at least try here, lest I have to actually figure out autoconf on my own! ;-) thanks, -steve Begin forwarded message: > From: Steve Spicklemire > Date: Tue Aug 28, 2001 09:32:55 AM America/Indianapolis > To: python-list@python.org > Cc: steve@spvi.com > Subject: configure.in syntax to find python binary during build... > > > Hi Python Folk, > > I'd like to modify configure.in for building Python on darwin. The > current configure.in uses "-undefined suppress" for generating shared > libs, and this get's a little tricky in later versions of darwin. I > snooped around on the darwin mailing list(s) and someone pointed me in > the direction of "-bundle_loader" which tells ld where to find symbols > that the library needs to have from the loading binary. Anyway.. since > I choose '.exe' as the --with-suffix then my python binary turns out to > be "python.exe" so this works for me in 'configure': > > Darwin/*|next/*) > if test "$ns_dyld" > then LDSHARED='$(CC) $(LDFLAGS) -bundle -bundle_loader > python.exe' > else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; > fi > > However.. someone else might choose a different suffix, and when > building shared modules in other directories I'm thinking that you may > need a full path to the python binary for this to work. Long story > short: How to you spell "Path to the installed binary of python" in > configure.in so that I can modify it for newer versions of darwin? > > thanks! > -steve From jack@oratrix.nl Sat Sep 1 21:03:46 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 01 Sep 2001 22:03:46 +0200 Subject: [Pythonmac-SIG] Fwd: configure.in syntax to find python binary during build... In-Reply-To: Message by Steve Spicklemire , Sat, 1 Sep 2001 11:15:32 -0500 , <91522760-9EF4-11D5-BDE5-0050E480B13C@spvi.com> Message-ID: <20010901200351.7BEE6AB444@oratrix.oratrix.nl> Recently, Steve Spicklemire said: > > I'd like to modify configure.in for building Python on darwin. The > > current configure.in uses "-undefined suppress" for generating shared > > libs, and this get's a little tricky in later versions of darwin. Note that "-undefined suppress" is only used if you don't "--enable-framework". If you're doing a framework build then the loader does know of all the externals (as they're in the Python framework). > > I > > snooped around on the darwin mailing list(s) and someone pointed me in > > the direction of "-bundle_loader" which tells ld where to find symbols > > that the library needs to have from the loading binary. Anyway.. since > > I choose '.exe' as the --with-suffix then my python binary turns out to > > be "python.exe" so this works for me in 'configure': > > > > Darwin/*|next/*) > > if test "$ns_dyld" > > then LDSHARED='$(CC) $(LDFLAGS) -bundle -bundle_loader > > python.exe' > > else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; > > fi $(PYTHON) is what you're looking for. (Now you're probably saying, "ah...":-) However, I have a question about the -bundle_loader: is it also supported under 10.0.4 and earlier (not running OSX at the moment, so can't check myself)? If it isn't you should make this dependent on the Darwin version. And something else: as I see the Darwin/*|next/* in your code: you're probably using an older release of Python than 2.2a2. I would suggest you upgrade, as a lot of things related to dynamic loading have changed. And finally: if you have a patch relative to the current CVS sources (or 2.2a2, that's good enough, I guess) please put it in the sourceforge patch manager. You can assign it to me and I'll check it in. > > However.. someone else might choose a different suffix, and when > > building shared modules in other directories I'm thinking that you may > > need a full path to the python binary for this to work. Long story > > short: How to you spell "Path to the installed binary of python" in > > configure.in so that I can modify it for newer versions of darwin? Hmm, that's a more difficult problem. Because LDSHARED can be used in two circumstances: - During the build, when python.exe (or whatever) is in the current directory (and not in the installed directory yet) - Later, during distutils-based extension building, when python.exe is installed (and you don't know where the build directory is anymore). I don't see a solution for this (except for switching to frameworks, which don't have the problem). -- 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 hummelsean@mac.com Wed Sep 5 00:42:12 2001 From: hummelsean@mac.com (Sean Hummel) Date: Tue, 04 Sep 2001 16:42:12 -0700 Subject: [Pythonmac-SIG] Codewarrior project generation In-Reply-To: <20010901200351.7BEE6AB444@oratrix.oratrix.nl> Message-ID: Does anyone have a class, which generates, Macintosh Codewarrior projects? I need it for porting some UNIX open source stuff to the Macintosh. From jack@oratrix.nl Wed Sep 5 09:19:03 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 05 Sep 2001 10:19:03 +0200 Subject: [Pythonmac-SIG] Codewarrior project generation In-Reply-To: Message by Sean Hummel , Tue, 04 Sep 2001 16:42:12 -0700 , Message-ID: <20010905081904.57D3D303181@snelboot.oratrix.nl> > Does anyone have a class, which generates, Macintosh Codewarrior projects? One alternative is to try and use distutils. The more powerful alternative is to use mkcwproject (which is also the underlying mechanism used by distutils on the mac). For an example of how to use mkcwproject see :Mac:scripts:genpluginprojects.py, which generates the projects for the standard extension modules. I'd like to hear of missing functionality in mkcwproject. I've put in just the bits and pieces that I needed for distutils and generating the plugin projects. -- 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 steve@spvi.com Wed Sep 5 11:39:48 2001 From: steve@spvi.com (Steve Spicklemire) Date: Wed, 5 Sep 2001 05:39:48 -0500 Subject: [Pythonmac-SIG] New autoconf patches.. In-Reply-To: <20010816214226.0676014B630@oratrix.oratrix.nl> Message-ID: <546C43D6-A1EA-11D5-BD7C-0050E480B13C@spvi.com> Hi MacPython folk, I finally got around to downloading autoconf and playing around with building Python-2.2a2. Here is my best guess, at this point, at changes to configure.in that would work for Darwin shipped with 10.0.X and current builds of Darwin (which will presumably ship with later releases of MacOSX) There may be an easier/better way to handle these case statements, but I'm not a autoconf jock... ;-) -steve P.S. Is there any way to tell "Mail" not to wrap my plain text messages? I may have to go back to emacs! ;-) [vh10-15:~/Packages] steve% diff -c Python-2.2a2/configure.in Python-2.2a2_mod/configure.in *** Python-2.2a2/configure.in Fri Aug 17 13:39:24 2001 --- Python-2.2a2_mod/configure.in Wed Sep 5 05:18:23 2001 *************** *** 581,586 **** --- 581,592 ---- AC_SUBST(LIBTOOL_CRUFT) case $ac_sys_system/$ac_sys_release in + Darwin/1.4*) + ns_undef_sym='_environ' + LIBTOOL_CRUFT="-lcc_dynamic -arch_only ppc -flat_namespace -U $ns_undef_sym" + LIBTOOL_CRUFT="$LIBTOOL_CRUFT $extra_frameworks" + LIBTOOL_CRUFT=$LIBTOOL_CRUFT' -install_name $(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/Python' + LIBTOOL_CRUFT=$LIBTOOL_CRUFT' -compatibility_version $(VERSION) -current_version $(VERSION)';; Darwin/*) ns_undef_sym='_environ' LIBTOOL_CRUFT="-lcc_dynamic -arch_only ppc -U $ns_undef_sym" *************** *** 598,604 **** # -F. is needed to allow linking to the framework while # in the build location. ! LDFLAGS="$LDFLAGS -Wl,-F. -Wl,-U,$ns_undef_sym" AC_DEFINE(WITH_NEXT_FRAMEWORK) AC_MSG_RESULT(yes) else --- 604,613 ---- # -F. is needed to allow linking to the framework while # in the build location. ! case $ac_sys_system/$ac_sys_release in ! Darwin/1.4*)LDFLAGS="$LDFLAGS -Wl,-F. -Wl,-flat_namespace,-U,$ns_undef_sym";; ! Darwin/*)LDFLAGS="$LDFLAGS -Wl,-F. -Wl,-U,$ns_undef_sym";; ! esac AC_DEFINE(WITH_NEXT_FRAMEWORK) AC_MSG_RESULT(yes) else *************** *** 661,666 **** --- 670,684 ---- hp*|HP*) LDSHARED="ld -b";; OSF*) LDSHARED="ld -shared -expect_unresolved \"*\"";; DYNIX/ptx*) LDSHARED="ld -G";; + Darwin/1.4*) + LDSHARED='$(CC) $(LDFLAGS) -bundle' + if test "$enable_framework" ; then + # Link against the framework. All externals should be defined. + LDSHARED="$LDSHARED "'-framework $(PYTHONFRAMEWORK)' + else + # No framework. Ignore undefined symbols, assuming they come from Python + LDSHARED="$LDSHARED -flat-namespace -undefined suppress" + fi ;; Darwin/*) LDSHARED='$(CC) $(LDFLAGS) -bundle' if test "$enable_framework" ; then From mjb@thp.Uni-Koeln.DE Wed Sep 5 11:44:47 2001 From: mjb@thp.Uni-Koeln.DE (Michael J Barber) Date: Wed, 05 Sep 2001 12:44:47 +0200 Subject: [Pythonmac-SIG] how many 68k users? Message-ID: <3B96021F.E717B47F@thp.uni-koeln.de> Does anyone have any idea how many people are using Python on 68k macs? From simonmagus@earthlink.net Thu Sep 6 02:37:11 2001 From: simonmagus@earthlink.net (Sans Peur) Date: Wed, 05 Sep 2001 18:37:11 -0700 Subject: [Pythonmac-SIG] PyOpenGL using Python 2.1.1. on G3 distutils failure Message-ID: Greetings, I ran the distutils script and it looks like an exception is raised by the metrowerks compiler script, a distutils scripting error? I've got metrowerks installed so it should link, but it's not. I'm installing PyOpenGL ... if anyone knows how to fix this, please help. Thank you. Traceback follows: Bryce ======= PyOpenGL 2.0.0.42beta setup System configuration: Platform = mac GL Platform = AGL Numeric = 20.1.0b2 Build Togl = no Getting the list of platforms... Getting the list of packages... File contains \r characters (incorrect line endings?) Getting the list of extension modules... get_build_info ":interface:GL:ARB:matrix_palette.i" get_build_info ":interface:GL:ARB:multisample.i" get_build_info ":interface:GL:ARB:multitexture.i" get_build_info ":interface:GL:ARB:point_parameters.i" get_build_info ":interface:GL:ARB:texture_compression.i" get_build_info ":interface:GL:ARB:transpose_matrix.i" get_build_info ":interface:GL:ARB:vertex_blend.i" get_build_info ":interface:GL:Autodesk:facet_normal.i" get_build_info ":interface:GL:Autodesk:valid_back_buffer_hint.i" get_build_info ":interface:GL:EXT:blend_color.i" get_build_info ":interface:GL:EXT:blend_func_separate.i" get_build_info ":interface:GL:EXT:blend_minmax.i" get_build_info ":interface:GL:EXT:compiled_vertex_array.i" get_build_info ":interface:GL:EXT:convolution.i" get_build_info ":interface:GL:EXT:coordinate_frame.i" get_build_info ":interface:GL:EXT:copy_texture.i" get_build_info ":interface:GL:EXT:cull_vertex.i" get_build_info ":interface:GL:EXT:draw_range_elements.i" get_build_info ":interface:GL:EXT:fog_coord.i" get_build_info ":interface:GL:EXT:fragment_lighting.i" get_build_info ":interface:GL:EXT:index_func.i" get_build_info ":interface:GL:EXT:index_material.i" get_build_info ":interface:GL:EXT:light_texture.i" get_build_info ":interface:GL:EXT:multi_draw_arrays.i" get_build_info ":interface:GL:EXT:pixel_transform.i" get_build_info ":interface:GL:EXT:point_parameters.i" get_build_info ":interface:GL:EXT:polygon_offset.i" get_build_info ":interface:GL:EXT:scene_marker.i" get_build_info ":interface:GL:EXT:secondary_color.i" get_build_info ":interface:GL:EXT:subtexture.i" get_build_info ":interface:GL:EXT:texture3D.i" get_build_info ":interface:GL:EXT:texture_object.i" get_build_info ":interface:GL:EXT:texture_perturb_normal.i" get_build_info ":interface:GL:EXT:vertex_array.i" get_build_info ":interface:GL:EXT:vertex_weighting.i" get_build_info ":interface:GL:HP:image_transform.i" get_build_info ":interface:GL:IBM:multimode_draw_arrays.i" get_build_info ":interface:GL:IBM:static_data.i" get_build_info ":interface:GL:INTEL:texture_scissor.i" get_build_info ":interface:GL:KTX:buffer_region.i" get_build_info ":interface:GL:MESA:resize_buffers.i" get_build_info ":interface:GL:MESA:window_pos.i" get_build_info ":interface:GL:NV:fence.i" get_build_info ":interface:GL:NV:register_combiners.i" get_build_info ":interface:GL:NV:register_combiners2.i" get_build_info ":interface:GL:PGI:misc_hints.i" get_build_info ":interface:GL:SGIS:detail_texture.i" get_build_info ":interface:GL:SGIS:fog_function.i" get_build_info ":interface:GL:SGIS:multisample.i" get_build_info ":interface:GL:SGIS:multitexture.i" get_build_info ":interface:GL:SGIS:pixel_texture.i" get_build_info ":interface:GL:SGIS:sharpen_texture.i" get_build_info ":interface:GL:SGIS:texture4D.i" get_build_info ":interface:GL:SGIS:texture_color_mask.i" get_build_info ":interface:GL:SGIS:texture_filter4.i" get_build_info ":interface:GL:SGIX:async.i" get_build_info ":interface:GL:SGIX:flush_raster.i" get_build_info ":interface:GL:SGIX:frame_zoom.i" get_build_info ":interface:GL:SGIX:list_priority.i" get_build_info ":interface:GL:SGIX:pixel_texture.i" get_build_info ":interface:GL:SGIX:reference_plane.i" get_build_info ":interface:GL:SGIX:sprite.i" get_build_info ":interface:GL:SGIX:tag_sample_buffer.i" get_build_info ":interface:GL:SUN:global_alpha.i" get_build_info ":interface:GL:SUN:triangle_list.i" get_build_info ":interface:GL:SUNX:constant_data.i" get_build_info ":interface:GL:WIN:swap_hint.i" get_build_info ":interface:GL:_3DFX:tbuffer.i" get_build_info ":interface:GL:__init__.i" get_build_info ":interface:GLE.i" get_build_info ":interface:GLU:SGI:filter4_parameters.i" get_build_info ":interface:GLU:__init__.i" get_build_info ":interface:GLUT.i" get_build_info ":interface:WGL:ARB:buffer_region.i" get_build_info ":interface:WGL:ARB:extensions_string.i" get_build_info ":interface:WGL:EXT:extensions_string.i" get_build_info ":interface:WGL:EXT:swap_control.i" get_build_info ":interface:WGL:__init__.i" running build running build_w warning: build_w: Can't find SWIG, will just have to do with the existing wrapper source. running build_py get_build_info ":src:shadow:GL.__init__.c" Traceback (most recent call last): File "Macintosh HD20:Programming:Python:Python 2.1.1:PyOpenGL:setup:build_py.py", line 59, in run self.try_run(open(file).read()) File "Macintosh HD20:Programming:Python:Python 2.1.1:PyOpenGL:setup:build_py.py", line 128, in try_run libraries, library_dirs, lang) File "Macintosh HD20:Programming:Python:Python 2.1.1:PyOpenGL:setup:build_py.py", line 145, in _link library_dirs=library_dirs) File "Macintosh HD20:Programming:Python:Python 2.1.1:Lib:distutils:ccompiler.py", line 679, in link_executable debug, extra_preargs, extra_postargs, None) File "Macintosh HD20:Programming:Python:Python 2.1.1:Lib:distutils:mwerkscompiler.py", line 93, in link raise DistutilsPlatformError, 'Can only make SHARED_LIBRARY or SHARED_OBJECT targets on the Mac' DistutilsPlatformError: Can only make SHARED_LIBRARY or SHARED_OBJECT targets on the Mac get_build_info ":src:shadow:GLU.__init__.c" Traceback (most recent call last): File "Macintosh HD20:Programming:Python:Python 2.1.1:PyOpenGL:setup:build_py.py", line 59, in run self.try_run(open(file).read()) File "Macintosh HD20:Programming:Python:Python 2.1.1:PyOpenGL:setup:build_py.py", line 128, in try_run libraries, library_dirs, lang) File "Macintosh HD20:Programming:Python:Python 2.1.1:PyOpenGL:setup:build_py.py", line 145, in _link library_dirs=library_dirs) File "Macintosh HD20:Programming:Python:Python 2.1.1:Lib:distutils:ccompiler.py", line 679, in link_executable debug, extra_preargs, extra_postargs, None) File "Macintosh HD20:Programming:Python:Python 2.1.1:Lib:distutils:mwerkscompiler.py", line 93, in link raise DistutilsPlatformError, 'Can only make SHARED_LIBRARY or SHARED_OBJECT targets on the Mac' DistutilsPlatformError: Can only make SHARED_LIBRARY or SHARED_OBJECT targets on the Mac get_build_info ":src:shadow:WGL.__init__.c" Traceback (most recent call last): File "Macintosh HD20:Programming:Python:Python 2.1.1:PyOpenGL:setup:build_py.py", line 59, in run self.try_run(open(file).read()) File "Macintosh HD20:Programming:Python:Python 2.1.1:PyOpenGL:setup:build_py.py", line 128, in try_run libraries, library_dirs, lang) File "Macintosh HD20:Programming:Python:Python 2.1.1:PyOpenGL:setup:build_py.py", line 145, in _link library_dirs=library_dirs) File "Macintosh HD20:Programming:Python:Python 2.1.1:Lib:distutils:ccompiler.py", line 679, in link_executable debug, extra_preargs, extra_postargs, None) File "Macintosh HD20:Programming:Python:Python 2.1.1:Lib:distutils:mwerkscompiler.py", line 93, in link raise DistutilsPlatformError, 'Can only make SHARED_LIBRARY or SHARED_OBJECT targets on the Mac' DistutilsPlatformError: Can only make SHARED_LIBRARY or SHARED_OBJECT targets on the Mac not copying :OpenGL:__init__.py (output up-to-date) not copying :OpenGL:trackball.py (output up-to-date) error: package directory 'EXT' does not exist From doug@sonosphere.com Thu Sep 6 06:18:34 2001 From: doug@sonosphere.com (Doug Wyatt) Date: Wed, 5 Sep 2001 22:18:34 -0700 Subject: [Pythonmac-SIG] Python / MachO / Cocoa Message-ID: <9E524AD2-A286-11D5-B37B-00039301A6E6@sonosphere.com> I'm curious about what work others may have already done, and what further work would remain, to make it possible to write Cocoa apps in Python ... Is there a general mechanism to call functions in native Mach-O frameworks without having to write/generate tons of glue? (I just did some Java native bindings so I've got my head in this problem space at the moment :-) Doug -- Doug Wyatt personal: doug@sonosphere.com http://www.sonosphere.com "Music happens when you disrupt space in a secure and confident manner." -- One of the members of the Art Ensemble of Chicago From moehl@akaflieg.extern.tu-berlin.de Thu Sep 6 15:06:23 2001 From: moehl@akaflieg.extern.tu-berlin.de (Torsten Sadowski) Date: Thu, 6 Sep 2001 16:06:23 +0200 (CEST) Subject: [Pythonmac-SIG] PyOpenGL using Python 2.1.1. on G3 distutils failure In-Reply-To: Message-ID: Hi, you have something about incorrect line endings in your traceback. This can be the reason for many unexpected problems. You should change this first, TextSpresso should do the trick. Then try again without _w. There is no swig on the Mac. PyopenGL should install but you cant really use it because you dont have a GL canvas. Togl wont build and wxpython is not available on the Mac (yet?). HTH Torsten From managan@llnl.gov Thu Sep 6 16:36:11 2001 From: managan@llnl.gov (Rob Managan) Date: Thu, 6 Sep 2001 08:36:11 -0700 Subject: [Pythonmac-SIG] PyOpenGL using Python 2.1.1. on G3 distutils failure In-Reply-To: References: Message-ID: >Hi, >you have something about incorrect line endings in your traceback. This >can be the reason for many unexpected problems. You should change this >first, TextSpresso should do the trick. Then try again without _w. There >is no swig on the Mac. PyopenGL should install but you cant really use it >because you dont have a GL canvas. Togl wont build and wxpython is not >available on the Mac (yet?). > >HTH Torsten > I tried PyOpenGL also and ran into line ending problems as well. I have not gotten back to it yet. There is a SWIG for the Mac. Unfortunately the interface was a simple Tcl dialog and probably does not lend itself to AppleEvents or any other easy way to script making the SWIG wrappers -- *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan LLNL ph: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From Y.Benita@pharm.uu.nl Thu Sep 6 17:08:26 2001 From: Y.Benita@pharm.uu.nl (Yair Benita) Date: Thu, 06 Sep 2001 18:08:26 +0200 Subject: [Pythonmac-SIG] Launch application Message-ID: Hi all, In my efforts to port Biopython to the mac I still cannot make blast work. On unix machine they use popen2 to launch blast and give it some arguments. How can this be done on the Mac? Blast for mac is a graphical window with fields you need to fill. How can I script this from python. Not only do I need to launch the application but also to give it some arguments. Any ideas? Yair -- Yair Benita Pharmaceutical Proteomics Faculty of Pharmacy Utrecht University The Netherlands Tel: +31 30 2539340 Fax: +31-2518219 E-mail: Y.Benita@pharm.uu.nl From aparente@adobe.com Thu Sep 6 18:38:42 2001 From: aparente@adobe.com (Alexandre Parenteau) Date: Thu, 06 Sep 2001 10:38:42 -0700 Subject: [Pythonmac-SIG] GUSI and MacOSX Message-ID: Hi, I'm a new user of Python for Mac, I'm currently integrating it with MacCvs and WinCvs (http://www/cvsgui.org). Jack asked me to make some tests on OSX, because GUSI has some problems, it reaches assertions in GUSIBuffer.cp from time to time. Well it turned out I could not reproduce it using a SMP blue G4 using an early OSX 10.1 access we have with our company. It's strange because it happens sometimes with 10.0.4, without SMP. I would guess Apple did fix something. I would guess the problem was that OSX was doing some preemptive call to GUSI callbacks even though it should not. So I hope I'm truthful when I state that MacPython Carbon should run beautifully on 10.1 when it goes out. As for 10.0.4, I'll continue to look at it. Regards, Alex. -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From aparente@adobe.com Thu Sep 6 18:49:32 2001 From: aparente@adobe.com (Alexandre Parenteau) Date: Thu, 06 Sep 2001 10:49:32 -0700 Subject: [Pythonmac-SIG] 2 proposals for embedding MacPython in a C++ app Message-ID: Hi, 1 - Provide a registry mechanism for the MacPython preferences 2 - Provide a PyMac_SetWindowless function 1 - Manipulating the Popt preferences is difficult has both parties (application and Python). Instead of using a struct, I proposed Jack to essentially make each field an independent resource, a little bit like the Windows registry work. This is implemented in MacCvs this way : in the C code of python, each preference field is a template. For example the verbose persistent field would be created this way (I put it in C++ style, but it doesn't have to be implemented that way): CPersistent gVerbose("Verbose", false) When we start-up, the C code search (for example) for a 'Popt' resource named 'Verbose' and get the value out of it (first in the app resources, then in the python resources). When we close down, we go thru each persistent value and store then individually inside the preferences. This method means backward compatibility, default values, ability for the client to override by providing the same resource. 2 - I fund several cases where Python would open some dialogs or the SIOUX console, even though I'd like it to not do that. PyMac_SetWindowless(bool) can help resolve this issue early on. Thanks to comment, I made it short intentionally. Regards, Alex. -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From simonmagus@earthlink.net Fri Sep 7 02:31:41 2001 From: simonmagus@earthlink.net (Sans Peur) Date: Thu, 06 Sep 2001 18:31:41 -0700 Subject: [Pythonmac-SIG] PyOpenGL using Python 2.1.1. on G3 distutils failure In-Reply-To: Message-ID: on 9/6/01 7:06 AM, Torsten Sadowski at moehl@akaflieg.extern.tu-berlin.de wrote: > Hi, > you have something about incorrect line endings in your traceback. The mac uses \r line breaks. PyOpenGL setup fails right off the bat unless I put in the \r line breaks. The message is there about \r because the .tar file was intended for UNIX, since there is no Mac version. > This > can be the reason for many unexpected problems. Maybe, but putting in \r's has let me get this far without problems. There is an exception being thrown my the linker.. therein lies the problem. > You should change this > first, TextSpresso should do the trick. The method described in the Python for Mac doc is to use BBEdit, which is what I did. What is TextSpresso? > Then try again without _w. What is _w ? > PyopenGL should install but you cant really use it > because you dont have a GL canvas. I use OpenGL on the Mac just fine with C code, all that PyOpenGL does is wrap the C code, so I don't see why it wouldn't work. The graphics API used by MacOS is OpenGL. Also, PyOpenGL is fully advertised as working on MacOS by it's authors. What do you mean by GL canvas? There is an API for OpenGL that is an Apple download that gives everything needed. > Togl wont build and wxpython is not > available on the Mac (yet?). True, but Togl is not required for anything that I want to do, and wxpython is a Windows widget tool. GLUT provides the Window for Mac. Bryce From jack@oratrix.nl Fri Sep 7 10:51:30 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 07 Sep 2001 11:51:30 +0200 Subject: [Pythonmac-SIG] Urgent: please resend OSX 10.1 configure patches Message-ID: <20010907095132.0013E303181@snelboot.oratrix.nl> Someone sent me configure.in patches to make the whole Python build process work better on MacOSX 10.1, but I appear to have misfiled them, *and* I have completely forgotten who sent them. Could whoever sent me the stuff please do so again? Python 2.2a3 is scheduled to go out Real Soon Now, and I'd like to get this in, of course. -- 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 noon@snow.cit.cornell.edu Fri Sep 7 13:10:38 2001 From: noon@snow.cit.cornell.edu (William Noon) Date: Fri, 07 Sep 2001 08:10:38 -0400 Subject: [Pythonmac-SIG] Urgent: please resend OSX 10.1 configure patches In-Reply-To: Your message of "Fri, 07 Sep 2001 11:51:30 +0200." <20010907095132.0013E303181@snelboot.oratrix.nl> Message-ID: <200109071210.IAA10421@snow.cit.cornell.edu> Jack -- I tried the patches from Steve Spicklemire and fixed one typo (-flat-namespace not -flat_namespace in one case) and they fixed the link problems on puma. I am building with frameworks. --Bill Noon Index: configure.in =================================================================== RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.254 diff -c -r1.254 configure.in *** configure.in 2001/09/05 19:11:49 1.254 --- configure.in 2001/09/07 12:05:09 *************** *** 582,587 **** --- 582,593 ---- AC_SUBST(LIBTOOL_CRUFT) case $ac_sys_system/$ac_sys_release in + Darwin/1.4*) + ns_undef_sym='_environ' + LIBTOOL_CRUFT="-lcc_dynamic -arch_only ppc -flat_namespace -U $ns_undef_sym" + LIBTOOL_CRUFT="$LIBTOOL_CRUFT $extra_frameworks" + LIBTOOL_CRUFT=$LIBTOOL_CRUFT' -install_name $(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/Python' + LIBTOOL_CRUFT=$LIBTOOL_CRUFT' -compatibility_version $(VERSION) -current_version $(VERSION)';; Darwin/*) ns_undef_sym='_environ' LIBTOOL_CRUFT="-lcc_dynamic -arch_only ppc -U $ns_undef_sym" *************** *** 599,605 **** # -F. is needed to allow linking to the framework while # in the build location. ! LDFLAGS="$LDFLAGS -Wl,-F. -Wl,-U,$ns_undef_sym" AC_DEFINE(WITH_NEXT_FRAMEWORK) AC_MSG_RESULT(yes) else --- 605,614 ---- # -F. is needed to allow linking to the framework while # in the build location. ! case $ac_sys_system/$ac_sys_release in ! Darwin/1.4*)LDFLAGS="$LDFLAGS -Wl,-F. -Wl,-flat_namespace,-U,$ns_undef_sym";; ! Darwin/*)LDFLAGS="$LDFLAGS -Wl,-F. -Wl,-U,$ns_undef_sym";; ! esac AC_DEFINE(WITH_NEXT_FRAMEWORK) AC_MSG_RESULT(yes) else *************** *** 662,667 **** --- 671,685 ---- hp*|HP*) LDSHARED="ld -b";; OSF*) LDSHARED="ld -shared -expect_unresolved \"*\"";; DYNIX/ptx*) LDSHARED="ld -G";; + Darwin/1.4*) + LDSHARED='$(CC) $(LDFLAGS) -bundle' + if test "$enable_framework" ; then + # Link against the framework. All externals should be defined. + LDSHARED="$LDSHARED "'-framework $(PYTHONFRAMEWORK)' + else + # No framework. Ignore undefined symbols, assuming they come from Python + LDSHARED="$LDSHARED -flat_namespace -undefined suppress" + fi ;; Darwin/*) LDSHARED='$(CC) $(LDFLAGS) -bundle' if test "$enable_framework" ; then From steve@spvi.com Fri Sep 7 13:14:51 2001 From: steve@spvi.com (Steve Spicklemire) Date: Fri, 7 Sep 2001 07:14:51 -0500 Subject: [Pythonmac-SIG] Urgent: please resend OSX 10.1 configure patches In-Reply-To: <200109071210.IAA10421@snow.cit.cornell.edu> Message-ID: Oops.... dangit. I was testing changes in all the 10.1 configurations I could come up with at one point or another.. but obviously got out of sync somehow.. sorry! thanks for catching that Bill! -steve On Friday, September 7, 2001, at 07:10 AM, William Noon wrote: > Jack -- I tried the patches from Steve Spicklemire and fixed one typo > (-flat-namespace not -flat_namespace in one case) and they fixed the > link problems on puma. > > I am building with frameworks. > > --Bill Noon From jbradley@whiplashmedia.com Fri Sep 7 18:32:57 2001 From: jbradley@whiplashmedia.com (Jon Bradley) Date: Fri, 07 Sep 2001 13:32:57 -0400 Subject: [Pythonmac-SIG] 2 proposals for embedding MacPython in a C++ app In-Reply-To: Message-ID: > From: Alexandre Parenteau > > Hi, > > 1 - Provide a registry mechanism for the MacPython preferences > 2 - Provide a PyMac_SetWindowless function > > 1 - Manipulating the Popt preferences is difficult has both parties > (application and Python). Instead of using a struct, I proposed Jack to > essentially make each field an independent resource, a little bit like the > Windows registry work. For our 'little project', Alex, I just chose to allow Python to maintain control over it's own preferences. Could you possibly expand on your ideas on concerned? Maybe I'm just too new to all of this to make a useful comment. :) Then again - since I'm embedding Python right now in one of our 'little projects' ... we should be talking more often on these subjects. :) Jon From landauer@apple.com Fri Sep 7 18:29:49 2001 From: landauer@apple.com (Doug Landauer) Date: Fri, 7 Sep 2001 10:29:49 -0700 Subject: [Pythonmac-SIG] Urgent: please resend OSX 10.1 configure patches In-Reply-To: <200109071210.IAA10421@snow.cit.cornell.edu> Message-ID: On Friday, September 7, 2001, at 05:10 AM, William Noon wrote: > Jack -- I tried the patches from Steve Spicklemire and fixed one typo > (-flat-namespace not -flat_namespace in one case) and they fixed the > link problems on puma. Eventually, it's conceivable that support for the flat namespace model might go away. It may be slightly better to use "-bundle_loader python.exe" instead. Jack, here's a message that I sent you several weeks ago; maybe it's the one you're looking for? Haven't had time to try it since then... -- Doug L. From: Doug Landauer Date: Wed Aug 01, 2001 11:15:57 AM US/Pacific To: Jack Jansen Subject: Re: [Pythonmac-SIG] (unix) Python 2.2a1 on Mac OS X "10.>0" notes ... On Wednesday, August 1, 2001, at 04:21 AM, Jack Jansen wrote: ... too busy with OSX and 2.1.1 at the moment ... Hi, I just yesterday brought up Unix-python, 2.2a1 on "a future version of Mac OS X". Some linker changes require the dynamically loadable modules to be built with different flags. Since this OS X version isn't released yet, I'm reluctant to file my suggested fixes (which include answers to some of the questions in the README) as a bug on Sourceforge -- I'd rather send email to a few of the individuals involved. Any suggestions as to who would be appropriate folks to bother with it? Feel free to forward this to them. It'd be nice to get these changes into 2.2, since the "future" OS X release may not be *too* far in the future. (I'm too unfamiliar with Python's "configure" to know the right way to teach it how to test for the required linker flag changes, but I suggest a few simple one-liner shell tests that can detect the changes I'm talking about.) Here's my notes ... -- Doug L. Here are a few notes about trying to build Python-2.2a1 on "a future release of Mac OS X" ... The stuff ">-quoted" below is from the 2.2a1 README: > Mac OS X 10.0: Run configure with "OPT='-no-cpp-precomp' ./configure > --with-suffix=.exe --with-dyld". This generates executable > file: 'python.exe' (it cannot be named 'python' on an HFS or > HFS+ disk as the file name clashes with directory 'Python'). > The '-no-cpp-precomp' option prevents a large number of > compilation warnings. In "a future release of Mac OS X", the default behaviour of ld will require a different way to compile the extensions bundles. The short description is that you'll have to replace -undefined suppress with -bundle_loader python.exe (or whatever python --suffix= has been used) in all of the dynamically linked extensions. One easy-to-run test to see if this ld is a recent enough version to complain about "-undefined suppress" is: if ld -undefined suppress /usr/lib/bundle1.o -o /tmp/junk >& /dev/null then echo Using -undefined suppress is ok. else echo Must use -bundle_loader python.exe fi > One of the regular expression tests > fails with a SEGV due to the small stack size used by default > (how to change this?), In zsh: limit stacksize 800k is still too small, but limit stacksize 2000k seems to only set it to 1Mb -- I guess this version of the OS apparently has a hard limit of 1Mb. (Possibly overridable if you're root.) Anyway, at 1Mb, I get this: ./python.exe Lib/test/test_re.py Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded zsh: file size limit exceeded ./python.exe Lib/test/test_re.py Don't know what it's supposed to say, so I don't know whether or not this means that it worked. > and the test_largefile test is only > expected to work on a Unix UFS filesystem (how to check for > this on Mac OS X?). % mkdir foo Foo mkdir: Foo: File exists % Or % touch a ; [ -f A ] # fails on UFS, succeeds on HFS+ Of course, this will break if a UFS variant is ever created that is case-preserving instead of case-sensitive. My guess is that we don't have to worry about that. > IMPORTANT: If the tests fail and you decide to mail a bug report, > *don't* include the output of "make test". It is useless. Run the > failing test manually, as follows: > > python ../Lib/test/test_whatever.py Here, that would be ./python.exe Lib/test/test_whatever.py > (substituting the top of the source tree for .. if you built in a > different directory). This runs the test in verbose mode. ... > If you have a previous installation of Python that you don't > want to replace yet, use > > make altinstall > > This installs the same set of files as "make install" except it > doesn't create the hard link to "python" named "python" and > it doesn't install the manual page at all. I tried this, and the first time it ran, it spewed out a whole bunch of 'Skipping: ' errors looking like they're related to trying to run h2py.py, from inside of "regen". python$EXE ../../Tools/scripts/h2py.py /usr/include/fcntl.h python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h ../../Tools/scripts/h2py.py:24: DeprecationWarning: the regex module is deprecated; please use the re module import sys, regex, regsub, string, getopt, os /Volumes/zuni/insw/python2/Python-2.2a1/Lib/regsub.py:15: DeprecationWarning: the regsub module is deprecated; please use re.sub() DeprecationWarning) Skipping: INADDR_ANY = (u_int32_t)0x00000000 Skipping: INADDR_LOOPBACK = (u_int32_t)0x7f000001 Skipping: INADDR_BROADCAST = (u_int32_t)0xffffffff Skipping: INADDR_UNSPEC_GROUP = (u_int32_t)0xe0000000 After I killed this in the middle, the next "make altinstall" looked like it worked. From steve@spvi.com Fri Sep 7 19:19:37 2001 From: steve@spvi.com (Steve Spicklemire) Date: Fri, 7 Sep 2001 13:19:37 -0500 Subject: [Pythonmac-SIG] Urgent: please resend OSX 10.1 configure patches In-Reply-To: Message-ID: Yes.. we discussed this.. the problem is that the created Makefile is used not only to build python, but also to build distutils based extension modules.. and it wasn't clear that the python executable would be easy to find in a completely general way. If we can *find* a way.. then this makes complete sense. Jack also mentioned that frameworks don't suffer from this problem.. so maybe it's better to use the framework style. -steve On Friday, September 7, 2001, at 12:29 PM, Doug Landauer wrote: > On Friday, September 7, 2001, at 05:10 AM, William Noon wrote: >> Jack -- I tried the patches from Steve Spicklemire and fixed one typo >> (-flat-namespace not -flat_namespace in one case) and they fixed the >> link problems on puma. > > Eventually, it's conceivable that support for the flat namespace > model might go away. It may be slightly better to use > "-bundle_loader python.exe" > instead. > > Jack, here's a message that I sent you several weeks ago; maybe > it's the one you're looking for? Haven't had time to try it > since then... > > -- Doug L. > From steve@spvi.com Fri Sep 7 19:19:37 2001 From: steve@spvi.com (Steve Spicklemire) Date: Fri, 7 Sep 2001 13:19:37 -0500 Subject: [Pythonmac-SIG] Urgent: please resend OSX 10.1 configure patches In-Reply-To: Message-ID: Yes.. we discussed this.. the problem is that the created Makefile is used not only to build python, but also to build distutils based extension modules.. and it wasn't clear that the python executable would be easy to find in a completely general way. If we can *find* a way.. then this makes complete sense. Jack also mentioned that frameworks don't suffer from this problem.. so maybe it's better to use the framework style. -steve On Friday, September 7, 2001, at 12:29 PM, Doug Landauer wrote: > On Friday, September 7, 2001, at 05:10 AM, William Noon wrote: >> Jack -- I tried the patches from Steve Spicklemire and fixed one typo >> (-flat-namespace not -flat_namespace in one case) and they fixed the >> link problems on puma. > > Eventually, it's conceivable that support for the flat namespace > model might go away. It may be slightly better to use > "-bundle_loader python.exe" > instead. > > Jack, here's a message that I sent you several weeks ago; maybe > it's the one you're looking for? Haven't had time to try it > since then... > > -- Doug L. > From jack@oratrix.nl Fri Sep 7 23:55:58 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 08 Sep 2001 00:55:58 +0200 Subject: [Pythonmac-SIG] Urgent: please resend OSX 10.1 configure patches In-Reply-To: Message by Doug Landauer , Fri, 7 Sep 2001 10:29:49 -0700 , Message-ID: <20010907225604.7E4C011D122@oratrix.oratrix.nl> Recently, Doug Landauer said: > > Eventually, it's conceivable that support for the flat namespace > model might go away. It may be slightly better to use > "-bundle_loader python.exe" > instead. I was referring to either, but Steve's message got to me first, so that's going to be in the repository. However, I like your method better, as it actually checks that the right symbols are defined at compile time, whereas Steve's fix does "the unix thing", it'll just build a library that will happily fail at runtime. Something else I would like for the next release is not keying on Darwin/1.4 or so, as that is error-prone when Darwin/1.5 comes out. If you (or Steve, or someone else) could come up with a test to put into configure.in to test whether the -bundle_loader option is supported on this specific version of the OS that would be very welcome. Just put a patch into sourceforge and I'll find it when I return from holidays:-) -- 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 Sep 8 00:05:54 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 08 Sep 2001 01:05:54 +0200 Subject: [Pythonmac-SIG] 2 proposals for embedding MacPython in a C++ app In-Reply-To: Message by Alexandre Parenteau , Thu, 06 Sep 2001 10:49:32 -0700 , Message-ID: <20010907230559.2675C11D122@oratrix.oratrix.nl> Recently, Alexandre Parenteau said: > Hi, > > 1 - Provide a registry mechanism for the MacPython preferences > 2 - Provide a PyMac_SetWindowless function I like your (1), it would also solve the problem that to override one prefernce you have to override them all, and that a new version of the prefs resource means I have to put in backward compatability hacks or all .rsrc files for applets will break. I think I'll want to do this myself, as there's various issues with overriding prefs and such that I feel are important. Maybe put in a sourceforge change request, so I'll remember? As to (2): I like the idea, but as we've discussed offline I don't have a clear picture of when you would want to call this (before PyMac_Initialize()? At any time?) and exactly what it should do (close stdin/stdout/stderr? More?). Do you think you can come up with a patch yourself? For the benefit of the rest of the list: I think a way to forbid Python to touch the UI on its own initiative would make it possible (or at least safer) to create FBAs in Python, use Python for Netscape Plugins and all that sort of things. -- 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 Sep 8 00:33:48 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 08 Sep 2001 01:33:48 +0200 Subject: [Pythonmac-SIG] A MachO Python application in 2.2a3 - please try it! Message-ID: <20010907233353.ACCAF11D122@oratrix.oratrix.nl> Folks, in Python 2.2a3, which went out earlier today, there is a feature that I would like people to play with. Note that this refers to unix-Python, MacPython 2.2a3 will come soon (monday at the latest, is my guess). Anyway, if you build Python as a framework and install that you can create a "real" Python application with a Makefile that is in Mac/OSX. You can drop Python scripts on this application and they'll run in a full windowing environment, so you should be able to open dialogs, etc. All this was quickly hacked together by using the MacPython main.c and getargv.c (one evening got it working!) so it's probably still a little rough around the edges. For one thing I think it loses argv[0], the program name, at the moment. Still, I think this may be a good starting point to experiment with Carbon development on OSX MachO-Python. And even though I know next to nothing about the ObjC module and Cocoa I have the hope that this could also kick that back into life, because now your script gets run as true application, appearing in the dock, etc. Here is some of the things that I had in mind doing, but won't get around until I'm back from holidays (early october), so feel free to beat me to it and/or implement something better. 1. I think we can do applets real easy. If the main program can get its bundle directory it can check for a file Resources/__main__.py or .pyc and if that exists it can execute that script. Presto, applets are there! 2. It could also look for Resources/__rawmain__.py or pyc, and if that exists also execute that script, *but skipping it's normal argv emulation*. This would mean that when the script gets control the appleevent that started it would still be sitting in the queue waiting for you, similar to "don't do argc processing" in MacPython applets. I think this may also be needed for Cocoa apps (but I'm not sure). 3. The .rsrc files in the unix distribution are not really resource files, they're AppleSingle encoded resource files. My plan was to leave this so, so they can survive tar transmission. The idea is that there's going to be an AppleSingle decoder, and that if the new macresource module (which is now used by all the standard modules that used to simply open a .rsrc file) will detect that the xxxx.rsrc is an AppleSingle file, and attempt to open xxxx.decoded.rsrc. If this file doesn't exist (or is older that xxxx.rsrc) it would use the AppleSingle module to unpack it. 4. Python.app currently misses all the standard resources (from dialogs.rsrc and such). This means EasyDialogs won't work, and Python may also use these resources internally. At some point the build process should use AppleSingle to convert the .rsrc files to *data fork* resources and put them in the right place in the application 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/ ++++ From jack@oratrix.nl Sat Sep 8 22:30:21 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat, 08 Sep 2001 23:30:21 +0200 Subject: [Pythonmac-SIG] MacPython 2.2a3 available Message-ID: <20010908213026.DD94E139843@oratrix.oratrix.nl> In an unprecedented move MacPython 2.2a3 is available only a scant 26 hours or so after the unix/windows distribution of 2.2a3. MacPython 2.2a3 is available via http://www.cwi.nl/~jack/macpython.html, as usual, and in hqx or macbinary form, as a full installer, an active installer and a source distribution (as usual:-). Aside from the general new 2.2a3 features there are three specific changes in MacPython that are worth mentioning: - The structure of the MacOS toolbox modules has changed. All the modules have been put into a "Carbon" package (which, despite the name, runs fine in the classic PPC runtime model). There is a backwards compatibility folder on sys.path that will keep imports with the old names working (with an obnoxious warning). - Plugin modules are now in :Lib:lib-dynload in stead of in :Mac:PlugIns, to make the installed tree look more like the unix tree. - On input, unix line-endings are now acceptable for all text files. This is an experimental feature (awaiting a general solution, for which a PEP has been promised but not started yet, the giulty parties know who they are:-), and it can be turned off with a preference. The downside of the quick release is that the installer has only been tested on MacOSX 10.0.4 and MacOS 9.1. Please report problems on older releases of MacOS asap. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From garyb@strata.com Sat Sep 8 22:53:02 2001 From: garyb@strata.com (Gary Bringhurst) Date: Sat, 08 Sep 2001 15:53:02 -0600 Subject: [Pythonmac-SIG] 2 proposals for embedding MacPython in a C++ app In-Reply-To: Message-ID: The latest documentation on Metrowerks 7's MSL indicates that there is a function call available to make something linked against SIOUX "windowless". They talk about going into stub mode, as if you had not linked against SIOUX but rather the console stubs. This allows a runtime determination of whether to ever show a console window. Does this satisify the need on the Mac? Gary Bringhurst garyb@strata.com > From: Jack Jansen > Date: Friday, September 7, 2001 5:05 PM > To: Alexandre Parenteau > CC: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] 2 proposals for embedding MacPython in a C++ app > > > Recently, Alexandre Parenteau said: >> Hi, >> >> 1 - Provide a registry mechanism for the MacPython preferences >> 2 - Provide a PyMac_SetWindowless function > > I like your (1), it would also solve the problem that to override one > prefernce you have to override them all, and that a new version of the > prefs resource means I have to put in backward compatability hacks or > all .rsrc files for applets will break. I think I'll want to do this > myself, as there's various issues with overriding prefs and such that > I feel are important. Maybe put in a sourceforge change request, so > I'll remember? > > As to (2): I like the idea, but as we've discussed offline I don't > have a clear picture of when you would want to call this (before > PyMac_Initialize()? At any time?) and exactly what it should do > (close stdin/stdout/stderr? More?). Do you think you can come up with > a patch yourself? > > For the benefit of the rest of the list: I think a way to forbid > Python to touch the UI on its own initiative would make it possible > (or at least safer) to create FBAs in Python, use Python for Netscape > Plugins and all that sort of things. > -- > 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 hummelsean@mac.com Sat Sep 8 23:02:18 2001 From: hummelsean@mac.com (Sean Hummel) Date: Sat, 08 Sep 2001 15:02:18 -0700 Subject: [Pythonmac-SIG] 2 proposals for embedding MacPython in a C++ app In-Reply-To: Message-ID: When I did some embedding of Python earlier, I found that this worked for me. Instead of directing characters to the console for SIOUX, I instead just redirected to a logfile, which worked fine for me. > From: Gary Bringhurst > Date: Sat, 08 Sep 2001 15:53:02 -0600 > To: > Subject: Re: [Pythonmac-SIG] 2 proposals for embedding MacPython in a C++ app > > The latest documentation on Metrowerks 7's MSL indicates that there is a > function call available to make something linked against SIOUX "windowless". > They talk about going into stub mode, as if you had not linked against SIOUX > but rather the console stubs. This allows a runtime determination of > whether to ever show a console window. Does this satisify the need on the > Mac? > > Gary Bringhurst > garyb@strata.com > > >> From: Jack Jansen >> Date: Friday, September 7, 2001 5:05 PM >> To: Alexandre Parenteau >> CC: pythonmac-sig@python.org >> Subject: Re: [Pythonmac-SIG] 2 proposals for embedding MacPython in a C++ app >> >> >> Recently, Alexandre Parenteau said: >>> Hi, >>> >>> 1 - Provide a registry mechanism for the MacPython preferences >>> 2 - Provide a PyMac_SetWindowless function >> >> I like your (1), it would also solve the problem that to override one >> prefernce you have to override them all, and that a new version of the >> prefs resource means I have to put in backward compatability hacks or >> all .rsrc files for applets will break. I think I'll want to do this >> myself, as there's various issues with overriding prefs and such that >> I feel are important. Maybe put in a sourceforge change request, so >> I'll remember? >> >> As to (2): I like the idea, but as we've discussed offline I don't >> have a clear picture of when you would want to call this (before >> PyMac_Initialize()? At any time?) and exactly what it should do >> (close stdin/stdout/stderr? More?). Do you think you can come up with >> a patch yourself? >> >> For the benefit of the rest of the list: I think a way to forbid >> Python to touch the UI on its own initiative would make it possible >> (or at least safer) to create FBAs in Python, use Python for Netscape >> Plugins and all that sort of things. >> -- >> 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 csmith@blakeschool.org Sun Sep 9 05:33:11 2001 From: csmith@blakeschool.org (Christopher Smith) Date: Sat, 08 Sep 2001 23:33:11 -0500 Subject: [Pythonmac-SIG] resolve alias Message-ID: Hello, Can I get a hand on this from someone? I am trying to write a script that will get and restore preference files (or any files for that matter). I read in the macostools docs that #If the source is an alias the original to which the alias points #is copied, not the aliasfile. Well...I created a file on the desktop, dragged an alias of it to a "src" folder and fed the path to that alias to the macostools.copy(). The alias itself is copied to the destination folder (dst), not the original. How can I get the original to copy instead of the alias? Did I misread the docs? Here's what I tried so far: I read a bit more and found the ResolveAliasFile routine...I used it to obtain the fss for this file and then tried to use Resolve to get the actual path to the file that is on the desktop. BUT I can't figure out how to use Resolve. The docs say that it is an Alias method but I can't see how to use the method. How do I get an alias object to use this method on? /c From stefan.witzgall@online.de Sun Sep 9 10:31:19 2001 From: stefan.witzgall@online.de (Stefan Witzgall) Date: Sun, 9 Sep 2001 11:31:19 +0200 Subject: [Pythonmac-SIG] Error 45 with Paos and setsockopt Message-ID: Dear PythonMac-list, I tried the database server Paos found on www.sourceforge.net and run into a problem. The interpreter and the IDE give me an error 45 when running the Server.py script: ------------------------------Traceback window------------------------- error: (45, 'Operation not supported on socket') Traceback (innermost last): -------------------------------------------------- File "Server.py", line 50, in ? s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) -------------------------------------------------- ------------------------------Traceback window------------------------- Could you please give me any advise to fix the problem or is anyone using Paos here on the list? I found Paos when I searched for an database for/with/in Python. At least I can run GadFly, a SQL- database with MacPython. With MetaKit I did run into the problem that the .slb file is too old for MacPython 2.1.1 and too new for 1.5.2c1. Perhaps you have any thoughts about that too. Thank You for reading this and any help or hint. Stefan ############################################################################## Here are the first few lines of Server.py, changed by me as you can see to run on my Macintosh: # # Copyright 1995 Carlos Maltzahn [copyright] # # Author: # Carlos Maltzahn # Dept. of Computer Science # Campus Box 430 # Univ. of Colorado, Boulder # Boulder, CO 80309 # # carlosm@cs.colorado.edu # import sys import socket import select import pickle import string from types import * import traceback import Store import Utilities """ stef commented these lines to test on a Macintosh: if len(sys.argv) not in [2,3]: print 'Usage: python Server.py []' sys.exit(1) """ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) """ stef commented this line: s.bind('',string.atoi(sys.argv[1])) and made this: """ portnumber = 10050 # arbitrary chosen portnumber s.bind('',portnumber) s.listen(5) conn_table = {} # conn -> client client_table = {} # client -> conn conn_list = [s] print 'Server: ready and listening' while 1: (ready_list, x, y) = select.select(conn_list, [], []) for ready_conn in ready_list: if ready_conn is s: (conn, address) = s.accept() [the rest of Server.py] From mday@mac.com Mon Sep 10 02:57:49 2001 From: mday@mac.com (Mark Day) Date: Sun, 09 Sep 2001 18:57:49 -0700 Subject: [Pythonmac-SIG] resolve alias In-Reply-To: Message-ID: on 9/8/01 9:33 PM, Christopher Smith at csmith@blakeschool.org wrote: > I read a bit more and found the ResolveAliasFile routine...I used it > to obtain the fss for this file and then tried to use Resolve to get > the actual path to the file that is on the desktop. BUT I can't figure > out how to use Resolve. The docs say that it is an Alias method but I > can't > see how to use the method. How do I get an alias object to use this > method on? Here's one way to resolve an alias. It will print the pathname to Sherlock 2. It finds the alias file in the Apple Menu Items folder, and resolves it to find the application itself. -Mark from macfs import * from MACFS import * # Get the vRefNum and dirID of the Apple Menu Items folder d = FindFolder(kOnSystemDisk, kAppleMenuFolderType, 0) # Make an FSSpec for the "Sherlock 2" alias in the Apple Menu Items folder # Note we're passing a (vRefNum, parID, name) tuple to FSSpec() src = FSSpec((d[0], d[1], "Sherlock 2")) # Find the real "Sherlock 2" application by resolving the alias # If the application itself was in the Apple Menu Items folder, # this would dest would be the same as src, and wasAliased would # be false. dest, isFolder, wasAliased = ResolveAliasFile(src) # Print the pathname of the Sherlock 2 application print dest.as_pathname() From jack@oratrix.nl Mon Sep 10 11:28:41 2001 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 10 Sep 2001 12:28:41 +0200 Subject: [Pythonmac-SIG] resolve alias In-Reply-To: Message by "Christopher Smith" , Sat, 08 Sep 2001 23:33:11 -0500 , Message-ID: <20010910102842.5D0E1303181@snelboot.oratrix.nl> > Well...I created a file on the desktop, dragged an alias of it to a > "src" folder and fed the path to that alias to the macostools.copy(). The > alias itself is copied to the destination folder (dst), not the > original. How can I get the original to copy instead of the alias? > Did I misread the docs? No, you didn't misread the docs, the docs were just wrong. They've been fixed: if you copy an alias file you copy the alias file, not what it is pointing to. > I read a bit more and found the ResolveAliasFile routine...I used it > to obtain the fss for this file and then tried to use Resolve to get > the actual path to the file that is on the desktop. You don't have to do that. ResolveAliasFile does all the work for you: you pass in the pathname or fsspec for the alias file, you get out the fsspec for the file it points to. Resolve() is only needed if you have an alias object, for instance created with fsspec.NewAlias(). -- 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 Mon Sep 10 11:45:01 2001 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 10 Sep 2001 12:45:01 +0200 Subject: [Pythonmac-SIG] Error 45 with Paos and setsockopt In-Reply-To: Message by Stefan Witzgall , Sun, 9 Sep 2001 11:31:19 +0200 , Message-ID: <20010910104501.9CFEF303181@snelboot.oratrix.nl> > The interpreter and the IDE give me an error 45 when running the Server.py > script: > > ------------------------------Traceback window------------------------- > error: (45, 'Operation not supported on socket') > Traceback (innermost last): > -------------------------------------------------- > File "Server.py", line 50, in ? > s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) > -------------------------------------------------- I'm a bit surprised that SO_REUSEADDR isn't supported (but then, I never tried it:-). Anyway, you can safely take this out, usually. Setting SO_REUSEADDR is mostly used to be able to quickly listen to a port again after the previous program listening to that port has crashed. Normally there is a timeout of about a minute. If you take out this option the only thing you may notice is that if your program is aborted and you immedeately try to start it again you will get an "Address in use" or something similar. Wait a minute and it will go away. -- 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 Mon Sep 10 13:10:23 2001 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Mon, 10 Sep 2001 08:10:23 -0400 Subject: [Pythonmac-SIG] Error 45 with Paos and setsockopt Message-ID: > If you take out this option the only thing you may notice is that if your > program is aborted and you immedeately try to start it again you will get an > "Address in use" or something similar. Wait a minute and it will go away. Or even better, capture the error, and if it is Address in Use, place a error message ("Port busy, retrying in 15 seconds..."). Then sleep, and retry. - Benjamin -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Monday, September 10, 2001 6:45 AM To: Stefan Witzgall Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Error 45 with Paos and setsockopt > The interpreter and the IDE give me an error 45 when running the Server.py > script: > > ------------------------------Traceback window------------------------- > error: (45, 'Operation not supported on socket') > Traceback (innermost last): > -------------------------------------------------- > File "Server.py", line 50, in ? > s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) > -------------------------------------------------- I'm a bit surprised that SO_REUSEADDR isn't supported (but then, I never tried it:-). Anyway, you can safely take this out, usually. Setting SO_REUSEADDR is mostly used to be able to quickly listen to a port again after the previous program listening to that port has crashed. Normally there is a timeout of about a minute. If you take out this option the only thing you may notice is that if your program is aborted and you immedeately try to start it again you will get an "Address in use" or something similar. Wait a minute and it will go away. -- 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 csmith@blakeschool.org Mon Sep 10 17:55:08 2001 From: csmith@blakeschool.org (Christopher Smith) Date: Mon, 10 Sep 2001 11:55:08 -0500 Subject: [Pythonmac-SIG] Re: resolve alias In-Reply-To: <20010910102842.5D0E1303181@snelboot.oratrix.nl> References: <20010910102842.5D0E1303181@snelboot.oratrix.nl> Message-ID: jack@oratrix.nl writes: > >> Well...I created a file on the desktop, dragged an alias of it to a >> "src" folder and fed the path to that alias to the macostools.copy(). >The >> alias itself is copied to the destination folder (dst), not the >> original. How can I get the original to copy instead of the alias? >> Did I misread the docs? > >No, you didn't misread the docs, the docs were just wrong. They've been >fixed: >if you copy an alias file you copy the alias file, not what it is >pointing to. > OK, now it's as easy as falling off a log! What a nice set of tools for working with files on the Mac :-) Thanks for the responses. If anyone else is thinking about copying files around on the Mac with Python, here is a demo code. #### ''' A file demonstrating how to copy a source file to a destination file. In this case the dst file has the same name as the src file. If the src file is an alias, the alias will be resolved and the original file will be copied. If the reolution is not made then the alias file itself will be copied. .copy automatically copies the creator and type information. cps 9/10/01 ''' import macostools,macfs #src: file named a in folder orig on the desktop a='Macintosh HD:Desktop Folder:orig:a' #dst: file named a in folder pref on the desktop b='Macintosh HD:Desktop Folder:pref:a' #resolve alias if necessary afss,aIsFolder,aIsAliased=macfs.ResolveAliasFile(a) if aIsAliased: a=afss #copy src to dst macostools.copy(a, b) #### /c From dpreston@intersight.com Tue Sep 11 02:07:04 2001 From: dpreston@intersight.com (Donovan Preston) Date: Mon, 10 Sep 2001 18:07:04 -0700 Subject: [Pythonmac-SIG] A MachO Python application in 2.2a3 - please try it! In-Reply-To: <20010907233353.ACCAF11D122@oratrix.oratrix.nl> Message-ID: <50161348-A651-11D5-9140-003065B33450@intersight.com> --Apple-Mail-1-388387879 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Jack, and everyone, I have to say that Mach-O python is the best thing since sliced bread. I have been trying halfheartedly for a few months to tie command-line python and GUI Mac OS X together, but not knowing enough about either MacPython or Mac OS X, had little success. But your Makefile and email busted the door wide open. I had been attempting to write a C extension which would allow python to bring up a full-fledged carbon events application, but the key I was missing was the bundle structure. Since your Makefile in Mac/OSX provides that structure, it was simply a matter of dropping a nib file inside of Python.app/Contents/Resources/English.lproj, and I was able to load the carbon nib, producing a window, and start the carbon events loop with the help of my C extension. So, I set about implementing points 1 and 2 in your original message to provide application and applet functionality in Mach-O Python. With the Apple developer site as my reference, I was able to query the Resources directory inside of the bundle for .py files. As you suggested, if __rawmain__.py is present, I immediately pass control on to it. If __main__.py is present, I use your argv processing code before passing control to it. As you mentioned, it loses argv[0], but I didn't look into that bug. I also wrote some code to add the Resources directory to the python path. This is very handy since you can place all python modules and extension modules you wish to use there, creating a fully self contained application which can be distributed by dragging and dropping! Unfortunately, my code seems to lose site-packages, and Mach-O Python out of the box doesn't seem to be set up for /Library/Frameworks/Python.framework/Mac/Lib, so there is some path work left to be done. It wasn't immediately obvious to me how best to deal with these path issues. I wanted to mention the possibility of using the Bundle packaging scheme with Mac OS 9 -- Apple supports all of the Core Foundation calls related to bundle resource location on OS 9 as well as OS X. Obviously the binary would need to be compiled into a CFM binary, but the current bundle structure and code that I have written should also locate and load resources on OS 9. The only difference with a CFM Package versus a Mach-O Package as far as I can tell (from peeking inside of Acrobat 5 and other carbonized applications) is that an alias to the CFM binary needs to be placed at the root level of the Package. As a matter of fact, it may be possible to create a single Package which contains both Mach-O and CFM binaries, with the correct one being selected automatically depending on which OS the user is running. By starting with the Mach-O bundle, compiling a CFM binary with the proper bundle handling code compiled in, placing the CFM binary in the correct place and creating the alias, it should just work. I don't currently have CodeWarrior on my machine and have never compiled MacPython, so I'm hoping someone else with experience will try this and have success, but if no one does I may tackle it myself sometime soon. All in all, I'm very excited by the possibilities of Mach-O Python on OS X. I will follow up with a message detailing my experiments with loading .nib files from python and using the carbon event manager. Jack, thanks for taking the time to figure out how to properly bundle Mach-O Python, it really got the ball rolling for me! Attached is my modified macmain.c, modified from a fresh install of Python 2.2a3. --Apple-Mail-1-388387879 Content-Disposition: attachment Content-Type: multipart/appledouble; boundary=Apple-Mail-2-388387880 --Apple-Mail-2-388387880 Content-Disposition: attachment; filename=macmain.c Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="macmain.c" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAAAoAAAADAAAASAAAAAkAAAACAAAA UQAAAdZURVhUAAAAAAAAbWFjbWFpbi5jAAABAAAAAZAAAACQAAAARgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgA C1ZlcmRhbmEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYABAAvAEAC6ALjAC8AQALoAuO3wqlB AAA/QwAAP0MAAAAAAQAAAABAQy9DKysAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAQAB EAAAAFAAAAAAAAAAAAAAAAAAAAAAAA5wAAAAAQAAAAGQAAAAkAAAAEYAItCQFm8AAAAcAEYAAU1Q U1IAAAASUHBycwAAAB4D7f//AAAAAAIZgVwAgP//AAAATAAAAAA= --Apple-Mail-2-388387880 Content-Disposition: attachment; filename=macmain.c Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-mac-creator=0; x-unix-mode=0644; x-mac-type=54455854; name="macmain.c" /*********************************************************** Copyright 1991-1997 by Stichting Mathematisch Centrum, Amsterdam, The Netherlands. All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the names of Stichting Mathematisch Centrum or CWI not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ******************************************************************/ /* Python interpreter main program */ #include "Python.h" #include "pythonresources.h" #include "import.h" #include "marshal.h" #include "macglue.h" #ifdef WITHOUT_FRAMEWORKS #include #include #include #include #include #include #include #ifdef USE_APPEARANCE #include #include #endif /* USE_APPEARANCE */ #else #include #endif /* WITHOUT_FRAMEWORKS */ #ifdef __MWERKS__ #include #define USE_SIOUX extern int ccommand(char ***); #if __profile__ == 1 #include #endif /* __profile__ */ #endif /* __MWERKS__ */ #include #ifdef USE_MAC_SHARED_LIBRARY extern PyMac_AddLibResources(void); #endif #define STARTUP "PythonStartup" #define COPYRIGHT \ "Type \"copyright\", \"credits\" or \"license\" for more information." short PyMac_AppRefNum; /* RefNum of application resource fork */ /* For Py_GetArgcArgv(); set by main() */ static char **orig_argv; static int orig_argc; /* A flag which remembers whether the user has acknowledged all the console ** output (by typing something) */ #define STATE_UNKNOWN 0 #define STATE_LASTREAD 1 #define STATE_LASTWRITE 2 int console_output_state = STATE_UNKNOWN; PyMac_PrefRecord PyMac_options; static void Py_Main(int, char **); /* Forward */ void PyMac_Exit(int); /* Forward */ static void init_appearance(void) { #ifdef USE_APPEARANCE OSErr err; SInt32 response; err = Gestalt(gestaltAppearanceAttr,&response); if ( err ) goto no_appearance; if ( !(response&(1< isn't pressed. */ if (p->nointopt) return; GetKeys(rmap); map = (unsigned char *)rmap; if ( ( map[0x3a>>3] & (1<<(0x3a&7)) ) == 0 ) /* option key is 3a */ return; dialog = GetNewDialog(OPT_DIALOG, NULL, (WindowPtr)-1); if ( dialog == NULL ) { printf("Option dialog not found - cannot set options\n"); return; } SetDialogDefaultItem(dialog, OPT_OK); SetDialogCancelItem(dialog, OPT_CANCEL); /* Set default values */ #define SET_OPT_ITEM(num, var) \ GetDialogItem(dialog, (num), &type, (Handle *)&handle, &rect); \ SetControlValue(handle, (short)p->var); SET_OPT_ITEM(OPT_INSPECT, inspect); SET_OPT_ITEM(OPT_VERBOSE, verbose); /* OPT_VERBOSEVERBOSE is default off */ SET_OPT_ITEM(OPT_OPTIMIZE, optimize); SET_OPT_ITEM(OPT_UNBUFFERED, unbuffered); SET_OPT_ITEM(OPT_DEBUGGING, debugging); GetDialogItem(dialog, OPT_KEEPALWAYS, &type, (Handle *)&handle, &rect); SetControlValue(handle, (short)(p->keep_console == POPT_KEEPCONSOLE_ALWAYS)); GetDialogItem(dialog, OPT_KEEPOUTPUT, &type, (Handle *)&handle, &rect); SetControlValue(handle, (short)(p->keep_console == POPT_KEEPCONSOLE_OUTPUT)); GetDialogItem(dialog, OPT_KEEPERROR, &type, (Handle *)&handle, &rect); SetControlValue(handle, (short)(p->keep_console == POPT_KEEPCONSOLE_ERROR)); GetDialogItem(dialog, OPT_KEEPNEVER, &type, (Handle *)&handle, &rect); SetControlValue(handle, (short)(p->keep_console == POPT_KEEPCONSOLE_NEVER)); /* SET_OPT_ITEM(OPT_KEEPCONSOLE, keep_console); */ SET_OPT_ITEM(OPT_TABWARN, tabwarn); SET_OPT_ITEM(OPT_NOSITE, nosite); SET_OPT_ITEM(OPT_DIVISIONWARN, divisionwarn); SET_OPT_ITEM(OPT_UNIXNEWLINES, unixnewlines); /* The rest are not settable interactively */ #undef SET_OPT_ITEM while (1) { handle = NULL; ModalDialog(NULL, &item); if ( item == OPT_OK ) break; if ( item == OPT_CANCEL ) { DisposeDialog(dialog); exit(0); } #if !TARGET_API_MAC_CARBON if ( item == OPT_HELP ) { HMSetBalloons(!HMGetBalloons()); } #endif #if !TARGET_API_MAC_OSX if ( item == OPT_CMDLINE ) { int old_argc = *argcp; int i; int new_argc, newer_argc; char **new_argv, **newer_argv; new_argc = ccommand(&new_argv); newer_argc = (new_argc-1) + old_argc; newer_argv = malloc((newer_argc+1)*sizeof(char *)); if( !newer_argv ) Py_FatalError("Cannot malloc argv\n"); for(i=0; ivar = !p->var; \ GetDialogItem(dialog, (num), &type, (Handle *)&handle, &rect); \ SetControlValue(handle, (short)p->var); \ } OPT_ITEM(OPT_INSPECT, inspect); OPT_ITEM(OPT_VERBOSE, verbose); if ( item == OPT_VERBOSEVERBOSE ) { if ( p->verbose == 2 ) p->verbose = 1; else p->verbose = 2; GetDialogItem(dialog, OPT_VERBOSE, &type, (Handle *)&handle, &rect); SetControlValue(handle, 1); } GetDialogItem(dialog, OPT_VERBOSEVERBOSE, &type, (Handle *)&handle, &rect); SetControlValue(handle, p->verbose == 2); OPT_ITEM(OPT_OPTIMIZE, optimize); OPT_ITEM(OPT_UNBUFFERED, unbuffered); OPT_ITEM(OPT_DEBUGGING, debugging); if ( item == OPT_KEEPALWAYS ) p->keep_console = POPT_KEEPCONSOLE_ALWAYS; if ( item == OPT_KEEPOUTPUT ) p->keep_console = POPT_KEEPCONSOLE_OUTPUT; if ( item == OPT_KEEPERROR ) p->keep_console = POPT_KEEPCONSOLE_ERROR; if ( item == OPT_KEEPNEVER ) p->keep_console = POPT_KEEPCONSOLE_NEVER; GetDialogItem(dialog, OPT_KEEPALWAYS, &type, (Handle *)&handle, &rect); SetControlValue(handle, (short)(p->keep_console == POPT_KEEPCONSOLE_ALWAYS)); GetDialogItem(dialog, OPT_KEEPOUTPUT, &type, (Handle *)&handle, &rect); SetControlValue(handle, (short)(p->keep_console == POPT_KEEPCONSOLE_OUTPUT)); GetDialogItem(dialog, OPT_KEEPERROR, &type, (Handle *)&handle, &rect); SetControlValue(handle, (short)(p->keep_console == POPT_KEEPCONSOLE_ERROR)); GetDialogItem(dialog, OPT_KEEPNEVER, &type, (Handle *)&handle, &rect); SetControlValue(handle, (short)(p->keep_console == POPT_KEEPCONSOLE_NEVER)); OPT_ITEM(OPT_TABWARN, tabwarn); OPT_ITEM(OPT_NOSITE, nosite); OPT_ITEM(OPT_DIVISIONWARN, divisionwarn); OPT_ITEM(OPT_UNIXNEWLINES, unixnewlines); #undef OPT_ITEM } DisposeDialog(dialog); } /* ** Initialization code, shared by interpreter and applets */ static void init_common(int *argcp, char ***argvp, int embedded) { /* Remember resource fork refnum, for later */ PyMac_AppRefNum = CurResFile(); /* Initialize toolboxes */ init_mac_world(); #ifdef USE_MAC_SHARED_LIBRARY /* Add the shared library to the stack of resource files */ (void)PyMac_init_process_location(); PyMac_AddLibResources(); #endif #if defined(USE_GUSI1) /* Setup GUSI */ GUSIDefaultSetup(); PyMac_SetGUSISpin(); PyMac_SetGUSIOptions(); #endif #if defined(USE_GUSI) atexit(PyMac_StopGUSISpin); #endif #ifdef USE_SIOUX /* Set various SIOUX flags. Some are changed later based on options */ #if 0 SIOUXSettings.standalone = 0; /* XXXX Attempting to keep sioux from eating events */ #endif SIOUXSettings.asktosaveonclose = 0; SIOUXSettings.showstatusline = 0; SIOUXSettings.tabspaces = 4; #endif /* Get options from preference file (or from applet resource fork) */ PyMac_options.keep_console = POPT_KEEPCONSOLE_OUTPUT; /* default-default */ PyMac_options.unixnewlines = 1; #if !TARGET_API_MAC_OSX PyMac_PreferenceOptions(&PyMac_options); #endif if ( embedded ) { static char *emb_argv[] = {"embedded-python", 0}; *argcp = 1; *argvp = emb_argv; } else { /* Create argc/argv. Do it before we go into the options event loop. */ *argcp = PyMac_GetArgv(argvp, PyMac_options.noargs); #if !TARGET_API_MAC_OSX #ifndef NO_ARGV0_CHDIR if (*argcp >= 1 && (*argvp)[0] && (*argvp)[0][0]) { /* Workaround for MacOS X, which currently (DP4) doesn't set ** the working folder correctly */ char app_wd[256], *p; strncpy(app_wd, (*argvp)[0], 256); p = strrchr(app_wd, ':'); if ( p ) *p = 0; chdir(app_wd); } #endif #endif /* Do interactive option setting, if allowed and