From shendric@arches.uga.edu Mon Jul 1 21:38:11 2002 From: shendric@arches.uga.edu (shendric@arches.uga.edu) Date: Mon, 1 Jul 2002 15:38:11 -0500 Subject: [Pythonmac-SIG] Mac and Tkinter Message-ID: <1025552291.smmsdV1.1.1@mail.arches.uga.edu> Hi all, I wrote an application in Python and Tkinter for Windows, but I'd like to make a version that functions on Mac. I'm using Mac OS 9.2, but I can use Mac OS X, as well. I installed the latest version of MacPython, but I can't get the program to find Tkinter. Is this a problem that others have had? or is there any idea why this might happen? The directory structure of the Python22 folder is different from what I'm used to in Python22 for Windows, so I'm not even really sure how to tell that it's configured correctly. Any help I can get would be sincerely appreciated. Sean From Jack.Jansen@cwi.nl Tue Jul 2 09:58:15 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 2 Jul 2002 10:58:15 +0200 Subject: [Pythonmac-SIG] Mac and Tkinter In-Reply-To: <1025552291.smmsdV1.1.1@mail.arches.uga.edu> Message-ID: On Monday, July 1, 2002, at 10:38 , shendric@arches.uga.edu wrote: > Hi all, > > I wrote an application in Python and Tkinter for Windows, but I'd like > to make a version that functions on Mac. I'm using Mac OS 9.2, but I > can use Mac OS X, as well. I installed the latest version of MacPython, > but I can't get the program to find Tkinter. Under MacOS 9 with MacPython run the ConfigurePythonClassic applet and Tkinter will start working. Tk doesn't work under the newer Carbon execution model, and probably never will. Under Mac OS X you can use Tkinter with the normal unix Python (not with MacPython), but you have to do all the building and installing yourself. Look through the pythonmac-sig archives for details. > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From just@letterror.com Tue Jul 2 10:07:19 2002 From: just@letterror.com (Just van Rossum) Date: Tue, 2 Jul 2002 11:07:19 +0200 Subject: [Pythonmac-SIG] Framework confusion (was: Mac and Tkinter) In-Reply-To: Message-ID: Jack Jansen wrote: > Under Mac OS X you can use Tkinter with the normal unix Python (not with > MacPython), but you have to do all the building and installing yourself. > Look through the pythonmac-sig archives for details. Does Aqua Tkinter also work for a non-framework build? Which reminds me of a question I was meaning to ask earlier: what's the reason that .so files compiled for a framework build cannot be used in a non-framework build and vice versa? I always thought that frameworks were just a clever way of packaging, but I guess I'm wrong... Is a framework build 100% compatible with a standard (non-framework) unix install from a command line perspective? Eg. will CGI work the exact same way? Just From paul@fxtech.com Tue Jul 2 15:08:21 2002 From: paul@fxtech.com (Paul Miller) Date: Tue, 02 Jul 2002 09:08:21 -0500 Subject: [Pythonmac-SIG] NumPy for MacPython/Carbon? In-Reply-To: References: Message-ID: <5.1.0.14.2.20020702090719.01ff6fa8@cedar.he.net> Hi Folks, Saw some discussion about compiling NumPy for Mach-O Python, but is there a pre-built installer and/or archive with NumPy for MacPython 2.2.1? If not, should this be a straightforward compile if grab the sources? Cheers, -Paul -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From just@letterror.com Tue Jul 2 15:26:32 2002 From: just@letterror.com (Just van Rossum) Date: Tue, 2 Jul 2002 16:26:32 +0200 Subject: [Pythonmac-SIG] NumPy for MacPython/Carbon? In-Reply-To: <5.1.0.14.2.20020702090719.01ff6fa8@cedar.he.net> Message-ID: Paul Miller wrote: > Saw some discussion about compiling NumPy for Mach-O Python, but is there a > pre-built installer and/or archive with NumPy for MacPython 2.2.1? If not, > should this be a straightforward compile if grab the sources? NumPy is included with MacPython, so I'd say, try to do "import Numeric"... Just From paul@fxtech.com Tue Jul 2 15:40:07 2002 From: paul@fxtech.com (Paul Miller) Date: Tue, 02 Jul 2002 09:40:07 -0500 Subject: [Pythonmac-SIG] NumPy for MacPython/Carbon? In-Reply-To: References: <5.1.0.14.2.20020702090719.01ff6fa8@cedar.he.net> Message-ID: <5.1.0.14.2.20020702093953.039b9ec8@cedar.he.net> > > Saw some discussion about compiling NumPy for Mach-O Python, but is > there a > > pre-built installer and/or archive with NumPy for MacPython 2.2.1? If not, > > should this be a straightforward compile if grab the sources? > >NumPy is included with MacPython, so I'd say, try to do "import Numeric"... Oh, duh. I was thrown by it being a separate installer on Windows. -- Paul T. Miller | paul@fxtech.com | http://www.fxtech.com From senn@maya.com Tue Jul 2 17:14:43 2002 From: senn@maya.com (Jeff Senn) Date: Tue, 02 Jul 2002 12:14:43 -0400 Subject: [Pythonmac-SIG] threads in OSX IDLE In-Reply-To: <5.1.0.14.2.20020702093953.039b9ec8@cedar.he.net> (Paul Miller's message of "Tue, 02 Jul 2002 09:40:07 -0500") Message-ID: I just built the Mac OS X python with frameworks & Tkinter out of CVS and installed idle as tony suggests (http://tony.lownds.com/macosx/tkinter.html) If I type the following into the resulting IDLE Python Shell window, Python crashes: --snip-- def foo(): print "hello" import thread thread.start_new_thread(foo,()) thread.start_new_thread(foo,()) --snip-- ...um... is it supposed to work? -- -Jas From pecora@anvil.nrl.navy.mil Tue Jul 2 18:55:55 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Tue, 2 Jul 2002 13:55:55 -0400 Subject: [Pythonmac-SIG] Memory Leak in Python 2.2 IDE on Mac? Message-ID: I run the following code in a file under the IDE (under System 9.1 on a G4 Mac with 40 MB allocated to Python 2.2 IDE): #--Test code from Numeric import * tab1=zeros((200000,4)) print shape(tab1) #--End Test code Check the memory under 'About this Computer' in the Finder. Then change tab1 to tab2 and run again (I hit cmd-R several times quickly and that seems to worsen the problem - don't know why), then check memory and see that more is used up. Continue this process to tab3, tab4, etc. and eventually I get an exception -- ran out of memory, cannot allocate more. Sure enough, under 'About this Computer' in the Finder, the memory is used up. Looks like a memory leak to me, but maybe the IDE is set up to keep variables around, hence tab1, tab2, etc. are never garbage collected after the module is run with a new varible name, e.g. tab2 in place of tab1. Anyone know? [Also posted to comp.lang.python -- Sorry if you've seen this before] -- Cheers, Lou Pecora From just@letterror.com Tue Jul 2 19:03:06 2002 From: just@letterror.com (Just van Rossum) Date: Tue, 2 Jul 2002 20:03:06 +0200 Subject: [Pythonmac-SIG] Memory Leak in Python 2.2 IDE on Mac? In-Reply-To: Message-ID: Louis M. Pecora wrote: > Looks like a memory leak to me, but maybe the IDE is set up to keep > variables around, hence tab1, tab2, etc. are never garbage collected > after the module is run with a new varible name, e.g. tab2 in place > of tab1. Variables are retained until overwritten, or until the script window is closed. I think this is handy, but I agree it's not a completely obvious why... Just From pecora@anvil.nrl.navy.mil Tue Jul 2 19:28:15 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Tue, 2 Jul 2002 14:28:15 -0400 Subject: [Pythonmac-SIG] Memory Leak in Python 2.2 IDE on Mac? In-Reply-To: References: Message-ID: > > Looks like a memory leak to me, but maybe the IDE is set up to keep >> variables around, hence tab1, tab2, etc. are never garbage collected >> after the module is run with a new varible name, e.g. tab2 in place >> of tab1. > >Variables are retained until overwritten, or until the script window is closed. >I think this is handy, but I agree it's not a completely obvious why... Well, that explains it. Thanks. It also explains to me that my C extension (separate example from the one I gave) probably does not have a memory leak like I thought. :-) Thanks, again. -- Cheers, Lou Pecora From Jack.Jansen@oratrix.com Tue Jul 2 21:20:46 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 2 Jul 2002 22:20:46 +0200 Subject: [Pythonmac-SIG] threads in OSX IDLE In-Reply-To: Message-ID: <3173DCC9-8DF9-11D6-A45D-003065517236@oratrix.com> On dinsdag, juli 2, 2002, at 06:14 , Jeff Senn wrote: > > I just built the Mac OS X python with frameworks & Tkinter out > of CVS and > installed idle as tony suggests > (http://tony.lownds.com/macosx/tkinter.html) > > If I type the following into the resulting IDLE Python Shell window, > Python crashes: > > --snip-- > def foo(): > print "hello" > > import thread > thread.start_new_thread(foo,()) > thread.start_new_thread(foo,()) > --snip-- > > ...um... is it supposed to work? Have you tried threads in IDLE on other (non-OSX) platforms? I could imagine that threads and IDLE (or even threads and Tkinter) don't go together. Note that I say "could imagine", I've never tried it and I haven't heard that it doesn't work, but I can imagine problems... If it works on other platforms then try getting a stacktrace: start Python under gdb and get a traceback after it crashed. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From dev@brotsky.com Tue Jul 2 23:04:31 2002 From: dev@brotsky.com (Daniel Brotsky) Date: Tue, 2 Jul 2002 15:04:31 -0700 Subject: [Pythonmac-SIG] newbie process question about building MachoPython In-Reply-To: <1F9A68CB-8BB3-11D6-AF0F-003065517236@oratrix.com> Message-ID: --Apple-Mail-1-95631898 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Jack, Thanks for the (correct) analysis and suggestion. But I think there's still a config bug in the python stuff (at the bottom). On Saturday, June 29, 2002, at 03:54 PM, Jack Jansen wrote: > My suggestion would be to not use /sw/include and /sw/lib > unconditionally but in stead refer to it with the various --with-foobar > options of configure (for all foobars you have in /sw). In fact there aren't any things Python uses that need to come from /sw, so just compiling with no external CFLAGS, CPPFLAGS, and LDFLAGS (and no special --with-foobar options) works fine. > My guess (because of the references to "dl") is that you're picking up > stuff from /sw that you don't want to pick up. Or, at least, you're > picking up stuff that the build process hasn't been tested for. > Specifically, if you have dl installed in /sw (dl is the "linux-way" of > doing dynamic loading) Oh, thanks, that's interesting and I didn't know that. > it could be that Python partially configures itself to use dl-based > dynamic linking in stead of dynload-based dynamic linking. But: > apparently it only partially works (otherwise it would have "just > worked"). The last sentence because I know some people have used dl on > OSX and gotten it to work (IIRC). It's this "partially works" thing that's the problem, and I think it's actually a python config bug (rather than, say, a dl bug). The problem is that the configure program fully uses the fooFLAGS environment variables, so it correctly notices that the dl stuff is available (and also that the dylib stuff is available because it's Darwin). But Makefile.pre.in doesn't take full advantage of configure, because while it sets LDFLAGS to include the value of @LDFLAGS@ (from config), it doesn't do the same with either CFLAGS or CPPFLAGS. Thus there's a mismatch between the settings at compile and link time, and this mismatch breaks the build process. In an attempt to make this clear, I've attached a context diff of the existing Makefile.pre.in and one that I've hacked to fix this mismatch problem (and a separate problem involving the parser library not being linked using the LDFLAGS). The Python which builds as a result of these changes seems to work just fine, passes the test suite, loads dynamic modules OK, and hasn't displayed any of the dynamic loading issues that were discussed on this list a few months ago. As I mentioned above, it's clear that Python can be built fine *without* fixing this problem. But it seems to me that it makes the build process unnecessarily brittle for people with non-standard (but working) build environments. dan --Apple-Mail-1-95631898 Content-Disposition: attachment; filename=Makefile.pre.in.patch Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="Makefile.pre.in.patch" Index: Makefile.pre.in =================================================================== RCS file: /cvsroot/python/python/dist/src/Makefile.pre.in,v retrieving revision 1.86 diff -c -r1.86 Makefile.pre.in *** Makefile.pre.in 21 Jun 2002 14:48:36 -0000 1.86 --- Makefile.pre.in 29 Jun 2002 09:24:19 -0000 *************** *** 55,62 **** # Compiler options OPT= @OPT@ DEFS= @DEFS@ ! CFLAGS= $(OPT) ! CPPFLAGS= -I. -I$(srcdir)/Include $(DEFS) LDFLAGS= @LDFLAGS@ LDLAST= @LDLAST@ SGI_ABI= @SGI_ABI@ --- 55,62 ---- # Compiler options OPT= @OPT@ DEFS= @DEFS@ ! CFLAGS= $(OPT) @CFLAGS@ ! CPPFLAGS= -I. -I$(srcdir)/Include $(DEFS) @CPPFLAGS@ LDFLAGS= @LDFLAGS@ LDLAST= @LDLAST@ SGI_ABI= @SGI_ABI@ *************** *** 409,415 **** -$(PGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C) $(PGEN): $(PGENOBJS) ! $(CC) $(OPT) $(PGENOBJS) $(LIBS) -o $(PGEN) Parser/grammar.o: $(srcdir)/Parser/grammar.c \ $(srcdir)/Include/token.h \ --- 409,415 ---- -$(PGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C) $(PGEN): $(PGENOBJS) ! $(CC) $(OPT) $(PGENOBJS) $(LDFLAGS) $(LIBS) -o $(PGEN) Parser/grammar.o: $(srcdir)/Parser/grammar.c \ $(srcdir)/Include/token.h \ --Apple-Mail-1-95631898-- From Jack.Jansen@cwi.nl Wed Jul 3 10:05:11 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 3 Jul 2002 11:05:11 +0200 Subject: [Pythonmac-SIG] newbie process question about building MachoPython In-Reply-To: Message-ID: Daniel, I had a long look at it, and I think you're right: it's reasonable that the CFLAGS and CPPFLAGS from configure are treated the same way as LDFLAGS. This change, however, will affect any and all unix platform builds, so I'd like you to put the path in the sourceforge bug reporter. That way some other people can have a look at it. I think your use case of adding your own "standard" location for extra libraries and such with CPPFLAGS=-I/foo/include LDFLAGS=-L/foo/lib is a good one. On Wednesday, July 3, 2002, at 12:04 , Daniel Brotsky wrote: > It's this "partially works" thing that's the problem, and I think it's > actually a python config bug (rather than, say, a dl bug). The problem > is that the configure program fully uses the fooFLAGS environment > variables, so it correctly notices that the dl stuff is available (and > also that the dylib stuff is available because it's Darwin). But > Makefile.pre.in doesn't take full advantage of configure, because while > it sets LDFLAGS to include the value of @LDFLAGS@ (from config), it > doesn't do the same with either CFLAGS or CPPFLAGS. Thus there's a > mismatch between the settings at compile and link time, and this > mismatch breaks the build process. > > In an attempt to make this clear, I've attached a context diff of the > existing Makefile.pre.in and one that I've hacked to fix this mismatch > problem (and a separate problem involving the parser library not being > linked using the LDFLAGS). The Python which builds as a result of > these changes seems to work just fine, passes the test suite, loads > dynamic modules OK, and hasn't displayed any of the dynamic loading > issues that were discussed on this list a few months ago. > > As I mentioned above, it's clear that Python can be built fine > *without* fixing this problem. But it seems to me that it makes the > build process unnecessarily brittle for people with non-standard (but > working) build environments. > > dan > > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From senn@maya.com Wed Jul 3 14:43:36 2002 From: senn@maya.com (Jeff Senn) Date: Wed, 03 Jul 2002 09:43:36 -0400 Subject: [Pythonmac-SIG] threads in OSX IDLE In-Reply-To: <3173DCC9-8DF9-11D6-A45D-003065517236@oratrix.com> (Jack Jansen's message of "Tue, 2 Jul 2002 22:20:46 +0200") References: <3173DCC9-8DF9-11D6-A45D-003065517236@oratrix.com> Message-ID: <8z4tgc53.fsf@SNIPE.maya.com> Jack Jansen writes: > Have you tried threads in IDLE on other (non-OSX) platforms? I could > imagine that threads and IDLE (or even threads and Tkinter) don't go ... I'm doing that now... The same version under Linux seems to work... (but that may be lucky -- see below) > If it works on other platforms then try getting a stacktrace: start > Python under gdb and get a traceback after it crashed. it seems to have something to do with inserting the text into the idle (Tk) window from the "other thread". Top of the stack dump below. So... Tk itself is not thread safe ... I've had luck trying to limit Tkinter calls to only the main(first) thread in a multi-threaded Python app. I don't know how idle works, but I would guess it is (at least) trapping stdin/out and turning them into calls to insert into the "shell" window. Instead these probably need to be queued back to the main thread in a thread-safe way to avoid such crashes... (this is probably a lot of work...) Alternatively I think one could make a Tkinter that would queue all calls back to a single thread. (I have to think more about this... the difficulty lies in blocking the thread on the next window event OR the next queued request...) -Jas -------- #0 0x0115bb1c in Tk_FreeGC (display=0x0, gc=0x2eaacf0) at ../generic/tkGC.c:300 #1 0x0118d334 in FreeDLines (textPtr=0x325cf0, firstPtr=0x2e62130, lastPtr=0x0, unlink=1) at ../generic/tkTextDisp.c:732 #2 0x01190fe8 in TkTextChanged (textPtr=0x2e62130, index1Ptr=0x2e5a090, index2Ptr=0x325cf0) at ../generic/tkTextDisp.c:2737 #3 0x01187ec4 in InsertChars (textPtr=0x2e62130, indexPtr=0x2e59fe0, string=0x0) at ../generic/tkText.c:1237 #4 0x01186f68 in TextWidgetCmd (clientData=0x325cf0, interp=0x33d6c0, argc=0, argv=0x325cf0) at ../generic/tkText.c:723 #5 0x00c1d1a4 in TclInvokeStringCommand () #6 0x00c62144 in TclExpandTokenArray () #7 0x00c62474 in Tcl_EvalObjv () #8 0x00b23e00 in Tkapp_Call (self=0x325cf0, args=0x2e62130) at ./Modules/_tkinter.c:623#9 0x004384c8 in fast_cfunction (func=0x0, pp_stack=0x0, na=13109488) at Python/ceval.c:3157 #10 0x00435b84 in eval_frame (f=0x2e60b70) at Python/ceval.c:2020 #11 0x00437018 in PyEval_EvalCodeEx (co=0xf47820, globals=0x11cbb00, locals=0xc808f0, args=0xf661bc, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2601 From Jack.Jansen@oratrix.com Thu Jul 4 23:12:32 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 5 Jul 2002 00:12:32 +0200 Subject: [Pythonmac-SIG] Extensions for static versus framework MachoPython Message-ID: <237E4C40-8F9B-11D6-8B00-003065517236@oratrix.com> Folks, I need a bit of extra brainpower for a solution to the following problem. MachoPython can be built in 2 variants: as a static binary (like it usually is on Unix systems) or with the whole interpreter in a dynamic framework with the python executable being a tiny main program linked to that. Now, there's a potential problem with dynamically loadable plugin modules. If you build a plugin module for one variant and then try to use it in the other variant this is potentially unsafe. And I don't know how to fix it. Actually, I don't even know that it is unsafe. If you build an extension module for a static Python the module will be linked with "-bundle_loader python.exe" and then everything is fine: all Python symbols it needs it will try to satisfy from the program that loads it, and this will fail if you load it into a framework python (because the symbols are now defined in the framework, not in the main program, which is where the extension module looks for them). If you build an extension module for a framework Python it will not use the -bundle_loader option, but in stead link with "-framework Python". If you import this module into a framework Python it'll notice that the Python.framework is incore already, link against that and everything is fine. If you try to load this module into a static Python, however, it will simply pull in a fresh copy of Python.framework. Even this shouldn't be a problem, because once the module tries to initialize itself it'll call PyModule_Initialize4(), which should notice that the module lives in a fresh, uninitialized interpreter and it should complain bitterly. However: it doesn't complain. Which means that it must somehow call PyModule_Initialize4() from the already loaded static python (or, at least share its datastructures). But it *does* load Python.framework (checked by turning on DYLD debugging). This makes me very uneasy, is it may be using some stuff from the static Python and some (uninitialized) stuff from the framework it pulled in. That would definitely spell disaster, especially if the two Pythons have been compiled with different options (GC or debugging, for instance). I'm not sure why it doesn't complain, it may have something to do with Python.framework being linked with -flat_namespace, which it needs because it needs access to _environ (which frameworks or dynamic libraries don't get, sigh, only main programs). I tried specifying Python.framework as the -bundle_loader, but that doesn't work. I'm out of good ideas now. And it may be that I'm seeing a problem where there really isn't any: if 100% of the symbols are satisfied from the static Python then everything should be fine. Major differences between versions will be caught by the PY_API_VERSION mechanism (which is the general mechanism that stops you from loading an extension module into a Python that is too old or too new), so it's really only "little differences". Should I stop worrying and just think of this as an advantage ("If you build your extension module with a framework Python you can also use it with a static Python")? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Jul 5 09:02:08 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 5 Jul 2002 10:02:08 +0200 Subject: [Pythonmac-SIG] threads in OSX IDLE In-Reply-To: <8z4tgc53.fsf@SNIPE.maya.com> Message-ID: <80D71DDF-8FED-11D6-BBAB-0030655234CE@cwi.nl> On Wednesday, July 3, 2002, at 03:43 , Jeff Senn wrote: > > Jack Jansen writes: >> Have you tried threads in IDLE on other (non-OSX) platforms? I could >> imagine that threads and IDLE (or even threads and Tkinter) don't go > ... > > I'm doing that now... The same version under Linux seems to work... > (but that may be lucky -- see below) > >> If it works on other platforms then try getting a stacktrace: start >> Python under gdb and get a traceback after it crashed. > > it seems to have something to do with inserting the text into > the idle (Tk) window from the "other thread". Top of the stack dump > below. Tk is deinitely not threadsafe. At least, it wasn't the last time I examined it. So this may well be your problem. Maybe you should ask the Idle folks (there's a couple of people working on it) how feasible it is to create a threadsafe Idle. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From fancher@pacbell.net Fri Jul 5 21:37:16 2002 From: fancher@pacbell.net (bill fancher) Date: Fri, 05 Jul 2002 13:37:16 -0700 Subject: [Pythonmac-SIG] Extensions for static versus framework MachoPython In-Reply-To: <237E4C40-8F9B-11D6-8B00-003065517236@oratrix.com> Message-ID: On Thursday, July 4, 2002, at 03:12 PM, Jack Jansen wrote: > If you build an extension module for a framework Python it will not use > the -bundle_loader option, but in stead link with "-framework Python". If > you import this module into a framework Python it'll notice that the > Python.framework is incore already, link against that and everything is > fine. > > If you try to load this module into a static Python, however, it will > simply pull in a fresh copy of Python.framework. Even this shouldn't be a > problem, because once the module tries to initialize itself it'll call > PyModule_Initialize4(), which should notice that the module lives in a > fresh, uninitialized interpreter and it should complain bitterly. > > However: it doesn't complain. Which means that it must somehow call > PyModule_Initialize4() from the already loaded static python (or, at > least share its datastructures). But it *does* load Python.framework > (checked by turning on DYLD debugging). This makes me very uneasy, is it > may be using some stuff from the static Python and some (uninitialized) > stuff from the framework it pulled in. That would definitely spell > disaster, especially if the two Pythons have been compiled with different > options (GC or debugging, for instance). > > I'm not sure why it doesn't complain, it may have something to do with > Python.framework being linked with -flat_namespace, which it needs > because it needs access to _environ (which frameworks or dynamic > libraries don't get, sigh, only main programs). It doesn't complain because the *modules* are linked with -flat_namespace, so they know what libraries they "need" but not which library a particular symbol comes from. Apparently, dyld finds what it's looking for in the statically linked library before getting to the shared lib's namespace. I put a breakpoint on the static lib's PyModule_Initialize4 and that is in fact what gets called. Module symbols are in a separate namespaces and the dylib's symbols are thus segregated, otherwise dyld would complain about duplicates. As for _environ, there's a way around that. From Mach-O Runtime Architecture, p.24: "Shared libraries that need to reference symbols defined in the program main executable, such as the environ variable, must load the symbol dynamically using a function that does not require a library reference, such as NSLookupAndBindSymbol (page 83). (In the specific case of environ, you can use the function _NSGetEnviron, embedded as part of the C runtime)." > I tried specifying Python.framework as the -bundle_loader, but that doesn' > t work. > > I'm out of good ideas now. > > And it may be that I'm seeing a problem where there really isn't any: if > 100% of the symbols are satisfied from the static Python then everything > should be fine. Major differences between versions will be caught by the > PY_API_VERSION mechanism (which is the general mechanism that stops you > from loading an extension module into a Python that is too old or too new) > , so it's really only "little differences". Assuming the PYTHON_API_VERSION varies with what Apple calls major versions (as it does in Python 2.2 vs. 2.3), then it should be safe. I'd rather have the module not get linked against the library, but use -flat_namespace -undefined suppress. That keeps dyld from looking for a library that might not be needed and might not even be there. That patch I sent you off list that allows one to build Python as a standalone dynamic shared library uses that approach, and doesn't have the problem discussed here. It also links the main library without -two_level_namespace, which, Apple claims, makes it load faster and also provides protection against namespace collisions (though that's probably not much of a practical problem.) > > Should I stop worrying and just think of this as an advantage ("If you > build your extension module with a framework Python you can also use it > with a static Python")? I wouldn't worry too much about it for the nonce, but in the long run, I think we'd be better off with a -two_level_namespace shared library in /usr/local/lib and modules that are a bit more modular. FWIW, -- bill From bfancher@mac.com Sat Jul 6 20:06:26 2002 From: bfancher@mac.com (bill fancher) Date: Sat, 6 Jul 2002 12:06:26 -0700 Subject: [Pythonmac-SIG] Extensions for static versus framework MachoPython In-Reply-To: Message-ID: <78743059-9113-11D6-83E1-0005029E8B13@mac.com> On Friday, July 5, 2002, at 01:37 PM, bill fancher wrote: > links the main library without -two_level_namespace, which, Apple claims, > makes it load faster That should have been "with -two_level_namespace". Apple DOES NOT claim -flat_namespace libraries load faster. Just for the record... -- bill From Jack.Jansen@oratrix.com Sun Jul 7 23:12:43 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 8 Jul 2002 00:12:43 +0200 Subject: [Pythonmac-SIG] Extensions for static versus framework MachoPython In-Reply-To: Message-ID: On vrijdag, juli 5, 2002, at 10:37 , bill fancher wrote: >> I'm not sure why it doesn't complain, it may have something to >> do with Python.framework being linked with -flat_namespace, >> which it needs because it needs access to _environ (which >> frameworks or dynamic libraries don't get, sigh, only main >> programs). > > It doesn't complain because the *modules* are linked with > -flat_namespace, > so they know what libraries they "need" but not which library > a particular symbol comes from. Aargh, you're right! Silly me, now if I can only remember why this is. I'll try changing it, maybe it was just an oversight... > As for _environ, there's a way around that. From Mach-O Runtime > Architecture, p.24: Tried this, but didn't get it to work without major surgery to the Python core (removing all direct references to the _environ global). Because when I simply added a global _environ to Python.framework I couldn't link the interpreter anymore because of the multiply-defined _environ (one from Python.framework, one from crt0). > Assuming the PYTHON_API_VERSION varies with what Apple calls > major versions (as it does in Python 2.2 vs. 2.3), then it > should be safe. I'd rather have the module not get linked > against the library, but use -flat_namespace -undefined > suppress. That keeps dyld from looking for a library that might > not be needed and might not even be there. That patch I sent > you off list that allows one to build Python as a standalone > dynamic shared library uses that approach, and doesn't have the > problem discussed here. [I hadn't replied to your mods yet, as I didn't get around to it, but I might as well do so now] I know, but it has a major problem in that -flat_namespace will take any symbol with the correct name and simply assume it is the symbol needed. This is an accident waiting to happen, and I'm heavily opposed to it. I know that for unix-Python this is the norm, but it leads to very obscure bugs. And note that these bugs aren't theoretical, either. I've been bitten by it twice over the years, once because both SGI's original GL library and curses had a clear() function, and once because the SGI compression library contained a modified version of the IJG JPEG library with unmodified external names so anything that was linked against the normal jpeg library would be dead. The first case (some Python script importing both the gl and curses modules) happened in exactly one Python script in the world: test.regrtest. The second case was really nasty, though, because image processing apps might easily import both PIL and cl without being aware of it. I'm very glad that MacPython has never had these problems (because external symbol and library are matched up), and so when Apple made this functionality available for OSX with the two-level namespaces I immediately jumped on the bandwagon. But again: if enough people here feel that the benefits of -flat_namespace outweigh these problems, please speak up! I'm always will to (grudgingly:-) bend to the majority... I have a completely unrelated problem with your patch (maybe you should post it to sourceforge as Tony suggested?) and that is that you build the shared library in /usr/local and then symlink to it from the Python.framework. In my opinion this defeats the purpose of using the framework in the first place, and that is having everything contained in a single location, so that install/uninstall becomes a trivial copy or remove. From historical data (usage of MacPython and Python on Windows) I assume that most OSX Python users will not build Python from source, and will probably not have installed the developer tools (they may not even have them if their OSX came bundled with their machine). I want MachoPython to make life easy for these people primarily, as the people who build from source are probably also more knowledgeable. The question is really one of "should MachoPython behave like a Macintosh package or like a unix package", and my answer would be "like a Macintosh package". If you want the more traditional unix behavior you can ignore the whole framework business and do "configure; make" and have a perfectly normal unix Python on your OSX box. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From doug@sonosphere.com Mon Jul 8 08:53:14 2002 From: doug@sonosphere.com (Doug Wyatt) Date: Mon, 8 Jul 2002 00:53:14 -0700 Subject: [Pythonmac-SIG] Macho, socketmodule Message-ID: I did a little recreational programming today to see if I could put a Cocoa GUI on top of some Python modules I've written. I've built Python 2.2.1 on MacOSX from the main (non-Mac) distribution, with readline/termap enabled because I like them in the interpreter, and sockets enabled because PyXML-0.7.1 requires them. But when I try to link libpython2.2.a into my Cocoa app, I get link errors because freeaddrinfo and gai_strerror are multiply defined. I find that socketmodule has some __APPLE__-specific mods to include getaddrinfo.c, which defines these symbols, which are also define in libSystem.dylib, which Cocoa apps link against. grepping the source tree, I see that getaddrinfo.c is only used when included from socketmodule.c, and in Mac/Distributions/dev.include, which I suspect isn't used because I removed the Mac directory, not caring about access to the classic Mac toolbox in my Python. I suspect that making the functions in getaddrinfo.c static would solve the problem but wonder if it would break something else ... Would appreciate tips. Doug -- Doug Wyatt personal: doug@sonosphere.com http://www.sonosphere.com "There is real magic in enthusiasm. It spells the difference between mediocrity and accomplishment." -- Norman Vincent Peale From Jack.Jansen@cwi.nl Mon Jul 8 10:26:35 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 8 Jul 2002 11:26:35 +0200 Subject: [Pythonmac-SIG] Macho, socketmodule In-Reply-To: Message-ID: On Monday, July 8, 2002, at 09:53 , Doug Wyatt wrote: > But when I try to link libpython2.2.a into my Cocoa app, I get link > errors because freeaddrinfo and gai_strerror are multiply defined. I > find that socketmodule has some __APPLE__-specific mods to include > getaddrinfo.c, which defines these symbols, which are also define in > libSystem.dylib, which Cocoa apps link against. > > grepping the source tree, I see that getaddrinfo.c is only used when > included from socketmodule.c, and in Mac/Distributions/dev.include, > which I suspect isn't used because I removed the Mac directory, not > caring about access to the classic Mac toolbox in my Python. getaddrinfo() is a bit funny under 10.1, as it exists in the standard C library but doesn't really work. Declaring it as static in getaddrinfo.c should probably work, that C file is #include'd into socketmodule.c. And I have reason to believe that the getaddrinfo problem will disappear in the next version of OSX. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From guy.flowers@lightworkdesign.com Mon Jul 8 14:01:38 2002 From: guy.flowers@lightworkdesign.com (Guy Flowers) Date: Mon, 8 Jul 2002 14:01:38 +0100 Subject: [Pythonmac-SIG] Mac sit files Message-ID: <8815647C7041D111A3010060B06BE1C001AEC641@elvis.lightwork> Hi Quick question, I've been looking at the zip module in python, I was wondering if there is some code of some sort, anywhere that could do the same but in a mac sit file. Guy From senn@maya.com Mon Jul 8 14:56:03 2002 From: senn@maya.com (Jeff Senn) Date: Mon, 08 Jul 2002 09:56:03 -0400 Subject: [Pythonmac-SIG] threads in OSX IDLE In-Reply-To: <80D71DDF-8FED-11D6-BBAB-0030655234CE@cwi.nl> (Jack Jansen's message of "Fri, 5 Jul 2002 10:02:08 +0200") References: <80D71DDF-8FED-11D6-BBAB-0030655234CE@cwi.nl> Message-ID: Jack Jansen writes: > Tk is deinitely not threadsafe. At least, it wasn't the last time I > examined it. So this may well be your problem. > > Maybe you should ask the Idle folks (there's a couple of people > working on it) how feasible it is to create a threadsafe Idle. Alternatively, (and I apologize for my lack of MacOS X Python knowlege) is there some way to run python with stdio to/from a terminal and still be able to use the TK Framework? -- -Jas From Jack.Jansen@cwi.nl Mon Jul 8 15:02:58 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 8 Jul 2002 16:02:58 +0200 Subject: [Pythonmac-SIG] Mac sit files In-Reply-To: <8815647C7041D111A3010060B06BE1C001AEC641@elvis.lightwork> Message-ID: <6836D413-927B-11D6-9516-0030655234CE@cwi.nl> On Monday, July 8, 2002, at 03:01 , Guy Flowers wrote: > Hi > > Quick question, > > I've been looking at the zip module in python, I was wondering if there > is > some > code of some sort, anywhere that could do the same but in a mac sit > file. .sit files use a proprietary encoding. Last time I checked (which was, admittedly, many years ago) the scheme was either unpublished or copyright-protected or some such, and no third-party decoders were available. You could probably wrap the stuffit engine (which is allowed, I assume), I'll gladly accept contributed code, -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mwh@python.net Mon Jul 8 15:08:58 2002 From: mwh@python.net (Michael Hudson) Date: 08 Jul 2002 15:08:58 +0100 Subject: [Pythonmac-SIG] threads in OSX IDLE In-Reply-To: Jeff Senn's message of "Mon, 08 Jul 2002 09:56:03 -0400" References: <80D71DDF-8FED-11D6-BBAB-0030655234CE@cwi.nl> Message-ID: <2msn2unwg5.fsf@starship.python.net> Jeff Senn writes: > Jack Jansen writes: > > Tk is deinitely not threadsafe. At least, it wasn't the last time I > > examined it. So this may well be your problem. > > > > Maybe you should ask the Idle folks (there's a couple of people > > working on it) how feasible it is to create a threadsafe Idle. > > Alternatively, (and I apologize for my lack of MacOS X Python knowlege) > is there some way to run python with stdio to/from a terminal and still > be able to use the TK Framework? Tkinter works from fink's Python under X, which perhaps isn't the most helpful of answers... Don't recall installing an aqua version of Tk yet. Cheers, M. -- The gripping hand is really that there are morons everywhere, it's just that the Americon morons are funnier than average. -- Pim van Riezen, alt.sysadmin.recovery From Jack.Jansen@cwi.nl Mon Jul 8 15:05:27 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 8 Jul 2002 16:05:27 +0200 Subject: [Pythonmac-SIG] threads in OSX IDLE In-Reply-To: Message-ID: On Monday, July 8, 2002, at 03:56 , Jeff Senn wrote: > Alternatively, (and I apologize for my lack of MacOS X Python knowlege) > is there some way to run python with stdio to/from a terminal and still > be able to use the TK Framework? Build a framework Python, build the Python.app with Mac/OSX/Makefile, and run "make installunixprograms" there too. Now run your script from Terminal with "pythonw mytkscript.py". Haven't tried it for Tkinter, but it works for Cocoa and Carbon so it should be fine for Tkinter too. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Mon Jul 8 23:00:10 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 9 Jul 2002 00:00:10 +0200 Subject: [Pythonmac-SIG] Extensions for static versus framework MachoPython In-Reply-To: Message-ID: <128DD8B2-92BE-11D6-ACC3-003065517236@oratrix.com> On maandag, juli 8, 2002, at 12:12 , Jack Jansen wrote: > > On vrijdag, juli 5, 2002, at 10:37 , bill fancher wrote: >>> I'm not sure why it doesn't complain, it may have something to >>> do with Python.framework being linked with -flat_namespace, >>> which it needs because it needs access to _environ (which >>> frameworks or dynamic libraries don't get, sigh, only main >>> programs). >> >> It doesn't complain because the *modules* are linked with >> -flat_namespace, >> so they know what libraries they "need" but not which library >> a particular symbol comes from. > > Aargh, you're right! Silly me, now if I can only remember why > this is. I'll try changing it, maybe it was just an oversight... > >> As for _environ, there's a way around that. From Mach-O >> Runtime Architecture, p.24: > > Tried this, but didn't get it to work without major surgery to > the Python core (removing all direct references to the _environ > global). Tried it again, and I got it to work this time. I now have both python.exe and all the extension modules linked with two-level namespace, and handled _environ by making it a static variable and initializing it with _NSGetEnviron. However, the cure appears worse than the problem: in stead of "just working" what happens now if you import a framework-based module into a non-framework-based Python is that Python crashes with a bus error:-( I'll investigate a bit more, if anyone wants to help please speak up and I'll put the diffs up on sourceforge, -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From tony@lownds.com Mon Jul 8 23:47:43 2002 From: tony@lownds.com (Tony Lownds) Date: Mon, 8 Jul 2002 15:47:43 -0700 Subject: [Pythonmac-SIG] threads in OSX IDLE In-Reply-To: References: Message-ID: At 10:02 AM +0200 7/5/02, Jack Jansen wrote: > >Tk is deinitely not threadsafe. At least, it wasn't the last time I >examined it. So this may well be your problem. Tcl/Tk 8.4 has threading that can be turned off, and Aqua Tk is by default threaded as well. In fact it needs thread local storage to work. I don't know if 8.3 had threading or not. When Tk wasn't thread safe, Tkinter added a lock around calls to Tk. Now that Tk is threaded, this lock isn't enough: Python creates a Python thread object with an OS level thread underneath it, but Tk doesn't get a chance to initialize it's thread local storage for that OS level thread. So Tkinter should probably get fixed. >Maybe you should ask the Idle folks (there's a couple of people >working on it) how feasible it is to create a threadsafe Idle. The idlefork project on sourceforge is where the action is. They have an IDLE that runs the python code in a separate process, and transmits stdin/stdout/stderr over sockets. So for Jeff's specific problem (printing from multiple threads) the idlefork stuff is already fixed! At 4:05 PM +0200 7/8/02, Jack Jansen wrote: >On Monday, July 8, 2002, at 03:56 , Jeff Senn wrote: >>Alternatively, (and I apologize for my lack of MacOS X Python knowlege) >>is there some way to run python with stdio to/from a terminal and still >>be able to use the TK Framework? > >Build a framework Python, build the Python.app with >Mac/OSX/Makefile, and run "make installunixprograms" there too. Now >run your script from Terminal with "pythonw mytkscript.py". > >Haven't tried it for Tkinter, but it works for Cocoa and Carbon so >it should be fine for Tkinter too. This works fine for Tkinter. Here's a neat trick: copy that pythonw script somewhere and name it pythonw.command - double clicking it in the finder will open a terminal window for you. Another way to work around this can't print from threads issue is doing print >> opened_file in your script and then tail -F file in another window. -Tony From tony@lownds.com Tue Jul 9 00:00:27 2002 From: tony@lownds.com (Tony Lownds) Date: Mon, 8 Jul 2002 16:00:27 -0700 Subject: [Pythonmac-SIG] threads in OSX IDLE In-Reply-To: References: Message-ID: I found some documentation about Tcl and threading: Beginning with the 8.1 release, the Tcl core is thread safe, which allows you to incorporate Tcl into multithreaded applica- tions without customizing the Tcl core. ... An important constraint of the Tcl threads implementation is that only the thread that created a Tcl interpreter can use that in- terpreter. In other words, multiple threads can not access the same Tcl interpreter. (However, as was the case in previous re- leases, a single thread can safely create and use multiple inter- preters.) That constraint makes fixing Tkinter pretty hard! -Tony At 3:47 PM -0700 7/8/02, Tony Lownds wrote: >At 10:02 AM +0200 7/5/02, Jack Jansen wrote: >> >>Tk is deinitely not threadsafe. At least, it wasn't the last time I >>examined it. So this may well be your problem. > >Tcl/Tk 8.4 has threading that can be turned off, and Aqua Tk is by >default threaded as well. In fact it needs thread local storage to >work. I don't know if 8.3 had threading or not. > >When Tk wasn't thread safe, Tkinter added a lock around calls to Tk. >Now that Tk is threaded, this lock isn't enough: Python creates a >Python thread object with an OS level thread underneath it, but Tk >doesn't get a chance to initialize it's thread local storage for >that OS level thread. > >So Tkinter should probably get fixed. > >>Maybe you should ask the Idle folks (there's a couple of people >>working on it) how feasible it is to create a threadsafe Idle. > >The idlefork project on sourceforge is where the action is. They >have an IDLE that runs the python code in a separate process, and >transmits stdin/stdout/stderr over sockets. So for Jeff's specific >problem (printing from multiple threads) the idlefork stuff is >already fixed! > >At 4:05 PM +0200 7/8/02, Jack Jansen wrote: >>On Monday, July 8, 2002, at 03:56 , Jeff Senn wrote: >>>Alternatively, (and I apologize for my lack of MacOS X Python knowlege) >>>is there some way to run python with stdio to/from a terminal and still >>>be able to use the TK Framework? >> >>Build a framework Python, build the Python.app with >>Mac/OSX/Makefile, and run "make installunixprograms" there too. Now >>run your script from Terminal with "pythonw mytkscript.py". >> >>Haven't tried it for Tkinter, but it works for Cocoa and Carbon so >>it should be fine for Tkinter too. > >This works fine for Tkinter. Here's a neat trick: copy that pythonw >script somewhere and name it pythonw.command - double clicking it in >the finder will open a terminal window for you. > >Another way to work around this can't print from threads issue is >doing print >> opened_file in your script and then tail -F file in >another window. > >-Tony > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig From fancher@pacbell.net Tue Jul 9 00:53:09 2002 From: fancher@pacbell.net (bill fancher) Date: Mon, 08 Jul 2002 16:53:09 -0700 Subject: [Pythonmac-SIG] Extensions for static versus framework MachoPython In-Reply-To: Message-ID: On Sunday, July 7, 2002, at 03:12 PM, Jack Jansen wrote: >> As for _environ, there's a way around that. From Mach-O Runtime >> Architecture, p.24: > > Tried this, but didn't get it to work without major surgery to the Python > core (removing all direct references to the _environ global). AFAIK, the only references are in posixmodule.c. I just conditionally defined "_environ" as "(*_NSGetEnviron())" in the same place Cygwin implements its support for _environ. Seems to me to work well: it's fairly simple surgery and "the leading platform" has to do something special here too, so we've got lots of (perhaps questionable) company. (Pardon also my chauvinism.) > Because when I simply added a global _environ to Python.framework I > couldn't link the interpreter anymore because of the multiply-defined > _environ (one from Python.framework, one from crt0). By #defining _environ as above, we don't end up with "_environ" as a symbol in the Python library so there's no link problem. We link to the function implemented in the standard runtime library and the function returns a pointer to _environ, which is dereffed by the macro. This works for static libraries too, so there's no need to treat that case specially. > >> Assuming the PYTHON_API_VERSION varies with what Apple calls major >> versions (as it does in Python 2.2 vs. 2.3), then it should be safe. I'd >> rather have the module not get linked against the library, but use >> -flat_namespace -undefined suppress. That keeps dyld from looking for a >> library that might not be needed and might not even be there. That patch >> I sent you off list that allows one to build Python as a standalone >> dynamic shared library uses that approach, and doesn't have the problem >> discussed here. > > [I hadn't replied to your mods yet, as I didn't get around to it, but I > might as well do so now] > > I know, but it has a major problem in that -flat_namespace will take any > symbol with the correct name and simply assume it is the symbol needed. > This is an accident waiting to happen, and I'm heavily opposed to it. I > know that for unix-Python this is the norm, but it leads to very obscure > bugs. But we'd have lots of good company... > > And note that these bugs aren't theoretical, either. I've been bitten by > it twice over the years, once because both SGI's original GL library and > curses had a clear() function, and once because the SGI compression > library contained a modified version of the IJG JPEG library with > unmodified external names so anything that was linked against the normal > jpeg library would be dead. If something fails everywhere else, it should, by default, fail on a Mac. If we have special Mac machinery that would allow it to succeed, we should engage that machinery consciously and be aware that software depending on such Mac specific features isn't portable. IMO, the default installation should be bug compatible across platforms. We can always tweak various things for the binary distribution, which should cater to the majority, and we might find, e.g., that most people want two-level namespaces. Such adjustments can be made at build time by setting environment variables. > > The first case (some Python script importing both the gl and curses > modules) happened in exactly one Python script in the world: > test.regrtest. The second case was really nasty, though, because image > processing apps might easily import both PIL and cl without being aware > of it. I'm very glad that MacPython has never had these problems (because > external symbol and library are matched up), and so when Apple made this > functionality available for OSX with the two-level namespaces I > immediately jumped on the bandwagon. There's no compelling reason I can see to get off the bandwagon. The price of admission is that the libs you link against are going to get loaded along with the module. The main library doesn't care how modules are linked. One reason the "two Pythons" problem even comes up is that there are now two fundamentally different ways to install Python, resulting in two sets of everything. I think this is a bad situation. We can avoid the duplication with linked frameworks. > > But again: if enough people here feel that the benefits of > -flat_namespace outweigh these problems, please speak up! I'm always will > to (grudgingly:-) bend to the majority... I think cross platform modules should, by default, be linked to behave as they do on other platforms even if that means behaving badly in some ways. Mac docs should note the default, outline its practical consequences, mention the workarounds possible on Mac OS X, and remind users that software depending on these platform specific tricks is not portable. For Mac only stuff like the binary distribution, just link the best way. We have complete control over the Mac only build process and how things get compiled for the binary distribution. > > I have a completely unrelated problem with your patch (maybe you should > post it to sourceforge as Tony suggested?) As soon as I fix the bugs he found and change things to get install_name from the -enable-shared value so it's independent of prefix... > and that is that you build the shared library in /usr/local and then > symlink to it from the Python.framework. In my opinion this defeats the > purpose of using the framework in the first place, and that is having > everything contained in a single location, so that install/uninstall > becomes a trivial copy or remove. Linked frameworks don't have that bit of useful behavior, but AFAICT, it's the only one they lack. That doesn't stop Apple from using them. One reason, among many, why you can't do drag and drop system installations, as on Mac OS 9, is that there are Frameworks in System with links to files in /usr. It could even be argued that *versioning* is the principal advantage of frameworks. Apple's description of Frameworks begins: "A framework is a type of bundle that packages a dynamic shared library with the resources that the library requires, including header files and reference documentation. This consolidation of code and resources brings with it a number of benefits. For example, it makes it easier for the library to locate its resources, and it makes installation and uninstallation easier on the user." This doesn't say exactly how the "packaging" is to be done (through inclusion or linkage), though it's apparent from the examples that inclusion is taken as the norm. Note that "ease of installation" is mentioned after "location of resources" . And that's all the mention it gets. The passage then goes on to describe the benefits of shared libraries and versioning (a product of how resources are "consolidated" and which resources get "located") at length. Linked frameworks can fully support versioning, and frameworks of any sort are easy to add to Project Builder projects and allow convenient access to headers and documentation. So to take drag and drop as the only framework advantage is to ignore other benefits. (Speaking of docs, the Macintosh binary distribution should include the html docs in the fromework and a help index. Very nice for module builders or adventurous scripters using PB. Dropping a few links here and there would put them in Help Viewer and make them searchable.) Once we're not considering installation or developer questions, nobody cares much about frameworks. From inside, Python looks the pretty much the same with a real framework, a linked framework, or no framework at all. > From historical data (usage of MacPython and Python on Windows) I assume > that most OSX Python users will not build Python from source, and will > probably not have installed the developer tools (they may not even have > them if their OSX came bundled with their machine). I want MachoPython to > make life easy for these people primarily, as the people who build from > source are probably also more knowledgeable. In keeping with the trend toward a "standard" Macho binary distribution, which I applaud, I suggest the first step should be to move all the mac specific stuff (or as much as we can) out of the core build mechanism. In particular, there should be no hint of frameworks there. On a Mac, running "./configure; make; make install" should produce what we'd expect on any other *NIX: a library in /usr/local/lib etc. Call this the "generic" installation. The Mach-O binary distribution should, IMO, install over the generic installation. (Or it could do the generic installation as a first step. Whatever.) We might want a minimal "Darwin only" option and a "Mac OS X" option to install pieces that link to libraries not found on Darwin. I would urge that supporting two totally different installation schemes such as "standard" and "real framework" is asking for trouble. A linked framework would make the Mac binary distribution an Installer package, but I'd note that Apple recommends drag and drop only for "simple" installations. If uninstallation is a requirement, we can provide an "Uninstall" option with the package. It's also worth mentioning that the "simple" drag and drop installation of Apple's Tcl/Tk stuff (using "real" frameworks) involves dragging various pieces to various locations, as would a similar Python distribution. Not very user friendly. > > The question is really one of "should MachoPython behave like a Macintosh > package or like a unix package", and my answer would be "like a Macintosh > package". Given a "generic" build process to produce a shared library, we could easily tweak things in the Mac specific stuff to create an installation inside a framework, if that's the way we end up going. Making the appropriate links to create a "real" framework is then trivial. Whatever we do about frameworks, building a shared library with an appropriate install_name is a necessary step. We put that much in the core distribution and hash out the remainder among ourselves, without bothering the neighbors. To pursue the latter goal a bit, let me again advocate following Apple's lead in adopting a more lenient conception of "behaving like a Macintosh package". One anecdote in support: My first attempt to compile against the Mac Tcl/Tk frameworks from Apple failed because I hadn't defined "TCLFRAMEWORK" . Again, these are "real" frameworks. A linked framework needn't care whether you say #include or #include , and there's no need modify library code to check whether SPIFFYSTUFF_FRAMEWORK is defined and perform conditional compiliation as was done with Tcl/Tk. So the advantages of drag and drop install/uninstall are offset by the need for changes to library code and to code that compiles and links against that library. A developer can say "I'll take the hit by changing my library code to deal with real frameworks", but that decision affects other developers too; the library developer only takes PART of the hit and IMPOSES the rest on third-party coders, who are, in turn, free to pass it on to those who compile their product. Apple recommends that "legacy code" be compiled in the usual way, and that no modifications be made to library code to accommodate frameworks. It then ignores its own (to me, sensible,) advice with Mac Tcl/Tk, providing, at the same time, an example of the pitfalls of doing so. That doesn't give us much guidance. > If you want the more traditional unix behavior you can ignore the whole > framework business and do "configure; make" and have a perfectly normal > unix Python on your OSX box. Can't we get that with the Macho binary distribution, so developer tools aren't required to get a "normal unix Python"? I'll close with this observation, hinted at above: currently there's no way to get a normal unix *shared* library installation *at all*. I see that as the fundamental shortcoming of the current Mac platform support (hence, the patch I sent for comment). -- bill > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > From gherman@darwin.in-berlin.de Tue Jul 9 11:47:38 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Tue, 09 Jul 2002 12:47:38 +0200 (CEST) Subject: [Pythonmac-SIG] Reading iPod files Message-ID: <1026211658.3d2abf4ac6492@webmail.in-berlin.de> Hi, is any iPod owner here interested in a Python lib/tool to ex- tract sound files from an attached iPod back to a Mac again? Apple has made this rather difficult (probably paying some tribute to the Recording Mafia) by storing the songs in many subfolders and providing a binary database file that you need to read to find them. Also, the Finder hides them entirely. The DB format is mostly understood and there are already some GUI tools to extract files. Mine is different in that it has no GUI, but lets you export the song list into an XML file and provides a song search interface via regular expressions, so you can generate a decision tree-like directory hierarchy with the songs as leaf nodes. I wonder if I should make a Cocoa GUI for it or just give it away as-is (which probably means that true Mackies won't adopt it that easily)? Regards, Dinu From mjb@uma.pt Tue Jul 9 12:24:05 2002 From: mjb@uma.pt (Michael J. Barber) Date: Tue, 9 Jul 2002 12:24:05 +0100 Subject: [Pythonmac-SIG] Mac sit files In-Reply-To: <6836D413-927B-11D6-9516-0030655234CE@cwi.nl> Message-ID: <60C7A6D5-932E-11D6-AADD-0050E4794D0F@uma.pt> On Monday, July 8, 2002, at 03:02 PM, Jack Jansen wrote: > > On Monday, July 8, 2002, at 03:01 , Guy Flowers wrote: > >> Hi >> >> Quick question, >> >> I've been looking at the zip module in python, I was wondering if >> there is >> some >> code of some sort, anywhere that could do the same but in a mac sit >> file. > > .sit files use a proprietary encoding. Last time I checked (which was, > admittedly, many years ago) the scheme was either unpublished or > copyright-protected or some such, and no third-party decoders were > available. > > You could probably wrap the stuffit engine (which is allowed, I > assume), I'll gladly accept contributed code, > Possibly, the StuffIt Commands OSAX could be helpful. Python can talk to that using the OSA tools. The OSAX is available at . From senn@maya.com Tue Jul 9 13:42:22 2002 From: senn@maya.com (Jeff Senn) Date: Tue, 09 Jul 2002 08:42:22 -0400 Subject: [Pythonmac-SIG] threads in OSX IDLE In-Reply-To: (Tony Lownds's message of "Mon, 8 Jul 2002 16:00:27 -0700") References: Message-ID: Tony Lownds writes: > I found some documentation about Tcl and threading: ... > terpreter. In other words, multiple threads can not access the > same Tcl interpreter. (However, as was the case in previous re- ... > That constraint makes fixing Tkinter pretty hard! Yes -- the only thing I can think of is to make Tkinter forward all Tk calls from alternate threads back through a "main" thread (which is presumably running the main event loop) and return the responses via a thread-safe queue... -- -Jas From fancher@pacbell.net Wed Jul 10 01:38:56 2002 From: fancher@pacbell.net (bill fancher) Date: Tue, 09 Jul 2002 17:38:56 -0700 Subject: [Pythonmac-SIG] Extensions for static versus framework MachoPython In-Reply-To: <128DD8B2-92BE-11D6-ACC3-003065517236@oratrix.com> Message-ID: <6B0CDC55-939D-11D6-BB27-0005029E8B13@pacbell.net> On Monday, July 8, 2002, at 03:00 PM, Jack Jansen wrote: > > Tried it again, and I got it to work this time. I now have both > python.exe and all the extension modules linked with two-level namespace, > and handled _environ by making it a static variable and initializing it > with _NSGetEnviron. > > However, the cure appears worse than the problem: in stead of "just > working" what happens now if you import a framework-based module into a > non-framework-based Python is that Python crashes with a bus error:-( > > I'll investigate a bit more, if anyone wants to help please speak up and > I'll put the diffs up on sourceforge, Having opened this can of worms, I almost feel obliged to take a look, assuming it's still an issue. If no one else expresses interest, feel free to mail diffs if that's easier than putting them on sourceforge. FWIW, when I do something similar here I get: Fatal Python error: Interpreter not initialized (version mismatch?) Abort This seems to me to be the correct behavior. (It's what you had originally expected to happen, IIRC.) To try it out, I cooked up two_level_namespace sha and _AE modules. Of course the libpython2.3.dylib that my test modules are linked against is not the same as what you're using there... -- bill From vern@hcc.hawaii.edu Wed Jul 10 21:51:46 2002 From: vern@hcc.hawaii.edu (Vern T Takebayashi) Date: Wed, 10 Jul 2002 10:51:46 -1000 (HST) Subject: [Pythonmac-SIG] Using XSLT on Mac Message-ID: Hi, Has anyone had experience setting up 4XSLT on a Mac classic (OS version 9.1). If not, can you provide me some feedback on what XSLT processor you use with Python on Mac classic. Any guidance in this matter would be appreciated. Thanks, Vern Vern Takebayashi vern@hcc.hawaii.edu Honolulu Community College ICS/Engineering From Jack.Jansen@oratrix.com Wed Jul 10 22:17:01 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 10 Jul 2002 23:17:01 +0200 Subject: [Pythonmac-SIG] Extensions for static versus framework MachoPython In-Reply-To: <6B0CDC55-939D-11D6-BB27-0005029E8B13@pacbell.net> Message-ID: <600A0AD0-944A-11D6-B6F5-003065517236@oratrix.com> On woensdag, juli 10, 2002, at 02:38 , bill fancher wrote: > Having opened this can of worms, I almost feel obliged to take > a look, assuming it's still an issue. If no one else expresses > interest, feel free to mail diffs if that's easier than putting > them on sourceforge. I've put them on sourceforge (this'll also make sure I either fix them or delete them in a finite amount of time:-). They're at http://www.python.org/sf/579841 . > FWIW, when I do something similar here I get: > > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort That is indeed what I expected. > This seems to me to be the correct behavior. (It's what you had > originally expected to happen, IIRC.) To try it out, I cooked > up two_level_namespace sha and _AE modules. Of course the > libpython2.3.dylib that my test modules are linked against is > not the same as what you're using there... Did you test with a "normal" dylib build, or with a dylib-linked-from-a-framework build? BTW: the bit of your patch that we agree on is the bit about getting --enable-shared to work. Is it possible to extract that from the rest, so we can then happily continue debating linked-framework-built-externally vs. self-contained-framework-built-from-makefile? (The other bit I agreed with, that the Carbon modules shouldn't be built for a non-framework build, was a silly mistake on my part and has been fixed already). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Wed Jul 10 22:38:03 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 10 Jul 2002 23:38:03 +0200 Subject: [Pythonmac-SIG] Reading iPod files In-Reply-To: <1026211658.3d2abf4ac6492@webmail.in-berlin.de> Message-ID: <507A9870-944D-11D6-B6F5-003065517236@oratrix.com> Dinu, depending on how much work you want to put into this it might make a very nice demo of the capabilities of Python. I'm thinking of something like a lowlevel module that allows access to the database, and a couple of programs: at least a command line program and a GUI program, possibly a GUI program both with Carbon and one with Cocoa, maybe even a Scripting Addition that opens up the files to AppleScript, or [Help! Help! He's getting carried away!!] a CGI script that makes the contents of your iPod available on a webpage, that sort of things. Hmm, [talk about getting carried away...], if the API to the lowlevel module is reasonably clean it might also be possible to write an alternative lowlevel module that would give the same access to your iTunes playlists. That would really be a very nice demo of the powers of Python... But: by all means makes this available, even if the rant above doesn't have you jumping up and down with excitement:-) On dinsdag, juli 9, 2002, at 12:47 , Dinu Gherman wrote: > Hi, > > is any iPod owner here interested in a Python lib/tool to ex- > tract sound files from an attached iPod back to a Mac again? > > Apple has made this rather difficult (probably paying some > tribute to the Recording Mafia) by storing the songs in many > subfolders and providing a binary database file that you need > to read to find them. Also, the Finder hides them entirely. > > The DB format is mostly understood and there are already some > GUI tools to extract files. Mine is different in that it has > no GUI, but lets you export the song list into an XML file and > provides a song search interface via regular expressions, so > you can generate a decision tree-like directory hierarchy with > the songs as leaf nodes. > > I wonder if I should make a Cocoa GUI for it or just give it > away as-is (which probably means that true Mackies won't > adopt it that easily)? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Wed Jul 10 22:23:20 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 10 Jul 2002 23:23:20 +0200 Subject: [Pythonmac-SIG] Anyone willing to put documentation into the Python.framework? Message-ID: <4226ED08-944B-11D6-B6F5-003065517236@oratrix.com> There's a work package that is pretty much self-contained, and that I'd like to offer here for volunteers, and that's getting the Python documentation into a form that is suitable for inclusion in Python.framework, and getting it accessible with (aaarrrgggghhh:-) Help Viewer, etc. This is mainly a question of digging up the Apple documentation on the format needed, which I've seen once but haven't found again (it's mainly html files with a naming convention and some sort of index file), and finding out how to create these html files from either the python documentation TeX source, or maybe even the documentation in html form. Any takers? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From skim@adobe.com Wed Jul 10 23:46:26 2002 From: skim@adobe.com (Sung Kim) Date: Wed, 10 Jul 2002 15:46:26 -0700 Subject: [Pythonmac-SIG] Advice for GUI app on Mac & Windows In-Reply-To: <507A9870-944D-11D6-B6F5-003065517236@oratrix.com> Message-ID: <200207102240.g6AMe7UU017356@inner-relay-2.corp.adobe.com> Hi, I'm considering using Python to write a cross-platform API tester (a GUI app). I have already created glue libraries on Windows and Mac (so that our Python script can access C APIs in question). Fyi, on the Mac, the C APIs live in a carbon-compliant shared library. Are there reasons why Python would or would not be a good solution for this? If Python is a good solution, any advice on which Python modules/libraries to use would be appreciated as well. One of the benefits of Python is "write-once for Mac and Windows" but I'm having a hard time finding a GUI solution that'll work on both platforms. Thank you! --Sung H. Kim From ryanwilcox@mac.com Wed Jul 10 23:51:09 2002 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Wed, 10 Jul 2002 18:51:09 -0400 Subject: [Pythonmac-SIG] Advice for GUI app on Mac & Windows In-Reply-To: <200207102240.g6AMe7UU017356@inner-relay-2.corp.adobe.com> Message-ID: <869641B6-9457-11D6-8044-0050E4A60816@mac.com> On Wednesday, July 10, 2002, at 06:46 PM, Sung Kim wrote: > One of the benefits of Python is "write-once for Mac and Windows" but > I'm having a hard time finding a GUI solution that'll work on both > platforms. Thank you! > > wxPython, perhaps? HTH, -Ryan Wilcox From fancher@pacbell.net Thu Jul 11 01:20:42 2002 From: fancher@pacbell.net (bill fancher) Date: Wed, 10 Jul 2002 17:20:42 -0700 Subject: [Pythonmac-SIG] Anyone willing to put documentation into the Python.framework? In-Reply-To: <4226ED08-944B-11D6-B6F5-003065517236@oratrix.com> Message-ID: <0918EBB3-9464-11D6-83A8-0005029E8B13@pacbell.net> On Wednesday, July 10, 2002, at 02:23 PM, Jack Jansen wrote: > There's a work package that is pretty much self-contained, and that I'd > like to offer here for volunteers, and that's getting the Python > documentation into a form that is suitable for inclusion in > Python.framework, and getting it accessible with (aaarrrgggghhh:-) Help > Viewer, etc. I'll see your arg "aaarrrgggghhh", and raise you one. Current Help Viewer is a disgrace. > This is mainly a question of digging up the Apple documentation on the > format needed, which I've seen once but haven't found again (it's mainly > html files with a naming convention and some sort of index file), and > finding out how to create these html files from either the python > documentation TeX source, or maybe even the documentation in html form. > > Any takers? I've done it before with the HTML stuff. Not a big deal. I'd be happy to cobble a script to build something workable. Is there a deadline? -- bill From gherman@darwin.in-berlin.de Thu Jul 11 13:06:57 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Thu, 11 Jul 2002 14:06:57 +0200 (CEST) Subject: [Pythonmac-SIG] Reading iPod files Message-ID: <1026389217.3d2d74e183f5f@webmail.in-berlin.de> This message is in MIME format. ---MOQ10263892175aad7b8e3211e9f316ac342ac38df611 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Jack Jansen : > Dinu, > depending on how much work you want to put into this it might > make a very nice demo of the capabilities of Python. I'm > thinking of something like a lowlevel module that allows access > to the database, and a couple of programs: at least a command > line program and a GUI program, possibly a GUI program both with > Carbon and one with Cocoa, maybe even a Scripting Addition that > opens up the files to AppleScript, or [Help! Help! He's getting > carried away!!] a CGI script that makes the contents of your > iPod available on a webpage, that sort of things. That would be simple enough, even accessing the files directly on an iPod attached to a networked machine! But that sounds *very* much like some folks will more than not like this... I don't know how much more time I'll put in. A Cocoa i/f is doable, but I have no clue about Carbon and certain- ly won't take courses to learn it... ;-) More or less the same with AppleScript. > Hmm, [talk about getting carried away...], if the API to the > lowlevel module is reasonably clean it might also be possible to > write an alternative lowlevel module that would give the same > access to your iTunes playlists. That would really be a very > nice demo of the powers of Python... The API is dead-simple. I'm attaching my test suite as a proof! ;-) > But: by all means makes this available, even if the rant above > doesn't have you jumping up and down with excitement:-) It does! ;-) Dinu ---MOQ10263892175aad7b8e3211e9f316ac342ac38df611 Content-Type: application/octet-stream; name="test.py" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test.py" IyEvdXNyL2Jpbi9lbnYgcHl0aG9uCgppbXBvcnQgc3RyaW5nLCBzeXMsIG9zLCB1bml0dGVzdCwg cmFuZG9tCgpmcm9tIGlwb2RsaWIgaW1wb3J0IGxvY2F0ZWlQb2RWb2x1bWUsIGxvY2F0ZWlQb2Rp VHVuZXNEQgpmcm9tIGlwb2RsaWIgaW1wb3J0IERCLCBTb25nCgoKCgpjbGFzcyBJUG9kQWNjZXNz VGVzdHModW5pdHRlc3QuVGVzdENhc2UpOgoKICAgIGRlZiB0ZXN0TG9jYXRlX2lQb2Rfdm9sdW1l KHNlbGYpOgogICAgICAgICJUZXN0IGNvcHlpbmcgaVBvZCBtdXNpYyBmaWxlcyB0byBhIHNpbmds ZSBkZXN0aW5hdGlvbiBmb2xkZXIuIgoKICAgICAgICBleHBlY3RlZCA9ICcvVm9sdW1lcy9Qb2Rk eScKICAgICAgICBhc3NlcnQgbG9jYXRlaVBvZFZvbHVtZSgpID09IGV4cGVjdGVkCgoKICAgIGRl ZiB0ZXN0TG9jYXRlX2lUdW5lc0RCX29uX2lQb2Qoc2VsZik6CiAgICAgICAgIlRlc3QgY29weWlu ZyBpUG9kIG11c2ljIGZpbGVzIHRvIGEgc2luZ2xlIGRlc3RpbmF0aW9uIGZvbGRlci4iCgogICAg ICAgIGV4cGVjdGVkID0gJy9Wb2x1bWVzL1BvZGR5L2lQb2RfQ29udHJvbC9pVHVuZXMvaVR1bmVz REInCiAgICAgICAgYXNzZXJ0IGxvY2F0ZWlQb2RpVHVuZXNEQigpID09IGV4cGVjdGVkCgoKCgpj bGFzcyBGaWxlQ29weVRlc3RzKHVuaXR0ZXN0LlRlc3RDYXNlKToKCiAgICBkZWYgX3Rlc3RDb3B5 KHNlbGYpOgogICAgICAgICJUZXN0IGNvcHlpbmcgaVBvZCBtdXNpYyBmaWxlcyB0byBhIHNpbmds ZSBkZXN0aW5hdGlvbiBmb2xkZXIuIgoKICAgICAgICBkYiA9IERCKCdpVHVuZXNEQicpLnJlYWQo KQogICAgICAgIGRiLmNvcHlGaWxlcygnc29uZ3MvJywgKCgnYXJ0aXN0JywgJ0FzdG9yLionKSwg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCd0aXRsZScsICdBLionKSkpCgoKICAg IGRlZiBfdGVzdENvcHlUcmVlKHNlbGYpOgogICAgICAgICJUZXN0IGNvcHlpbmcgaVBvZCBtdXNp YyBmaWxlcyB0byBkZXN0aW5hdGlvbiBmb2xkZXIgaGllcmFyY2h5LiIKCiAgICAgICAgZGIgPSBE QignaVR1bmVzREInKS5yZWFkKCkKICAgICAgICBkYi5jb3B5RmlsZXNUcmVlKCdzb25ncy8nLCAo KCdhcnRpc3QnLCAnQXN0b3IuKicpLCAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAoJ3RpdGxlJywgJ0EuKicpKSkKCgogICAgZGVmIHRlc3RDb3B5TW9yZU5lc3RlZFRyZWUoc2Vs Zik6CiAgICAgICAgIlRlc3QgY29weWluZyBpUG9kIG11c2ljIGZpbGVzIHRvIGRlc3RpbmF0aW9u IGZvbGRlciBoaWVyYXJjaHkuIgoKICAgICAgICBkYiA9IERCKCdpVHVuZXNEQicpLnJlYWQoKQog ICAgICAgIGRiLmNvcHlGaWxlc1RyZWUoJ3NvbmdzLycsICgoJ2FsYnVtJywgJ0EuKicpLCAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCdhcnRpc3QnLCAnLionKSwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCd0aXRsZScsICdbQS1NXS4qJykpICkKCgog ICAgZGVmIF90ZXN0V3JpdGVYbWwoc2VsZik6CiAgICAgICAgIlRlc3QgY29udmVydGluZyBzb25n cyB0byBYTUwuIgoKICAgICAgICBkYiA9IERCKCdpVHVuZXNEQicpLnJlYWQoKQogICAgICAgIHNv bmdzID0gZGIuZ2V0U29uZ3MoKCgnYXJ0aXN0JywgJ0FzdG9yLionKSwgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKCdhbGJ1bScsICdTdSonKSkpCiAgICAgICAgZGIud3JpdGVUb1htbCgn c29uZ3Mvc29uZ3MueG1sJywgc29uZ3MpCgoKCgpjbGFzcyBMb2NhbERiQWNjZXNzVGVzdHModW5p dHRlc3QuVGVzdENhc2UpOgogICAgIlRlc3RzIG9uIGEgbG9jYWwgY29weSBvZiBhbiBpUG9kJ3Mg aVR1bmVzREIgZmlsZS4iCgogICAgZGVmIHRlc3Qoc2VsZik6CiAgICAgICAgIlRlc3Qgc29uZyBz b3J0aW5nIgoKICAgICAgICBkYiA9IERCKCdpVHVuZXNEQicpLnJlYWQoKQogICAgICAgIHNvbmcw ID0gZGIuc29uZ3NbMF0KICAgICAgICBkYi5zb3J0KCkKICAgICAgICBzb25nMSA9IGRiLnNvbmdz WzBdCiAgICAgICAgYXNzZXJ0IHNvbmcwLnRpdGxlICE9IHNvbmcxLnRpdGxlCgoKICAgIGRlZiB0 ZXN0R2V0U29uZ3Moc2VsZik6CiAgICAgICAgIlRlc3Qgc29uZyByZXRyaWV2YWwgdmlhIGdldFNv bmdzKCkiCgogICAgICAgIGRiID0gREIoJ2lUdW5lc0RCJykucmVhZCgpCiAgICAgICAgc29uZzAg PSBkYi5nZXRTb25ncygpWzBdCiAgICAgICAgZGIuc29ydCgpCiAgICAgICAgc29uZzEgPSBkYi5n ZXRTb25ncygpWzBdCiAgICAgICAgYXNzZXJ0IHNvbmcwLnRpdGxlICE9IHNvbmcxLnRpdGxlCgoK ICAgIGRlZiB0ZXN0R2V0U29uZ3NCeVRpdGxlKHNlbGYpOgogICAgICAgICJUZXN0IHNvbmcgY29u ZGl0aW9uYWwgcmV0cmlldmFsIHZpYSBnZXRTb25ncygpIgoKICAgICAgICBkYiA9IERCKCdpVHVu ZXNEQicpLnJlYWQoKQogICAgICAgIHNvbmcwID0gZGIuZ2V0U29uZ3MoWygndGl0bGUnLCcuKicp XSlbMF0KICAgICAgICBkYi5zb3J0KCkgIyBzaG91bGQgbm90IGNvbmZ1c2UKICAgICAgICBzb25n MSA9IGRiLmdldFNvbmdzKFsoJ3RpdGxlJywnLionKV0pWzBdCiAgICAgICAgYXNzZXJ0IHNvbmcw LnRpdGxlID09IHNvbmcxLnRpdGxlCgoKCgpjbGFzcyBQbGF5aW5nVGVzdHModW5pdHRlc3QuVGVz dENhc2UpOgoKICAgIGRlZiBfdGVzdFBsYXlSYW5kb21GaWxlKHNlbGYpOgogICAgICAgICJUZXN0 IHBsYXlpbmcgYSByYW5kb20gZmlsZSBvZiB0aGUgZGF0YWJhc2UuIgoKICAgICAgICB2b2wgPSBs b2NhdGVpUG9kVm9sdW1lKCkKICAgICAgICBkYlBhdGggPSBsb2NhdGVpUG9kaVR1bmVzREIoKQog ICAgICAgIGRiID0gREIoZGJQYXRoKS5yZWFkKCkKICAgICAgICAjIGluZGV4ID0gbGVuKGRiLnNv bmdzKS8yKzEwCiAgICAgICAgaW5kZXggPSByYW5kb20ucmFuZGludCgwLCBsZW4oZGIuc29uZ3Mp KQogICAgICAgIHNvbmcgPSBkYi5nZXRTb25ncygpW2luZGV4XQogICAgICAgIGZuID0gdm9sICsg c3RyaW5nLnJlcGxhY2Uoc29uZy5maWxlbmFtZSwgJzonLCAnLycpCiAgICAgICAgIyBwcmludCBm biwgb3MucGF0aC5leGlzdHMoZm4pCiAgICAgICAgcmVzID0gb3MucG9wZW4oJ29wZW4gIiVzIicg JSBmbikKICAgICAgICBhc3NlcnQgcmVzICE9IDAKCgogICAgZGVmIHRlc3RQbGF5UmFuZG9tSmF6 ekZpbGUoc2VsZik6CiAgICAgICAgIlRlc3QgcGxheWluZyBhIHJhbmRvbSBKYXp6IGZpbGUgb2Yg dGhlIGRhdGFiYXNlLiIKCiAgICAgICAgdm9sID0gbG9jYXRlaVBvZFZvbHVtZSgpCiAgICAgICAg ZGJQYXRoID0gbG9jYXRlaVBvZGlUdW5lc0RCKCkKICAgICAgICBkYiA9IERCKGRiUGF0aCkucmVh ZCgpCiAgICAgICAgamF6elNvbmdzID0gZGIuZ2V0U29uZ3MoWygnZ2VucmUnLCAnLiphenouKicp XSkKICAgICAgICBpbmRleCA9IHJhbmRvbS5yYW5kaW50KDAsIGxlbihqYXp6U29uZ3MpKQogICAg ICAgIHNvbmcgPSBqYXp6U29uZ3NbaW5kZXhdCiAgICAgICAgZm4gPSB2b2wgKyBzdHJpbmcucmVw bGFjZShzb25nLmZpbGVuYW1lLCAnOicsICcvJykKICAgICAgICAjcHJpbnQgZm4sIG9zLnBhdGgu ZXhpc3RzKGZuKQogICAgICAgIHJlcyA9IG9zLnBvcGVuKCdvcGVuICIlcyInICUgZm4pCiAgICAg ICAgYXNzZXJ0IHJlcyAhPSAwCgoKCgpjbGFzcyBSZXBvcnRpbmdUZXN0cyh1bml0dGVzdC5UZXN0 Q2FzZSk6CgogICAgZGVmIHRlc3QwKHNlbGYpOgogICAgICAgICJUZXN0IG1ha2luZyBhIHJlcG9y dCAodXNpbmcgYW4gZXh0ZXJuYWwgbW9kdWxlKS4iCgogICAgICAgIHZvbCA9IGxvY2F0ZWlQb2RW b2x1bWUoKQogICAgICAgIGRiUGF0aCA9IGxvY2F0ZWlQb2RpVHVuZXNEQigpCiAgICAgICAgZGIg PSBEQihkYlBhdGgpLnJlYWQoKQogICAgICAgIGNyaXRlcmlhID0gWygnYXJ0aXN0JywgJ0FzLion KSwgKCdnZW5yZScsICcuKicpXQogICAgICAgIGNhdGVnb3JpZXMgPSBtYXAobGFtYmRhIGM6Y1sw XSwgY3JpdGVyaWEpCiAgICAgICAgc29uZ3MgPSBkYi5nZXRTb25ncyhjcml0ZXJpYSkKICAgICAg ICAjIGZpZGRsZSBhIGJpdCAocmVwbGFjZSAnJicgYW5kIGZpbHRlciByZWFsIFVuaWNvZGUgc3R1 ZmYuLi4pCiAgICAgICAgZm9yIGkgaW4gcmFuZ2UobGVuKHNvbmdzKSk6CiAgICAgICAgICAgIHMg PSBzb25nc1tpXQogICAgICAgICAgICBmb3IgYSBpbiBzdHJpbmcuc3BsaXQocy5maWVsZE5hbWVz KToKICAgICAgICAgICAgICAgIHRyeToKICAgICAgICAgICAgICAgICAgICB2ID0gZ2V0YXR0cihz LCBhKS5lbmNvZGUoIkFzY2lpIikKICAgICAgICAgICAgICAgICAgICB2ID0gc3RyaW5nLnJlcGxh Y2UodiwgJyYnLCAnJmFtcDsnKQogICAgICAgICAgICAgICAgICAgIHNldGF0dHIocywgYSwgdikK ICAgICAgICAgICAgICAgIGV4Y2VwdCBVbmljb2RlRXJyb3I6CiAgICAgICAgICAgICAgICAgICAg c29uZ3NbaV0gPSBOb25lCiAgICAgICAgc29uZ3MgPSBmaWx0ZXIobGFtYmRhIHM6cyE9Tm9uZSwg c29uZ3MpCiAgICAgICAgIyBmb3Igbm93IHRoaXMgdXNlcyBhbiBleHRlcm5hbCBtb2R1bGUgKHdo aWNoIGl0c2VsZiB1c2VzIHJlcG9ydGxhYikKICAgICAgICBpbXBvcnQgbWFrZVRhYmxlCiAgICAg ICAgbWFrZVRhYmxlLm1haW4oY2F0ZWdvcmllcywgc29uZ3MpCgoKCgoKY2xhc3MgRXh0cmFjdFRl c3RzKHVuaXR0ZXN0LlRlc3RDYXNlKToKCiAgICBkZWYgdGVzdDAoc2VsZik6CiAgICAgICAgIlRl c3QgY29weWluZyBpUG9kIG11c2ljIGZpbGVzIHRvIGEgc2luZ2xlIGRlc3RpbmF0aW9uIGZvbGRl ci4iCgogICAgICAgIGRiUGF0aCA9IGxvY2F0ZWlQb2RpVHVuZXNEQigpCiAgICAgICAgZGIgPSBE QihkYlBhdGgpLnJlYWQoKQogICAgICAgIGRiLmNvcHlGaWxlc1RyZWUoJ3NvbmdzLycsICgoJ2Fs YnVtJywgJy4qJyksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgnYXJ0aXN0 JywgJ0FzdG9yLionKSwgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgndGl0 bGUnLCAnLionKSkpCgoKCgpkZWYgbWFrZVN1aXRlKCk6CiAgICBzdWl0ZSA9IHVuaXR0ZXN0LlRl c3RTdWl0ZSgpCiAgICBsb2FkZXIgPSB1bml0dGVzdC5UZXN0TG9hZGVyKCkKCiAgICBmb3IgYyBp biBbRXh0cmFjdFRlc3RzLCBSZXBvcnRpbmdUZXN0cywgSVBvZEFjY2Vzc1Rlc3RzLCBGaWxlQ29w eVRlc3RzLCAKICAgICAgICAgICAgICBMb2NhbERiQWNjZXNzVGVzdHNdOgogICAgICAgIHN1aXRl LmFkZFRlc3QobG9hZGVyLmxvYWRUZXN0c0Zyb21UZXN0Q2FzZShjKSkKCiAgICByZXR1cm4gc3Vp dGUKCgppZiBfX25hbWVfXyA9PSAiX19tYWluX18iOgogICAgdW5pdHRlc3QuVGV4dFRlc3RSdW5u ZXIoKS5ydW4obWFrZVN1aXRlKCkpCg== ---MOQ10263892175aad7b8e3211e9f316ac342ac38df611-- From Jack.Jansen@oratrix.com Thu Jul 11 14:13:35 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 11 Jul 2002 15:13:35 +0200 Subject: [Pythonmac-SIG] Anyone willing to put documentation into the Python.framework? In-Reply-To: <0918EBB3-9464-11D6-83A8-0005029E8B13@pacbell.net> Message-ID: <01DB495C-94D0-11D6-966F-003065517236@oratrix.com> On donderdag, juli 11, 2002, at 02:20 , bill fancher wrote: > > On Wednesday, July 10, 2002, at 02:23 PM, Jack Jansen wrote: > >> There's a work package that is pretty much self-contained, and >> that I'd like to offer here for volunteers, and that's getting >> the Python documentation into a form that is suitable for >> inclusion in Python.framework, and getting it accessible with >> (aaarrrgggghhh:-) Help Viewer, etc. > > I've done it before with the HTML stuff. Not a big deal. I'd be > happy to cobble a script to build something workable. Is there > a deadline? > Bill, that would be great! The release of 2.3a1 would be a good candidate for a deadline. But I'm not sure when that is going to be: the original planning says "before OSCON 2002", which is in two weeks time, but I haven't seen any indication that this deadline is going to be met. My (wild) guess is that the first 2.3 alfa will be some time in August. Does that fit your schedule? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From elmlish@mac.com Wed Jul 10 16:29:44 2002 From: elmlish@mac.com (Israel) Date: Wed, 10 Jul 2002 08:29:44 -0700 Subject: [Pythonmac-SIG] Can't open windows .py files with MacPython IDE. Message-ID: Hello there all goodly mac people... I've run into a problem with opening and editing my old python files which had been created on a windows box. When I go to open them through the IDE the files are grayed out and I'm not allowed to touch them. When I change the .py files to be opened up by the MacPython interpreter, I'm told that my python scripts aren't really scripts at all, but probably preference files or or and application template. When I change the .py files to be opened up by the MacPython IDE, I'm told that the IDE can't open files of type ''. So, I'm confused. Any suggestions? I'm new to macpython so I'm probably missing something. Also, when I double click a script made in the IDE, it opens up in the IDE and doesn't run as I would expect it to, coming from windows and a little bit of linux. Is that normal. To run a script should I use the Terminal or the Run all buttons inside the IDE? Thanks for any help you can offer... ~Israel~ From marcus.h.mendenhall@vanderbilt.edu Thu Jul 11 17:50:10 2002 From: marcus.h.mendenhall@vanderbilt.edu (Marcus H. Mendenhall) Date: Thu, 11 Jul 2002 11:50:10 -0500 Subject: [Pythonmac-SIG] Can't open windows .py files with MacPython IDE. In-Reply-To: References: Message-ID: --============_-1185716285==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" The attached 'make python' script is an AppleScipt app which, if you drop a bunch of files on it, will assign the correct type so that double-clicking them opens them in the IDE. The maketext script is the raw applescript from which this app is built, except that the type in maketext are appropriate for a text file. It is very useful for transferring files from win/dos/unix/etc. to the Mac. Marcus Mendenhall >Hello there all goodly mac people... > >I've run into a problem with opening and editing my old python files >which had been created on a windows box. When I go to open them >through the IDE the files are grayed out and I'm not allowed to >touch them. When I change the .py files to be opened up by the >MacPython interpreter, I'm told that my python scripts aren't really >scripts at all, but probably preference files or or and application >template. When I change the .py files to be opened up by the >MacPython IDE, I'm told that the IDE can't open files of type ''. > >So, I'm confused. Any suggestions? I'm new to macpython so I'm >probably missing something. Also, when I double click a script made >in the IDE, it opens up in the IDE and doesn't run as I would expect >it to, coming from windows and a little bit of linux. Is that >normal. To run a script should I use the Terminal or the Run all >buttons inside the IDE? > >Thanks for any help you can offer... > >~Israel~ --============_-1185716285==_============ Content-Id: Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="make_Python" Content-Disposition: attachment; filename="make_Python" ; modification-date="Thu, 11 Jan 2001 11:18:46 -0500" AAUWAAACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAADAAAASgAAAAsAAAAJAAAAVQAAACAA AAAIAAAAdQAAABAAAAACAAAAhQAADMBtYWtlIFB5dGhvbkFQUExkcGx0IQAAgACBAAAA AAAAAAAAAIAAAAAAAAAAAfBTFQHwUxZLbQwABMAtcwAAAQAAAAtaAAAKWgAAAWYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQmRmFzZFVBUyAxLjEwMS4x MA4AAAAED/////4AAQACAf//AAAB//4AAA4AAQAADxAAAgAF//0AAwAEAAUABgH//QAA EAADAAP//P/7//oL//wACDAABGRvaXQAAAr/+wAYLmFldnRvZG9jbnVsbAAAgAAAABAA YWxpcwr/+gAYLmFldnRvYXBwbnVsbAAAgAAAAJAAKioqKg4ABAAHEP/5//j/9//2AAcA CP/1C//5AAgwAARkb2l0AAAB//gAAA7/9wACBP/0AAkD//QAAQ4ACQABAP/zC//zAAow AAZteWZpbGUAAAL/9gAAEAAHAAH/8gv/8gAKMAAGbXlmaWxlAAAQAAgABQAKAAv/8QAM //APAAoBNAhudWxsAAAAAAAB34D//wAAAB0GRmluZGVypacgIgAASAHQaEg9hpXQPaWn MAA27YAB0OWEPaWvLD2lp0BEAABE/9EbPAAAAAAANxvaAUYXUAAATUFDUwAAEQBhbGlz AAAAAADWAAIAAAlNYXJjdXMgRzQAAAAAAAAAAAAAAAAAAAAAAAC1xwvNQkQAAAAAAB0G RmluZGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABlLQD6UBGTkRSTUFDU/////8AAAAAAAAAAAAAAAAAAAAAAAAA DVN5c3RlbSBGb2xkZXIAAAEABAAAAB0AAgAeTWFyY3VzIEc0OlN5c3RlbSBGb2xkZXI6 RmluZGVy//8AAAwACwAKAARURVhUAAIAAAr/8QAECmFzdHkMAAwACgAEUGlkZQACAAAK //AABApmY3J0Ef/1ABPgEgAP4aDiLEZP46DkLEZPUFUPDgAFAAcQ/+//7v/t/+wADQAO /+sK/+8AGC5hZXZ0b2RvY251bGwAAIAAAAAQAGFsaXMB/+4AAAv/7QANMAAJZmlsZW5h bWVzAAAC/+wAABAADQAC/+r/6Qv/6gANMAAJZmlsZW5hbWVzAAAL/+kABTAAAWkAABAA DgAE/+j/5//m/+UK/+gABAprb2NsCv/nAAQKY29iagr/5gAYLmNvcmVjbnRlKioqKgAA AAAAABAAKioqKgv/5QAIMAAEZG9pdAAAEf/rABwXABqgW+DhbAwAAmtoGwABKqFrKwAD W09Z//QPDgAGAAcQ/+T/4//i/+EADwAQ/+AK/+QAGC5hZXZ0b2FwcG51bGwAAIAAAACQ ACoqKioB/+MAAAH/4gAAAv/hAAAQAA8AABAAEAAD/9//3v/dCv/fABguc3lzb3N0ZGZh bGlzAAAAAP//gABudWxsC//eAAowAAZteWZpbGUAAAv/3QAIMAAEZG9pdAAAEf/gAA8q agwAAEXRTyrBaysAAg8AYXNjcgABAA363t6tAAAAGAAAACgAAAAAAAAACAAAACAAZD88 AAGp8AAAAMIAAAABTlb/+C8DdgAvAzA8oa2nRiYfLUj/+C8DMDyon6dGJh8gLv/4scBn IC8DIDxjcG50Qe7//CJIoa0iiCYfSkBmCEqu//xnAnYBEAMmLv/0Tl5OdY9Hb3RDb21w b25lbnRNZ3IAAE5WAAAvDE66/5RKAGcqWY8vPGFwbHQvPHNjcHRwIagqKF8gDGcSWY8v DC88AAAAAXAAqCqp9FhPcAM/AKnIcAM/AKnIKG7//E5eTnWKQXBwbGV0U3R1YgAAAAAA ABpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApY4AADIAAAAyAAAAAANGRwbHQA AAABRlJFRgADAAAAgQABAIIAAgCDAAMAhElDTiMAAwAAAJcAAQAAAAIAAAADAAAAAAAB AAAAAAdBUFBMAAAAAAAAByoqKioAAQAAAAAHZm9sZAACAAAAAAdkaXNrAAMAAAABAAAA h8AAAUfAAAInwAAEF8AACA/AABAHwAHgB8ACEAfABAg/+AgIH/AQEA/gICAH0EBQA4jw iAEEiQQAAoYEAAGEAgACQAIABCACAAgQAgAQCAQAIBQIAEAkEACAQiABAEJAAgBCwAQA IyAIAB4QEAAACCAAAARAAAACgAAAAQAAAACHwAABx8AAA+fAAAf3wAAP/8AAH//AAf// wAP//8AH///4D///8B///+A////wf///+P////z////+//////////5////8P///+B// //AP///gH///wD///4B///8Af//+AH///AA/P/gAHh/wAAAP4AAAB8AAAAOAAAABAAAA AAIAAAAAAAAAAADwAA///wAAAAAAAAAAAAAPDwAPdX8AAAAAAAAAAAAA8ADwD1dfAAAA AAAAAAAADwAADw91fwAAAAAAAAAAAPAAAAD/V18AAAAAAAAAAA8AAAAAD3V/AAAAAAAA D//wAAAAAA9XXwAAAAAAAPDM3wAAAAAPdX8AAAAAAA8ADMzwAAD//1df//AAAADwAMzN 8AAAD3V1dX8AAAAPAAzM3wAAAAD3V1fwAAAA8ADMzfAAAAAAD3V/DwAADwAMzN/fAAAA AAD38ADwAP//zM393fAAAAAADwAADwD+3Pzf3czfAAAAAAAAAADw/czP/dzAz9AAAAAA AAAMz/zMD83MAM3wAAAAAAAAzPAPAMDMwAzN8AAAAAAADM8AAPAMDADAzfAAAAAAAMzw AAAPAMAMDM3wAAAAAAzPAAAAAPAAwMzfwAAAAADM8AAAAA/fDAzN/MAAAAAMzwAAAAD9 38DM38zAAAAAzPAAAAAP3cz8zfzMAAAADM8AAAAAD9zM/N/MwAAAAMzwAAAAAA/MwP3/ zAAAAAzPAAAAAAAA/Az/APzAAADM8AAAAAAAAA//8AAPzAAMzwAAAAAAAAAAAAAAAPzA zPAAAAAAAAAAAAAAAAAPzM8AAAAAAAAAAAAAAAAAAPzwAAAAAAAAAAAAAAAAAAAPAAAA AAAAAAAAAABAALgBeAI4HDgi/kR8zDqyEaECQQRiCJQQmCB0QAKAAQAAuAH4A/gf+D/+ f/z//v////5//H/4//D/4HfAA4ABAAAAAIAAAAAA8P/wAAAAAA8P9fAAAAAA8AD38AAA D/8AAPXwAADwzPD/9//wDwzPAA91fwD/zP8AAPfw8P3/3PAADwDP/P3AzwAADPAPDAzP AADPAA/wzPwADPAA/c/PzADPAAD8D/zADPAAAA//D8DPAAAAAAAA/PAAAAAAAAAPAAAA AAAAABIAAgAAAAAAAAAAAAEABgAGE4kAAAC3U2NyaXB0IEFwcGxpY2F0aW9uDQ1UaGlz IGlzIGFuIGV4ZWN1dGFibGUgc2NyaXB0IHNhdmVkIGFzIGFuIGFwcGxpY2F0aW9uLiBM YXVuY2ggdGhlIGFwcGxpY2F0aW9uIHRvIHJ1biB0aGUgc2NyaXB0Lg1Zb3UgY2FuIGVk aXQgdGhlIHNjcmlwdCBieSBkcm9wcGluZyB0aGlzIGljb24gb24gdGhlIFNjcmlwdCBF ZGl0b3IuAAAAFAA1AAcBtgF3ADUABwGwAm0AAAAAAAABAAAAC1oAAApaAAABZj2Sv8AD 8gAAABwBZgANc2NwdAAAAHJDT0RFAAEAfnNjc3oAAACWU0laRQAAAKJCTkRMAAAArmRw bHQAAAC6RlJFRgADAMZJQ04jAAAA9mljbDQAAAECaWNzIwAAAQ5pY3M0AAABGmhmZHIA AAEmVEVYVAAAATJXUG9zAAABPgCA//8AAAAAPZVVUAAA//8gAAQqPZVVSAAB//8UAARG PZVVRAAA//8AAAUMPZVVQP////8AAAUqPZVVPACA//8AAAU4PZVVOAAA//8AAAVwPZVV NACB//8AAAV1PZVVMACC//8AAAWAPZVVLACD//8AAAWLPZVVKACE//8AAAWWPZVVJACX //8AAAWhPZVVIACX//8AAAalPZVVHACX//8AAAipPZVVGACX//8AAAjtPZVVFOnA//8A AAlxPZVVEBOJ//8AAAmHPZVYnACA//8AAApCPZK/xA== --============_-1185716285==_============ Content-Id: Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="maketext_script" Content-Disposition: attachment; filename="maketext_script" ; modification-date="Wed, 17 Jun 1998 13:41:02 -0500" AAUWAAACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAADAAAASgAAAA8AAAAJAAAAWQAAACAA AAAIAAAAeQAAABAAAAACAAAAiQAACoJtYWtldGV4dCBzY3JpcHRvc2FzVG95UwEAAMAA gQAAAAAAAAAAAAAAAAAAAAAAAP0UF7L9GoPuS20MAATALXMAAAEAAAAKPAAACTwAAABG /wj/CP///wj//wAAAAAAAP8I/wj/CAj/AAAAAAAAAAAYU2NyaXB0IEVkaXRvciBUZW1w IDAwMDAxbmNlc2VzcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACxrXfu AAAAAAAAAR7QAAOIEAADiBAb9wgQEA4IEDgcCBBwCAgQ7/sIEcAACBHAAAsQ79gPEHAA CxA4AAsQEgALEAWgCxAFUA8f/V/4AAVQEAACqCAAAUBAAAC/gADgAAAB/AAAA/+AAAf/ wAAP/+AAH///+P////j////4////+P////j////4////+N//AAAJIEZhc2RVQVMgMS4x MDEuMTAOAAAABA///wABAAIAAwH//wAADQABAAFrAAAAAAAAAAQCAAQAAgAFAAYNAAUA AmwAAgAAAAcAB//+DQAHAAJyAAAAAAAHAAgACQ0ACAADSQACAAAABf/9//z/+wr//QAY LnN5c29zdGRmYWxpcwAAAAD//4AAbnVsbAH//AAAAv/7AAANAAkAAW8AAAAAAAD/+gv/ +gAKMAAGbXlmaWxlAAAB//4AAAIABgACAAoACw0ACgACbAACAAgADgAM//kNAAwAA0kA AAAIAA7/+AAN//cL//gACDAABGRvaXQAAAIADQACAA7/9g0ADgABbwAAAAkACv/1C//1 AAowAAZteWZpbGUAAAL/9gAAAv/3AAAB//kAAAIACwACAA8AEA0ADwACbAACAAAAAP/0 //MB//QAAAH/8wAAAgAQAAIAEQASDQARAAJpAAAAAAADABMAFA0AEwADSQAAAAAAAP/y ABX/8Qv/8gAIMAAEZG9pdAAAAgAVAAIAFv/wDQAWAAFvAAAAAAAA/+8L/+8ACjAABm15 ZmlsZQAAAv/wAAAC//EAAA0AFAACTwAAAAAAEgAXABgNABcAAWsAAAAEABEAGQIAGQAC ABoAGw0AGgACbAABAAQABP/uABwB/+4AAAwAHAAmACBzZXQgdCB0byB0aGUgZmlsZSB0 eXBlIG9mIG15ZmlsZQACAAACABsAAgAdAB4NAB0AAmwAAQAEAAT/7QAfAf/tAAAMAB8A KQAjc2V0IGMgdG8gdGhlIGNyZWF0b3IgdHlwZSBvZiBteWZpbGUAAgAAAgAeAAIAIAAh DQAgAAJyAAAABAAJACIAIw0AIgABbQAAAAQABQAkDAAkAAoABFRFWFQAAgAADQAjAAJs AQAAAAAAACX/7A0AJQACbgAAAAAAAAAmACcNACYAATEAAAAGAAj/6wr/6wAECmFzdHkN ACcAAW8AAAAFAAb/6gv/6gAKMAAGbXlmaWxlAAAB/+wAAAIAIQACACgAKQ0AKAACcgAA AAoADwAqACsNACoAAW0AAAAKAAsALAwALAAKAARDV0lFAAIAAA0AKwACbAEAAAAAAAAt /+kNAC0AAm4AAAAAAAAALgAvDQAuAAExAAAADAAO/+gK/+gABApmY3J0DQAvAAFvAAAA CwAM/+cL/+cACjAABm15ZmlsZQAAAf/pAAACACkAAgAw/+YNADAAAmwAAQAQABD/5QAx Af/lAAAMADEAEwANcmV0dXJuIHt0LCBjfQACAAAC/+YAAA0AGAABbQAAAAAAAQAyDwAy ATQIbnVsbAAAAAAAAd+A//8AAAASBkZpbmRlciUH7d+EAAAoAAAAKAAHs/3y/8PHQgAA KAAAAAAAAHxVUAez/g7/w98EAAAAAAAAAAEHrFtSB6xbUk1BQ1MAABEAYWxpcwAAAAAA 1gACAAAJTWFyY3VzIEczAAAAAAAAAAAAAAAAAAAAAAAAsZq43EJEAAAAAAASBkZpbmRl cgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAcCwvB3ARk5EUk1BQ1P/////AAAAAAAAAAAAAAAAAAAAAAAAAA1TeXN0 ZW0gRm9sZGVyAAABAAQAAAASAAIAHk1hcmN1cyBHMzpTeXN0ZW0gRm9sZGVyOkZpbmRl cv//AAACABIAAgAzADQNADMAAmwAAgAAAAD/5P/jAf/kAAAB/+MAAAIANAACADUANg0A NQACaQAAAAQABwA3ADgNADcAA0kAAgAAAAD/4gA5/+EK/+IAGC5hZXZ0b2RvY251bGwA AIAAAAAQAGFsaXMNADkAAmwABQAAAAAAOv/gDQA6AAFvAAAAAAAA/98L/98ADTAACWZp bGVuYW1lcwAAAf/gAAAC/+EAAA0AOAADWAAAAAAAGwA7/94APA0AOwADSQAAABAAFv/d AD3/3Av/3QAIMAAEZG9pdAAAAgA9AAIAPv/bDQA+AAFvAAAAEQAS/9oL/9oABTAAAWkA AAL/2wAAAv/cAAAL/94ABTAAAWkAAA0APAABbwAAAAMABP/ZC//ZAA0wAAlmaWxlbmFt ZXMAAAIANgACAD//2A0APwACbAACAAAAAP/X/9YB/9cAAAH/1gAAAv/YAAAOAAIAAA8Q AAMABf/VAEAAQQBCAEMB/9UAABAAQAAD/9T/0//SC//UAAgwAARkb2l0AAAK/9MAGC5h ZXZ0b2RvY251bGwAAIAAAAAQAGFsaXMK/9IAGC5hZXZ0b2FwcG51bGwAAIAAAACQACoq KioOAEEABxD/0QAU/9D/zwBEAEX/zgv/0QAIMAAEZG9pdAAADv/QAAIE/80ARgP/zQAB DgBGAAEA/8wL/8wACjAABm15ZmlsZQAAAv/PAAAQAEQAAf/LC//LAAowAAZteWZpbGUA ABAARQAFADIAJP/KACz/yQr/ygAECmFzdHkK/8kABApmY3J0Ef/OABPgEgAP4aDiLEZP 46DkLEZPUFUPDgBCAAcQ/8gAOP/H/8YARwBI/8UK/8gAGC5hZXZ0b2RvY251bGwAAIAA AAAQAGFsaXML/8cADTAACWZpbGVuYW1lcwAAAv/GAAAQAEcAAv/E/8ML/8QADTAACWZp bGVuYW1lcwAAC//DAAUwAAFpAAAQAEgABP/C/8H/wP+/Cv/CAAQKa29jbAr/wQAECmNv YmoK/8AAGC5jb3JlY250ZSoqKioAAAAAAAAQACoqKioL/78ACDAABGRvaXQAABH/xQAc FwAaoFvg4WwMAAJraBsAASqhaysAA1tPWf/0Dw4AQwAHEP++AEn/vf+8AEoAS/+7Cv++ ABguYWV2dG9hcHBudWxsAACAAAAAkAAqKioqDQBJAAFrAAAAAAAOAEwCAEwAAgAFAE0C AE0AAgAK/7oC/7oAAAH/vQAAAv+8AAAQAEoAABAASwAD/7n/uP+3Cv+5ABguc3lzb3N0 ZGZhbGlzAAAAAP//gABudWxsC/+4AAowAAZteWZpbGUAAAv/twAIMAAEZG9pdAAAEf+7 AA8qagwAAEXRTyrBaysAAg8AYXNjcgABAA363t6tAAAAFAA1AAcBtgF3ADUABwGwAm0A AAAAAAABAAAACjwAAAk8AAAARgepQJwhDgAAABwARgABc2NwdAAAABJXUG9zAAAAHgCA //8AAAAAB6k+HACA//8AAAkkB6lAmA== --============_-1185716285==_============-- From fpierfed@eso.org Fri Jul 12 10:13:54 2002 From: fpierfed@eso.org (Francesco Pierfederici) Date: Fri, 12 Jul 2002 11:13:54 +0200 Subject: [Pythonmac-SIG] Macho python: os.popen3 hangs Message-ID: Hi everybody, I'm using macho-python on a MacOSX 10.1.5 box (I installed the wxPython version of Python). I noticed that using os.popen3 to read the stderr of a system command, makes the python interpreter hang. Did anybody experience anything like this? Thanks Fra astarte> python -v # /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/site.pyc matches /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/site.py import site # precompiled from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/site.pyc # /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/os.pyc matches /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/os.py import os # precompiled from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/os.pyc import posix # builtin # /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/posixpat h.pyc matches /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/posixpat h.py import posixpath # precompiled from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/posixpat h.pyc # /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/stat.pyc matches /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/stat.py import stat # precompiled from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/stat.pyc # /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/UserDict .pyc matches /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/UserDict .py import UserDict # precompiled from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/UserDict .pyc # /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/copy_reg .pyc matches /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/copy_reg .py import copy_reg # precompiled from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/copy_reg .pyc # /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/types.py c matches /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/types.py import types # precompiled from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/types.py c # /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/__future __.pyc matches /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/__future __.py import __future__ # precompiled from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/__future __.pyc # /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/sitecust omize.pyc matches /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/sitecust omize.py import sitecustomize # precompiled from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/sitecust omize.pyc Python 2.2.1 (#14, Apr 17 2002, 11:23:23) [GCC 2.95.2 19991024 (release)] on darwin Type "help", "copyright", "credits" or "license" for more information. import readline # dynamically loaded from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/lib-dynl oad/readline.so >>> import os >>> (d, o, e) = os.popen3('diff /Users/fpierfed/.subscriptions/AAS/AAS /Users/fpierfed/.subscriptions/AAS/AAS.temp') # /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/popen2.p yc matches /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/popen2.p y import popen2 # precompiled from /Library/Frameworks/Python.framework/Versions/Current/lib/python2.2/popen2.p yc >>> e.readlines() And then a ^C results in the usual Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> From erik@letterror.com Fri Jul 12 12:34:04 2002 From: erik@letterror.com (Erik van Blokland) Date: Fri, 12 Jul 2002 13:34:04 +0200 Subject: [Pythonmac-SIG] findertools.move In-Reply-To: Message-ID: I noticed something odd with findertools.move in python 2.2.1c2, both in OSX 10.1.5 and Classic 9.2.2. The finder performs the move alright but Python raises an error anyway. The exception reads: aetools.Error: (0, 'component result = no error', None) The exception is raised in line 292 in StdSuites.Standard_Suite, in the move method: if _arguments.has_key('errn'): raise aetools.Error, aetools.decodeerror(_arguments) Maybe this line should check what exactly the content of _arguments['errn'] is before being upset about it? Erik van Blokland From jay@heynow.com Fri Jul 12 14:09:43 2002 From: jay@heynow.com (Jay Koutavas) Date: Fri, 12 Jul 2002 09:09:43 -0400 Subject: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon Message-ID: I've become a bit confused about the proper way to embed Python into an OS X Carbon application. Perhaps someone could give a simple step-by-step procedure to do this? Here's what I want to do: ------------------------- Embed Python into my OS X Carbon application and access Python via a command shell window of my own devising. I don't want to use the SIOUX console at all. Python will be contained in a shared library. If the library is present, my application is python enabled. If the shared library is not present, no python (I do a weak link to the shared library and determine at launch time if I'm going to provide python support.) My python embed requires no mac-specific modules. I'm using it for automated unit testing of my application's C++ data model. What I ran into: --------------- The embed demo suggests that I use PythonCore as my shared library, and if I want to disable the SIOUX console, simply use the PyMac_SetConsoleHandler(). However, the PyMac_SetConsoleHandler() assumes you are using some form of GUSI, and in order to build the PythonCore, you need GUSI. I don't want GUSI. I'm on OS X. OS X provides all GUSI could ever provide, plus more. Additionally, I don't want to provide resources for configuring Python, I'd rather configure python in the standard Unix way with environment variables. I noted that macmain.c makes lots of resource fork assumptions. The Question is: --------------- So, I *think* this is the question I need to ask you all: ``How does one generate a python shared library for Mac OS X Carbon usage that doesn't require GUSI, nor does it use SIOUX? i.e. How to do unix-style Python on an OS X box?'' I'm really interested in Python on the Mac and have been following this conference for years. Embedding Python on Mac OS X Carbon, I think, should easily be equal to the ease of embedding Python on any generic Unix box, agreed? ... and perhaps that ease of embedding already exists and I simply need a gentle "look right here!" and my confusion on this matter will subside. :) Thank you very much to whom ever provides me the answer to this. Best, /Jay -- ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Jay Koutavas mailto:jay@heynow.com Heynow Software http://www.heynow.com Windham, New Hampshire, USA ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' From just@letterror.com Fri Jul 12 16:06:38 2002 From: just@letterror.com (Just van Rossum) Date: Fri, 12 Jul 2002 17:06:38 +0200 Subject: [Pythonmac-SIG] findertools.move In-Reply-To: Message-ID: Erik van Blokland wrote: > > I noticed something odd with findertools.move in python 2.2.1c2, both in > OSX 10.1.5 and Classic 9.2.2. The finder performs the move alright but > Python raises an error anyway. The exception reads: > > aetools.Error: (0, 'component result = no error', None) > > The exception is raised in line 292 in StdSuites.Standard_Suite, in the > move method: > > if _arguments.has_key('errn'): > raise aetools.Error, aetools.decodeerror(_arguments) > > Maybe this line should check what exactly the content of > _arguments['errn'] is before being upset about it? It's a known issue, and I think Jack fixed it: http://www.python.org/sf/493826 Just From welch@cs.unc.edu Fri Jul 12 16:20:14 2002 From: welch@cs.unc.edu (Greg Welch) Date: Fri, 12 Jul 2002 11:20:14 -0400 Subject: [Pythonmac-SIG] python package module name collision Message-ID: I am using Python 2.2.1-6 (from Fink) on OS X 10.1.5. A colleague (Gary Bishop) and I have found what seems to be a bug in that version of Python on the Mac. I have verified it in the stock tgz release of 2.2.1. The problem does not seem to occur w/ the same Python under Windows (Cygwin). I have made a tiny tgz archive with code that illustrates the problem. The file is at http://mac-welch.cs.unc.edu/~welch/tmp/samename.tgz Just unpack, "cd samename," and "sudo python setup.py install." The problem occurs when (it seems) if you have two *different* extension packages ("Package_1" and "Package_2" in my example) that use different shared library modules that have the *same* name ("samename.so" in my example). If you import "Package_1" Python loads *its* respective "samename" module just fine. However if you then load "Package_2" Python does *not* load *its* "samename" module. It apparently thinks it has already has "samename" leftover from the previous load of "Package_1". FYI, I discovered the problem when trying to build PyOpenGL, which I think I successfully did, working from the PyOpenGL part of Bob Ippolito's "ultramega" source package (http://redivi.com/~bob/). Unfortunately the PyOpenGL code (we discovered) has shared libraries called "__init___.so" in *both* the OpenGL.GL and OpenGL.GLU Here is example session where I import Package_1, then Package_2, then restart python and import in the opposite order. In each case you can see second import runs the same init module. [mac-welch] welch% python Python 2.2.1 (#1, 07/10/02, 10:09:28) [GCC Apple cpp-precomp 6.12] on darwin Type "help", "copyright", "credits" or "license" for more information. Welcome to Lazy Python. Type "help LazyPython" for help. >>> import Package_1 Init samename from Package_1 >>> import Package_2 Init samename from Package_1 >>> [mac-welch:lib/python2.2/site-packages] welch% python Python 2.2.1 (#1, 07/10/02, 10:09:28) [GCC Apple cpp-precomp 6.12] on darwin Type "help", "copyright", "credits" or "license" for more information. Welcome to Lazy Python. Type "help LazyPython" for help. >>> import Package_2 Init samename from Package_2 >>> import Package_1 Init samename from Package_2 >>> [mac-welch] welch% ________ Gregory F. Welch Research Associate Professor Department of Computer Science University of North Carolina at Chapel Hill http://www.cs.unc.edu/~welch welch@cs.unc.edu 919-962-1819 From alexp@strata.com Fri Jul 12 17:06:16 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Fri, 12 Jul 2002 09:06:16 -0700 Subject: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon References: Message-ID: <003101c229be$0dbf96a0$0300a8c0@veropc> > I'm really interested in Python on the Mac and have been following > this conference for years. Embedding Python on Mac OS X Carbon, I > think, should easily be equal to the ease of embedding Python on any > generic Unix box, agreed? Depend if you want to use CFM instead of Mach-O. If you prefer the first one, you are out of luck and you will need Gusi/SIOUX. If you use the second one, you need MacPython for Mach-O compiled and installed as a framework, and that's it. You can look at the latest source code of MacCvs (cvsgui on SourceForge), it has the ability to optionnaly load Python for both CFM and Mach-O. alex. > > ... and perhaps that ease of embedding already exists and I simply > need a gentle "look right here!" and my confusion on this matter will > subside. :) > > Thank you very much to whom ever provides me the answer to this. > > > Best, > > /Jay > > > -- > ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' > Jay Koutavas mailto:jay@heynow.com > Heynow Software http://www.heynow.com > Windham, New Hampshire, USA > ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From tony@lownds.com Fri Jul 12 17:08:20 2002 From: tony@lownds.com (Tony Lownds) Date: Fri, 12 Jul 2002 09:08:20 -0700 Subject: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon In-Reply-To: References: Message-ID: Hi Jay, You have two options with Python 2.1 and 2.2. The first is to build a framework Python: ./configure --enable-framework; sudo make frameworkinstall Then, in your app use the Python framework. 1. #include Python's Embedding docs always says #include "Python.h"; if your code uses that, add -I/Library/Frameworks/Python.framework/Headers to your compile command 2. compile and link with -F Python This is not really "weak linking", good luck with that aspect (I haven't tried it) The second option is to build a static libpython.a and link it right into your app. As I understand it this is useful when you won't need Python's standard lib, and not having a separate framework is a bonus. (Start by building python: ./configure; make; sudo make install) Bill Fancher is working on providing a third option: a shared library that does not live in a framework. -Tony At 9:09 AM -0400 7/12/02, Jay Koutavas wrote: >I've become a bit confused about the proper way to embed Python into >an OS X Carbon application. Perhaps someone could give a simple >step-by-step procedure to do this? > >Here's what I want to do: >------------------------- >Embed Python into my OS X Carbon application and access Python via a >command shell window of my own devising. I don't want to use the >SIOUX console at all. Python will be contained in a shared library. >If the library is present, my application is python enabled. If the >shared library is not present, no python (I do a weak link to the >shared library and determine at launch time if I'm going to provide >python support.) My python embed requires no mac-specific modules. >I'm using it for automated unit testing of my application's C++ data >model. > >What I ran into: >--------------- >The embed demo suggests that I use PythonCore as my shared library, >and if I want to disable the SIOUX console, simply use the >PyMac_SetConsoleHandler(). However, the PyMac_SetConsoleHandler() >assumes you are using some form of GUSI, and in order to build the >PythonCore, you need GUSI. > >I don't want GUSI. I'm on OS X. OS X provides all GUSI could ever >provide, plus more. > >Additionally, I don't want to provide resources for configuring >Python, I'd rather configure python in the standard Unix way with >environment variables. I noted that macmain.c makes lots of resource >fork assumptions. > >The Question is: >--------------- >So, I *think* this is the question I need to ask you all: > >``How does one generate a python shared library for Mac OS X Carbon >usage that doesn't require GUSI, nor does it use SIOUX? i.e. How to >do unix-style Python on an OS X box?'' > >I'm really interested in Python on the Mac and have been following >this conference for years. Embedding Python on Mac OS X Carbon, I >think, should easily be equal to the ease of embedding Python on any >generic Unix box, agreed? > >... and perhaps that ease of embedding already exists and I simply >need a gentle "look right here!" and my confusion on this matter >will subside. :) > >Thank you very much to whom ever provides me the answer to this. > > >Best, > >/Jay > > >-- >''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' > Jay Koutavas mailto:jay@heynow.com > Heynow Software http://www.heynow.com > Windham, New Hampshire, USA >''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.com Fri Jul 12 23:00:29 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 13 Jul 2002 00:00:29 +0200 Subject: [Pythonmac-SIG] python package module name collision In-Reply-To: Message-ID: On vrijdag, juli 12, 2002, at 05:20 , Greg Welch wrote: > I am using Python 2.2.1-6 (from Fink) on OS X 10.1.5. A colleague (Gary > Bishop) and I have found what seems to be a bug in that version > of Python on > the Mac. I have verified it in the stock tgz release of 2.2.1. > The problem > does not seem to occur w/ the same Python under Windows (Cygwin). > > I have made a tiny tgz archive with code that illustrates the > problem. The > file is at > > http://mac-welch.cs.unc.edu/~welch/tmp/samename.tgz > > Just unpack, "cd samename," and "sudo python setup.py install." > > The problem occurs when (it seems) if you have two *different* > extension > packages ("Package_1" and "Package_2" in my example) that use different > shared library modules that have the *same* name ("samename.so" in my > example). This will be fixed in 2.3 (and is already fixed if you build Python from CVS). It cannot be fixed in the 2.2.X series, however, because the fix breaks some programs, and that is disallowed for minor version unless you can convincingly prove that the programs were broken anyway (I believe they were, but I wasn't convincing enough:-). There are sets of extension modules out there that belong together and think they can access each others global symbols, i.e. if you have a module second.so which refers to symbols defined in first.so and you load first first and second afterwards it will magically work. I'm using PyOpenGL on OSX with the CVS head, and it works fine (well, except for stereo, but that's a whole different issue. If you happen to be working on stereo too I'd like a hand there:-) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Fri Jul 12 23:06:01 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 13 Jul 2002 00:06:01 +0200 Subject: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon In-Reply-To: <003101c229be$0dbf96a0$0300a8c0@veropc> Message-ID: <8D96DDD2-95E3-11D6-B444-003065517236@oratrix.com> On vrijdag, juli 12, 2002, at 06:06 , Alexandre Parenteau wrote: > If you use the second one, you need MacPython for Mach-O compiled and > installed as a framework, and that's it. > > You can look at the latest source code of MacCvs (cvsgui on > SourceForge), it > has the ability to optionnaly load Python for both CFM and Mach-O. Alexandre, is Python actually optional for MacCVS? Do you do some sort of dynamic loading of the Python framework? If you do I think the code would make a nice example, could it be separated out of Maccvs into a small sample program? And to Jay: I agree with Tony and Alexandre: forget about MacPython and go for the unix Python. If you're on OSX only there's no reason to bother with CFM and GUSI if you don't have to. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From alexp@strata.com Sat Jul 13 00:21:07 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Fri, 12 Jul 2002 16:21:07 -0700 Subject: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon In-Reply-To: <8D96DDD2-95E3-11D6-B444-003065517236@oratrix.com> Message-ID: Jack, > is Python actually optional for MacCVS? Do you do some sort of > dynamic loading of the Python framework? If you do I think the Exactly, same thing on Windows, CFM and Mach-O. For Windows it uses 'LoadLibrary', for CFM it uses the weak import capability of CFM, and finally for Mach-O it uses CFBundleCreate, CFBundleLoadExecutable and CFBundleGetFunctionPointerForName. The problem with this method is that you have to overload all the Python functions with macros that get function pointer instead. This is especially bad for structures exported (like PyNone), because you need to use an accessor instead. One thing Guido should consider would be to do what did TCL at some point (only it would be nice to make it so it works ;-)): provide from within the Python headers some mean of using optionally a glue code executed on the client side in order to provide dynamic loading. I have all the source code to do that, it only is a huge change to the Python headers. Beside I was thinking this could lead to another development I have been dreaming for months : being able to make a CFM Python module and use it along with a Python Mach-O executable : would be awesome for legacy components of companies like mine. But this is out of the figure for now. > code would make a nice example, could it be separated out of > Maccvs into a small sample program? Not small, but separable yes ! I need to speak with you before in order to get a sense of the kind of compiler environment you want that for. In MacCvs: the dynamic loading for mac is inside cvsgui/common/TclGlue.mac.cpp (nothing to do with TCL in fact, but it was my first test for dynamic loading). Now the macros that override a small amount of the Python functions are inside cvsgui/common/PythonGlue.impl.h. The ongoing Python integration for WinCvs/MacCvs is inside PythonGlue.cpp. Alex. > > And to Jay: I agree with Tony and Alexandre: forget about > MacPython and go for the unix Python. If you're on OSX only > there's no reason to bother with CFM and GUSI if you don't have > to. > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- > Emma Goldman - > > From sdm7g@mac.com Sat Jul 13 02:59:55 2002 From: sdm7g@mac.com (Steven Majewski) Date: Fri, 12 Jul 2002 21:59:55 -0400 Subject: [Pythonmac-SIG] stack limit for test_re Message-ID: <3A838204-9604-11D6-8F24-003065A7CFBA@mac.com> This is the python equivalent of doing 'limit stack 2048' in tcsh before running test_re: from resource import * soft, hard = getrlimit( RLIMIT_STACK ) setrlimit( RLIMIT_STACK, (1024 * 2048, hard)) from test import test_re It would be nice to fix this in the test suite, but I'm not quite sure where to stick it. ( As a conditional in test_re ? ) -- Steve Majewski From jadams@climax.co.uk Sat Jul 13 11:36:22 2002 From: jadams@climax.co.uk (Julian Adams) Date: Sat, 13 Jul 2002 11:36:22 +0100 Subject: [Pythonmac-SIG] Extensions for static versus framework MachoP ython Message-ID: > > [I hadn't replied to your mods yet, as I didn't get around > to it, but I > > might as well do so now] > > > > I know, but it has a major problem in that -flat_namespace > will take any > > symbol with the correct name and simply assume it is the > symbol needed. > > This is an accident waiting to happen, and I'm heavily > opposed to it. I > > know that for unix-Python this is the norm, but it leads to > very obscure > > bugs. > > But we'd have lots of good company... > > > > And note that these bugs aren't theoretical, either. I've > been bitten by > > it twice over the years, once because both SGI's original > GL library and > > curses had a clear() function, and once because the SGI compression > > library contained a modified version of the IJG JPEG library with > > unmodified external names so anything that was linked > against the normal > > jpeg library would be dead. > > If something fails everywhere else, it should, by default, > fail on a Mac. > If we have special Mac machinery that would allow it to > succeed, we should > engage that machinery consciously and be aware that software > depending on > such Mac specific features isn't portable. IMO, the default > installation > should be bug compatible across platforms. > that's never necessarily going to be the case. ms windows dll's work in a different way to mac / unix frameworks / shared objects, and some knowledge / support is required to make code work on all platforms > We can always tweak various things for the binary distribution, which > should cater to the majority, and we might find, e.g., that > most people > want two-level namespaces. Such adjustments can be made at > build time by > setting environment variables. or configure script options ? > > > > > The first case (some Python script importing both the gl and curses > > modules) happened in exactly one Python script in the world: > > test.regrtest. The second case was really nasty, though, > because image > > processing apps might easily import both PIL and cl without > being aware > > of it. I'm very glad that MacPython has never had these > problems (because > > external symbol and library are matched up), and so when > Apple made this > > functionality available for OSX with the two-level namespaces I > > immediately jumped on the bandwagon. > > There's no compelling reason I can see to get off the > bandwagon. The price > of admission is that the libs you link against are going to > get loaded > along with the module. The main library doesn't care how modules are > linked. > > One reason the "two Pythons" problem even comes up is that > there are now > two fundamentally different ways to install Python, resulting > in two sets > of everything. I think this is a bad situation. We can avoid the > duplication with linked frameworks. although you later quoted precedent for linked frameworks from apple they do kill one of the big advantages of frameworks (to the user) - deleting frameworks removes all the associated files. IMHO frameworks are Apples alternative (and equally) neat solution to package management. over a long period of time every unix box I've ever worked on has build up a cruft of homebuild files in /usr/local, uncontrolled by any packaging system, and it would be good to avoid this, especially if Apple provide a viable system. i agree it's ugly to have 2 pythons, but in some ways Mac OS X is 2 operating systems, or layers: UNIX + NEXT. while you could treat a Mac box as a vanilla unix box this deprives you from a whole raft of goodies which make Mac OS, well, Mac OS. personally I think Macho Python should exploit all those goodies by default, from a source build. otherwise it won't be a first class player in the Mac world. it shouldn't be difficult to optionally maintain / build a lowest common denominator unix version. some people will want this (e.g. to develop fully portable scripts),but I doubt it would be a majority. > > > > > But again: if enough people here feel that the benefits of > > -flat_namespace outweigh these problems, please speak up! > I'm always will > > to (grudgingly:-) bend to the majority... > > I think cross platform modules should, by default, be linked > to behave as > they do on other platforms even if that means behaving badly > in some ways. > Mac docs should note the default, outline its practical > consequences, > mention the workarounds possible on Mac OS X, and remind users that > software depending on these platform specific tricks is not portable. > you might guess that I think we should use Mac specific stuff, to prevent the issues outlined above, as long as it doesn't generally cause other platforms problems. > For Mac only stuff like the binary distribution, just link > the best way. > We have complete control over the Mac only build process and > how things > get compiled for the binary distribution. I thinks it's important for it to be as easy as possible to build the binary distribution from source, as easy as on a unix platform. Probably the full Mac version would be the default, as most Mac people would want this. The unix version would be a configure option. It strikes me that a "vanilla" unix build would be rather crippled, as there is no X server / TK on Mac by default. > > In keeping with the trend toward a "standard" Macho binary > distribution, > which I applaud, I suggest the first step should be to move > all the mac > specific stuff (or as much as we can) out of the core build > mechanism. In > particular, there should be no hint of frameworks there. On a > Mac, running > "./configure; make; make install" should produce what we'd > expect on any > other *NIX: a library in /usr/local/lib etc. Call this the "generic" > installation. > you might guess by now that I disagree with this ... > The Mach-O binary distribution should, IMO, install over the generic > installation. (Or it could do the generic installation as a > first step. > Whatever.) We might want a minimal "Darwin only" option and a > "Mac OS X" > option to install pieces that link to libraries not found on Darwin. ... and also with this ! why should the Macho distribution be primarily binary ? since the source would be available I guess you mean "non standard or hard to build", which would suck. > > I would urge that supporting two totally different > installation schemes > such as "standard" and "real framework" is asking for trouble. > > A linked framework would make the Mac binary distribution an > Installer > package, but I'd note that Apple recommends drag and drop > only for "simple" > installations. If uninstallation is a requirement, we can > provide an > "Uninstall" option with the package. having a self contained package would void any need for an installer :) > > > > The question is really one of "should MachoPython behave > like a Macintosh > > package or like a unix package", and my answer would be > "like a Macintosh > > package". > oh yeah ! ...these are observations of a unix guy, who's a Mac OS X convert. julian From bob@redivi.com Sat Jul 13 13:53:17 2002 From: bob@redivi.com (Bob Ippolito) Date: Sat, 13 Jul 2002 08:53:17 -0400 Subject: [Pythonmac-SIG] python package module name collision In-Reply-To: Message-ID: <80A43598-965F-11D6-A128-0003938210D6@redivi.com> I had fixed this issue in my version of Python by using apple's libdl wrapper (they call it libcompat or something) and dynload_shlib instead of the NeXT one.. but, I was pretty sure that they fixed dynload_next a couple months ago? I definitely brought this one up on the python lists around December/January, I'd imagine such an important issue would be fixed by now. -bob On Friday, July 12, 2002, at 11:20 AM, Greg Welch wrote: > I am using Python 2.2.1-6 (from Fink) on OS X 10.1.5. A colleague (Gary > Bishop) and I have found what seems to be a bug in that version of > Python on > the Mac. I have verified it in the stock tgz release of 2.2.1. The > problem > does not seem to occur w/ the same Python under Windows (Cygwin). > > I have made a tiny tgz archive with code that illustrates the problem. > The > file is at > > http://mac-welch.cs.unc.edu/~welch/tmp/samename.tgz > > Just unpack, "cd samename," and "sudo python setup.py install." > > The problem occurs when (it seems) if you have two *different* extension > packages ("Package_1" and "Package_2" in my example) that use different > shared library modules that have the *same* name ("samename.so" in my > example). > > If you import "Package_1" Python loads *its* respective "samename" > module > just fine. However if you then load "Package_2" Python does *not* load > *its* > "samename" module. It apparently thinks it has already has "samename" > leftover from the previous load of "Package_1". > > FYI, I discovered the problem when trying to build PyOpenGL, which I > think I > successfully did, working from the PyOpenGL part of Bob Ippolito's > "ultramega" source package (http://redivi.com/~bob/). Unfortunately the > PyOpenGL code (we discovered) has shared libraries called > "__init___.so" in > *both* the OpenGL.GL and OpenGL.GLU > > Here is example session where I import Package_1, then Package_2, then > restart python and import in the opposite order. In each case you can > see > second import runs the same init module. > > [mac-welch] welch% python > Python 2.2.1 (#1, 07/10/02, 10:09:28) > [GCC Apple cpp-precomp 6.12] on darwin > Type "help", "copyright", "credits" or "license" for more information. > Welcome to Lazy Python. Type "help LazyPython" for help. >>>> import Package_1 > Init samename from Package_1 >>>> import Package_2 > Init samename from Package_1 >>>> > [mac-welch:lib/python2.2/site-packages] welch% python > Python 2.2.1 (#1, 07/10/02, 10:09:28) > [GCC Apple cpp-precomp 6.12] on darwin > Type "help", "copyright", "credits" or "license" for more information. > Welcome to Lazy Python. Type "help LazyPython" for help. >>>> import Package_2 > Init samename from Package_2 >>>> import Package_1 > Init samename from Package_2 >>>> > [mac-welch] welch% > > > ________ > > Gregory F. Welch > Research Associate Professor > Department of Computer Science > University of North Carolina at Chapel Hill > http://www.cs.unc.edu/~welch > welch@cs.unc.edu > 919-962-1819 > > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From erik@letterror.com Sat Jul 13 15:02:20 2002 From: erik@letterror.com (Erik van Blokland) Date: Sat, 13 Jul 2002 16:02:20 +0200 Subject: [Pythonmac-SIG] findertools.move In-Reply-To: Message-ID: just@letterror.com (Just van Rossum): [12:7:02 at 17:06] > Erik van Blokland wrote: > >> >> I noticed something odd with findertools.move >> in python 2.2.1c2, both in OSX 10.1.5 and >> Classic 9.2.2. The finder performs the move >> alright but Python raises an error anyway. The >> exception reads: >> >> aetools.Error: (0, 'component result = no >> error', None) >> >> The exception is raised in line 292 in >> StdSuites.Standard_Suite, in the move method: >> >> if _arguments.has_key('errn'): raise >> aetools.Error, aetools.decodeerror(_arguments) >> >> Maybe this line should check what exactly the >> content of _arguments['errn'] is before being >> upset about it? > > It's a known issue, and I think Jack fixed it: > > http://www.python.org/sf/493826 > > Just from the bugtrack page above: > Date: 2002-05-23 15:05 > Sender: jackjansen > Logged In: YES > user_id=45365 > > Fixed a while ago (the fix is already in 2.2.1) Uh, as far as I can tell: the fix is not in the 2.2.1 release. I can work around this bug and I know there are bigger problems to tackle at the moment. But I thought I'd mention it. Erik van Blokland From jay@heynow.com Sat Jul 13 19:23:45 2002 From: jay@heynow.com (Jay Koutavas) Date: Sat, 13 Jul 2002 14:23:45 -0400 Subject: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon Message-ID: [Although this email is slightly off-topic (it goes into some specifics about building MacCVS), I think it's worth adding to the public thread I've started on this subject. Note, the troubles I'm seeing with building MacCVS are *not* indicative of the quality of MacCVS. I've used MacCVS before and can say it's a very worthy CVS client. More accurately, they're indicative of missing information I have as I come up to speed on the subject of building MacCVS and Python. With that all said, here's my next email on this subject, which contains additional information on what I'm trying to achieve with my Python embed. /Jay] Alex, Thank you for your emails on this subject. One thing I realized, after reading the thread was that I didn't clarify the target of my OS X Carbon application. It's CFM, not Mach-O. The reason I am CFM-targeted is that my application needs to also run on Mac OS 9. Single binary. It is not a requirement that the application supports Python when running on OS 9, thus the weak link I spoke of in my opening email. Also, for sake of providing possible missing useful information, I'm using CodeWarrior 7.2 as my development environment. My C/C++ application also runs on Windows, and am using CodeWarrior there too. I learned from this thread that if I'm going to embed Carbon Python into a CFM application running on Mac OS X, I'll either have to use GUSI, or I'll have to do the rather tedious Mach-O --> CFM wrapping technic you outlined in this email. I've done this sort of wrapping for specific Quartz calls, so I am familiar with it. So, I looked over MacCVS. First, I build MacCVS 3.2 Carbon from sources and built Python 2.2.1's PythonCarbonLib and dropped it into the same folder as the MacCVS application. Launching MacCVS on Mac OS X 10.1.5, I found the following two problems: 1) the console window that you provide comes up under macCVS's toolbar. I see no way to get it moved into the foreground 2) MacCVS is suffering from the "dual menubar problem" -- where SIOUX (via PythonCarbonLib) is presenting it's own rendition of the main menu to the right of MacCVS's, resulting in an unusable application. At this point I thought I'd better get the latest sources, and did a full CVS get of MacCVS. I built the Carbon target of MacCVS with minimum fuss (there's a broken copy of getdate.c in CVS at the moment) and dropped my same copy of PythonCarbonLib into the application's folder. MacCVS from latest sources won't launch. What happens is it brings up a dialog stating that no debugger was found and that it's not a fatal thing, but then silently the application quits. I then tried to make the Mach-O target of MacCVS from latest sources. When launching it, there's a dialog saying "You need to put PythonCarbonLib into the application folder to get python support." I have one there. The MacCVS Mach-o application doesn't recognize it. My questions: 1) How do I get MacCVS Mach-o to run with Python via latest sources? 2) (the question I was persuing at the start of this) Should I attempt to follow your lead and wrap Python-Mach-O calls for use in my CFM application? How much work is it? Will it be a mere matter of copy/pasting your work? Best, /Jay -- ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Jay Koutavas mailto:jay@heynow.com Heynow Software http://www.heynow.com Windham, New Hampshire, USA ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' From alexp@strata.com Sat Jul 13 19:48:52 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Sat, 13 Jul 2002 11:48:52 -0700 Subject: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon References: Message-ID: <000e01c22a9d$ef44f0e0$0300a8c0@veropc> Hello all, I promise I will try to do something over the week-end to help people embed on OSX/Classic. I'll keep the list posted. > One thing I realized, after reading the thread was that I didn't > clarify the target of my OS X Carbon application. It's CFM, not > Mach-O. The reason I am CFM-targeted is that my application needs to > also run on Mac OS 9. Single binary. It is not a requirement that the > application supports Python when running on OS 9, thus the weak link OK. MacCvs does that with the CFM target. For the CFM target, it uses CFM Python. But it could use Mach-O Python selectively for OSX only. Doing that would suppose you do the kind of manual function binding. I believe you have all you need inside the MacCvs source code to get started. > I spoke of in my opening email. Also, for sake of providing possible > missing useful information, I'm using CodeWarrior 7.2 as my > development environment. My C/C++ application also runs on Windows, > and am using CodeWarrior there too. This is my current config. > I learned from this thread that if I'm going to embed Carbon Python > into a CFM application running on Mac OS X, I'll either have to use > GUSI, or I'll have to do the rather tedious Mach-O --> CFM wrapping > technic you outlined in this email. I've done this sort of wrapping > for specific Quartz calls, so I am familiar with it. Exactly. > So, I looked over MacCVS. First, I build MacCVS 3.2 Carbon from > sources and built Python 2.2.1's PythonCarbonLib and dropped it into > the same folder as the MacCVS application. Launching MacCVS on Mac OS > X 10.1.5, I found the following two problems: I'm not sure anymore you want to drop it : you actually want to launch the Python installer which will add aliases inside your system folders and other things. This is my config on OSX. > 1) the console window that you provide comes up under macCVS's > toolbar. I see no way to get it moved into the foreground Oh yeah. It is a bug at the moment.... Try to open a browser, quit and restart. > 2) MacCVS is suffering from the "dual menubar problem" -- where SIOUX > (via PythonCarbonLib) is presenting it's own rendition of the main > menu to the right of MacCVS's, resulting in an unusable application. This is not normal at all. I worked with Jack on this problem and thought it was fixed on 2.2.1. Please make sure you don't have bad Python aliases in your folder, try to re-do the Python install. > I then tried to make the Mach-O target of MacCVS from latest sources. > When launching it, there's a dialog saying "You need to put > PythonCarbonLib into the application folder to get python support." I > have one there. The MacCVS Mach-o application doesn't recognize it. It is a wrong message, because Mach-O python is using the python framework (Mach-O) indeed. > 1) How do I get MacCVS Mach-o to run with Python via latest sources? You need Python-Mach-O installed as a framework. I just found out there is an installer for it : just visit wxPython on SourceForge (www.sf.net/projects/wxpython). It is named MachO-Python. > 2) (the question I was persuing at the start of this) Should I > attempt to follow your lead and wrap Python-Mach-O calls for use in > my CFM application? How much work is it? Will it be a mere matter of > copy/pasting your work? It's not bad, considering you also did similar things for Quartz. Once again you have the choice on OSX-CFM : - Use CFM-Python, but GUSI is in the way, which means possible slow downs, strange socket locking, poor SMP support (none of these are really GUSI or Python fault BTW, it is more CFM which sucks). - Use Mach-O Python but it is complicated because you need to do a manual binding of the functions, you need to use the infamous Mach-O/CFM wrapper pointer function when handing function pointers to Python, and I don't have a concrete example of that, although all this code is partially implemented in MacCvs. alex. > > Best, > > /Jay > > -- > ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' > Jay Koutavas mailto:jay@heynow.com > Heynow Software http://www.heynow.com > Windham, New Hampshire, USA > ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From sdm7g@mac.com Sun Jul 14 16:33:18 2002 From: sdm7g@mac.com (Steven Majewski) Date: Sun, 14 Jul 2002 11:33:18 -0400 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] Proof of concept - Cocoa Python applet with Interface Builder! In-Reply-To: Message-ID: <05CC1641-973F-11D6-8E29-003065A7CFBA@mac.com> Jack, I tried out your nibpythonexample code: I got around the problem with the scripts directory that's already been noted. On trying to build the CurrencyConverterPY, I get: Can't get DLOG resource with id = 260 Do you happen to know where that resource is supposed to come from ? It's nice to see that my pyobjc "HelloWorld" works by dropping the script on the Python.app icon, as well as some Carbon examples like EasyDialogs. Donovan said that running from the Framework and/or Bundled App fixes some of the other problems I ran into with Cocoa (like the Menu problems caused by not having a MainMenu.nib) -- I'll go back and give a few of my failed experiments another try. I've started doing diffs of your modified pyobjc against cvs and will review the patches ASAP. -- Steve From Jack.Jansen@cwi.nl Mon Jul 15 10:25:34 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 15 Jul 2002 11:25:34 +0200 Subject: [Pythonmac-SIG] stack limit for test_re In-Reply-To: <3A838204-9604-11D6-8F24-003065A7CFBA@mac.com> Message-ID: On Saturday, July 13, 2002, at 03:59 , Steven Majewski wrote: > This is the python equivalent of doing 'limit stack 2048' in tcsh > before running test_re: > > from resource import * > soft, hard = getrlimit( RLIMIT_STACK ) > setrlimit( RLIMIT_STACK, (1024 * 2048, hard)) > from test import test_re > > It would be nice to fix this in the test suite, but I'm not > quite sure where to stick it. ( As a conditional in test_re ? ) > Yes, I think I'd put it in test_re. Inside an 'if platform == "darwin"'. And also protected against resource not being available. Could you put a patch up on sourceforge? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Mon Jul 15 10:36:31 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 15 Jul 2002 11:36:31 +0200 Subject: [Pythonmac-SIG] findertools.move In-Reply-To: Message-ID: <58572B78-97D6-11D6-8A31-0030655234CE@cwi.nl> On Saturday, July 13, 2002, at 04:02 , Erik van Blokland wrote: > >> Date: 2002-05-23 15:05 >> Sender: jackjansen >> Logged In: YES >> user_id=45365 >> >> Fixed a while ago (the fix is already in 2.2.1) > Uh, as far as I can tell: the fix is not in the 2.2.1 release. You're right: the fix was a little too late for 2.2.1. It will be in 2.2.2. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Mon Jul 15 10:54:19 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 15 Jul 2002 11:54:19 +0200 Subject: [Pythonmac-SIG] Interface Builder Carbon NIBs and Python Message-ID: Has anyone tried to use the NIB files (and xib files and all the other stuff) that Interface Builder creates if you build an interface in Carbon mode from a Python program? Did it work? Was it a lot of work? Any code or insights to share? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From gherman@darwin.in-berlin.de Mon Jul 15 10:54:39 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Mon, 15 Jul 2002 11:54:39 +0200 (CEST) Subject: [Pythonmac-SIG] Cocoa/Python beta iPod app available Message-ID: <1026726879.3d329bdf70548@webmail.in-berlin.de> Hi again, for those hidden iPod owners among us: I've wrapped my Python library with some very light Cocoa sugar, resul- ting in a little beta app named Podpourri that you should be able to run on OS X if you have a Python 2.2.1 sitting in /usr/local/bin/python. You can download it here: http://python.net/~gherman/projects/podpourri The backend needs a little bit more work before making its more interesting features (XML and PDF output) also available from the frontend. But I've uploaded a sample (abbreviated) PDF file, so you'll see what I mean... I'd be happy about any feedback! Dinu From Chris.Barker@noaa.gov Mon Jul 15 18:24:23 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Mon, 15 Jul 2002 10:24:23 -0700 Subject: [Pythonmac-SIG] Extensions for static versus frame References: Message-ID: <3D330547.6F663603@noaa.gov> Jack et al. I've been trying to follow this conversation as best I can. I am still pretty confused about the mingled world of OS-X (is it a Mac? is it Unix? it's both!). I do think that it would be best to settle on a single version of Python for OS-X that is generally distributed as a binary, but also easy to re-build. I recently tried out the Mach-O Framework build that Robin Dunn put on the wxPython sourceforge site, and it seems to work just great. With limited testing, it seems to act like it should from the Finder, and act like Unix Python at the command line. Is there anything Unix-y that you can't do with it? If not, it seems like it should be the standard build. I understand that there are issues with whether you can use the same extensions with a Framework and non-Framework build. It seems to me that if you don't lose anything Unix-y by using a Framework build, then that could just be the standard, and it doesn't matter if extensions work the other way. If you really want to use a non-Framework build, you can always re-compile your own extensions, and a non-standard build should only be used by folks that can handle doing that anyway. For all this to work, I suppose distutils should work "as expected" with either type of build. Does it? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From jay@heynow.com Mon Jul 15 20:26:45 2002 From: jay@heynow.com (Jay Koutavas) Date: Mon, 15 Jul 2002 15:26:45 -0400 Subject: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon In-Reply-To: <000701c22a9e$349cb600$0300a8c0@veropc> References: <000701c22a9e$349cb600$0300a8c0@veropc> Message-ID: At 11:50 AM -0700 on 7/13/02, Alexandre Parenteau wrote: >Jay, > >Please type inside the MacCVs console : > >import sys >print sys.version > >2.2.1 (#133, May 8 2002, 22:24:21) [CW CARBON GUSI2 THREADS GC] > >print sys.exec_prefix > >Sources:python:dist:src: > >This will help us to see if you use the good thing. > >alex. Alex, I had the problem when using my own hacked-up build of PythonCoreCarbon myself. When I use the PythonCoreCarbon that comes in the binary installation, all works well. No double menus. Cool, so I went and used the shipping PythonCoreCarbon library with my application. It initializes well with this opening code: --- mHasPython = (Ptr) PyMac_Initialize != (Ptr)kUnresolvedCFragSymbolAddress; if( mHasPython ) { PyMac_SetConsoleHandler(PyMac_DummyReadHandler, PyMac_DummyWriteHandler, PyMac_DummyWriteHandler); PyMac_Initialize(); } --- However, shortly later, my application crashes when it attempts to load one my custom resource types, a type of resource I've been using for months before I introduced Python to the mix. If I don't make the above two calls to Python, then the error goes away. So, I thought "Maybe it's because PyMac_Initialize() is doing those couple of toolbox initialization calls (InitCursor, InitAppearanceManager), what if I took those away, will the crash also go?" So, of course, I had to build my own version of PythonCoreCarbon. When I tried to build PythonCoreCarbon "out of the box" I get GUSI compile errors. I'm using the latest GUSI, 2.2.2, downloaded from Source Forge. The compile errors, when I try to build PythonCoreCarbon are: Error : expression syntax error GUSIBasics.h line 34 ..GENERATINGCFM_is_obsolete.. Error : undefined identifier 'LMGetTicks' GUSISocket.h line 117 void CheckClose(UInt32 now = LMGetTicks()) I get the impression that GUSI 2.2.2 isn't Carbon ready. I poked around in the MacPython README file and saw mention of this: --- A special mention is deserved by Matthias Neeracher, who has written the brilliant unix-compatible GUSI I/O library, without which MacPython would not have sockets or select, and to Alexandre Parenteau, who has ported this library to Carbon. --- Did you (Alex) do tweaks to GUSI to make it Carbon friendly? Where are these tweaks, how do I apply them? Really looking forward to moving past this point. Thanks, /Jay > >----- Original Message ----- >From: "Jay Koutavas" >To: >Sent: Saturday, July 13, 2002 11:23 AM >Subject: Re: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon > > >> [Although this email is slightly off-topic (it goes into some >> specifics about building MacCVS), I think it's worth adding to the >> public thread I've started on this subject. >> >> Note, the troubles I'm seeing with building MacCVS are *not* >> indicative of the quality of MacCVS. I've used MacCVS before and can >> say it's a very worthy CVS client. More accurately, they're >> indicative of missing information I have as I come up to speed on the >> subject of building MacCVS and Python. >> >> With that all said, here's my next email on this subject, which >> contains additional information on what I'm trying to achieve with my >> Python embed. >> >> /Jay] >> >> Alex, >> >> Thank you for your emails on this subject. >> >> One thing I realized, after reading the thread was that I didn't >> clarify the target of my OS X Carbon application. It's CFM, not >> Mach-O. The reason I am CFM-targeted is that my application needs to >> also run on Mac OS 9. Single binary. It is not a requirement that the >> application supports Python when running on OS 9, thus the weak link >> I spoke of in my opening email. Also, for sake of providing possible >> missing useful information, I'm using CodeWarrior 7.2 as my >> development environment. My C/C++ application also runs on Windows, >> and am using CodeWarrior there too. >> >> I learned from this thread that if I'm going to embed Carbon Python > > into a CFM application running on Mac OS X, I'll either have to use >> GUSI, or I'll have to do the rather tedious Mach-O --> CFM wrapping >> technic you outlined in this email. I've done this sort of wrapping >> for specific Quartz calls, so I am familiar with it. >> >> So, I looked over MacCVS. First, I build MacCVS 3.2 Carbon from >> sources and built Python 2.2.1's PythonCarbonLib and dropped it into >> the same folder as the MacCVS application. Launching MacCVS on Mac OS >> X 10.1.5, I found the following two problems: >> >> 1) the console window that you provide comes up under macCVS's >> toolbar. I see no way to get it moved into the foreground >> >> 2) MacCVS is suffering from the "dual menubar problem" -- where SIOUX >> (via PythonCarbonLib) is presenting it's own rendition of the main >> menu to the right of MacCVS's, resulting in an unusable application. >> >> At this point I thought I'd better get the latest sources, and did a >> full CVS get of MacCVS. I built the Carbon target of MacCVS with >> minimum fuss (there's a broken copy of getdate.c in CVS at the >> moment) and dropped my same copy of PythonCarbonLib into the >> application's folder. MacCVS from latest sources won't launch. What >> happens is it brings up a dialog stating that no debugger was found >> and that it's not a fatal thing, but then silently the application >> quits. >> >> I then tried to make the Mach-O target of MacCVS from latest sources. >> When launching it, there's a dialog saying "You need to put >> PythonCarbonLib into the application folder to get python support." I >> have one there. The MacCVS Mach-o application doesn't recognize it. >> >> My questions: >> >> 1) How do I get MacCVS Mach-o to run with Python via latest sources? >> >> 2) (the question I was persuing at the start of this) Should I >> attempt to follow your lead and wrap Python-Mach-O calls for use in >> my CFM application? How much work is it? Will it be a mere matter of >> copy/pasting your work? >> >> Best, >> >> /Jay >> >> -- >> ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' >> Jay Koutavas mailto:jay@heynow.com >> Heynow Software http://www.heynow.com >> Windham, New Hampshire, USA >> ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> -- ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Jay Koutavas mailto:jay@heynow.com Heynow Software http://www.heynow.com Windham, New Hampshire, USA ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' From Jack.Jansen@oratrix.com Mon Jul 15 22:13:09 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 15 Jul 2002 23:13:09 +0200 Subject: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon In-Reply-To: Message-ID: Jay, you're getting up to speed on a rather complicated and convoluted build pretty quickly! Congratulations! On maandag, juli 15, 2002, at 09:26 , Jay Koutavas wrote: > Cool, so I went and used the shipping PythonCoreCarbon library > with my application. It initializes well with this opening code: > > [...] > > However, shortly later, my application crashes when it attempts > to load one my custom resource types, a type of resource I've > been using for months before I introduced Python to the mix. If > I don't make the above two calls to Python, then the error goes > away. PyMac_Initialize() opens at least one resource file. So if you're getting your resources with the "1" variation (Get1NamedResource() and such) it won't work because the Python resource file is now at the head of the list. Try UseResFile() on your own resource file after initializing Python. > When I tried to build PythonCoreCarbon "out of the box" I get > GUSI compile errors. I'm using the latest GUSI, 2.2.2, > downloaded from Source Forge. The compile errors, when I try to > build PythonCoreCarbon are: > [...] > I get the impression that GUSI 2.2.2 isn't Carbon ready. the standard GUSI isn't Carbon ready. You should load the GUSI from http://www.cwi.nl/ftp/jack/python/mac . This should be in the MacPython README file or in the :Mac:Demo:building.html documentation. Let me know if you think it needs to be more prominent. (Note that the changes for Carbon are in the GUSI repository, so if you're building GUSI from CVS you simply need to check out the right branch. Don't know the name of the branch right now, but it's something obvious like "CARBON"). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From alexp@strata.com Mon Jul 15 22:40:59 2002 From: alexp@strata.com (Alexandre Parenteau) Date: Mon, 15 Jul 2002 14:40:59 -0700 Subject: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon In-Reply-To: Message-ID: Jay, I make my best to come up with a set of examples of how to do it properly. I should have that by the ned of the week. I see you run into specific and real issues here: You need GUSI2 distributed by Jack (Jack already told why). If the SIOUX console is still showing up, try to do this prior of calling PyMac_SetConsoleHandler and PyMac_Initialize : #if TARGET_RT_MAC_CFM // work around for a bug of Python 2.2 which draws the // Sioux menu even though we have a custom console extern int console_output_state; console_output_state = 1; #endif I thought this problem was corrected in 2.2.1, but I might be wrong. MAKE SURE YOU USE the correct Python (look inside your /Library/CFMSupport folder), you may have an earlier Python 2.2 which messes the things around. Alex. > At 11:50 AM -0700 on 7/13/02, Alexandre Parenteau wrote: > >> Jay, >> >> Please type inside the MacCVs console : >> >> import sys >> print sys.version >> >> 2.2.1 (#133, May 8 2002, 22:24:21) [CW CARBON GUSI2 THREADS GC] >> >> print sys.exec_prefix >> >> Sources:python:dist:src: >> >> This will help us to see if you use the good thing. >> >> alex. > > Alex, > > I had the problem when using my own hacked-up build of > PythonCoreCarbon myself. When I use the PythonCoreCarbon that comes > in the binary installation, all works well. No double menus. > > Cool, so I went and used the shipping PythonCoreCarbon library with > my application. It initializes well with this opening code: > > --- > mHasPython = (Ptr) PyMac_Initialize != > (Ptr)kUnresolvedCFragSymbolAddress; > if( mHasPython ) > { > PyMac_SetConsoleHandler(PyMac_DummyReadHandler, > PyMac_DummyWriteHandler, > PyMac_DummyWriteHandler); > PyMac_Initialize(); > } > --- > > However, shortly later, my application crashes when it attempts to > load one my custom resource types, a type of resource I've been using > for months before I introduced Python to the mix. If I don't make the > above two calls to Python, then the error goes away. So, I thought > "Maybe it's because PyMac_Initialize() is doing those couple of > toolbox initialization calls (InitCursor, InitAppearanceManager), > what if I took those away, will the crash also go?" So, of course, I > had to build my own version of PythonCoreCarbon. > > When I tried to build PythonCoreCarbon "out of the box" I get GUSI > compile errors. I'm using the latest GUSI, 2.2.2, downloaded from > Source Forge. The compile errors, when I try to build > PythonCoreCarbon are: > > Error : expression syntax error > GUSIBasics.h line 34 ..GENERATINGCFM_is_obsolete.. > > Error : undefined identifier 'LMGetTicks' > GUSISocket.h line 117 void CheckClose(UInt32 now = LMGetTicks()) > > I get the impression that GUSI 2.2.2 isn't Carbon ready. > > I poked around in the MacPython README file and saw mention of this: > > --- > A special mention is deserved by Matthias Neeracher, who has written > the brilliant unix-compatible GUSI I/O library, without which > MacPython would not have sockets or select, and to Alexandre > Parenteau, who has ported this library to Carbon. > --- > > Did you (Alex) do tweaks to GUSI to make it Carbon friendly? Where > are these tweaks, how do I apply them? > > Really looking forward to moving past this point. > > Thanks, > > /Jay > > > >> >> ----- Original Message ----- >> From: "Jay Koutavas" >> To: >> Sent: Saturday, July 13, 2002 11:23 AM >> Subject: Re: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon >> >> >>> [Although this email is slightly off-topic (it goes into some >>> specifics about building MacCVS), I think it's worth adding to the >>> public thread I've started on this subject. >>> >>> Note, the troubles I'm seeing with building MacCVS are *not* >>> indicative of the quality of MacCVS. I've used MacCVS before and can >>> say it's a very worthy CVS client. More accurately, they're >>> indicative of missing information I have as I come up to speed on the >>> subject of building MacCVS and Python. >>> >>> With that all said, here's my next email on this subject, which >>> contains additional information on what I'm trying to achieve with my >>> Python embed. >>> >>> /Jay] >>> >>> Alex, >>> >>> Thank you for your emails on this subject. >>> >>> One thing I realized, after reading the thread was that I didn't >>> clarify the target of my OS X Carbon application. It's CFM, not >>> Mach-O. The reason I am CFM-targeted is that my application needs to >>> also run on Mac OS 9. Single binary. It is not a requirement that the >>> application supports Python when running on OS 9, thus the weak link >>> I spoke of in my opening email. Also, for sake of providing possible >>> missing useful information, I'm using CodeWarrior 7.2 as my >>> development environment. My C/C++ application also runs on Windows, >>> and am using CodeWarrior there too. >>> >>> I learned from this thread that if I'm going to embed Carbon Python >>> into a CFM application running on Mac OS X, I'll either have to use >>> GUSI, or I'll have to do the rather tedious Mach-O --> CFM wrapping >>> technic you outlined in this email. I've done this sort of wrapping >>> for specific Quartz calls, so I am familiar with it. >>> >>> So, I looked over MacCVS. First, I build MacCVS 3.2 Carbon from >>> sources and built Python 2.2.1's PythonCarbonLib and dropped it into >>> the same folder as the MacCVS application. Launching MacCVS on Mac OS >>> X 10.1.5, I found the following two problems: >>> >>> 1) the console window that you provide comes up under macCVS's >>> toolbar. I see no way to get it moved into the foreground >>> >>> 2) MacCVS is suffering from the "dual menubar problem" -- where SIOUX >>> (via PythonCarbonLib) is presenting it's own rendition of the main >>> menu to the right of MacCVS's, resulting in an unusable application. >>> >>> At this point I thought I'd better get the latest sources, and did a >>> full CVS get of MacCVS. I built the Carbon target of MacCVS with >>> minimum fuss (there's a broken copy of getdate.c in CVS at the >>> moment) and dropped my same copy of PythonCarbonLib into the >>> application's folder. MacCVS from latest sources won't launch. What >>> happens is it brings up a dialog stating that no debugger was found >>> and that it's not a fatal thing, but then silently the application >>> quits. >>> >>> I then tried to make the Mach-O target of MacCVS from latest sources. >>> When launching it, there's a dialog saying "You need to put >>> PythonCarbonLib into the application folder to get python support." I >>> have one there. The MacCVS Mach-o application doesn't recognize it. >>> >>> My questions: >>> >>> 1) How do I get MacCVS Mach-o to run with Python via latest sources? >>> >>> 2) (the question I was persuing at the start of this) Should I >>> attempt to follow your lead and wrap Python-Mach-O calls for use in >>> my CFM application? How much work is it? Will it be a mere matter of >>> copy/pasting your work? >>> >>> Best, >>> >>> /Jay >>> >>> -- >>> ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' >>> Jay Koutavas mailto:jay@heynow.com >>> Heynow Software http://www.heynow.com >>> Windham, New Hampshire, USA >>> ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' >>> >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> > From fancher@pacbell.net Tue Jul 16 01:46:21 2002 From: fancher@pacbell.net (bill fancher) Date: Mon, 15 Jul 2002 17:46:21 -0700 Subject: [Pythonmac-SIG] Anyone willing to put documentation into the Python.framework? In-Reply-To: <01DB495C-94D0-11D6-966F-003065517236@oratrix.com> Message-ID: <72907D82-9855-11D6-B2A3-0005029E8B13@pacbell.net> On Thursday, July 11, 2002, at 06:13 AM, Jack Jansen wrote: > The release of 2.3a1 would be a good candidate for a deadline. But I'm > not sure when that is going to be: the original planning says "before > OSCON 2002", which is in two weeks time, but I haven't seen any > indication that this deadline is going to be met. My (wild) guess is that > the first 2.3 alfa will be some time in August. > > Does that fit your schedule? That's fine. What do deliverables look like? -- bill From andrew.straw@adelaide.edu.au Tue Jul 16 03:09:23 2002 From: andrew.straw@adelaide.edu.au (Andrew Straw) Date: Tue, 16 Jul 2002 11:39:23 +0930 Subject: [Pythonmac-SIG] What is a bus error, anyway? Message-ID: <0C50FD98-9861-11D6-BC1B-00039311EA24@adelaide.edu.au> Hi all, For so long I've accepted the fact that I can't run python on Mac OS X twice simultaneously because of the dreaded "bus error". But why? What is a bus error? Cheers! Andrew From Jack.Jansen@cwi.nl Tue Jul 16 09:38:53 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 16 Jul 2002 10:38:53 +0200 Subject: [Pythonmac-SIG] Anyone willing to put documentation into the Python.framework? In-Reply-To: <72907D82-9855-11D6-B2A3-0005029E8B13@pacbell.net> Message-ID: <7584CBA6-9897-11D6-9961-0030655234CE@cwi.nl> On Tuesday, July 16, 2002, at 02:46 , bill fancher wrote: > > On Thursday, July 11, 2002, at 06:13 AM, Jack Jansen wrote: > >> The release of 2.3a1 would be a good candidate for a deadline. But I'm >> not sure when that is going to be: the original planning says "before >> OSCON 2002", which is in two weeks time, but I haven't seen any >> indication that this deadline is going to be met. My (wild) guess is >> that the first 2.3 alfa will be some time in August. >> >> Does that fit your schedule? > > That's fine. What do deliverables look like? Ideally a script (or set of scripts) that I can run with the existing Python documentation (whether in .tex source or html doesn't really matter) and that produces a directory full of stuff I can just dump into the framework. But if it's just the output directory (because the stuff is difficult to script) that's fine too. And even if it's just a set of instructions on how to get from the Python documentation to a form palatable to Help Viewer: still great. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Tue Jul 16 09:43:09 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 16 Jul 2002 10:43:09 +0200 Subject: [Pythonmac-SIG] What is a bus error, anyway? In-Reply-To: <0C50FD98-9861-11D6-BC1B-00039311EA24@adelaide.edu.au> Message-ID: <0E1E420E-9898-11D6-9961-0030655234CE@cwi.nl> On Tuesday, July 16, 2002, at 04:09 , Andrew Straw wrote: > Hi all, > > For so long I've accepted the fact that I can't run python on Mac OS X > twice simultaneously because of the dreaded "bus error". But why? What > is a bus error? The "bus error" in this case is just a symptom. (What it usually means is that a program tries to write to either a non-existing memory address, or write a 4-byte quantity to an address that isn't a 4-byte multiple. In other words: the program in question has completely fouled up it's data structures). But, that aside: what exactly are you doing that you get a bus error? If you're running python twice from the commandline there should be absolutely no problem. If you try to run Python.app twice by double-clicking on a second .py script while the first one is still running it doesn't work, but I woulnd't expect a bus error (I would expect nothing to happen). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From gherman@darwin.in-berlin.de Tue Jul 16 16:25:18 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Tue, 16 Jul 2002 17:25:18 +0200 (CEST) Subject: [Pythonmac-SIG] ANN: Podpourri 0.1 Message-ID: <1026833118.3d343adef16b0@webmail.in-berlin.de> Ok, after talking a bit to Jack, I've released Podpourri 0.1 which is a Cocoa wrapper around a Python package to access iPod songs. This Python package is currently con- tained inside (as two files headery.py and ipodlib.py in Podpourri.app/Contents/Resources), but will also be avail- able seperately, sooner or later. Please find more info here: http://www.versiontracker.com/moreinfo.fcgi?id=15530 Enjoy, Dinu From Chris.Barker@noaa.gov Tue Jul 16 18:43:06 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Tue, 16 Jul 2002 10:43:06 -0700 Subject: [Pythonmac-SIG] Extensions for static versus frame References: <3D330547.6F663603@noaa.gov> Message-ID: <3D345B2A.AF7FBBC@noaa.gov> Hi folks, It seems there is some debate over what the "default" build/distribution of Python on OS-X should look like. I thought I'd put in my $.02, and see what others think. In a private message, Jack Jansen wrote: > I want to have all of Python contained in one spot: > /Library/Frameworks/Python.framework. Users may install it > elsewhere, such as in ~/Library/Frameworks/Python.framework or > so, but it is 100% self-contained, that's the main point. > (Exceptions to this rule are PythonIDE.app and the soon-to-come > Python Launcher.app, which will live in /Applications, but that > is true for both architectures). And it's binary-installable. > Another option is to have a completely normal Unix installation, with files in > /usr/local/bin and /usr/local/lib/pythonX.Y. This is possible, > and the Python.framework would then consist mainly of symlinks > into /usr/local. The bad side of this is that you lose non-admin > installation, you lose uninstall by simple drag-to-thrash, and > to people who don't know the Terminal it will be completely > unclear where this thing lives (/usr is invisible from the > Finder). The good side is that it is exactly the same filesystem > layout as on Linux or any other unix. I am primarily a Linux user, and I don't see much advantage at all to the second approach. In fact, I really don't like the *nix standard of sprinkling files realated to a single app all over the system in /usr, /usr/lib, /usr/share, etc. I much prefer apps that come packaged all up in a /usr/local/appname directory. The only thing that makes the standard approach tolerable is if everything is installed by a package system like rpm. That way it can be upgraded, repaired and uninstalled cleanly. Apple has not provided such a system, and instead encourages people to distribute apps in a Framework directory to make maintainance easier. It's a good idea. What I suggest is a Framework build, with the following symlinks: /usr/local/bin/python /usr/local/bin/python2 /usr/local/bin/python2.2 /usr/local/lib/python2.2 and wherever else we think we need them. This way it will still look pretty much like a standard install to the Unix side. Note that "real" unix geeks can do whatever they want anyway, we are only talking about the "standard" build, which will be installed pre-compiled by most people. I'm also assuming that distutils will do "the right thing" with a Framework install. By the way, I also suggest /usr/local, rather than /usr/, following the tradition that stuff supplied by folks other than the vendor be put in /local. That way it is very clear when administering the system what Apple (or RedHat, or whoever) supplied, and what was hand-installed. On another issue, but related to what the standard install should look like: > If you try to run Python.app twice by > double-clicking on a second .py script while the first one is still > running it doesn't work, but I woulnd't expect a bus error (I would > expect nothing to happen). This needs to be solved. Except for command line use, Python is not an application. It is a virtual machine or runtime environment, and should be invisible to users running multiple python programs at once. Is the above mentioned "Python Launcher.app" the solution to this? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From rbl@hal.epbi.cwru.edu Tue Jul 16 19:46:50 2002 From: rbl@hal.epbi.cwru.edu (Robin B. Lake) Date: Tue, 16 Jul 2002 14:46:50 -0400 (EDT) Subject: [Pythonmac-SIG] Extensions for static versus frame Message-ID: <200207161846.g6GIkoqm028186@hal.epbi.cwru.edu> With respect to the packaging of Python ... I was a very early user and evangelist for Python. However, as Python has grown and spread, it takes a fanatic, not an evangelist, to deploy it. When it was a Mac (Classic) tool and didn't try to be the Universal Solvent on all platforms, there were just a few bits of juggling and incantation that were required to get it to run. Now, it seems that one can't even select the appropriate flavor of Python to install and the "rulebook" for getting it up and going rivals a Congressional appropriation bill. I'd pay real-money for a retail shrink-wrapped package with decent documentation and a CLEAR explaination of the (OS X) installation procedure(s). Yes, I've been to the Web site; Yes, I have a half-dozen Python texts; Yes, I'm afraid to install it. Cheers, Robin Lake, Ph.D. Environmental Modeling Inc. Cleveland, OH lake@cwru.edu From Jack.Jansen@oratrix.com Tue Jul 16 22:58:34 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 16 Jul 2002 23:58:34 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <200207161846.g6GIkoqm028186@hal.epbi.cwru.edu> Message-ID: <2CC37081-9907-11D6-A13A-003065517236@oratrix.com> Robin, rest assured, this is definitely where I want to go. 2.2.1 and earlier are really unix tools: the README states that building a framework MachoPython and using the Carbon modules is an experimental feature (and even Apple themselves seem to be aware of this:-). As of 2.3 the situation should be infinitely better: a simple binary installer that will give you the framework, the IDE and the Launcher, and optionally the unix tools. It should also contain the documentation, or at least allow it to be accessed at the press of a button. And it will be happy with Unix linefeeds or Mac linefeeds or even Windows linefeeds. And the webpage will be updated, moving our old friend MacPython down and putting the binary OSX MachoPython installer prominently at the top. And if you want to re-create the whole thing from source it should be a _lot_ simpler than it is with MacPython. 2.3 will definitely not be the be-all-end-all Python, because there are oodles of technologies that are optional but need easy access (Tkinter, wxWindows, Cocoa, Python Scripting Component), and I don't think there'll be time to do all that, but it should definitely be a leap in the right direction. And, if you're serious about paying real money: we can definitely work something out whereby we relieve you of that money in exchange for a speedup of the process... On dinsdag, juli 16, 2002, at 08:46 , Robin B. Lake wrote: > > With respect to the packaging of Python ... > > I was a very early user and evangelist for Python. However, as Python > has grown and spread, it takes a fanatic, not an evangelist, to deploy > it. When it was a Mac (Classic) tool and didn't try to be the > Universal > Solvent on all platforms, there were just a few bits of juggling and > incantation that were required to get it to run. > > Now, it seems that one can't even select the appropriate flavor of > Python to install and the "rulebook" for getting it up and going rivals > a Congressional appropriation bill. > > I'd pay real-money for a retail shrink-wrapped package with decent > documentation and a CLEAR explaination of the (OS X) installation > procedure(s). Yes, I've been to the Web site; Yes, I have a > half-dozen > Python texts; Yes, I'm afraid to install it. > > Cheers, > Robin Lake, Ph.D. > Environmental Modeling Inc. > Cleveland, OH > lake@cwru.edu > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Tue Jul 16 22:41:19 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 16 Jul 2002 23:41:19 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <3D345B2A.AF7FBBC@noaa.gov> Message-ID: On dinsdag, juli 16, 2002, at 07:43 , Chris Barker wrote: [lots of detail and explanation omitted] > I am primarily a Linux user, and I don't see much advantage at all to > the second approach. Ok, thanks, that was about my own line of reasoning too! > On another issue, but related to what the standard install should look > like: >> If you try to run Python.app twice by >> double-clicking on a second .py script while the first one is still >> running it doesn't work, but I woulnd't expect a bus error (I would >> expect nothing to happen). > > This needs to be solved. Except for command line use, Python is not an > application. It is a virtual machine or runtime environment, and should > be invisible to users running multiple python programs at once. Is the > above mentioned "Python Launcher.app" the solution to this? yes, it is. Just and myself had a session of heavy MachoPython design last week, and here's what we've come up with. please comment. The thing that we now call /Applications/Python.app will become hidden: it will move into the Python.framework somewhere. It will also *not* advertise (in its .plist file) itself as capable of running Python scripts. It will be changed a little, mainly replacing macmain.c by the standard Modules/main.c with a little mod to allow it to look for __rawmain__.py or .pyc, so it can still be used for building applets. The tricky AppleEvent code to create sys.argv on startup will be re-implemented in Python, and applets that need it will get it in their __rawmain__.py (and that's the only place it will be used). There will be a new program /Applications/Python Launcher.app, modelled after Java's Applet Launcher (hmm, maybe it should go into Utilities?). It will understand two file types: ".py" and ".pyw". If a script.py is doubleclicked it will by default open a terminal window and run "/Library/Frameworks/Python.framework/Versions/Current/bin/python script.py" in it. If a script.pyw is doubleclicked it will run (without a terminal window) "...../Python.app/Contents/MacOS/python script.pyw". This .py/.pyw distinction, and the behaviour, is modelled after the way things work on Windows. Python Launcher will get a couple of bells and whistles (modelled after how Stuffit Expander works, of all tools:-): if you option-drag or option-double-click a script you get a chance to add the verbose flag and other flags to Python, or pick a diffferent interpreter. Also, if you manually run the launcher you get access to it's preferences dialog, where you can set the defaults for these (or restore the "factory defaults"), separately for .py and .pyw scripts. I'm pretty happy with this solution, as it is pretty mac-like (for instance, the Get Info box can be used to select whether the IDE or the launcher should open a document by default, and use drag and drop if they want the other one) and it's also pretty familiar to people coming from Windows (.py -> you get a console for your I/O, .pyw -> no ugly consoles if you want to do your own UI, be it with wxWindows, Tkinter, Carbon or Cocoa). Please feel free to rain on my parade and tell us what we missed, where we seriously messed up the design or why this idea will never fly:-) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tony@lownds.com Wed Jul 17 00:12:14 2002 From: tony@lownds.com (Tony Lownds) Date: Tue, 16 Jul 2002 16:12:14 -0700 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: References: Message-ID: >yes, it is. Just and myself had a session of heavy MachoPython >design last week, and here's what we've come up with. please comment. Nice! >The thing that we now call /Applications/Python.app will become >hidden: it will move into the Python.framework somewhere. It will >also *not* advertise (in its .plist file) itself as capable of >running Python scripts. It will be changed a little, mainly >replacing macmain.c by the standard Modules/main.c with a little mod >to allow it to look for __rawmain__.py or .pyc, so it can still be >used for building applets. The tricky AppleEvent code to create >sys.argv on startup will be re-implemented in Python, and applets >that need it will get it in their __rawmain__.py (and that's the >only place it will be used). What will the __name__ inside __rawmain__.py be? I hope that it will not be '__main__', so that __rawmain__.py can import the "real" __main__ >There will be a new program /Applications/Python Launcher.app, >modelled after Java's Applet Launcher (hmm, maybe it should go into >Utilities?). I'd vote for a /Applications/Python folder (consistent with MacPython, and PythonWin) /Applications/Python/Python Launcher.app Will the Python Launcher be buildable from Python's source tree, or another source tree? >Python Launcher will get a couple of bells and whistles (modelled >after how Stuffit Expander works, of all tools:-): if you >option-drag or option-double-click a script you get a chance to add >the verbose flag and other flags to Python These are set by #! line in UNIX; will that line be consulted? >, or pick a diffferent interpreter. What does this do? >Also, if you manually run the launcher you get access to it's >preferences dialog, where you can set the defaults for these (or >restore the "factory defaults"), separately for .py and .pyw scripts. How do you get to an interactive Python interpreter? I mean, click an icon, and see a window with: Python 2.3a0 (#1, Jul 15 2002, 08:02:36) [GCC 2.95.2 19991024 (release)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> > >Please feel free to rain on my parade and tell us what we missed, >where we seriously messed up the design or why this idea will never >fly:-) Thanks for thinking this through! -Tony From just@letterror.com Wed Jul 17 08:51:34 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 17 Jul 2002 09:51:34 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: Message-ID: Tony Lownds wrote: > How do you get to an interactive Python interpreter? I mean, click an > icon, and see a window with: Hm, there's a (simple) interactive window in the IDE, but if you mean an interactive interpreter in a Terminal window: good catch, we didn't think of that one yet! Btw. I like your suggestion of putting a "Python" directory in /Applications. It's a great place for readme files as well. Just From mwh@python.net Wed Jul 17 10:17:34 2002 From: mwh@python.net (Michael Hudson) Date: 17 Jul 2002 10:17:34 +0100 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: Jack Jansen's message of "Tue, 16 Jul 2002 23:41:19 +0200" References: Message-ID: <2md6tmzpap.fsf@starship.python.net> Jack Jansen writes: > yes, it is. Just and myself had a session of heavy MachoPython > design last week, and here's what we've come up with. please > comment. A thought I had a while back. Feel free to ignore it. What is the current opinion on extension modules? Currently they tend to end up deep down in /Libary/Frameworks/Python.framework/.../site-packages/ Wouldn't it be nice if one could build a loadable bundle type thing that could be installed alongside the framework, or in /Library/Application Support/Python or somewhere? This could include headers for e.g. Numeric. Cheers, M. -- $ head -n 2 src/bash/bash-2.04/unwind_prot.c /* I can't stand it anymore! Please can't we just write the whole Unix system in lisp or something? */ -- spotted by Rich van der Hoff From mjb@uma.pt Wed Jul 17 11:52:51 2002 From: mjb@uma.pt (Michael J. Barber) Date: Wed, 17 Jul 2002 11:52:51 +0100 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: Message-ID: <576B1DB6-9973-11D6-B37A-0050E4794D0F@uma.pt> On Tuesday, July 16, 2002, at 10:41 PM, Jack Jansen wrote: > > There will be a new program /Applications/Python Launcher.app, modelled > after Java's Applet Launcher (hmm, maybe it should go into Utilities?). > It will understand two file types: ".py" and ".pyw". What will happen with .pyc files? From mjb@uma.pt Wed Jul 17 12:01:18 2002 From: mjb@uma.pt (Michael J. Barber) Date: Wed, 17 Jul 2002 12:01:18 +0100 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: Message-ID: <8518D866-9974-11D6-B37A-0050E4794D0F@uma.pt> On Wednesday, July 17, 2002, at 12:12 AM, Tony Lownds wrote: > >> There will be a new program /Applications/Python Launcher.app, >> modelled after Java's Applet Launcher (hmm, maybe it should go into >> Utilities?). > > I'd vote for a /Applications/Python folder (consistent with MacPython, > and PythonWin) > This is also consistent with how Apple handled Script Runner by placing it in /Applications/AppleScript along with Script Editor and ScriptMenu.menu. I hadn't particularly liked that approach before, but after considering the possibility of other programming tools in a parallel structure, it now makes a lot of sense to me. Wherever they go, the idea behind the tools sounds great! From p.oberndoerfer@urheberrecht.org Wed Jul 17 18:13:13 2002 From: p.oberndoerfer@urheberrecht.org (Pascal Oberndoerfer) Date: Wed, 17 Jul 2002 19:13:13 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: Message-ID: Jack Jansen at Jack.Jansen@oratrix.com: > There will be a new program /Applications/Python Launcher.app, > modelled after Java's Applet Launcher (hmm, maybe it should go > into Utilities?). Does this mean the Python IDE should go into /Developer/Applications ? The idea of a Python folder inside /Applications sounds nicer to me. Pascal From oussoren@cistron.nl Wed Jul 17 18:27:12 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Wed, 17 Jul 2002 19:27:12 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <2md6tmzpap.fsf@starship.python.net> Message-ID: <6DE3F064-99AA-11D6-916C-0003931CFE24@cistron.nl> On Wednesday, July 17, 2002, at 11:17 , Michael Hudson wrote: > Wouldn't it be nice if one could build a loadable bundle type thing > that could be installed alongside the framework, or in > > /Library/Application Support/Python > > or somewhere? This could include headers for e.g. Numeric. I like the idea. You could add something like the code below to a 'sitecustomize.py' somewhere on the default search-path: import sys import os.path ver = "%d.%d"%sys.version_info[:2] for top in (os.path.expanduser('~'), '', '/Network'): p = os.path.join(top, 'Library/Application Support/Python/lib/python') sys.path.append(p) sys.path.append(p + ver) Ronald From F.Schippers@inter.NL.net Wed Jul 17 21:03:12 2002 From: F.Schippers@inter.NL.net (Frans H. Schippers) Date: Wed, 17 Jul 2002 22:03:12 +0200 Subject: [Pythonmac-SIG] What is a bus error, anyway? In-Reply-To: <0E1E420E-9898-11D6-9961-0030655234CE@cwi.nl> References: <0E1E420E-9898-11D6-9961-0030655234CE@cwi.nl> Message-ID: At 10:43 +0200 16-07-2002, Jack Jansen wrote: > >But, that aside: what exactly are you doing that you get a bus error? If you're running python twice from the commandline there should be absolutely no problem. If you try to run Python.app twice by double-clicking on a second .py script while the first one is still running it doesn't work, but I woulnd't expect a bus error (I would expect nothing to happen). Jack Although i don't understand what is happening i do the following things: localhost% ls -l /usr/local/bin/python lrwxrwxrwx 1 ronald staff 46 Jun 21 15:50 /usr/local/bin/python -> /Applications/Python.app/Contents/MacOS/python localhost% ls -l /Applications/Python.app/Contents/MacOS/python -rwxr-xr-x 1 frans admin 19576 Jul 12 16:01 /Applications/Python.app/Contents/MacOS/python localhost% python Pythonw 2.3a0 (#1, Jul 12 2002, 13:20:46) [GCC 2.95.2 19991024 (release)] on darwin Type "copyright", "credits" or "license" for more information. >>> Now in an other terminal window (same user frans) localhost% python zsh: bus error python Now in yet an other terminal window (same user frans) localhost% /Applications/Python.app/Contents/MacOS/python Pythonw 2.3a0 (#1, Jul 12 2002, 13:20:46) [GCC 2.95.2 19991024 (release)] on darwin Type "copyright", "credits" or "license" for more information. >>> So if i invoke python twice though the symbolic link it results in bus errors. Hope you can explain it. Frans -- X|support bv mailto:xsupport@inter.nl.net From Jack.Jansen@oratrix.com Wed Jul 17 22:26:20 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 17 Jul 2002 23:26:20 +0200 Subject: [Pythonmac-SIG] What is a bus error, anyway? In-Reply-To: Message-ID: There are two problems with your installation. The first one, but this isn't the cause of your problems, is that you've linked /usr/local/bin/python to the Python.app executable. This is a bad idea as all Python scripts will now use Python.app (which you can distinguish from the "normal" python because it has "Pythonw 2.3a0" in its banner in stead of "Python 2.3a0". The second problem is that a symlink to the executable inside a .app will not work. You *must* start the executable inside the app with a full pathname. We discovered this the hard way a few months ago, and since then we no longer put a symlink "pythonw" in /usr/local/bin but in stead a shell script. If you are working from current CVS then the Makefile in Mac/OSX knows how to set things up correctly. And, in case you're interested, the reason the symlink doesn't work is because somewhere early in startup the executable inside the .app will try to find it's bundle. It does so by looking at argv[0], apparently. argv[0] will be the symlink (/usr/local/bin/python), not the path that the symlink points to. Then, something gets very confused and scribbles over memory. Don't blame me, I didn't write it:-) On woensdag, juli 17, 2002, at 10:03 , Frans H. Schippers wrote: > Although i don't understand what is happening i do the > following things: > > localhost% ls -l /usr/local/bin/python > lrwxrwxrwx 1 ronald staff 46 Jun 21 15:50 > /usr/local/bin/python -> > /Applications/Python.app/Contents/MacOS/python > > localhost% ls -l /Applications/Python.app/Contents/MacOS/python > -rwxr-xr-x 1 frans admin 19576 Jul 12 16:01 > /Applications/Python.app/Contents/MacOS/python > > localhost% python > Pythonw 2.3a0 (#1, Jul 12 2002, 13:20:46) > [GCC 2.95.2 19991024 (release)] on darwin > Type "copyright", "credits" or "license" for more information. >>>> > > Now in an other terminal window (same user frans) > localhost% python > zsh: bus error python > > Now in yet an other terminal window (same user frans) > localhost% /Applications/Python.app/Contents/MacOS/python > Pythonw 2.3a0 (#1, Jul 12 2002, 13:20:46) > [GCC 2.95.2 19991024 (release)] on darwin > Type "copyright", "credits" or "license" for more information. >>>> > > So if i invoke python twice though the symbolic link it results > in bus errors. > > Hope you can explain it. > > Frans > -- > X|support bv mailto:xsupport@inter.nl.net > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Wed Jul 17 22:18:33 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 17 Jul 2002 23:18:33 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <6DE3F064-99AA-11D6-916C-0003931CFE24@cistron.nl> Message-ID: On woensdag, juli 17, 2002, at 07:27 , Ronald Oussoren wrote: > I like the idea. You could add something like the code below to > a 'sitecustomize.py' somewhere on the default search-path: > > import sys > import os.path > ver = "%d.%d"%sys.version_info[:2] > > for top in (os.path.expanduser('~'), '', '/Network'): > p = os.path.join(top, 'Library/Application > Support/Python/lib/python') > sys.path.append(p) > sys.path.append(p + ver) Good idea, but you should use macfs.FindFolder() to locate the specific folders. And I think it's probably best if the Python installer didn't put this straight in sitecustomize.py, but in stead put it somewhere in Mac/Lib (addosxlibpath.py?) and suggest people add the single line "import addosxlibpath" to their sitecustomize.py. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tony@lownds.com Wed Jul 17 22:58:34 2002 From: tony@lownds.com (Tony Lownds) Date: Wed, 17 Jul 2002 14:58:34 -0700 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: References: Message-ID: At 11:18 PM +0200 7/17/02, Jack Jansen wrote: >On woensdag, juli 17, 2002, at 07:27 , Ronald Oussoren wrote: >>I like the idea. You could add something like the code below to >>a 'sitecustomize.py' somewhere on the default search-path: >... >And I think it's probably best if the Python installer didn't put >this straight in sitecustomize.py, but in stead put it somewhere in >Mac/Lib (addosxlibpath.py?) and suggest people add the single line >"import addosxlibpath" to their sitecustomize.py. Putting the actual code in a separate module sounds like a good plan, but why not have the Python installer provide this behavior by default? It's much less valuable if newbies have to learn Python path manipulation tricks before getting a nice environment. BTW, you can put "import addosxlibpath" in a .pth file too. -Tony From skim@adobe.com Thu Jul 18 00:46:27 2002 From: skim@adobe.com (Sung Kim) Date: Wed, 17 Jul 2002 16:46:27 -0700 Subject: [Pythonmac-SIG] Advice for GUI app on Mac & Windows Message-ID: <6952182B-99DF-11D6-A7AB-003065B90A20@adobe.com> --Apple-Mail-1--749736105 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, I'm still trying to find the GUI toolkit which will work on MacOS 9, MacOS X and Windows... I have a related question: My glue library is a carbon-compliant PEF-executable format library. Can I rewrite the library to be Mach-O and still call functions in (someone else's) carbon-compliant PEF-executable format library? Thanks again. --Sung H. Kim skim@adobe.com On Wednesday, July 10, 2002, at 03:46 PM, Sung Kim wrote: Hi, I'm considering using Python to write a cross-platform API tester (a GUI app). I have already created glue libraries on Windows and Mac (so that our Python script can access C APIs in question). Fyi, on the Mac, the C APIs live in a carbon-compliant shared library. Are there reasons why Python would or would not be a good solution for this? If Python is a good solution, any advice on which Python modules/libraries to use would be appreciated as well. One of the benefits of Python is "write-once for Mac and Windows" but I'm having a hard time finding a GUI solution that'll work on both platforms. Thank you! --Sung H. Kim _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig --Apple-Mail-1--749736105 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Hi, I'm still trying to find the GUI toolkit which will work on MacOS 9, MacOS X and Windows... I have a related question: My glue library is a carbon-compliant PEF-executable format library. Can I rewrite the library to be Mach-O and still call functions in (someone else's) carbon-compliant PEF-executable format library? Thanks again. --Sung H. Kim skim@adobe.com On Wednesday, July 10, 2002, at 03:46 PM, Sung Kim wrote: 0000,0000,DEDEHi, I'm considering using Python to write a cross-platform API tester (a GUI app). I have already created glue libraries on Windows and Mac (so that our Python script can access C APIs in question). Fyi, on the Mac, the C APIs live in a carbon-compliant shared library. Are there reasons why Python would or would not be a good solution for this? If Python is a good solution, any advice on which Python modules/libraries to use would be appreciated as well. One of the benefits of Python is "write-once for Mac and Windows" but I'm having a hard time finding a GUI solution that'll work on both platforms. Thank you! --Sung H. Kim _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig --Apple-Mail-1--749736105-- From fgranger@mac.com Thu Jul 18 08:34:27 2002 From: fgranger@mac.com (=?iso-8859-1?Q?Fran=E7ois?= Granger) Date: Thu, 18 Jul 2002 09:34:27 +0200 Subject: [Pythonmac-SIG] Advice for GUI app on Mac & Windows In-Reply-To: <6952182B-99DF-11D6-A7AB-003065B90A20@adobe.com> References: <6952182B-99DF-11D6-A7AB-003065B90A20@adobe.com> Message-ID: At 16:46 -0700 17/07/02, in message Re: [Pythonmac-SIG] Advice for GUI app on Mac & Windows, Sung Kim wrote: >Hi, > >I'm still trying to find the GUI toolkit which will work on MacOS 9, >MacOS X and Windows... As far as I know, the only one available is tk. There is one ongoing project in it early stage: http://www.anygui.org Then another more advanced project but not for MacOS 9.0 http://www.pythoncard.org -- =46ran=E7ois Granger fgranger@mac.com From dp@ulaluma.com Thu Jul 18 07:14:01 2002 From: dp@ulaluma.com (Donovan Preston) Date: Wed, 17 Jul 2002 23:14:01 -0700 Subject: [Pythonmac-SIG] Interface Builder Carbon NIBs and Python In-Reply-To: Message-ID: On 7/15/02 2:54 AM, "Jack Jansen" wrote: > Has anyone tried to use the NIB files (and xib files and all the other > stuff) that Interface Builder creates if you build an interface in > Carbon mode from a Python program? Yes. The ibcarbon module code I sent you (bgen) was for specifically doing this. I think I sent this along with some documentation to the list a while ago (6 months or so?), but if it can't be found I could probably dig it up again. > > Did it work? Was it a lot of work? Any code or insights to share? Yes, it worked quite well. The great thing about Carbon Nibs is that they work just fine on both Mac OS 9 and X, and integrate very well with Carbon Events. You can set which event handlers will fire using Project Builder, register your event handlers in Python, and when you load the Carbon Nib using the correct routine in ibcarbon, your Python event handlers will start firing in response to the carbon events. The only tricky part is acquiring the GIL from a Carbon Event Handler, which is what I was working on so hard before Christmas. I got things working to my satisfaction but haven't really looked at it much since then. I know a lot more now than I did then about threading issues, so I may pick it up again if there is interest. BTW Jack, I'd just like to take this opportunity to thank you for all your hard work on MacPython :-) Donovan From Chris.Barker@noaa.gov Thu Jul 18 17:16:35 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Thu, 18 Jul 2002 09:16:35 -0700 Subject: [Pythonmac-SIG] Advice for GUI app on Mac & Windows References: <6952182B-99DF-11D6-A7AB-003065B90A20@adobe.com> Message-ID: <3D36E9E3.8AAC871C@noaa.gov> Fran=E7ois Granger wrote: > >I'm still trying to find the GUI toolkit which will work on MacOS 9, > >MacOS X and Windows... >=20 > As far as I know, the only one available is tk. I thought tk was kind of dead in teh water for OS-9 with Carbon. > http://www.anygui.org Are they wrapping the MAC toolbox? I'm sure it's on their list, but is anyone actually doing it > Then another more advanced project but not for MacOS 9.0 >=20 > http://www.pythoncard.org PythonCard is based on wxPython, which is not currently functional on OS-9. Which brings us to wxPython. wxPython on OS-X is in pretty good shape. I recently tried it out for the first time, and it ran most of the wxPython demo, and an App of mine with only a few small issues, that I can easily address in my Python code. While wxPython for OS-9 does not yet exist, the pieces are there. wxMac is a Carbon library that works on OS-9 as well as OS-X. Many of the issues with the wxPython wrappers should be similar to OS-X, so all you need is someone to put some time into it. Ideally someone with Carbon on OS-9 experience. It sounds like the OP might have the programming experience to do the job. WHile it is unfortunate that there is no option that really works now, it may be less effort to get wxPython working on OS-9 that it is to build two different GUIs. This is particularly true if you have other uses for it in the future. anyone working on wxPython for OS-9 will probably get help as well. good luck, -Chris --=20 Christopher Barker, Ph.D. Oceanographer =09 NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From pdetagyos@palm.com Thu Jul 18 16:09:01 2002 From: pdetagyos@palm.com (pdetagyos@palm.com) Date: Thu, 18 Jul 2002 15:09:01 +0000 (GMT) Subject: [Pythonmac-SIG] O'Reilly OSCON Message-ID: <20020718150901.CF37B4514@mo120uhou.palm.net> Anyone planning to attend the O'Reilly Open Source convention next week? I'm goint to be there, and would be happy to meet other Mac pythonistas and discuss my favorite language running on my favorite platform. Peter From senn@maya.com Thu Jul 18 14:10:27 2002 From: senn@maya.com (Jeff Senn) Date: Thu, 18 Jul 2002 09:10:27 -0400 Subject: [Pythonmac-SIG] Mac OSX pythonw python and Tk... In-Reply-To: (Jack Jansen's message of "Mon, 8 Jul 2002 16:05:27 +0200") References: Message-ID: How can I get python to run from a terminal window (i.e. no idle and also stdio to the terminal) and also have Tk work? I tried the not-so-obvious: cp /usr/local/bin/python pythonw ./pythonw blah.py Which almost works -- I get windows but also the "SetFrontProcess failed,-600" error when trying to interact with them... (I seem to recall this worked at some point...) -- -Jas From bob@redivi.com Thu Jul 18 18:53:57 2002 From: bob@redivi.com (Bob Ippolito) Date: Thu, 18 Jul 2002 13:53:57 -0400 Subject: [Pythonmac-SIG] Mac OSX pythonw python and Tk... In-Reply-To: Message-ID: <55645008-9A77-11D6-9F91-0003938210D6@redivi.com> try: /usr/local/bin/python The argv[0] is actually (seemingly) vitally important to the WindowServer, an argv[0] with a relative or shell-completed path is not going to make it happy. Far as I know it needs to be set properly *as soon as you link* to Carbon or Cocoa. There's a way to molest it into working even if that's not the case, but it's nasty and uses some undocumented (and not listed in the headers) CoreGraphics calls. There's also a way to rewrite argv[0], in C.. because it's near the top of the stack.. Doing that is also very nasty. I really don't know why Apple thought this was a good idea.. seems they're using the argv[0] and pid as a key to tie events from the WindowServer back to the process, and apparently it knows what the argv[0] SHOULD be so if it's not copacetic it just doesn't work. Almost wish I worked for Apple so I could see why this is and how to get it fixed :) -bob On Thursday, July 18, 2002, at 09:10 AM, Jeff Senn wrote: > > How can I get python to run from a terminal window (i.e. no idle and > also stdio to the terminal) and also have Tk work? > > I tried the not-so-obvious: > > cp /usr/local/bin/python pythonw > ./pythonw blah.py > > Which almost works -- I get windows but also the "SetFrontProcess > failed,-600" > error when trying to interact with them... > > (I seem to recall this worked at some point...) > -- > -Jas > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bweiland@chiinc.com Thu Jul 18 14:49:42 2002 From: bweiland@chiinc.com (bweiland@chiinc.com) Date: Thu, 18 Jul 2002 09:49:42 -0400 Subject: [Pythonmac-SIG] Extensions for static versus frame Message-ID: > In response to Jack Jansen's comment: > > ---------- > > > This needs to be solved. Except for command line use, Python is not an > > application. It is a virtual machine or runtime environment, and should > > be invisible to users running multiple python programs at once. Is the > > above mentioned "Python Launcher.app" the solution to this? > > > There will be a new program /Applications/Python Launcher.app, > modelled after Java's Applet Launcher (hmm, maybe it should go > into Utilities?). It will understand two file types: ".py" and > ".pyw". If a script.py is doubleclicked it will by default open > a terminal window and run ... > > > Just making sure, does this mean that _multiple_ python scripts can be run > simultaneously (as if they were separate applications)? > > Thanks! > > Bill Weiland > From senn@maya.com Thu Jul 18 20:33:02 2002 From: senn@maya.com (Jeff Senn) Date: Thu, 18 Jul 2002 15:33:02 -0400 Subject: [Pythonmac-SIG] Mac OSX pythonw python and Tk... In-Reply-To: <55645008-9A77-11D6-9F91-0003938210D6@redivi.com> (Bob Ippolito's message of "Thu, 18 Jul 2002 13:53:57 -0400") References: <55645008-9A77-11D6-9F91-0003938210D6@redivi.com> Message-ID: Bob Ippolito writes: > try: > /usr/local/bin/python Same problem. Ok... I see that just doing /Applications/.../MacOS/python seems to work. I was confused because someone once suggested putting "import idle.idle" in __main__.py --- this is a very *bad* idea if your application is multi-threaded (like mine) since the import lock will never be released and every additional thread will certainly lock up on the first "import". -Jas From matt@reprocessed.org Thu Jul 18 18:40:24 2002 From: matt@reprocessed.org (Matt Patterson) Date: Thu, 18 Jul 2002 18:40:24 +0100 Subject: [Pythonmac-SIG] Problems with Python and SAX on OS X Message-ID: List people (blind cross-posted to python-mac and python-XML), Having just installed unix python on Mac OS X via Fink I tried to run one of my beginner XML scripts from my Mac and not my Debian box. The scripts work fine on the debian box but crash out with a segmentation fault on the OS X box, which is kind of irritating. The crash happens when I call the parser at the end of: from xml.sax import make_parser saxparser = make_parser() saxparser.setContentHandler(cHandler) saxparser.parse(sys.stdin) I've been able to figure out that the crash happens when saxparser.parse is called (by inserting print statements after each of the calls involving saxparser... crude, but informative enough for my abilities). I'm using python 2.2.1 (Python 2.2 (#1, Apr 17 2002, 17:13:51) according to the interpreter) on Mac OS X 10.1.5 with Fink 0.4 binary distribution. Has anyone seen anything like this? Thanks, Matt -- Matt Patterson | Typographer | http://www.emdash.co.uk/ | http://reprocessed.org/ From Jack.Jansen@oratrix.com Thu Jul 18 21:49:47 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 18 Jul 2002 22:49:47 +0200 Subject: [Pythonmac-SIG] Mac OSX pythonw python and Tk... In-Reply-To: Message-ID: On donderdag, juli 18, 2002, at 03:10 , Jeff Senn wrote: > > How can I get python to run from a terminal window (i.e. no idle and > also stdio to the terminal) and also have Tk work? If you're building Python from CVS look at the Makefile in Mac/OSX. It will install a pythonw shell script in /usr/local/bin that does exactly what you want. It does require that you build Python as a framework, though. And I don't think this functionality is in 2.2.1 (but I'm not 100% sure). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Thu Jul 18 21:54:39 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 18 Jul 2002 22:54:39 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: Message-ID: <93C982A2-9A90-11D6-AFCE-003065517236@oratrix.com> >>> This needs to be solved. Except for command line use, Python >>> is not an >>> application. It is a virtual machine or runtime environment, >>> and should >>> be invisible to users running multiple python programs at >>> once. Is the >>> above mentioned "Python Launcher.app" the solution to this? I assume you mean that if you double click foobar.py you want the icon in the dock and the menubar to show "foobar" in stead of "Python", right? If this is what you mean: yes, that would be nice. Unfortunately I have no idea how this could be done. We can't set argv[0] to the value wanted, because argv[0] has to point to the .app bundle otherwise things don't work. Does anyone know of a call we could make to set what the window manager thinks is our program name, so it sets the menu and dock name correctly? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bob@redivi.com Thu Jul 18 22:08:00 2002 From: bob@redivi.com (Bob Ippolito) Date: Thu, 18 Jul 2002 17:08:00 -0400 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <93C982A2-9A90-11D6-AFCE-003065517236@oratrix.com> Message-ID: <71137480-9A92-11D6-9F91-0003938210D6@redivi.com> Try your luck with this... Undocumented calls, but I'm 99% sure it will work. I'm pretty sure CPS gets linked in with Carbon, definitely does with Cocoa.. /* code below */ struct CPSProcessSerNum { UInt32 lo; UInt32 hi; }; typedef struct CPSProcessSerNum CPSProcessSerNum; extern OSErr CPSGetCurrentProcess( CPSProcessSerNum *psn); extern OSErr CPSSetProcessName ( CPSProcessSerNum *psn, char *processname ); void setMyName(void) { CPSProcessSerNum PSN; CPSGetCurrentProcess(&PSN); CPSSetProcessName(&PSN,"foobar"); } /* end code */ On Thursday, July 18, 2002, at 04:54 PM, Jack Jansen wrote: > >>>> This needs to be solved. Except for command line use, Python is not >>>> an >>>> application. It is a virtual machine or runtime environment, and >>>> should >>>> be invisible to users running multiple python programs at once. Is >>>> the >>>> above mentioned "Python Launcher.app" the solution to this? > > I assume you mean that if you double click foobar.py you want the icon > in the dock and the menubar to show "foobar" in stead of "Python", > right? > > If this is what you mean: yes, that would be nice. Unfortunately I have > no idea how this could be done. We can't set argv[0] to the value > wanted, because argv[0] has to point to the .app bundle otherwise > things don't work. > > Does anyone know of a call we could make to set what the window manager > thinks is our program name, so it sets the menu and dock name correctly? > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.com Thu Jul 18 22:21:23 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 18 Jul 2002 23:21:23 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <71137480-9A92-11D6-9F91-0003938210D6@redivi.com> Message-ID: <50270DF2-9A94-11D6-AFCE-003065517236@oratrix.com> On donderdag, juli 18, 2002, at 11:08 , Bob Ippolito wrote: > Try your luck with this... Undocumented calls, but I'm 99% > sure it will work. I'm pretty sure CPS gets linked in with > Carbon, definitely does with Cocoa.. Ah, CPS again:-) I don't want to do this, because the interface is undocumented. CPS would also have allowed us to do other nifty things, like connecting to the window server without being in a .app framework, but I think relying on undocumented calls is simply too dangerous. At some point in the future there's a good chance Apple will take the interface away, and suddenly Python stops working. And it will really stop working: you'll get an undefined external when you try to start the interpreter. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bob@redivi.com Thu Jul 18 22:39:14 2002 From: bob@redivi.com (Bob Ippolito) Date: Thu, 18 Jul 2002 17:39:14 -0400 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <50270DF2-9A94-11D6-AFCE-003065517236@oratrix.com> Message-ID: So be tricky and check to see if the symbols are there dynamically, if you're really *that* worried about Python 2.2 not working in OS X 10.3.. I mean, you're only calling three functions, wouldn't be killer to do. I really really *really* doubt that they'd change the PSN structure (since it's the same as Carbon's) or calling arguments to any of those three functions provided they don't go away or get renamed. -bob On Thursday, July 18, 2002, at 05:21 PM, Jack Jansen wrote: > > On donderdag, juli 18, 2002, at 11:08 , Bob Ippolito wrote: > >> Try your luck with this... Undocumented calls, but I'm 99% sure it >> will work. I'm pretty sure CPS gets linked in with Carbon, definitely >> does with Cocoa.. > > Ah, CPS again:-) > > I don't want to do this, because the interface is undocumented. CPS > would also have allowed us to do other nifty things, like connecting to > the window server without being in a .app framework, but I think > relying on undocumented calls is simply too dangerous. > > At some point in the future there's a good chance Apple will take the > interface away, and suddenly Python stops working. And it will really > stop working: you'll get an undefined external when you try to start > the interpreter. From senn@maya.com Thu Jul 18 23:30:32 2002 From: senn@maya.com (Jeff Senn) Date: Thu, 18 Jul 2002 18:30:32 -0400 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <50270DF2-9A94-11D6-AFCE-003065517236@oratrix.com> (Jack Jansen's message of "Thu, 18 Jul 2002 23:21:23 +0200") References: <50270DF2-9A94-11D6-AFCE-003065517236@oratrix.com> Message-ID: <1ya03bzr.fsf@SNIPE.maya.com> Jack Jansen writes: > I don't want to do this, because the interface is undocumented. CPS > would also have allowed us to do other nifty things, like connecting > to the window server without being in a .app framework, but I think > relying on undocumented calls is simply too dangerous. > > At some point in the future there's a good chance Apple will take the > interface away, and suddenly Python stops working. And it will really > stop working: you'll get an undefined external when you try to start > the interpreter. Could you put the feature in a dynamically loaded module? At least then the failover could be somewhat more graceful... -- -Jas From gherman@darwin.in-berlin.de Fri Jul 19 10:20:51 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Fri, 19 Jul 2002 11:20:51 +0200 (CEST) Subject: [Pythonmac-SIG] ANN: Pycotin 0.1, a Python Cocoa Test Interface for PyUnit Message-ID: <1027070451.3d37d9f33da30@webmail.in-berlin.de> Hi, for those who care, I've just released "Pycotin", a native Cocoa GUI to PyUnit testing on OS X. It's been just born, but looks verys promising. Please find the code plus two screenshots in my Starship Python cabin: http://python.net/~gherman/#Pycotin Regards, Dinu PS: From the README: Pycotin 0.1 Pycotin (Python Cocoa Test Interface) is a Cocoa GUI to Steve Purcell's PyUnit test framework (1) on Mac OS X. For now, its user interface is very much designed after the existing Tkinter one (2), but that might slightly change again. Pycotin was developped from its author's personal frust- ration with running (or rather not running) Tkinter on Mac OS X as the only existing GUI for PyUnit. While it might well be possible to make Tkinter run on this plat- form, it was probably easier to write this little tool... Basically, with Pycotin you can "open" Python files (with extension ".py") and execute testsuites created in these files with the "unittest" module of the Python 2.0 stan- dard library. Right now Pycotin trys to import a function named "suite()" or "makeSuite()" from an opened Python module which it assumes to build and return a testsuite. This can clearly be made much smarter, but also depends on your habits as testsuite designer. The test files in samples/ were shamelessly copied from Steve Purcell's own original test cases for PyUnit 1.4.1 (just skipping the Tkinter ones for obvious reasons). I added only one new file, "listtestsfail.py" which shows a failing test, too. Pycotin is in early alpha phase! Be not surprised to see some buglets when dealing with paths containing blanks! From david.metzger@web.de Fri Jul 19 10:55:19 2002 From: david.metzger@web.de (David Metzger) Date: Fri, 19 Jul 2002 11:55:19 +0200 Subject: [Pythonmac-SIG] macpython Message-ID: <200207190955.g6J9tIX28256@mailgate5.cinetic.de> Hi there, I'd like to know if there's a possibility to call macpython from commandline with a python script as parameter, and if not, if it ist planned to implement that somehow. THX David ______________________________________________________________________________ FreeMail in der Premiumversion! Mit mehr Speicher, mehr Leistung, mehr Erlebnis und mehr Pramie. Jetzt unter http://club.web.de/?mc=021105 From owen@astro.washington.edu Fri Jul 19 14:50:22 2002 From: owen@astro.washington.edu (Russell E Owen) Date: Fri, 19 Jul 2002 07:50:22 -0600 Subject: [Pythonmac-SIG] Re: Mac OSX pythonw python and Tk... Message-ID: Jeff Senn asked: >How can I get python to run from a terminal window (i.e. no idle and >also stdio to the terminal) and also have Tk work? > >I tried the not-so-obvious: > > cp /usr/local/bin/python pythonw > ./pythonw blah.py > >Which almost works -- I get windows but also the "SetFrontProcess failed,-600" >error when trying to interact with them... > >(I seem to recall this worked at some point...) I used fink to install Python and xfree86 (XDarwin), then installed OroborOSX separately (since the fink-included window manager crashed) and it all works fine from the command line. I've done a ton of programming this way (I never use idle) and have not seen this error. If your setup is different, you might try this one. Of course it'd be nice to use the MacOS X native version of Tk, but I've not personally done that -- I figured I'd wait until it was reliable. Regards, -- Russell From lists@netelligent.biz Fri Jul 19 15:48:06 2002 From: lists@netelligent.biz (tmk) Date: Fri, 19 Jul 2002 16:48:06 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <2md6tmzpap.fsf@starship.python.net> Message-ID: <88E5AC00-9B26-11D6-A940-000393A49442@netelligent.biz> Yo, Overall, I'm really happy with Jack and Just design for Python install on Mac OS X, ie using a framework install. and a launcher app in (/Applications/Utilities). I think Michael's suggestion for Python extensions is right on the spot. They should go into a user-accessible place. And to me, the best place on Mac OS X is clearly the .../Application Support/Python folder under any of the Machine, Network, or User domains (meaning MacPython should really look into each of theses places like any well-behave Mac OS X app). Like Robin, I'd also be glad to contribute monetary support to the further advancement of a well integrated Mac OS X Python especially the Cocoa/PB/IB integration. = tmk = On Wednesday, July 17, 2002, at 11:17 AM, Michael Hudson wrote: > Jack Jansen writes: > >> yes, it is. Just and myself had a session of heavy MachoPython >> design last week, and here's what we've come up with. please >> comment. > > A thought I had a while back. Feel free to ignore it. > > What is the current opinion on extension modules? Currently they tend > to end up deep down in > > /Libary/Frameworks/Python.framework/.../site-packages/ > > Wouldn't it be nice if one could build a loadable bundle type thing > that could be installed alongside the framework, or in > > /Library/Application Support/Python > > or somewhere? This could include headers for e.g. Numeric. > > Cheers, > M. > > -- > $ head -n 2 src/bash/bash-2.04/unwind_prot.c > /* I can't stand it anymore! Please can't we just write the > whole Unix system in lisp or something? */ > -- spotted by Rich van der Hoff > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Jack.Jansen@oratrix.com Fri Jul 19 21:41:23 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 19 Jul 2002 22:41:23 +0200 Subject: [Pythonmac-SIG] macpython In-Reply-To: <200207190955.g6J9tIX28256@mailgate5.cinetic.de> Message-ID: On vrijdag, juli 19, 2002, at 11:55 , David Metzger wrote: > Hi there, > > I'd like to know if there's a possibility to call macpython > from commandline with a python script as parameter, and if not, > if it ist planned to implement that somehow. As you say "commandline" I assume you mean on Mac OS X. And I also assume you really mean MacPython, not MachoPython. If these assumptions are correct what you can do is use the standard command "open", as in open -a PythonInterpreter script.py -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Fri Jul 19 21:58:57 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 19 Jul 2002 22:58:57 +0200 Subject: [Pythonmac-SIG] Added platform-specific directories to sys.path Message-ID: <57BEAF46-9B5A-11D6-9B6B-003065517236@oratrix.com> I've a question that I'd like some feedback on. On MacOSX there's a set of directories that are meant especially for storing extensions to applications, and there's requests on the pythonmac-sig that I add these directories to the Python search path. This could easily be done optionally, with a .pth file in site-python. MacOSX has rationalized where preferences, libraries, licenses, extensions, etc are stored, and for all of these there's a hierarchy of folders. In the case of Python extension modules the logical places would be ~/Library/Application Support/Python (for user-installed extension modules), /Library/Application Support/Python (for machine-wide installed extension modules) and /Network/Library/Application Support/Python (for workgroup-wide installed modules). The final location, in /System, is for factory-installed stuff from Apple, not needed just yet for this example:-). I sympathize with the idea of making things more conform to the platform standard, on the other hand I'm a bit reluctant to do things differently again from what other Pythons do. But, one of the things that is sorely missing from Python is a standard place to install per-user extension modules, so this might well be the thing that triggers inclusion of such functionality into the grand scheme of things (including distutils support, etc). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From guido@python.org Fri Jul 19 22:23:07 2002 From: guido@python.org (Guido van Rossum) Date: Fri, 19 Jul 2002 17:23:07 -0400 Subject: [Pythonmac-SIG] Re: [Python-Dev] Added platform-specific directories to sys.path In-Reply-To: Your message of "Fri, 19 Jul 2002 22:58:57 +0200." <57BEAF46-9B5A-11D6-9B6B-003065517236@oratrix.com> References: <57BEAF46-9B5A-11D6-9B6B-003065517236@oratrix.com> Message-ID: <200207192123.g6JLN7s15263@pcp02138704pcs.reston01.va.comcast.net> > I've a question that I'd like some feedback on. On MacOSX > there's a set of directories that are meant especially for > storing extensions to applications, and there's requests on the > pythonmac-sig that I add these directories to the Python search > path. This could easily be done optionally, with a .pth file in > site-python. > > MacOSX has rationalized where preferences, libraries, licenses, > extensions, etc are stored, and for all of these there's a > hierarchy of folders. In the case of Python extension modules > the logical places would be ~/Library/Application Support/Python > (for user-installed extension modules), /Library/Application > Support/Python (for machine-wide installed extension modules) > and /Network/Library/Application Support/Python (for > workgroup-wide installed modules). The final location, in > /System, is for factory-installed stuff from Apple, not needed > just yet for this example:-). > > I sympathize with the idea of making things more conform to the > platform standard, on the other hand I'm a bit reluctant to do > things differently again from what other Pythons do. But, one of > the things that is sorely missing from Python is a standard > place to install per-user extension modules, so this might well > be the thing that triggers inclusion of such functionality into > the grand scheme of things (including distutils support, etc). Traditionally, on Unix per-user extensions are done by pointing PYTHONPATH to your per-user directory (-ies) in your .profile. On Windows you can do this too, but I bet most people just have a per-user computer. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From barry@zope.com Fri Jul 19 22:48:53 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Jul 2002 17:48:53 -0400 Subject: [Pythonmac-SIG] Re: [Python-Dev] Added platform-specific directories to sys.path References: <57BEAF46-9B5A-11D6-9B6B-003065517236@oratrix.com> <200207192123.g6JLN7s15263@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <15672.35141.803094.488541@anthem.wooz.org> >>>>> "GvR" == Guido van Rossum writes: GvR> Traditionally, on Unix per-user extensions are done by GvR> pointing PYTHONPATH to your per-user directory (-ies) in your GvR> .profile. Or adding them to sys.path via your $PYTHONSTARTUP file. OTOH, it might be nice if the distutils `install' command had some switches to make installing in some of these common alternative locations a little easier. That might dovetail nicely if/when we decide to add a site-updates directory to sys.path. -Barry From martin@v.loewis.de Sat Jul 20 01:06:51 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 20 Jul 2002 02:06:51 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Added platform-specific directories to sys.path In-Reply-To: <57BEAF46-9B5A-11D6-9B6B-003065517236@oratrix.com> References: <57BEAF46-9B5A-11D6-9B6B-003065517236@oratrix.com> Message-ID: Jack Jansen writes: > I sympathize with the idea of making things more conform to the > platform standard, on the other hand I'm a bit reluctant to do things > differently again from what other Pythons do. But, one of the things > that is sorely missing from Python is a standard place to install > per-user extension modules, so this might well be the thing that > triggers inclusion of such functionality into the grand scheme of > things (including distutils support, etc). If that is the platform convention, I see no problem following it. Windows already does things differently from Unix, by using the registry to compute sys.path. Regards, Martin From guess-who@kevin-masako.com Sat Jul 20 03:32:44 2002 From: guess-who@kevin-masako.com (Kevin Ollivier) Date: Fri, 19 Jul 2002 22:32:44 -0400 Subject: [Pythonmac-SIG] Re: [wxPython-mac] More feedback questions In-Reply-To: <069601c22f90$66496f80$6401a8c0@rogue> Message-ID: Hi Robin, For #1, my vote is to just do wxPythonMacOSX for the Mac OS X port, and wxPythonMac for Carbon MacPython (I think Stefan's build in Feb. is still the current one for this platform). Then just add a note for the OS X port that it requires MachoPython. A thought I had (Jack, I hope you're listening =), what do you guys think about changing the name for "MachoPython" to MacPythonX while MacPython undergoes the Carbon -> OS X only transition? I think the name makes it clearer that it's OS X only, and its probably a bit easier to remember as well for those not compiling Mac software. =) Also, is the wxPython Sourceforge site the only place MachoPython is available for download? For #2 and #3, both work for me! Thanks, Kevin On Friday, July 19, 2002, at 09:54 PM, Robin Dunn wrote: > Hi again. > > While thinking about the upcoming 2.3.3 release I have come up with some > more things that I would like to get feedback from the community on. > > 1. Package/Installer naming: I'm going to standardize a bit and change > the > names of the installers and packages (as in RPMs and .dmg's, *not* > Python > packages) and use the name of the wx port in the name. For example: > wxPythonMSW, wxPythonGTK, etc. Hopefully someday there will be a > wxPythonX11... I'm not sure though what to do about the Mac OSX > version. > There are in effect several wx ports that run on the Mac, Classic, > Carbon, > and an OSX-only version built using the Apple Developer Tools. > Currently > wxPython only works with the latter one. So should it be wxPythonMac, > wxPythonOSX, wxPythonMacOSX, wxPythonMacho, or ??? > > 2. Python versions: I plan on doing binary builds for both Python 2.1 > and > 2.2, (except on the Mac where it will only be 2.2.) Is this enough? If > not, why not? > > 3. Compile options: I'm thinking about dropping the -hybrid builds (and > also the -dbg RPM I just announced) and instead do a single build that > is > something in between the FINAL and HYBRID that I've done in the past. > Specifically it will be like the FINAL in that compiler optimizations > will > be turned on and debugging info won't be generated, but __WXDEBUG__ > will be > turned on so that the various runtime checks will always be there. As > it is > now it takes me a complete a day to do all the builds and to do test > installs, much longer if I have to make changes to installers, etc. I'd > like to chop that in half if possible. > > That's all for now. > > -- > Robin Dunn > Software Craftsman > http://wxPython.org Java give you jitters? Relax with wxPython! > > > > > > _______________________________________________ > wxPython-mac mailing list > wxPython-mac@lists.wxwindows.org > http://lists.wxwindows.org/mailman/listinfo/wxpython-mac > From pdetagyos@cox.net Sat Jul 20 17:52:03 2002 From: pdetagyos@cox.net (Peter de Tagyos) Date: Sat, 20 Jul 2002 09:52:03 -0700 Subject: [Pythonmac-SIG] Threading with Tkinter on OSX - Bus Error Message-ID: <041DBC9C-9C01-11D6-B04C-0003939D32AA@cox.net> --Apple-Mail-1--515400684 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I am writing a Tkinter app that is multithreaded, and the program is crashing when I try to run it under OSX with the native Aqua Tk libraries. I run the same program under XDarwin with the fink-installed python, and it runs just peachy. I was wondering if anyone could tell me what I am doing wrong, or if there is a problem in the Aqua Tkinter. I have distilled the larger program into a smaller test script, which appears below. The thread waits for three seconds before sending a message to the frame. You'll notice that the program crashes with a "Bus Error" when it gets to the line that tries to insert text into the Text widget (in the message() function). I know that some people have previously mentioned that Tk needs to have all GUI stuff on one thread, but in the example below, that is the case - and it's still crashing. I am running the precompiled Tk/Tcl libs from sourceforge (MacOSXTk8.4a4-2.tar.gz), and I compiled Python myself using the instructions from http://tony.lownds.com/macosx/tkinter.html. Any help would be greatly appreciated! Peter Here is the test script: # -------------------------------------------------------------------------- # -- buserr.py ---------------------------------------------------------------- from Tkinter import * from threading import * import time # Class frm -------------------------------------------------------------------- class frm(Frame): # Builtins ------------------------------------------------------------- def __init__(self, parent=None): Frame.__init__(self, master=parent) if ((parent.__class__ == Toplevel) or (parent.__class__ == Tk)): parent.title("Testing") parent.geometry("400x300") self.pack() self.__createGUI() # Start the message thread msgTh = Thread(target=msgThread, args=(self,)) msgTh.start() # Public Interface ---------------------------------------------------- def message(self, msg): """Add the given message to the text""" currText = self.txtFoo.get(1.0, END) newText = currText + msg print "About to explode..." self.txtFoo.insert(END, newText) print "We never get here!" # Private Methods ----------------------------------------------------- def __createGUI(self): """Create all the GUI components""" self.txtFoo = Text(self) self.txtFoo.pack(side=TOP, fill=X, expand=1, padx=10) # Thread routine -------------------------------------------------------------- def msgThread(delegate): time.sleep(3) delegate.message("Testing") # Main ------------------------------------------------------------------------ root = Tk() gui = frm(root) gui.mainloop() --Apple-Mail-1--515400684 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII I am writing a Tkinter app that is multithreaded, and the program is crashing when I try to run it under OSX with the native Aqua Tk libraries. I run the same program under XDarwin with the fink-installed python, and it runs just peachy. I was wondering if anyone could tell me what I am doing wrong, or if there is a problem in the Aqua Tkinter. I have distilled the larger program into a smaller test script, which appears below. The thread waits for three seconds before sending a message to the frame. You'll notice that the program crashes with a "Bus Error" when it gets to the line that tries to insert text into the Text widget (in the message() function). I know that some people have previously mentioned that Tk needs to have all GUI stuff on one thread, but in the example below, that is the case - and it's still crashing. I am running the precompiled Tk/Tcl libs from sourceforge (GenevaMacOSXTk8.4a4-2.tar.gz), and I compiled Python myself using the instructions from http://tony.lownds.com/macosx/tkinter.html. Any help would be greatly appreciated! Peter Here is the test script: # -------------------------------------------------------------------------- # -- buserr.py ---------------------------------------------------------------- from Tkinter import * from threading import * import time # Class frm -------------------------------------------------------------------- class frm(Frame): # Builtins ------------------------------------------------------------- def __init__(self, parent=None): Frame.__init__(self, master=parent) if ((parent.__class__ == Toplevel) or (parent.__class__ == Tk)): parent.title("Testing") parent.geometry("400x300") self.pack() self.__createGUI() # Start the message thread msgTh = Thread(target=msgThread, args=(self,)) msgTh.start() # Public Interface ---------------------------------------------------- def message(self, msg): """Add the given message to the text""" currText = self.txtFoo.get(1.0, END) newText = currText + msg print "About to explode..." self.txtFoo.insert(END, newText) print "We never get here!" # Private Methods ----------------------------------------------------- def __createGUI(self): """Create all the GUI components""" self.txtFoo = Text(self) self.txtFoo.pack(side=TOP, fill=X, expand=1, padx=10) # Thread routine -------------------------------------------------------------- def msgThread(delegate): time.sleep(3) delegate.message("Testing") # Main ------------------------------------------------------------------------ root = Tk() gui = frm(root) gui.mainloop() --Apple-Mail-1--515400684-- From F.Schippers@inter.NL.net Sat Jul 20 20:17:14 2002 From: F.Schippers@inter.NL.net (Frans H. Schippers) Date: Sat, 20 Jul 2002 21:17:14 +0200 Subject: [Pythonmac-SIG] Re: [Python-Dev] Added platform-specific directories to sys.path In-Reply-To: References: <57BEAF46-9B5A-11D6-9B6B-003065517236@oratrix.com> Message-ID: >Jack Jansen writes: > >> I sympathize with the idea of making things more conform to the >> platform standard, on the other hand I'm a bit reluctant to do things >> differently again from what other Pythons do. But, one of the things >> that is sorely missing from Python is a standard place to install >> per-user extension modules, so this might well be the thing that >> triggers inclusion of such functionality into the grand scheme of >> things (including distutils support, etc). > >If that is the platform convention, I see no problem following >it. Windows already does things differently from Unix, by using the >registry to compute sys.path. > Thas also my opion. Frans -- X|support bv mailto:xsupport@inter.nl.net Bezoek Adres: Mollerusweg 150 2031 BZ Haarlem tel: +31 23 5 317 519 fax: +31 23 5 424 282 mbl: +31 653 650 806 Post Adres: Grote Beer 189 1188 AZ Amstelveen Btw: NL-807284324B01 KvK: 33301359 Bank: ING Amstelveen 6533.74.208 From tony@lownds.com Sat Jul 20 20:36:36 2002 From: tony@lownds.com (Tony Lownds) Date: Sat, 20 Jul 2002 12:36:36 -0700 Subject: [Pythonmac-SIG] Threading with Tkinter on OSX - Bus Error In-Reply-To: <041DBC9C-9C01-11D6-B04C-0003939D32AA@cox.net> References: <041DBC9C-9C01-11D6-B04C-0003939D32AA@cox.net> Message-ID: Hi Peter, >I know that some people have previously mentioned that Tk needs to >have all GUI stuff on one thread, but in the example below, that is >the case I don't think it is the case. When your program gets to time.sleep(3), it's not in the main thread; the next line calls delegate.message("testing"), which ends up calling Tk. Calling Tk from a Python-created thread that Tk knows nothing about on Aqua Tkinter causes crashes to ensue. >Any help would be greatly appreciated! Here is your script adjusted to use a Queue. This way the GUI calls really only happen in one thread. I wish I had a more general solution. -Tony # -------------------------------------------------------------------------- # -- buserr.py ------------------------------------------------------------- from Tkinter import * from threading import * import time import Queue # Class frm ---------------------------------------------------------------- class frm(Frame): # Builtins --------------------------------------------------------- def __init__(self, parent=None): self.queue = Queue.Queue(10) Frame.__init__(self, master=parent) if ((parent.__class__ == Toplevel) or (parent.__class__ == Tk)): parent.title("Testing") parent.geometry("400x300") self.pack() self.__createGUI() # Start the message thread msgTh = Thread(target=msgThread, args=(self,)) msgTh.start() # Public Interface -------------------------------------------------- def message(self, msg): """Add the given message to the text; may fail with "Full" """ self.queue.put((self.__message, msg)) def runloop(self): """similar to mainloop, but also checks our Queue""" while 1: try: dispatch = self.queue.get_nowait() except Queue.Empty: root.tk.dooneevent() else: apply(dispatch[0], dispatch[1:]) # Private Methods --------------------------------------------------- def __createGUI(self): """Create all the GUI components""" self.txtFoo = Text(self) self.txtFoo.pack(side=TOP, fill=X, expand=1, padx=10) def __message(self, msg): """Add the given message to the text""" currText = self.txtFoo.get(1.0, END) newText = currText + msg print "About to explode..." self.txtFoo.insert(END, newText) print "We never get here!" # Thread routine ------------------------------------------------------------ def msgThread(delegate): time.sleep(3) delegate.message("Testing") # Main ---------------------------------------------------------------------- root = Tk() gui = frm(root) gui.runloop() From pdetagyos@cox.net Sat Jul 20 22:02:29 2002 From: pdetagyos@cox.net (Peter de Tagyos) Date: Sat, 20 Jul 2002 14:02:29 -0700 Subject: [Pythonmac-SIG] Threading with Tkinter on OSX - Bus Error In-Reply-To: Message-ID: <006CD10B-9C24-11D6-B04C-0003939D32AA@cox.net> Your modifications did the trick. Thanks a lot! For some reason I was thinking that when the delegate.message() routine was being called, it was switching threads. Duuuh. I'll play around with it a bit, and try to figure out a generic message forwarding design. I'll let you know what I come up with, in case anyone is interested. Thanks again for the speedy reply! Peter On Saturday, July 20, 2002, at 12:36 PM, Tony Lownds wrote: > # > -------------------------------------------------------------------------- > # -- > buserr.py ------------------------------------------------------------- > > from Tkinter import * > from threading import * > import time > import Queue > > # Class > frm ---------------------------------------------------------------- > class frm(Frame): > > # Builtins --------------------------------------------------------- > def __init__(self, parent=None): > self.queue = Queue.Queue(10) > Frame.__init__(self, master=parent) > if ((parent.__class__ == Toplevel) or (parent.__class__ == Tk)): > parent.title("Testing") > parent.geometry("400x300") > self.pack() > self.__createGUI() > > # Start the message thread > msgTh = Thread(target=msgThread, args=(self,)) > msgTh.start() > > # Public Interface -------------------------------------------------- > def message(self, msg): > """Add the given message to the text; may fail with "Full" """ > self.queue.put((self.__message, msg)) > > def runloop(self): > """similar to mainloop, but also checks our Queue""" > while 1: > try: > dispatch = self.queue.get_nowait() > except Queue.Empty: > root.tk.dooneevent() > else: > apply(dispatch[0], dispatch[1:]) > > # Private Methods --------------------------------------------------- > def __createGUI(self): > """Create all the GUI components""" > self.txtFoo = Text(self) > self.txtFoo.pack(side=TOP, fill=X, expand=1, padx=10) > > def __message(self, msg): > """Add the given message to the text""" > currText = self.txtFoo.get(1.0, END) > newText = currText + msg > print "About to explode..." > self.txtFoo.insert(END, newText) > print "We never get here!" > > > # Thread > routine ------------------------------------------------------------ > def msgThread(delegate): > time.sleep(3) > delegate.message("Testing") > > > # > Main ---------------------------------------------------------------------- > root = Tk() > gui = frm(root) > gui.runloop() From Jack.Jansen@oratrix.com Sat Jul 20 22:41:15 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 20 Jul 2002 23:41:15 +0200 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: Message-ID: <6AEAAB08-9C29-11D6-BF24-003065517236@oratrix.com> [Kevin, I've remove the wx-people off the cc, I hope you'll summarize for them] On zaterdag, juli 20, 2002, at 04:32 , Kevin Ollivier wrote: > A thought I had (Jack, I hope you're listening =), what do you > guys think about changing the name for "MachoPython" to > MacPythonX while MacPython undergoes the Carbon -> OS X only > transition? I think the name makes it clearer that it's OS X > only, and its probably a bit easier to remember as well for > those not compiling Mac software. =) Also, is the wxPython > Sourceforge site the only place MachoPython is available for > download? To start with the last question: yes, at the moment it is. On to the interesting bit, the naming question. I think the term MachoPython has served us well over the last year (I should think that, I think I was the one to come up with it, or at least picked it up pretty quickly). However, I think it's too techy for a large audience, as the Macho is a pun on the underlying Mach-O executable format, which noone knows or cares about. I want a naming scheme that will allow us to use the name MacPython again (for what is now MachoPython) in a few years/releases. In the mean time, as long as OS9 Python continues to exist it should have a name for itself, to forestall confusion (which is already happening, and which I don't want to get worse). All I can think of is putting a 9 and an X (or possibly an OSX) somewhere in the name. This would lead to combo's like Mac9Python and MacXPython, MacPython9 and MacPythonX, MacPython-OS9 and MacPython-OSX. (Or could we bite the bullet for the 2.3 release and call the old beast MacOS9Python and the new one simply MacPython?) Of these I think I like the first combo best, but that's only because I think the others are worse. Any suggestions for other names? Anyone think we can start using MacPython for Macho already? Any other insights? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tony@lownds.com Sun Jul 21 04:00:38 2002 From: tony@lownds.com (Tony Lownds) Date: Sat, 20 Jul 2002 20:00:38 -0700 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: <6AEAAB08-9C29-11D6-BF24-003065517236@oratrix.com> References: <6AEAAB08-9C29-11D6-BF24-003065517236@oratrix.com> Message-ID: >Or could we bite the bullet for the 2.3 release and call the old >beast MacOS9Python and the new one simply MacPython?) How about MacPython and ClassicPython? That flips the executable-format-designation onto the other beast. ClassicPython also sounds a bit more historical. -Tony From oussoren@cistron.nl Sun Jul 21 10:57:46 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Sun, 21 Jul 2002 11:57:46 +0200 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: Message-ID: <4F0F96DF-9C90-11D6-BF7B-0003931CFE24@cistron.nl> On Sunday, July 21, 2002, at 05:00 , Tony Lownds wrote: > >> Or could we bite the bullet for the 2.3 release and call the old beast >> MacOS9Python and the new one simply MacPython?) > > How about MacPython and ClassicPython? That flips the > executable-format-designation onto the other beast. ClassicPython also > sounds a bit more historical. I like these names. And to answer Jack's other question with a question: Will the 2.3 MachoPython be feature-compatible with MacPython? That is, will it contain the IDE and all other goodies that users expect to be in MacPython? If it does I'm all for renaming MachoPython to MacPython. Ronald From F.Schippers@inter.NL.net Sun Jul 21 15:54:57 2002 From: F.Schippers@inter.NL.net (Frans H. Schippers) Date: Sun, 21 Jul 2002 16:54:57 +0200 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: <4F0F96DF-9C90-11D6-BF7B-0003931CFE24@cistron.nl> References: <4F0F96DF-9C90-11D6-BF7B-0003931CFE24@cistron.nl> Message-ID: >On Sunday, July 21, 2002, at 05:00 , Tony Lownds wrote: > >> >>>Or could we bite the bullet for the 2.3 release and call the old beast MacOS9Python and the new one simply MacPython?) >> >>How about MacPython and ClassicPython? That flips the executable-format-designation onto the other beast. ClassicPython also sounds a bit more historical. > >I like these names. > >And to answer Jack's other question with a question: Will the 2.3 MachoPython be feature-compatible with MacPython? That is, will it contain the IDE and all other goodies that users expect to be in MacPython? If it does I'm all for renaming MachoPython to MacPython. > >Ronald I agree with Ronald. MacPython: for the full featured version with Carbon and in the future Cocoa support. [ We to do some work for this one ] ClassicPython: for the full featured version with Carbon support voor MacOs 8/9 python: for the old style unix version. Frans -- X|support bv mailto:xsupport@inter.nl.net Bezoek Adres: Mollerusweg 150 2031 BZ Haarlem tel: +31 23 5 317 519 fax: +31 23 5 424 282 mbl: +31 653 650 806 Post Adres: Grote Beer 189 1188 AZ Amstelveen Btw: NL-807284324B01 KvK: 33301359 Bank: ING Amstelveen 6533.74.208 From just@letterror.com Sun Jul 21 16:26:17 2002 From: just@letterror.com (Just van Rossum) Date: Sun, 21 Jul 2002 17:26:17 +0200 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: Message-ID: Ronald Oussoren wrote: > And to answer Jack's other question with a question: Will the 2.3 > MachoPython be feature-compatible with MacPython? That is, will it > contain the IDE and all other goodies that users expect to be in > MacPython? If it does I'm all for renaming MachoPython to MacPython. The IDE already works in MachoPython; all of Carbon is available. So I guess the answer is "yes". Frans H. Schippers wrote: > MacPython: > for the full featured version with Carbon and in the future Cocoa support. > [ We to do some work for this one ] > ClassicPython: > for the full featured version with Carbon support voor MacOs 8/9 I quite like the scheme, but there _is_ a problem: ClassicPython *does* run natively under OSX, it doesn't need the Classic environment... Just From tony@lownds.com Sun Jul 21 18:12:12 2002 From: tony@lownds.com (Tony Lownds) Date: Sun, 21 Jul 2002 10:12:12 -0700 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: References: Message-ID: > > MacPython: > > for the full featured version with Carbon and in the future >Cocoa support. > > [ We to do some work for this one ] >> ClassicPython: >> for the full featured version with Carbon support voor MacOs 8/9 > >I quite like the scheme, but there _is_ a problem: ClassicPython *does* run >natively under OSX, it doesn't need the Classic environment... Uh, oops, forgot about that. I guess calling it ClassicPython would be confusing! CarbonPython does not have quite the same ring... -Tony From Jack.Jansen@oratrix.com Sun Jul 21 21:09:11 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 21 Jul 2002 22:09:11 +0200 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: <4F0F96DF-9C90-11D6-BF7B-0003931CFE24@cistron.nl> Message-ID: >>> Or could we bite the bullet for the 2.3 release and call the >>> old beast MacOS9Python and the new one simply MacPython?) >> >> How about MacPython and ClassicPython? That flips the >> executable-format-designation onto the other beast. >> ClassicPython also sounds a bit more historical. > > I like these names. So do I. I think the fact that "Classic" in the name might lead people to believe it has to run under the classic environment isn't so much of a problem: we can explain it in the first sentence in the readme. Moreover, we'll steer OSX users to MacPython anyway. I am a bit worried about there not being a "Mac" in the name, though, so I think I would go for ClassicMacPython or MacPythonClassic. Probably the latter, because it sorts after MacPython, which may be a good thing for people searching versiontracker and such. > And to answer Jack's other question with a question: Will the > 2.3 MachoPython be feature-compatible with MacPython? That is, > will it contain the IDE and all other goodies that users expect > to be in MacPython? If it does I'm all for renaming MachoPython > to MacPython. IDE and the Carbon modules are going to be available. BuildApplet is going to be available. BuildApplication I'm not sure about yet[*]. Numeric and PIL are probably not oging to be included. At least: not by me[**]. [*] If someone is looking for a project: see if you can get BuildApplication-like functionality working for MachoPython. BuildApplet already works for MachoPython (if you run from CVS), the module finder shouldn't be a problem and all modules can be compiled into .pyc files to be stored in the .app bundle too (probably beside __main__.pyc is as goos a place as any other, but packages may need a bit of extra work). The remaining problem is stuffing Python.framework into the .app bundle. This should be doable, if I understand the Apple documentation correctly, by putting it in PrivateFrameworks or SharedFrameworks or some such place, but I've never tried this. [**] If someone is looking for a project: a "batteries included" MacPython 2.3 distribution would be nice. This should include at least the stuff that was included with MacPythonClassic (Tkinter, PIL, Numeric, probably img), but could also include Cocoa, maybe PyOpenGL, maybe wxPython, maybe documentation, .... Actually, what would be nifty is not so much a distribution but a script or set of scripts that can be run to easily create such a distribution. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From just@letterror.com Sun Jul 21 21:14:07 2002 From: just@letterror.com (Just van Rossum) Date: Sun, 21 Jul 2002 22:14:07 +0200 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: Message-ID: Jack Jansen wrote: [BuildApplication-like functionality] > but packages may need a bit of extra work). The remaining > problem is stuffing Python.framework into the .app bundle. This > should be doable, if I understand the Apple documentation > correctly, by putting it in PrivateFrameworks or > SharedFrameworks or some such place, but I've never tried this. I tried this and I couldn't get it to work: the Python.framework could not be found, no matter where I parked it inside the .app bundle. Anyone have a clue? Just From tim.one@comcast.net Sun Jul 21 22:04:02 2002 From: tim.one@comcast.net (Tim Peters) Date: Sun, 21 Jul 2002 17:04:02 -0400 Subject: [Pythonmac-SIG] RE: [Python-Dev] Added platform-specific directories to sys.path In-Reply-To: Message-ID: [Martin v. Loewis] > If that is the platform convention, I see no problem following > it. Windows already does things differently from Unix, by using the > registry to compute sys.path. FYI, this is mostly a myth. In normal operation for most people, Python never gets any info out of the Windows registry. The Python path in the registry is consulted only in unusual situations, when the Python library can't be found under the directory of the executable that called the sys.path-setting code. This can happen when, e.g., Python is embedded in some other app. The process is quite involved; the comment block at the top of PC/getpathp.c is a good summary. When reading it, note that there normally aren't any "application paths" in the registry; e.g., the PLabs Windows installer doesn't create any such beast. From fancher@pacbell.net Sun Jul 21 22:55:46 2002 From: fancher@pacbell.net (bill fancher) Date: Sun, 21 Jul 2002 14:55:46 -0700 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: Message-ID: <9CC34B02-9CF4-11D6-B548-0005029E8B13@pacbell.net> On Sunday, July 21, 2002, at 01:14 PM, Just van Rossum wrote: > Jack Jansen wrote: > > [BuildApplication-like functionality] >> but packages may need a bit of extra work). The remaining >> problem is stuffing Python.framework into the .app bundle. This >> should be doable, if I understand the Apple documentation >> correctly, by putting it in PrivateFrameworks or >> SharedFrameworks or some such place, but I've never tried this. > > I tried this and I couldn't get it to work: the Python.framework could > not be > found, no matter where I parked it inside the .app bundle. Anyone have a > clue? You need a library with a relative install_name. There's an install_name_tool that lets you fiddle with it. The name should locate the framework relative to the application executable, e.g. "@executable_path/../Frameworks". Dyld replaces the "@executable_path" part with the actual path at runtime. -- bill > Just > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob@redivi.com Sun Jul 21 23:46:44 2002 From: bob@redivi.com (Bob Ippolito) Date: Sun, 21 Jul 2002 18:46:44 -0400 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: Message-ID: You not only have to make it in there, but it has to link to the right place .. otool -Lv on the executable should say @executable_path/../PrivateFrameworks/Python.framework/Versions/2.3/Python .. It doesn't work just by dropping it where it needs to go, and I don't know of any tools to change this path in the Mach-O header post-link. This needs to happen when you link the python executable or when you link the framework.. I've had better luck specifying this when building the framework because it doesn't always like to override when you do it for the executable, even though according to docs it should work. Look in the man page for ld, specifically -dylib_file, -bundle_loader, -private_bundle, -dylib_install_name, -dylinker_install_name.. there are a few others if you're doing subframeworks, but those should cover anything you need.. actually if you don't need the private stuff -dylib_install_name may be sufficient (when building the framework) or -dylib_file (when building the executable -- if it works, I've had sketchy results w/ december dev tools.. haven't bothered to try w/ april tools). -bob On Sunday, July 21, 2002, at 04:14 PM, Just van Rossum wrote: > Jack Jansen wrote: > > [BuildApplication-like functionality] >> but packages may need a bit of extra work). The remaining >> problem is stuffing Python.framework into the .app bundle. This >> should be doable, if I understand the Apple documentation >> correctly, by putting it in PrivateFrameworks or >> SharedFrameworks or some such place, but I've never tried this. > > I tried this and I couldn't get it to work: the Python.framework could > not be > found, no matter where I parked it inside the .app bundle. Anyone have > a clue? > > Just From Jack.Jansen@cwi.nl Mon Jul 22 10:00:24 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 22 Jul 2002 11:00:24 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: Message-ID: <75BF7C03-9D51-11D6-9657-0030655234CE@cwi.nl> On Wednesday, July 17, 2002, at 01:12 , Tony Lownds wrote: >> The thing that we now call /Applications/Python.app will become >> hidden: it will move into the Python.framework somewhere. It will also >> *not* advertise (in its .plist file) itself as capable of running >> Python scripts. It will be changed a little, mainly replacing >> macmain.c by the standard Modules/main.c with a little mod to allow it >> to look for __rawmain__.py or .pyc, so it can still be used for >> building applets. The tricky AppleEvent code to create sys.argv on >> startup will be re-implemented in Python, and applets that need it >> will get it in their __rawmain__.py (and that's the only place it will >> be used). > > What will the __name__ inside __rawmain__.py be? I hope that it will > not be '__main__', so that __rawmain__.py can import the "real" __main__ We were thinking __rawmain__.py (or .pyc) would have to be __main__, and we would be doing some magic to run __main__.py (or .pyc) in that same module (by using either execfile or reading the code object from the .pyc file and exec-ing that). But this is a gross hack, so design alternatives are welcome. What I would really like is something along the lines of if exists(argv_emulation_module) run that first run __main__.py or .pyc as __main__ >> There will be a new program /Applications/Python Launcher.app, >> modelled after Java's Applet Launcher (hmm, maybe it should go into >> Utilities?). > > I'd vote for a /Applications/Python folder (consistent with MacPython, > and PythonWin) > > /Applications/Python/Python Launcher.app Good idea! > Will the Python Launcher be buildable from Python's source tree, or > another source tree? If at all possible I want everything to be buildable from the Python source tree. But at some point the other Python developers may start to complain about the amount of cruft we're putting in there. On the other hand: the cruft is pretty localised, I think most of the magic here would be in the Mac/OSX Makefile. >> Python Launcher will get a couple of bells and whistles (modelled >> after how Stuffit Expander works, of all tools:-): if you option-drag >> or option-double-click a script you get a chance to add the verbose >> flag and other flags to Python > > These are set by #! line in UNIX; will that line be consulted? Good idea, there should be an option to honour the #! line, if available, overriding the default interpreter picked for .py or .pyw. I'm not sure whether this option should be on or off by default, though... >> , or pick a diffferent interpreter. > > What does this do? Well, the idea is that if you have two Python's installed (for instance a framework 2.3 and a separate unix-only 2.2.1 in /usr/bin) you can use the 2.3 launcher to launch your script with /usr/bin/python. Or what may be a better example is that sometimes you may want to run your .pyw script in a terminal window, so you don't have to go hunt in the console window for any output it produces. >> Also, if you manually run the launcher you get access to it's >> preferences dialog, where you can set the defaults for these (or >> restore the "factory defaults"), separately for .py and .pyw scripts. > > How do you get to an interactive Python interpreter? I mean, click an > icon, and see a window with: > > Python 2.3a0 (#1, Jul 15 2002, 08:02:36) > [GCC 2.95.2 19991024 (release)] on darwin > Type "help", "copyright", "credits" or "license" for more information. >>>> By chance I was thinking of that while cycling in. I think we need a "Run Interactive Interpreter" command in the launcher. We may need two, even: one using python and one using pythonw. Note that, as Just pointed out, we don't have to make this functionality too obvious, the IDE should be the normal way to do interactive Python. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Mon Jul 22 10:16:58 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 22 Jul 2002 11:16:58 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <2md6tmzpap.fsf@starship.python.net> Message-ID: On Wednesday, July 17, 2002, at 11:17 , Michael Hudson wrote: > What is the current opinion on extension modules? Currently they tend > to end up deep down in > > /Libary/Frameworks/Python.framework/.../site-packages/ > > Wouldn't it be nice if one could build a loadable bundle type thing > that could be installed alongside the framework, or in > > /Library/Application Support/Python > > or somewhere? This could include headers for e.g. Numeric. For the time being I think they're safer inside the framework. The packages have been built with a certain Python, and using them with another Python is not guaranteed to work. But in the long run it would be good to use something like Application Support/Python (and then of course use all of the /, ~/, /Network variations) so your extension packages would survive a re-install of Python. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Mon Jul 22 10:18:21 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 22 Jul 2002 11:18:21 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <576B1DB6-9973-11D6-B37A-0050E4794D0F@uma.pt> Message-ID: On Wednesday, July 17, 2002, at 12:52 , Michael J. Barber wrote: >> There will be a new program /Applications/Python Launcher.app, >> modelled after Java's Applet Launcher (hmm, maybe it should go into >> Utilities?). It will understand two file types: ".py" and ".pyw". > > What will happen with .pyc files? Gee, I don't know! (and disappears in a cloud of smoke:-) I see three options: 1. Don't handle them (i.e. don't list them in the .plist file) 2. Handle them, and use the ".py" setting for determining how to run them 3. Handle them, and provide a third preference (.py/.pyw/.pyc). I'm tempted to go with 1 or 2. Probably 1 unless we're sure that we have the right solution. Suggestions? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From just@letterror.com Mon Jul 22 10:21:16 2002 From: just@letterror.com (Just van Rossum) Date: Mon, 22 Jul 2002 11:21:16 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <75BF7C03-9D51-11D6-9657-0030655234CE@cwi.nl> Message-ID: Jack Jansen wrote: > Note that, as Just pointed out, we don't have to make this functionality > too obvious, the IDE should be the normal way to do interactive Python. The other normal way would be to type "python" in Terminal.app, so I'm not sure Python Launcher needs to supply anything here. Let's keep things simple... Just From Jack.Jansen@cwi.nl Mon Jul 22 10:44:18 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 22 Jul 2002 11:44:18 +0200 Subject: [Pythonmac-SIG] Old messages leaking out Message-ID: <97662C76-9D57-11D6-8599-0030655234CE@cwi.nl> Folks, just now a couple of old messages by me (from last wednesday) finally made it to the list. It may look as if I reversed my standpoint on a couple of issues, but I haven't, really. At the moment I'm in favor of the Application Support solution, and I'm also in favor of handling .pyc files with the Python Launcher. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Mon Jul 22 10:56:46 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 22 Jul 2002 11:56:46 +0200 Subject: [Pythonmac-SIG] Private frameworks In-Reply-To: Message-ID: <55B183F0-9D59-11D6-8599-0030655234CE@cwi.nl> Bob and Bill, if I understand your comments correctly you *must* use the @executable_path trick to use a private framework, is that right? I was hoping that the trick used by Python to locate the framework while in the build directory could somehow be used for the private framework situation too. (Python links to the framework by relative name, i.e. Python.framework, in stead of the normal /Library/Frameworks/Python.framework. This works because there's a search path for frameworks, and I think it should also solve the situation where the framework is stored in ~/Library in stead of /Library, etc) -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tony@lownds.com Mon Jul 22 15:24:40 2002 From: tony@lownds.com (Tony Lownds) Date: Mon, 22 Jul 2002 07:24:40 -0700 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: References: Message-ID: At 6:46 PM -0400 7/21/02, Bob Ippolito wrote: >You not only have to make it in there, but it has to link to the >right place .. otool -Lv on the executable should say >@executable_path/../PrivateFrameworks/Python.framework/Versions/2.3/Python >.. It doesn't work just by dropping it where it needs to go, and I >don't know of any tools to change this path in the Mach-O header >post-link. Bill mentioned the tool: install_name_tool NAME install_name_tool - change dynamic shared library install names SYNOPSIS install_name_tool [-change old new ] ... [-id name] file DESCRIPTION Install_name_tool changes the dynamic shared library install names recorded in a Mach-O binary. For this tool to work when the install names are larger the binary should be built with the ld(1) -header- pad_max_install_names option. ...and it works for what we need it for: ironchef:~% sudo tcsh root# cd /Applications/Python.app/Contents/MacOS/ root# otool -Lv python python: ... Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0) ... root# install_name_tool -change Python.framework/Versions/2.3/Python @executable_path/../Frameworks/Python.framework/Versions/2.3/Python python root# otool -Lv python python: ... @executable_path/../Frameworks/Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0) ... root# mkdir ../Frameworks root# mv /Library/Frameworks/Python.framework ../Frameworks/ root# ./python Pythonw 2.3a0 (#1, Jul 15 2002, 08:02:36) [GCC 2.95.2 19991024 (release)] on darwin Type "copyright", "credits" or "license" for more information. >>> ^D root# Changing the shared library doesn't seem to be necessary. -Tony From Jack.Jansen@cwi.nl Mon Jul 22 15:34:46 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 22 Jul 2002 16:34:46 +0200 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: Message-ID: <2BE22E82-9D80-11D6-AACD-0030655234CE@cwi.nl> Ah, this is good news! Is there anyone here who does *not* have the developer tools installed, and could they please check that they have install_name_tool? Then I think we have a workable solution... On Monday, July 22, 2002, at 04:24 , Tony Lownds wrote: > ironchef:~% sudo tcsh > root# cd /Applications/Python.app/Contents/MacOS/ > root# otool -Lv python > python: > ... > Python.framework/Versions/2.3/Python (compatibility version > 2.3.0, current version 2.3.0) > ... > root# install_name_tool -change Python.framework/Versions/2.3/Python > @executable_path/../Frameworks/Python.framework/Versions/2.3/Python > python > root# otool -Lv python python: > ... > @executable_path/../Frameworks/Python.framework/Versions/2.3/Python > (compatibility version 2.3.0, current version 2.3.0) > ... > root# mkdir ../Frameworks > root# mv /Library/Frameworks/Python.framework ../Frameworks/ > root# ./python > Pythonw 2.3a0 (#1, Jul 15 2002, 08:02:36) > [GCC 2.95.2 19991024 (release)] on darwin > Type "copyright", "credits" or "license" for more information. >>>> ^D > root# -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From oussoren@cistron.nl Mon Jul 22 17:50:13 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Mon, 22 Jul 2002 18:50:13 +0200 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: <2BE22E82-9D80-11D6-AACD-0030655234CE@cwi.nl> Message-ID: <17C21FBA-9D93-11D6-8224-0003931CFE24@cistron.nl> A quick scan through /Library/Receipts seems to indicate that the tool is part of the developer tools: $ find . -name '*.bom' | while read fname; do echo ${fname} \ `lsbom ${fname} | grep install_name_tool`; done | grep install_name_tool ./DevTools.pkg/Contents/Resources/DevTools.bom ./usr/bin/install_name_tool 100555 0/0 109040 2985776814 ./usr/share/man/man1/install_name_tool.1 100444 0/0 1002 1086208193 Is the tool really needed on the system of someone developing with python? If the @executable_path is patched into the system as is you could add (yet) another python binary for use in the output of BuildApplication. Ronald On Monday, July 22, 2002, at 04:34 , Jack Jansen wrote: > Ah, this is good news! > > Is there anyone here who does *not* have the developer tools installed, > and could they please check that they have install_name_tool? Then I > think we have a workable solution... > > From bob@redivi.com Mon Jul 22 19:03:42 2002 From: bob@redivi.com (Bob Ippolito) Date: Mon, 22 Jul 2002 14:03:42 -0400 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: <17C21FBA-9D93-11D6-8224-0003931CFE24@cistron.nl> Message-ID: <5BB10F6C-9D9D-11D6-9C8E-0003938210D6@redivi.com> Well you could reverse engineer the process, or keep a set of diff files to go from the base to any of the others.. or flat out just include install_name_tool in the installer -- which would be useful, because you're going to need it for installing 3rd party .so modules! -bob On Monday, July 22, 2002, at 12:50 PM, Ronald Oussoren wrote: > A quick scan through /Library/Receipts seems to indicate that the tool > is part of the developer tools: > > $ find . -name '*.bom' | while read fname; do echo ${fname} \ > `lsbom ${fname} | grep install_name_tool`; done | grep > install_name_tool > ./DevTools.pkg/Contents/Resources/DevTools.bom > ./usr/bin/install_name_tool 100555 0/0 109040 2985776814 > ./usr/share/man/man1/install_name_tool.1 100444 0/0 1002 1086208193 > > Is the tool really needed on the system of someone developing with > python? If the @executable_path is patched into the system as is you > could add (yet) another python binary for use in the output of > BuildApplication. > > Ronald > > On Monday, July 22, 2002, at 04:34 , Jack Jansen wrote: > >> Ah, this is good news! >> >> Is there anyone here who does *not* have the developer tools >> installed, and could they please check that they have >> install_name_tool? Then I think we have a workable solution... >> >> > From oussoren@cistron.nl Mon Jul 22 19:24:16 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Mon, 22 Jul 2002 20:24:16 +0200 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: <5BB10F6C-9D9D-11D6-9C8E-0003938210D6@redivi.com> Message-ID: <3B2DEE34-9DA0-11D6-8224-0003931CFE24@cistron.nl> On Monday, July 22, 2002, at 08:03 , Bob Ippolito wrote: > Well you could reverse engineer the process, or keep a set of diff > files to go from the base to any of the others.. or flat out just > include install_name_tool in the installer -- which would be useful, > because you're going to need it for installing 3rd party .so modules! The shell output below (in an earlier mail from Tony Lownds) seems to indicate that the path from Python.framework is changed to a string that starts with '@executable_path'. > root# install_name_tool -change Python.framework/Versions/2.3/Python > @executable_path/../Frameworks/Python.framework/Versions/2.3/Python > python > root# otool -Lv python python: > ... > @executable_path/../Frameworks/Python.framework/Versions/2.3/Python > (compatibility version 2.3.0, current version 2.3.0) If I understand this correctly you don't need to change anything on install if you include the modified copy of python as the python inside an application bundle with a local python framework. If you'd provide a python that is changed in this way as part of a 'normal' Python.framework install you could use this when building a python application with a local Python.framework instead of the python executable from Python.app. E.g. no need to use install_name_tool in BuildApplication, or even in the python installer (well except for 3th part .so modules, I haven't thought much about those). Disclaimer: My discussion is purely theoretical based on the last few mails about this subject and a probably forgot about something important ;-| Ronald From Jack.Jansen@cwi.nl Tue Jul 23 12:01:36 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 23 Jul 2002 13:01:36 +0200 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: <3B2DEE34-9DA0-11D6-8224-0003931CFE24@cistron.nl> Message-ID: <8EC6C2BC-9E2B-11D6-9FFB-0030655234CE@cwi.nl> On Monday, July 22, 2002, at 08:24 , Ronald Oussoren wrote: >> root# install_name_tool -change Python.framework/Versions/2.3/Python >> @executable_path/../Frameworks/Python.framework/Versions/2.3/Python >> python >> root# otool -Lv python python: >> ... >> @executable_path/../Frameworks/Python.framework/Versions/2.3/Python >> (compatibility version 2.3.0, current version 2.3.0) > > If I understand this correctly you don't need to change anything on > install if you include the modified copy of python as the python inside > an application bundle with a local python framework. > > If you'd provide a python that is changed in this way as part of a > 'normal' Python.framework install you could use this when building a > python application with a local Python.framework instead of the python > executable from Python.app. E.g. no need to use install_name_tool in > BuildApplication, or even in the python installer (well except for 3th > part .so modules, I haven't thought much about those). I thought along these lines too, but then you can't get command line Python to work anymore. Also, using the framework in embedding applications and things like the Python scripting component would stop working. The functionality of install_name_tool shouldn't be too difficult to duplicate in Python, the structure of MachO binaries appears to be pretty straightforward (see /usr/include/mach-o for details). And otherwise we would require the developer tools for full BuildApplication support. Without the developer tools you would still get partial support: BuildApplication can build an application that has all your .pyc files in there but would depend on Python.framework. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Chris.Barker@noaa.gov Tue Jul 23 18:02:44 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Tue, 23 Jul 2002 10:02:44 -0700 Subject: [Pythonmac-SIG] Extensions for static versus frame References: <75BF7C03-9D51-11D6-9657-0030655234CE@cwi.nl> Message-ID: <3D3D8C34.3CD47293@noaa.gov> Jack Jansen wrote: > By chance I was thinking of that while cycling in. I think we need a > "Run Interactive Interpreter" command in the launcher. We may need two, > even: one using python and one using pythonw. > > Note that, as Just pointed out, we don't have to make this functionality > too obvious, the IDE should be the normal way to do interactive Python. Maybe not obvious, but not hard to find either. I very rarely use the IDE. I really like working in the interpreter (as long as it has readline) > Well, the idea is that if you have two Python's installed (for instance > a framework 2.3 and a separate unix-only 2.2.1 in /usr/bin) you can use > the 2.3 launcher to launch your script with /usr/bin/python. This is a fabulous idea. There is the endless discussion about compatability between versions, and the problem could be easily solved if you have a way to specify in your script what versin is required. Guido doesn't seem to want to put a version specifier in the Python language [*], so what mahy have reversted to is a #! line that specifies a version (I have a lot of: #!/usr/bin/env python2.1 lines at the top of my code). A launcher that parses that line an launches the correct python would be great. Maybe the even the Windows folks can do some thing like this some day. Disk space is cheap. Having five versions of Python on a system is not a big deal anymore. [*] (too bad, wouldn't it be nice to be able to specify what versions your script can use: requires(["2.1", "2.2"]) or something like that? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker@noaa.gov Tue Jul 23 18:08:20 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Tue, 23 Jul 2002 10:08:20 -0700 Subject: [Pythonmac-SIG] Name that Python References: Message-ID: <3D3D8D84.C8284713@noaa.gov> > >> How about MacPython and ClassicPython? That flips the > >> executable-format-designation onto the other beast. > >> ClassicPython also sounds a bit more historical. I seem to be in the minority here, but working in a very Mac-Centric shop that has not adopted OS-X yet (except a few of us doing a little testing), I dont' hink it is yet time to call an OS-X only version "MacPython" I like "MacPython" for the version that will run under either system, and "MacOS-XPython" or "MacPythonX" for the OS-X only version. By the way, I also love the idea of an easy way to get an excessories included MacPython*. The accessories I vote for are: Numeric PIL mxDateTime (or maybe all of the free mx tools) wxPython Easily installed packages are fine, but I'd probably prefer them to be part of the regular install. Disk space is cheap these days. I'd love MacPython to tbe the first distrobution that includes all this stuff! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From larry.bugbee@boeing.com Tue Jul 23 20:28:10 2002 From: larry.bugbee@boeing.com (Bugbee, Larry) Date: Tue, 23 Jul 2002 12:28:10 -0700 Subject: [Pythonmac-SIG] Name that Python Message-ID: <58B6DA1B98AA9149B13B029976A48BCC08799315@xch-nw-31.nw.nos.boeing.com> Hi, I haven't been lurking on this list very long so I apologize if you have already decided, but if not... To Chris' list I'd like to add Tkinter. Correct me if I'm wrong, but I'm getting the impression Tk will either require X11, or be dropped in favor of wxPython. Perhaps selfish, but we chose Tk because it was cross platform... right up until OSX. Life would be easier for me and my users if we had a simple install of the complete Python base. Larry Larry Bugbee Boeing Commercial Airplanes 425-234-8667 larry.bugbee@boeing.com -----Original Message----- From: Chris Barker [mailto:Chris.Barker@noaa.gov] Sent: Tuesday, July 23, 2002 10:08 AM Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Name that Python [snip] The accessories I vote for are: Numeric PIL mxDateTime (or maybe all of the free mx tools) wxPython Easily installed packages are fine, but I'd probably prefer them to be part of the regular install. Disk space is cheap these days. [snip] From bob@redivi.com Tue Jul 23 20:49:06 2002 From: bob@redivi.com (Bob Ippolito) Date: Tue, 23 Jul 2002 15:49:06 -0400 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: <8EC6C2BC-9E2B-11D6-9FFB-0030655234CE@cwi.nl> Message-ID: <3F5E56AA-9E75-11D6-9C8E-0003938210D6@redivi.com> You could make the command line python a stub to do something similar to open -a Python, and either make Resources/MacOS/python smart enough to know if it's CLI or not, or just have a separate binary in there.. like Resources/MacOS/python_unix or something On Tuesday, July 23, 2002, at 07:01 AM, Jack Jansen wrote: > > On Monday, July 22, 2002, at 08:24 , Ronald Oussoren wrote: >>> root# install_name_tool -change Python.framework/Versions/2.3/Python >>> @executable_path/../Frameworks/Python.framework/Versions/2.3/Python >>> python >>> root# otool -Lv python python: >>> ... >>> @executable_path/../Frameworks/Python.framework/Versions/2.3/Python >>> (compatibility version 2.3.0, current version 2.3.0) >> >> If I understand this correctly you don't need to change anything on >> install if you include the modified copy of python as the python >> inside an application bundle with a local python framework. >> >> If you'd provide a python that is changed in this way as part of a >> 'normal' Python.framework install you could use this when building a >> python application with a local Python.framework instead of the python >> executable from Python.app. E.g. no need to use install_name_tool in >> BuildApplication, or even in the python installer (well except for 3th >> part .so modules, I haven't thought much about those). > > I thought along these lines too, but then you can't get command line > Python to work anymore. Also, using the framework in embedding > applications and things like the Python scripting component would stop > working. > > The functionality of install_name_tool shouldn't be too difficult to > duplicate in Python, the structure of MachO binaries appears to be > pretty straightforward (see /usr/include/mach-o for details). And > otherwise we would require the developer tools for full > BuildApplication support. Without the developer tools you would still > get partial support: BuildApplication can build an application that has > all your .pyc files in there but would depend on Python.framework. > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob@redivi.com Tue Jul 23 20:52:10 2002 From: bob@redivi.com (Bob Ippolito) Date: Tue, 23 Jul 2002 15:52:10 -0400 Subject: [Pythonmac-SIG] Name that Python In-Reply-To: <58B6DA1B98AA9149B13B029976A48BCC08799315@xch-nw-31.nw.nos.boeing.com> Message-ID: There's an Aqua version of Tk, but it's somewhat buggy.. Not terribly hard to compile, might as well include it. If you're going to be including PIL and wxPython, should at least include pyOpenGL (maybe we should fork this and make a version that compiles in a straightforward way for MacOS X?).. but possibly also the SDL libraries and pygame. -bob On Tuesday, July 23, 2002, at 03:28 PM, Bugbee, Larry wrote: > Hi, > > I haven't been lurking on this list very long so I apologize if you have > already decided, but if not... To Chris' list I'd like to add Tkinter. > > Correct me if I'm wrong, but I'm getting the impression Tk will either > require X11, or be dropped in favor of wxPython. Perhaps selfish, but > we > chose Tk because it was cross platform... right up until OSX. Life > would > be easier for me and my users if we had a simple install of the complete > Python base. > > Larry > > Larry Bugbee > Boeing Commercial Airplanes > 425-234-8667 > larry.bugbee@boeing.com > > > > -----Original Message----- > From: Chris Barker [mailto:Chris.Barker@noaa.gov] > Sent: Tuesday, July 23, 2002 10:08 AM > Cc: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] Name that Python > > [snip] > > The accessories I vote for are: > > Numeric > PIL > mxDateTime (or maybe all of the free mx tools) > wxPython > > Easily installed packages are fine, but I'd probably prefer them to be > part of the regular install. Disk space is cheap these days. > > [snip] > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@cwi.nl Wed Jul 24 09:22:25 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 24 Jul 2002 10:22:25 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <3D3D8C34.3CD47293@noaa.gov> Message-ID: <7C1CC787-9EDE-11D6-AB50-0030655234CE@cwi.nl> On Tuesday, July 23, 2002, at 07:02 , Chris Barker wrote: > Jack Jansen wrote: > >> By chance I was thinking of that while cycling in. I think we need a >> "Run Interactive Interpreter" command in the launcher. We may need two, >> even: one using python and one using pythonw. >> >> Note that, as Just pointed out, we don't have to make this >> functionality >> too obvious, the IDE should be the normal way to do interactive Python. > > Maybe not obvious, but not hard to find either. I very rarely use the > IDE. I really like working in the interpreter (as long as it has > readline) But note that you do have to build your own interpreter if you want readline support: as far as I know the readline license is still contagious, so readline can't be included with the Mac{ho}Python binary distribution. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From gherman@darwin.in-berlin.de Wed Jul 24 12:31:34 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 24 Jul 2002 13:31:34 +0200 Subject: [Pythonmac-SIG] Need to hand-compile expat on OS X? (Fwd: [XML-SIG] Strange install issue) Message-ID: I think this is the more appropriate place to discuss it... It's the first time I encounter this issue, explicitly com- piling expat on OS X. Can that be true? Python's setup.py mentions something about "convincing the author (James Clark?) to let one allow libexpat.a automati- cally. Sounds all strange to me... Dinu > Von: Etienne Posthumus > Datum: Mi, 24. Jul. 2002 13:14:06 Europe/Berlin > An: Dinu Gherman > Betreff: Re: [XML-SIG] Strange install issue > > On Wed, 24 Jul 2002, Dinu Gherman wrote: > >> I'm a bit puzzled! Moving over to a new machine I found some strange >> errors with simple scripts handling simple XML. After a while, I've >> made a totally new Python 2.2.1 installation (on OS X) with only the >> std.lib. XML modules, but I get the traceback below. On my previous >> machine that worked fine, but there I also had PyXML installed... >> >> Really, all I did was to install Python with ./configure and make >> install... I'd like to have that running before considering to in- >> stall PyXML. Anybody a clue? > > That looks like expat was not compiled in? On OS X the default compile > does not include expat. (at least whenever I compiled it). > You need to edit the modules file and re-compile. > > gr. > > Etienne Posthumus > Amsterdam, Nederland From bob@redivi.com Wed Jul 24 16:55:56 2002 From: bob@redivi.com (Bob Ippolito) Date: Wed, 24 Jul 2002 11:55:56 -0400 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: <7C1CC787-9EDE-11D6-AB50-0030655234CE@cwi.nl> Message-ID: Maybe someone should write a readline-like interface using curses or libedit ? ( http://www.opensource.apple.com/projects/darwin/1.2/source/apsl/Libcurses-23. tar.gz http://www.opensource.apple.com/projects/darwin/1.2/source/apsl/Libedit-18. tar.gz ) Both of these should be BSD. Though it's a bit old, there's apparently also a drop-in replacement for the readline module that uses libedit. ( http://www.python.org/ftp/python/contrib-09-Dec-1999/Misc/editline.README ) I'd really hate to not have readline-like functionality because of a silly licensing issue. -bob On Wednesday, July 24, 2002, at 04:22 AM, Jack Jansen wrote: > > On Tuesday, July 23, 2002, at 07:02 , Chris Barker wrote: > >> Jack Jansen wrote: >> >>> By chance I was thinking of that while cycling in. I think we need a >>> "Run Interactive Interpreter" command in the launcher. We may need >>> two, >>> even: one using python and one using pythonw. >>> >>> Note that, as Just pointed out, we don't have to make this >>> functionality >>> too obvious, the IDE should be the normal way to do interactive >>> Python. >> >> Maybe not obvious, but not hard to find either. I very rarely use the >> IDE. I really like working in the interpreter (as long as it has >> readline) > > But note that you do have to build your own interpreter if you want > readline support: as far as I know the readline license is still > contagious, so readline can't be included with the Mac{ho}Python binary > distribution. > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From just@letterror.com Wed Jul 24 17:44:22 2002 From: just@letterror.com (Just van Rossum) Date: Wed, 24 Jul 2002 18:44:22 +0200 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: Message-ID: Bob Ippolito wrote: > I'd really hate to not have readline-like functionality because of a > silly licensing issue. Me too. An interactive Python interpreter in a terminal window is more or less useless without readline. Just From tony@lownds.com Wed Jul 24 18:38:24 2002 From: tony@lownds.com (Tony Lownds) Date: Wed, 24 Jul 2002 10:38:24 -0700 Subject: [Pythonmac-SIG] Extensions for static versus frame In-Reply-To: References: Message-ID: At 6:44 PM +0200 7/24/02, Just van Rossum wrote: >Bob Ippolito wrote: > >> I'd really hate to not have readline-like functionality because of a >> silly licensing issue. > >Me too. An interactive Python interpreter in a terminal window is more or less >useless without readline. > Me three. It seems to me that the people who would care are those who want to distribute their own code using BuildApplication. They can simply remove readline.so in that case. Or am I missing something obvious? A readline-alternative not yet mentioned is Michael Hudson's Pyrepl, which is way cool: http://starship.python.net/crew/mwh/hacks/pyrepl.html -Tony From doug@sonosphere.com Wed Jul 24 19:38:40 2002 From: doug@sonosphere.com (Doug Wyatt) Date: Wed, 24 Jul 2002 11:38:40 -0700 Subject: [Pythonmac-SIG] Need to hand-compile expat on OS X? (Fwd: [XML-SIG] Strange install issue) In-Reply-To: Message-ID: <93120F34-9F34-11D6-B43A-000393A34B5A@sonosphere.com> [localhost:~/dev/Python-2.2.1] doug% find . -name '*expat*' ./Doc/lib/libpyexpat.tex ./Lib/test/output/test_pyexpat ./Lib/test/test_pyexpat.py ./Lib/xml/parsers/expat.py ./Lib/xml/sax/expatreader.py ./Modules/pyexpat.c ./PCbuild/pyexpat.dsp The expat sources aren't part of the (main) Python source distribution (at least not the one I downloaded), so after building Python I build and install PyXML-0.7.1 and all is well. Doug On Wednesday, Jul 24, 2002, at 04:31 US/Pacific, Dinu Gherman wrote: > I think this is the more appropriate place to discuss it... > It's the first time I encounter this issue, explicitly com- > piling expat on OS X. Can that be true? > > Python's setup.py mentions something about "convincing the > author (James Clark?) to let one allow libexpat.a automati- > cally. Sounds all strange to me... > > Dinu > > >> Von: Etienne Posthumus >> Datum: Mi, 24. Jul. 2002 13:14:06 Europe/Berlin >> An: Dinu Gherman >> Betreff: Re: [XML-SIG] Strange install issue >> >> On Wed, 24 Jul 2002, Dinu Gherman wrote: >> >>> I'm a bit puzzled! Moving over to a new machine I found some strange >>> errors with simple scripts handling simple XML. After a while, I've >>> made a totally new Python 2.2.1 installation (on OS X) with only the >>> std.lib. XML modules, but I get the traceback below. On my previous >>> machine that worked fine, but there I also had PyXML installed... >>> >>> Really, all I did was to install Python with ./configure and make >>> install... I'd like to have that running before considering to in- >>> stall PyXML. Anybody a clue? >> >> That looks like expat was not compiled in? On OS X the default compile >> does not include expat. (at least whenever I compiled it). >> You need to edit the modules file and re-compile. >> >> gr. >> >> Etienne Posthumus >> Amsterdam, Nederland -- Doug Wyatt work: dwyatt@apple.com (CoreAudio) personal: doug@sonosphere.com http://www.sonosphere.com "It is a miracle that curiosity survives formal education." -- Albert Einstein -- Doug Wyatt work: dwyatt@apple.com (CoreAudio) personal: doug@sonosphere.com http://www.sonosphere.com "Live to learn to live." -- Sign at Wat Chedi Luang, Chiang Mai, Thailand From Chris.Barker@noaa.gov Wed Jul 24 19:28:01 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Wed, 24 Jul 2002 11:28:01 -0700 Subject: [Pythonmac-SIG] Status of wxPython on OS-9 ? References: Message-ID: <3D3EF1B1.184F29E5@noaa.gov> Hi all, Does anyone know the status of wxPython on OS-9? As far as I have seen, all of the activity with wxMacPython has been on OS-X, but wxMac is Carbon based, and I believe functional on OS-9, and therefore wxPython on OS-9 should be possible. Is anyone working on it? Has anyone evaluated what it would take to make it work? I am working on persuading my collueges that Python is a fabulous way to develop a large variety of applications, and that wxPython is the way to do GUIs. I have used Python+wxPython for a Linux+Windows app, and it went very well, but we are primarily a Mac house, and have not gone to OS-X yet. Given the inertia of this place, I imagine it will be a while before we do, so we are restricted on most of our projects to tools that support OS-9. We have a couple of very sharp and experienced Mac programmers here, and we may be able to do the wxPython on OS-9 work ourselves, but I would have to persuade my boss that it's a good idea, and the better assesment I can give as to what it would take, the better my chances, so I'm looking for that assessment now. By the way, TKinter is another option, but it looks like it will never work with Carbon, so that may not be workable either. Am I right about that? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From csomor@advanced.ch Wed Jul 24 21:40:30 2002 From: csomor@advanced.ch (Stefan Csomor) Date: Wed, 24 Jul 2002 22:40:30 +0200 Subject: [Pythonmac-SIG] RE: [wxPython-mac] Status of wxPython on OS-9 ? In-Reply-To: <10FE24C8-9F3F-11D6-BF63-0003938210D6@redivi.com> Message-ID: <003501c23352$5d73cc00$0b02a8c0@advancedcsob> Hi wxMac is already fully carbonized there's nothing more to do there, I've once in spring compiled the extensions for Python on classic mac os / carbon, and basically it was running although there were quite a few bugs ;-) I am not sure how much interest on the classic side remains, since till then nobody asked for it once we had it running under OSX. But if there is still interest I'll dig out my notes and attempt a rebuild... Stefan Csomor > -----Original Message----- > From: wxpython-mac-admin@lists.wxwindows.org > [mailto:wxpython-mac-admin@lists.wxwindows.org] On Behalf Of > Bob Ippolito > Sent: Mittwoch, 24. Juli 2002 21:54 > To: wxpython-mac@lists.wxwindows.org > Subject: Re: [wxPython-mac] Status of wxPython on OS-9 ? > > > Tk isn't an option you want to pursue.. it hardly works in OS > X as-is, > and isn't a great solution for Python in the first place. > Even though > it probably wouldn't be a gargantuan effort to make wxMac > fully Carbon > compatible, I don't think anyone is really working at it.. > You may have > to take it on yourself, or just try and migrate to OS X. > Moving to OS X > isn't really something you'll regret, it's definitely my > favorite OS to > develop with and for. > > -bob > > > On Wednesday, July 24, 2002, at 02:28 PM, Chris Barker wrote: > > > Hi all, > > > > Does anyone know the status of wxPython on OS-9? As far as I have > > seen, all of the activity with wxMacPython has been on > OS-X, but wxMac > > is Carbon based, and I believe functional on OS-9, and therefore > > wxPython on OS-9 should be possible. > > > > Is anyone working on it? > > > > Has anyone evaluated what it would take to make it work? > > > > I am working on persuading my collueges that Python is a > fabulous way > > to develop a large variety of applications, and that > wxPython is the > > way to do GUIs. I have used Python+wxPython for a > Linux+Windows app, > > and it went very well, but we are primarily a Mac house, > and have not > > gone to OS-X yet. Given the inertia of this place, I > imagine it will > > be a while before we do, so we are restricted on most of > our projects > > to tools that support OS-9. > > > > We have a couple of very sharp and experienced Mac > programmers here, > > and we may be able to do the wxPython on OS-9 work ourselves, but I > > would have to persuade my boss that it's a good idea, and > the better > > assesment I can give as to what it would take, the better > my chances, > > so I'm looking for that assessment now. > > > > By the way, TKinter is another option, but it looks like it > will never > > work with Carbon, so that may not be workable either. Am I > right about > > that? > > > > -Chris > > > _______________________________________________ > wxPython-mac mailing list > wxPython-mac@lists.wxwindows.org > http://lists.wxwindows.org/mailman/listinfo/wx> python-mac > > From pecora@anvil.nrl.navy.mil Wed Jul 24 22:43:33 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Wed, 24 Jul 2002 17:43:33 -0400 Subject: [Pythonmac-SIG] Numeric Q: How to get DBL_MAX, etc. in Python? Message-ID: In C there are platform-specfic, floating-point constants as follows defined in float.h, /* The largest double precision # */ DBL_MAX (* (double *) __double_max) /* The accuracy of double precision */ #define DBL_EPSILON (* (double *) __double_epsilon) /* The smallest double precision # */ #define DBL_MIN (* (double *) __double_min) Where do these reside in Python? I have looked over my Python manuals and done a Google search, but can't find any reference to them or float/double limits outside of some threads online that are requesting the same as me, but no answers. Are there standard Python functions or globals that return these values for the platform one is operating on? Any help appreciated. Thanks. (I am posting this on the Python Mac Sig list and the Python NG, so sorry if you are seeing it twice.) -- Cheers, Lou Pecora From fgranger@mac.com Thu Jul 25 00:46:25 2002 From: fgranger@mac.com (=?iso-8859-1?Q?Fran=E7ois?= Granger) Date: Thu, 25 Jul 2002 01:46:25 +0200 Subject: [Pythonmac-SIG] RE: [wxPython-mac] Status of wxPython on OS-9 ? In-Reply-To: <003501c23352$5d73cc00$0b02a8c0@advancedcsob> References: <003501c23352$5d73cc00$0b02a8c0@advancedcsob> Message-ID: At 22:40 +0200 24/07/02, in message [Pythonmac-SIG] RE: [wxPython-mac] Status of wxPython o, Stefan Csomor wrote: >Hi > >wxMac is already fully carbonized there's nothing more to do there, I've >once in spring compiled the extensions for Python on classic mac os / >carbon, and basically it was running although there were quite a few >bugs ;-) I am not sure how much interest on the classic side remains, >since till then nobody asked for it once we had it running under OSX. >But if there is still interest I'll dig out my notes and attempt a >rebuild... Ho, yes, please do ! I have not been vocal on this matter since: 1) for me it is a hobby 2) I was feeling that nobody was willing to listen to the fact that OSX force you to change your hardware and OS 9 was here for a long time..... I am currently working on PythonCard. It needs wxPython. To be able to work on it, I bought RealPC and installed it with Windows 98. This is a rela pain on a G4/400 B&W with 128 MB of memory...... Being able to run PythonCard native on a Mac with OS9 would be a real good news. -- =46ran=E7ois Granger fgranger@mac.com please replace this adress with fgranger@altern.org From johnson@pharmacy.arizona.edu Thu Jul 25 01:38:30 2002 From: johnson@pharmacy.arizona.edu (Bruce Johnson) Date: Wed, 24 Jul 2002 17:38:30 -0700 Subject: [Pythonmac-SIG] Rank beginner question... Message-ID: Hmmm...this is clearly a much higher level list than what I need...and on the newsgroup everyone sends Mac questions here, but I'll ask. Is it possible to get a Mac OSX version of Python running that will work on the command line without using Fink? All I've got is a 56k connection to the network, which pretty much rules out fink if I want to do anything but download stuff all the time. I've downloaded the python22_tkinter.tgz from http://tony.lownds.com/macosx/ and installed it, using the instructions for the python2.1 version, that is I untarred it in /usr/local I end up with a Python application in my Home/Applications folder that when run from the desktop merely bounced a few times and goes away. From the command line it gives the error: dyld: /Users/bruce/Applications/Python.app/Contents/MacOS/python can't open library: Python.framework/Versions/2.2/Python (No such file or directory, errno = 2) Obviously I did something wrong, but what? (I did install TK/TCL fine, the Wish.app fires right up...) -- Bruce Johnson Wherever you go, there you are. From jacobkm@cats.ucsc.edu Thu Jul 25 04:35:05 2002 From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss) Date: Wed, 24 Jul 2002 20:35:05 -0700 Subject: [Pythonmac-SIG] Rank beginner question... In-Reply-To: References: Message-ID: Bruce -- If you just download one of the source tarballs from python.org, you can get a Unix-type python easily. Just ./configure, make, and sudo make install. If you want the framework stuff, you'll have to ask someone else -- I've never tried it. Jacob At 5:38 PM -0700 7/24/02, Bruce Johnson wrote: >Hmmm...this is clearly a much higher level list than what I >need...and on the newsgroup everyone sends Mac questions here, but >I'll ask. > >Is it possible to get a Mac OSX version of Python running that will >work on the command line without using Fink? All I've got is a 56k >connection to the network, which pretty much rules out fink if I >want to do anything but download stuff all the time. > >I've downloaded the python22_tkinter.tgz from >http://tony.lownds.com/macosx/ and installed it, using the >instructions for the python2.1 version, that is I untarred it in >/usr/local > >I end up with a Python application in my Home/Applications folder >that when run from the desktop merely bounced a few times and goes >away. > >From the command line it gives the error: > >dyld: /Users/bruce/Applications/Python.app/Contents/MacOS/python >can't open library: Python.framework/Versions/2.2/Python (No such >file or directory, errno = 2) > >Obviously I did something wrong, but what? > >(I did install TK/TCL fine, the Wish.app fires right up...) > >-- >Bruce Johnson > >Wherever you go, there you are. > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig From gherman@darwin.in-berlin.de Thu Jul 25 07:56:22 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Thu, 25 Jul 2002 08:56:22 +0200 Subject: [Pythonmac-SIG] Need to hand-compile expat on OS X? (Fwd: [XML-SIG] Strange install issue) In-Reply-To: <93120F34-9F34-11D6-B43A-000393A34B5A@sonosphere.com> Message-ID: Doug Wyatt: > The expat sources aren't part of the (main) Python source distribution > (at least not the one I downloaded), so after building Python I build > and install PyXML-0.7.1 and all is well. Yes and no. There's a funny debate on this on XML-SIG, for those who want to follow... Dinu From mwh@python.net Thu Jul 25 16:00:38 2002 From: mwh@python.net (Michael Hudson) Date: 25 Jul 2002 16:00:38 +0100 Subject: [Pythonmac-SIG] Rank beginner question... In-Reply-To: Bruce Johnson's message of "Wed, 24 Jul 2002 17:38:30 -0700" References: Message-ID: <2meldrg8dl.fsf@starship.python.net> Bruce Johnson writes: > Hmmm...this is clearly a much higher level list than what I need...and > on the newsgroup everyone sends Mac questions here, but I'll ask. > > Is it possible to get a Mac OSX version of Python running that will work > on the command line without using Fink? Yeah, sure[1]. Just get the source tarball off python.org, and compile it. Should work. Current CVS may be a little better. Cheers, M. [1] I originally typed "Yeah, source" here... -- I'm okay with intellegent buildings, I'm okay with non-sentient buildings. I have serious reservations about stupid buildings. -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year) From mwh@python.net Thu Jul 25 16:03:24 2002 From: mwh@python.net (Michael Hudson) Date: 25 Jul 2002 16:03:24 +0100 Subject: [Pythonmac-SIG] Numeric Q: How to get DBL_MAX, etc. in Python? In-Reply-To: "Louis M. Pecora"'s message of "Wed, 24 Jul 2002 17:43:33 -0400" References: Message-ID: <2mbs8vg88z.fsf@starship.python.net> "Louis M. Pecora" writes: > In C there are platform-specfic, floating-point constants as follows defined in float.h, > > /* The largest double precision # */ > DBL_MAX (* (double *) __double_max) > > /* The accuracy of double precision */ > #define DBL_EPSILON (* (double *) __double_epsilon) > > /* The smallest double precision # */ > #define DBL_MIN (* (double *) __double_min) > > Where do these reside in Python? Nowhere. > I have looked over my Python manuals and done a Google search, but > can't find any reference to them or float/double limits outside of > some threads online that are requesting the same as me, but no > answers. Are there standard Python functions or globals that return > these values for the platform one is operating on? Nope. Obviously writing a C extension to expose these shouldn't be too hard... (although making them constants is inevitably a bit broken -- DBL_EPSILON varies as the rounding mode does, for example). > Any help appreciated. Thanks. Well, not sure this counts. Cheers, M. -- > So what does "abc" / "ab" equal? cheese -- Steve Holden defends obscure semantics on comp.lang.python From ariza@flexatone.com Thu Jul 25 17:32:11 2002 From: ariza@flexatone.com (christopher ariza) Date: Thu, 25 Jul 2002 12:32:11 -0400 (EDT) Subject: [Pythonmac-SIG] xml.dom.minidom error w/ python 2.2.1 as framework In-Reply-To: <20020725160002.8202.16154.Mailman@mail.python.org> Message-ID: just discovered a problem when trying to parse a xml string (or file) using xml.dom.minidom. this problem only emerges when using macho-python installed as a framework. the problem does _not_ happen when using a normal unix (via fink) python, nor when using MacPython. anything im missing? ### MacPython 2.2.1 on OSX------------------------------------ Python 2.2.1 (#134, Apr 9 2002, 21:16:52) [CW CARBON GUSI2 THREADS GC] on mac Type "copyright", "credits" or "license" for more information. >>> import xml.dom.minidom >>> doc = xml.dom.minidom.parseString("my document.") >>> doc ### unix python 2.2------------------------------------------- Python 2.2 (#1, Apr 17 2002, 16:11:12) [GCC 2.95.2 19991024 (release)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import xml.dom.minidom >>> doc = xml.dom.minidom.parseString("my document.") >>> doc ### framework installation of macho-python 2.2.1-------------- Python 2.2.1 (#1, Jul 25 2002, 11:24:12) [GCC 2.95.2 19991024 (release)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import xml.dom.minidom >>> doc = xml.dom.minidom.parseString("my document.") Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/xml/dom/minidom.py", line 967, in parseString return _doparse(pulldom.parseString, args, kwargs) File "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/xml/dom/minidom.py", line 953, in _doparse events = apply(func, args, kwargs) File "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/xml/dom/pulldom.py", line 340, in parseString parser = xml.sax.make_parser() File "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/xml/sax/__init__.py", line 93, in make_parser raise SAXReaderNotAvailable("No parsers found", None) xml.sax._exceptions.SAXReaderNotAvailable: No parsers found From skim@adobe.com Thu Jul 25 17:54:19 2002 From: skim@adobe.com (Sung Kim) Date: Thu, 25 Jul 2002 09:54:19 -0700 Subject: [Pythonmac-SIG] Can embed an extended Python module? Message-ID: <29A8DF62-9FEF-11D6-9C47-003065B90A20@adobe.com> Can a C app embed a Python module, which itself imported a C glue library? Thank you. --Sung H. Kim skim@adobe.com From pecora@anvil.nrl.navy.mil Thu Jul 25 17:53:36 2002 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Thu, 25 Jul 2002 12:53:36 -0400 Subject: [Pythonmac-SIG] Numeric Q: How to get DBL_MAX, etc. in Python? In-Reply-To: <2mbs8vg88z.fsf@starship.python.net> References: <2mbs8vg88z.fsf@starship.python.net> Message-ID: --============_-1184506472==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >"Louis M. Pecora" writes: > >> In C there are platform-specfic, floating-point constants as >>follows defined in float.h, >> >> /* The largest double precision # */ >> DBL_MAX (* (double *) __double_max) >> >> /* The accuracy of double precision */ >> #define DBL_EPSILON (* (double *) __double_epsilon) >> >> /* The smallest double precision # */ >> #define DBL_MIN (* (double *) __double_min) >> >> Where do these reside in Python? > >Nowhere. > >> I have looked over my Python manuals and done a Google search, but >> can't find any reference to them or float/double limits outside of >> some threads online that are requesting the same as me, but no >> answers. Are there standard Python functions or globals that return >> these values for the platform one is operating on? > >Nope. Obviously writing a C extension to expose these shouldn't be >too hard... (although making them constants is inevitably a bit broken >-- DBL_EPSILON varies as the rounding mode does, for example). > >> Any help appreciated. Thanks. > >Well, not sure this counts. > >Cheers, >M. Actually, someone online pointed me to the module that did what I needed: kinds.py in numeric, viz., import kinds kinds.default_float_kind. kinds.default_float_kind.DIG kinds.default_float_kind.EPSILON kinds.default_float_kind.MAX kinds.default_float_kind.MAX_10_EXP kinds.default_float_kind.MAX_EXP kinds.default_float_kind.MIN kinds.default_float_kind.MIN_10_EXP kinds.default_float_kind.MIN_EXP kinds.default_float_kind.RADIX kinds.default_float_kind.ROUNDS kinds.default_float_kind._basic_del kinds.default_float_kind._basic_get kinds.default_float_kind._basic_set kinds.default_float_kind._delete_disallowed kinds.default_float_kind._properties_d kinds.default_float_kind._properties_g kinds.default_float_kind._properties_s kinds.default_float_kind._write_disallowed kinds.default_float_kind.get_property_d kinds.default_float_kind.get_property_g kinds.default_float_kind.get_property_s kinds.default_float_kind.is_internal_attribute kinds.default_float_kind.name kinds.default_float_kind.set_property kinds.default_float_kind.str kinds.default_float_kind.typecode I'd love to know what other neat modules I don't know about (without getting too Zen there). -- Cheers, Lou Pecora --============_-1184506472==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Pythonmac-SIG] Numeric Q: How to get DBL_MAX, et
"Louis M. Pecora" <pecora@anvil.nrl.navy.mil> writes:

> In C there are platform-specfic, floating-point constants as follows defined in float.h,
>
> /* The largest double precision # */
> DBL_MAX                 (* (double *) __double_max)
>
> /* The accuracy of double precision */
> #define DBL_EPSILON     (* (double *) __double_epsilon)
>
> /* The smallest double precision # */
> #define DBL_MIN         (* (double *) __double_min)
>
> Where do these reside in Python? 

Nowhere.

> I have looked over my Python manuals and done a Google search, but
> can't find any reference to them or float/double limits outside of
> some threads online that are requesting the same as me, but no
> answers.  Are there standard Python functions or globals that return
> these values for the platform one is operating on?

Nope.  Obviously writing a C extension to expose these shouldn't be
too hard... (although making them constants is inevitably a bit broken
-- DBL_EPSILON varies as the rounding mode does, for example).

> Any help appreciated. Thanks.

Well, not sure this counts.
Cheers,
M.


Actually, someone online pointed me to the module that did what I needed: kinds.py in numeric, viz.,

import kinds

kinds.default_float_kind.
kinds.default_float_kind.DIG
kinds.default_float_kind.EPSILON
kinds.default_float_kind.MAX
kinds.default_float_kind.MAX_10_EXP
kinds.default_float_kind.MAX_EXP
kinds.default_float_kind.MIN
kinds.default_float_kind.MIN_10_EXP
kinds.default_float_kind.MIN_EXP
kinds.default_float_kind.RADIX
kinds.default_float_kind.ROUNDS
kinds.default_float_kind._basic_del
kinds.default_float_kind._basic_get
kinds.default_float_kind._basic_set
kinds.default_float_kind._delete_disallowed
kinds.default_float_kind._properties_d
kinds.default_float_kind._properties_g
kinds.default_float_kind._properties_s
kinds.default_float_kind._write_disallowed
kinds.default_float_kind.get_property_d
kinds.default_float_kind.get_property_g
kinds.default_float_kind.get_property_s
kinds.default_float_kind.is_internal_attribute
kinds.default_float_kind.name
kinds.default_float_kind.set_property
kinds.default_float_kind.str
kinds.default_float_kind.typecode
I'd love to know what other neat modules I don't know about (without getting too Zen there).


--

Cheers,

Lou Pecora
--============_-1184506472==_ma============-- From Cameron.Lewis@dsto.defence.gov.au Fri Jul 26 03:10:29 2002 From: Cameron.Lewis@dsto.defence.gov.au (Lewis, Cameron) Date: Fri, 26 Jul 2002 12:10:29 +1000 Subject: [Pythonmac-SIG] RE: [wxPython-mac] Status of wxPython o n OS-9 ? Message-ID: According to Steve Jobs 10% of active Mac systems are running Mac OS X with this expected to rise to 20% in a years time. This means that 90% currently aren't running X and 80% won't be in a years time. It would be useful to be able to write GUIs that ran across Classic/X (as well as other platforms). I would like to see wxPython available for Mac OS 9. Cameron Lewis > ---------- > From: Stefan Csomor > Sent: Thursday, July 25, 2002 6:40 AM > To: wxpython-mac@lists.wxwindows.org; pythonmac-sig@python.org; > Chris.Barker@noaa.gov > Subject: [Pythonmac-SIG] RE: [wxPython-mac] Status of wxPython on > OS-9 ? > > Hi > > wxMac is already fully carbonized there's nothing more to do there, I've > once in spring compiled the extensions for Python on classic mac os / > carbon, and basically it was running although there were quite a few > bugs ;-) I am not sure how much interest on the classic side remains, > since till then nobody asked for it once we had it running under OSX. > But if there is still interest I'll dig out my notes and attempt a > rebuild... > > Stefan Csomor > > > -----Original Message----- > > From: wxpython-mac-admin@lists.wxwindows.org > > [mailto:wxpython-mac-admin@lists.wxwindows.org] On Behalf Of > > Bob Ippolito > > Sent: Mittwoch, 24. Juli 2002 21:54 > > To: wxpython-mac@lists.wxwindows.org > > Subject: Re: [wxPython-mac] Status of wxPython on OS-9 ? > > > > > > Tk isn't an option you want to pursue.. it hardly works in OS > > X as-is, > > and isn't a great solution for Python in the first place. > > Even though > > it probably wouldn't be a gargantuan effort to make wxMac > > fully Carbon > > compatible, I don't think anyone is really working at it.. > > You may have > > to take it on yourself, or just try and migrate to OS X. > > Moving to OS X > > isn't really something you'll regret, it's definitely my > > favorite OS to > > develop with and for. > > > > -bob > > > > > > On Wednesday, July 24, 2002, at 02:28 PM, Chris Barker wrote: > > > > > Hi all, > > > > > > Does anyone know the status of wxPython on OS-9? As far as I have > > > seen, all of the activity with wxMacPython has been on > > OS-X, but wxMac > > > is Carbon based, and I believe functional on OS-9, and therefore > > > wxPython on OS-9 should be possible. > > > > > > Is anyone working on it? > > > > > > Has anyone evaluated what it would take to make it work? > > > > > > I am working on persuading my collueges that Python is a > > fabulous way > > > to develop a large variety of applications, and that > > wxPython is the > > > way to do GUIs. I have used Python+wxPython for a > > Linux+Windows app, > > > and it went very well, but we are primarily a Mac house, > > and have not > > > gone to OS-X yet. Given the inertia of this place, I > > imagine it will > > > be a while before we do, so we are restricted on most of > > our projects > > > to tools that support OS-9. > > > > > > We have a couple of very sharp and experienced Mac > > programmers here, > > > and we may be able to do the wxPython on OS-9 work ourselves, but I > > > would have to persuade my boss that it's a good idea, and > > the better > > > assesment I can give as to what it would take, the better > > my chances, > > > so I'm looking for that assessment now. > > > > > > By the way, TKinter is another option, but it looks like it > > will never > > > work with Carbon, so that may not be workable either. Am I > > right about > > > that? > > > > > > -Chris > > > > > > _______________________________________________ > > wxPython-mac mailing list > > wxPython-mac@lists.wxwindows.org > > http://lists.wxwindows.org/mailman/listinfo/wx> python-mac > > > > > > > > > From ross@karchner.com Fri Jul 26 04:34:05 2002 From: ross@karchner.com (Ross M Karchner) Date: Thu, 25 Jul 2002 23:34:05 -0400 Subject: [Pythonmac-SIG] mysqldb on mach-o python? Message-ID: <893E1F38-A048-11D6-AD05-003065F9CDA8@karchner.com> Has anyone been able to build mysqldb on OS X? I am using the binary mach-o python distributed by the people doing the wxPython port, version 2.2.1 I try to build it and get this output: sudo python setup.py build Password: running build running build_py not copying CompatMysqldb.py (output up-to-date) not copying _mysql_exceptions.py (output up-to-date) not copying MySQLdb/__init__.py (output up-to-date) not copying MySQLdb/converters.py (output up-to-date) not copying MySQLdb/connections.py (output up-to-date) not copying MySQLdb/cursors.py (output up-to-date) not copying MySQLdb/sets.py (output up-to-date) not copying MySQLdb/times.py (output up-to-date) not copying MySQLdb/constants/__init__.py (output up-to-date) not copying MySQLdb/constants/CR.py (output up-to-date) not copying MySQLdb/constants/FIELD_TYPE.py (output up-to-date) not copying MySQLdb/constants/ER.py (output up-to-date) not copying MySQLdb/constants/FLAG.py (output up-to-date) not copying MySQLdb/constants/REFRESH.py (output up-to-date) not copying MySQLdb/constants/CLIENT.py (output up-to-date) running build_ext building '_mysql' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -fno-common -dynamic -I/usr/include/mysql -I/Library/Frameworks/Python.framework/Versions/2.2/include/python2.2 -c _mysql.c -o build/temp.darwin-5.5-Power Macintosh-2.2/_mysql.o unable to execute gcc: No such file or directory error: command 'gcc' failed with exit status 1 I am able to get the gcc command to work by hand by removing the -c and escaping the space in Power Macintosh--2.2 with a backslash. If someone has a way to skip the build process, make it work, or simply has a link to a precompiled version I can drop in, I'd love to hear about it. Thanks in advance, -Ross From bob@redivi.com Fri Jul 26 06:40:30 2002 From: bob@redivi.com (Bob Ippolito) Date: Fri, 26 Jul 2002 01:40:30 -0400 Subject: [Pythonmac-SIG] mysqldb on mach-o python? In-Reply-To: <893E1F38-A048-11D6-AD05-003065F9CDA8@karchner.com> Message-ID: <325F82A2-A05A-11D6-9C3E-0003938210D6@redivi.com> On Thursday, July 25, 2002, at 11:34 PM, Ross M Karchner wrote: > Has anyone been able to build mysqldb on OS X? I am using the binary > mach-o python distributed by the people doing the wxPython port, > version 2.2.1 > > I try to build it and get this output: > > -snip- > error: command 'gcc' failed with exit status 1 > > I am able to get the gcc command to work by hand by removing the -c and > escaping the space in Power Macintosh--2.2 with a backslash. If someone > has a way to skip the build process, make it work, or simply has a link > to a precompiled version I can drop in, I'd love to hear about it. > > Thanks in advance, Pretty sure the April dev tools have a gcc link, if not do this: sudo ln -s /usr/bin/gcc2 /usr/bin/gcc If that doesn't work, very likely you don't have April dev tools.. I suggest going ahead and getting them... but if you're against it, just make a link from cc to gcc, it'll make life easier. As far as the space escaping and stuff goes, that's not the problem.. that's just the way distutils prints it out, it's not exactly what you would type if you were to spit it into a shell (but sometimes it is). -bob From Jack.Jansen@cwi.nl Fri Jul 26 09:21:50 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 26 Jul 2002 10:21:50 +0200 Subject: [Pythonmac-SIG] Can embed an extended Python module? In-Reply-To: <29A8DF62-9FEF-11D6-9C47-003065B90A20@adobe.com> Message-ID: On Thursday, July 25, 2002, at 06:54 , Sung Kim wrote: > Can a C app embed a Python module, which itself imported a C glue > library? Thank you. You have to be careful with your terminology here, because I have the feeling it matters (knowing that you've been posting Macho/CFM questions here). The C app will embed the Python interpreter, not a Python module, unless you are doing something out of the ordinary. And the Python module will most likely have been linked to the glue library, not imported it. If this is indeed what you wanted to ask ("Can a C app with an embedded Python interpreter import a module which was linked against a C glue library") then the answer is: yes, in principle there is no problem. There may however be a problem if the glue library expects a different runtime environment than what the embedding app uses (for example: on OS9 this will fail if the glue library is Carbon but the application is Classic). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Fri Jul 26 09:10:28 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 26 Jul 2002 10:10:28 +0200 Subject: [Pythonmac-SIG] Need to hand-compile expat on OS X? (Fwd: [XML-SIG] Strange install issue) In-Reply-To: Message-ID: <25432A2C-A06F-11D6-85BA-0030655234CE@cwi.nl> On Wednesday, July 24, 2002, at 01:31 , Dinu Gherman wrote: > I think this is the more appropriate place to discuss it... > It's the first time I encounter this issue, explicitly com- > piling expat on OS X. Can that be true? > > Python's setup.py mentions something about "convincing the > author (James Clark?) to let one allow libexpat.a automati- > cally. Sounds all strange to me... This is fixed in 2.3a0: Python now simply includes the relevant parts of expat. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Chris.Barker@noaa.gov Fri Jul 26 16:50:31 2002 From: Chris.Barker@noaa.gov (Chris Barker) Date: Fri, 26 Jul 2002 08:50:31 -0700 Subject: [Pythonmac-SIG] RE: [wxPython-mac] Status of wxPython on OS-9 ? References: <003501c23352$5d73cc00$0b02a8c0@advancedcsob> Message-ID: <3D416FC7.D4416336@noaa.gov> Stefan Csomor wrote: > But if there is still interest I'll dig out my notes and attempt a > rebuild... It seems there is a fair bit of interest, so it would be great if you could attempt a rebuild with all the current code. I'm off for a vacation for a couple of weeks, so I won't do anything with it until mid August, but I hope I can get some of our Mac programmers to work on here after that. Thanks for all your replies. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Martina@Oefelein.de Thu Jul 25 21:05:34 2002 From: Martina@Oefelein.de (Martina Oefelein) Date: Thu, 25 Jul 2002 22:05:34 +0200 Subject: [Pythonmac-SIG] webbrowser.py fails on MacOS 9? In-Reply-To: <3D3EF1B1.184F29E5@noaa.gov> References: <3D3EF1B1.184F29E5@noaa.gov> Message-ID: Hi, I'm trying to open a file using the webbrowser module: import webbrowser url ="file:///Falbala/Desktop%20Folder/Betriebsausflug/Site/index.html" webbrowser.open(url) However this results in the following traceback: Traceback (most recent call last): File "Falbala:Dokumente:test.py", line 3, in ? webbrowser.open(url) File "Falbala:Applications (Mac OS 9):Python 2.2.1:Lib:webbrowser.py", line 43, in open get().open(url, new, autoraise) File "Falbala:Applications (Mac OS 9):Python 2.2.1:Lib:webbrowser.py", line 275, in open ic.launchurl(url) File "Falbala:Applications (Mac OS 9):Python 2.2.1:Mac:Lib:ic.py", line 231, in launchurl return _dft_ic.launchurl(url, hint) File "Falbala:Applications (Mac OS 9):Python 2.2.1:Mac:Lib:ic.py", line 194, in launchurl self.ic.ICLaunchURL(hint, url, 0, len(url)) MacOS.Error: (-5012, 'Unknown UserName/UserID or missing comment/APPL entry') What am I doing wrong? ciao Martina From jwblist@olympus.net Sun Jul 28 18:43:34 2002 From: jwblist@olympus.net (John W Baxter) Date: Sun, 28 Jul 2002 10:43:34 -0700 Subject: [Pythonmac-SIG] Rank beginner question... In-Reply-To: References: Message-ID: At 17:38 -0700 7/24/2002, Bruce Johnson wrote: >Is it possible to get a Mac OSX version of Python running that will work >on the command line without using Fink? All I've got is a 56k connection >to the network, which pretty much rules out fink if I want to do >anything but download stuff all the time. Yes. This machine remains a fink-free zone (I don't think I want to buy into their odd placements of things). [And, as you see, while I've installed bash I haven't finished setting up little details like the prompt strings.] April developer tools. bash2.05 john@localhost ~ % python Python 2.2.1 (#1, May 5 2002, 12:25:31) [GCC 2.95.2 19991024 (release)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jwblist@olympus.net Sun Jul 28 18:46:38 2002 From: jwblist@olympus.net (John W Baxter) Date: Sun, 28 Jul 2002 10:46:38 -0700 Subject: [Pythonmac-SIG] Rank beginner question... In-Reply-To: References: Message-ID: At 17:38 -0700 7/24/2002, Bruce Johnson wrote: >Is it possible to get a Mac OSX version of Python running that will work >on the command line without using Fink? All I've got is a 56k connection >to the network, which pretty much rules out fink if I want to do >anything but download stuff all the time. > >I've downloaded the python22_tkinter.tgz from >http://tony.lownds.com/macosx/ and installed it, using the instructions >for the python2.1 version, that is I untarred it in /usr/local Oh, sorry, no interest in tk here (or other GUI stuff). My prior response was pure command line Python. [We don't do GUI python at work (except by writing web pages and letting a browser do the GUI), and I don't have time to do it at home for my own amusement.] --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From zbir@urbanape.com Sun Jul 28 21:07:51 2002 From: zbir@urbanape.com (Zachery Bir) Date: Sun, 28 Jul 2002 16:07:51 -0400 Subject: [Pythonmac-SIG] Somewhere in between fink python and Macpython? Message-ID: Hey, all. Been doing mostly command-line stuff with Python, and I'm trying to get Casey Duncan's zopeedit.py working as a recognizable target for Mac OS X browsers (Moz and IE in particular). I've stripped out the win32 stuff in an attempt to get down to basics, and I've gotten to the point where I can build a double-clickable application with the Macpython build. However, I had to rewrite some of the code, since it would fail creating a temp file with a name longer than 32 characters (Carbon limitation?), and now it breaks being unable to call os.spawnvp. I've Googled for info on spawnvp equivs in the Macpython distribution, but to no avail. Any pointers? Thanks, Zac From Jack.Jansen@oratrix.com Sun Jul 28 21:35:44 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 28 Jul 2002 22:35:44 +0200 Subject: [Pythonmac-SIG] webbrowser.py fails on MacOS 9? In-Reply-To: Message-ID: <972B98A6-A269-11D6-83B1-003065517236@oratrix.com> On donderdag, juli 25, 2002, at 10:05 , Martina Oefelein wrote: > Hi, > > I'm trying to open a file using the webbrowser module: > [...] > File "Falbala:Applications (Mac OS 9):Python > 2.2.1:Mac:Lib:ic.py", line 194, in launchurl > self.ic.ICLaunchURL(hint, url, 0, len(url)) > MacOS.Error: (-5012, 'Unknown UserName/UserID or missing > comment/APPL entry') This looks like a problem with Internet Config (also known nowadays as the "Internet" control panel). Open the control panel, look at the "web" tab, and check that you have something selected as your standard webbrowser (and that that program exists, etc). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From gherman@darwin.in-berlin.de Mon Jul 29 10:35:20 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Mon, 29 Jul 2002 11:35:20 +0200 Subject: [Pythonmac-SIG] Need to hand-compile expat on OS X? (Fwd: [XML-SIG] Strange install issue) In-Reply-To: <25432A2C-A06F-11D6-85BA-0030655234CE@cwi.nl> Message-ID: <7F86947A-A2D6-11D6-B82C-00039345C610@darwin.in-berlin.de> Jack Jansen: > This is fixed in 2.3a0: Python now simply includes the relevant > parts of expat. But when? If it's still a configure/compile-time option when building Python itself, it's hard to ship an expat executable or its source without writing a long install readme and not scare people of from compiling the Python interpreter. This is, of course, true only for "typical" Mac users who probably never run a compiler. If it was a wrapper module in the standard library or one I could put in site-packages, great, but I think this is not the case. It's kind of sad that OS X comes with some batteries excluded, like GNU readline and expat... not to mention a sane version- ing mechanism, which apparently is not really the case for Apple's Installer.app. I know of fink, but this is probably not for the "innocent masses"... So this is the only "solution" I see then, building my own fat Python distribution in this .pkg format with all extra batteries included, if I don't want people to compile stuff. Opinions? Dinu PS: Sorry, Jack if you receive this twice! It should have been sent to the list in the first place... From mwh@python.net Mon Jul 29 10:48:32 2002 From: mwh@python.net (Michael Hudson) Date: 29 Jul 2002 10:48:32 +0100 Subject: [Pythonmac-SIG] Need to hand-compile expat on OS X? (Fwd: [XML-SIG] Strange install issue) In-Reply-To: Dinu Gherman's message of "Mon, 29 Jul 2002 11:35:20 +0200" References: <7F86947A-A2D6-11D6-B82C-00039345C610@darwin.in-berlin.de> Message-ID: <2mr8hmx3tb.fsf@starship.python.net> Dinu Gherman writes: > Jack Jansen: > > > This is fixed in 2.3a0: Python now simply includes the relevant > > parts of expat. > > But when? If it's still a configure/compile-time option when > building Python itself, it's hard to ship an expat executable > or its source without writing a long install readme and not > scare people of from compiling the Python interpreter. This > is, of course, true only for "typical" Mac users who probably > never run a compiler. Huh? It all gets built by setup.py like everything else. > If it was a wrapper module in the standard library or one I > could put in site-packages, great, but I think this is not > the case. Wrong! Cheers, M. -- Or here's an even simpler indicator of how much C++ sucks: Print out the C++ Public Review Document. Have someone hold it about three feet above your head and then drop it. Thus you will be enlightened. -- Thant Tessman From Jack.Jansen@oratrix.com Mon Jul 29 22:44:27 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon, 29 Jul 2002 23:44:27 +0200 Subject: [Pythonmac-SIG] PythonLauncher - first stab available Message-ID: <5AE68EDE-A33C-11D6-B76A-003065517236@oratrix.com> Folks, the first stab at the PythonLauncher has just been checked in to the repository. It's in Mac/OSX/PythonLauncher. I would like people to check it out and comment on the functionality, interface, etc. Here's the checkin message: ------------------------------------- First stab at the launcher application. This will be run when the user doubleclicks a .py, .pyw or .pyc file. It runs the file by invoking the relevant interpreter (either the command line Python in a terminal window or a Python.app for GUI-based scripts). Interpreter to use and the options to pass are settable through preferences. If PythonLauncher wasn't running it does its thing for one script and exits. If it was manually started before a dialog is presented where the user can set the options to use, etc. To be done: - option-drag/doubleclick should always open the interactive dialog - Terminal-window isn't done yet - Should be reimplemented in Python, but pyobjc isn't part of the core. - Various menu entries should be disabled. ----------------------------------- I'd be especially grateful for help on the first, second and third "to be done" items, as I haven't a clue how to get these working. Also, this is my first Cocoa program (aside from doing the two tutorials), so I explicitly request comments on the organization of the classes, etc. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From altis@semi-retired.com Mon Jul 29 22:51:09 2002 From: altis@semi-retired.com (Kevin Altis) Date: Mon, 29 Jul 2002 14:51:09 -0700 Subject: [Pythonmac-SIG] macostools copy function broken in MachoPython build? Message-ID: A friend of mine wanted to start using Python and as his first program he wanted to be able to do a recursive backup of a directory of files to another volume. Since he's on a Mac that means using the copy or copytree functions in order to get the data and resource fork and Finder info. http://www.python.org/doc/current/mac/module-macostools.html However, he's trying to do this on Mac OS X, so I had him go get MachoPython-2.2.1-4.dmg from the wxPython distribution: http://sourceforge.net/project/showfiles.php?group_id=10718&release_id=56880 When we tried using copy function a file not found error was thrown for the destination file. If you go ahead and create a dummy file, the copy still seems to fail, though no errors are thrown. The actual message is: MacOS.Error: (-43, 'File not found') My friend installed MacPython on OS 9 and macostools.copy seemed to work there, though of course the path is done with ':' instead of '/'. Any ideas what we're doing wrong or is this a MachoPython macostools bug? Perhaps this is just a problem with how Robin did the 2.2.1-4 build? I've included some playing around I did in the shell under Mac OS X that shows the error. Sorry about the email line wrapping. ka --- Kevin Altis altis@semi-retired.com --- >>> import os >>> import macostools >>> os.getcwd() '/Users/altis/python/PythonCardPrototype/samples/minimal' >>> filename = 'readme.txt' >>> path = os.path.join(os.getcwd(), filename) >>> path '/Users/altis/python/PythonCardPrototype/samples/minimal/readme.txt' >>> os.path.exists(path) 1 >>> macostools.copy(path, path + '2') Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.2/Mac/Lib/macostools.py", line 88, in copy dstfss = macfs.FSSpec(dst) MacOS.Error: (-43, 'File not found') >>> macostools.macfs >>> macostools.macfs.FSSpec(path) FSSpec((-100, 141127, 'readme.txt')) >>> macostools.macfs.FSSpec(path + '1') Traceback (most recent call last): File "", line 1, in ? MacOS.Error: (-43, 'File not found') From just@letterror.com Mon Jul 29 22:52:16 2002 From: just@letterror.com (Just van Rossum) Date: Mon, 29 Jul 2002 23:52:16 +0200 Subject: [Pythonmac-SIG] macostools copy function broken in MachoPython build? In-Reply-To: Message-ID: Kevin Altis wrote: > A friend of mine wanted to start using Python and as his first program he > wanted to be able to do a recursive backup of a directory of files to > another volume. Since he's on a Mac that means using the copy or copytree > functions in order to get the data and resource fork and Finder info. > > http://www.python.org/doc/current/mac/module-macostools.html > > However, he's trying to do this on Mac OS X, so I had him go get > MachoPython-2.2.1-4.dmg from the wxPython distribution: > > http://sourceforge.net/project/showfiles.php?group_id=10718&release_id=56880 > > When we tried using copy function a file not found error was thrown for the > destination file. If you go ahead and create a dummy file, the copy still > seems to fail, though no errors are thrown. The actual message is: > > MacOS.Error: (-43, 'File not found') > > My friend installed MacPython on OS 9 and macostools.copy seemed to work > there, though of course the path is done with ':' instead of '/'. Any ideas > what we're doing wrong or is this a MachoPython macostools bug? Perhaps this > is just a problem with how Robin did the 2.2.1-4 build? > > I've included some playing around I did in the shell under Mac OS X that > shows the error. Sorry about the email line wrapping. This sounds a lot like this bug I filed the other day: http://www.python.org/sf/585923 Just From oussoren@cistron.nl Tue Jul 30 20:24:59 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Tue, 30 Jul 2002 21:24:59 +0200 Subject: [Pythonmac-SIG] More NIB examples Message-ID: <09F0AD80-A3F2-11D6-8E16-0003931CFE24@cistron.nl> I've some more examples of building NIB-based Cocoa applications in Python, and a heavily modified version of pyobjc to go with those. The 'CurrencyConvertor' applet that Jack posted a while back is now much shorter, and I've added a document based application (the Todo example from Learning Cocoa). The most important change to the pyobjc module is that you can now subclass Objective-C classes in python. These subclasses are both Python classes and Objective-C classes. This is very usefull when your building document based applications. The archive can be downloaded here: http://www.cistron.nl/~oussoren/pyobjc The code is work-in-progress, but usable. I'm developing using a Python 2.3 (from CVS), this is probably required to use the code. Check the readme in the archive for building and usage instructions. The layout of the archive is different from the original pyobjc, but that will change again when we merge the code into the pyobjc repository. Ronald From bbum@codefab.com Tue Jul 30 20:36:44 2002 From: bbum@codefab.com (Bill Bumgarner) Date: Tue, 30 Jul 2002 15:36:44 -0400 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] More NIB examples In-Reply-To: <09F0AD80-A3F2-11D6-8E16-0003931CFE24@cistron.nl> Message-ID: I would not be opposed to seeing these changes checked into the pyobjc repository. Ronald -- Do you have commit rights to the CVS repos? Steve -- If you agree, I say go for it... b.bum On Tuesday, Jul 30, 2002, at 15:24 US/Eastern, Ronald Oussoren wrote: > I've some more examples of building NIB-based Cocoa applications in > Python, and a heavily modified version of pyobjc to go with those. > > The 'CurrencyConvertor' applet that Jack posted a while back is now > much shorter, and I've added a document based application (the Todo > example from Learning Cocoa). > > The most important change to the pyobjc module is that you can now > subclass Objective-C classes in python. These subclasses are both > Python classes and Objective-C classes. This is very usefull when your > building document based applications. > > The archive can be downloaded here: > http://www.cistron.nl/~oussoren/pyobjc > > The code is work-in-progress, but usable. I'm developing using a > Python 2.3 (from CVS), this is probably required to use the code. > Check the readme in the archive for building and usage instructions. > > The layout of the archive is different from the original pyobjc, but > that will change again when we merge the code into the pyobjc > repository. > > Ronald > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > _______________________________________________ > Pyobjc-dev mailing list > Pyobjc-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > b.bum We gladly feast on those who would subdue us. From tony@lownds.com Tue Jul 30 22:43:44 2002 From: tony@lownds.com (Tony Lownds) Date: Tue, 30 Jul 2002 14:43:44 -0700 Subject: [Pythonmac-SIG] PythonLauncher - first stab available In-Reply-To: <5AE68EDE-A33C-11D6-B76A-003065517236@oratrix.com> References: <5AE68EDE-A33C-11D6-B76A-003065517236@oratrix.com> Message-ID: Hi Jack, >I would like people to check it out and comment on the >functionality, interface, etc. Here are some quick notes, before I leave on vacation (returning at end of August). - My .py files already had a preferential application; PythonLauncher didn't get called when I tried clicking for the first time. Unless PythonLauncher can magically take care of enforcing a preference, perhaps the following blurb could be added to the readme: Users of Python.app in previous versions of Python should use the Finder to create the association between .py files and PythonLauncher. Do this by selecting a .py file, choose the "Show Info" menu option under the "File" menu, and make the change in the "Open with Application" pane. Click the "Change All" button and apply it to all files with extension "py". - Is the File > New menu item one of the menu options that will be removed? If not I don't really understand what it does. - One way to do the terminal window bit is to make a temporary file named something.command then using the "open" command: def run_in_terminal(interpreter, script, args): # untested. filename = '/tmp/RunPythonInTerminal.command' handle = open(filename, 'w') handle.write('''#!/bin/sh exec %s %s %s ''' % (interpreter, script, ' '.join(args))) handle.close() os.system("open "+filename) - Are the preferences stored in a per-user area? I didn't get a chance to search thoroughly. >If PythonLauncher wasn't running it does its thing for one script and exits. >If it was manually started before a dialog is presented where the user >can set the options to use, etc. Since one can option-click to open the interactive dialog, and there is a menu item to open the interactive dialog, I'd suggest dropping the modal behavior described above. Basically, double-clicking should always do the same thing. Thanks, -Tony From Y.Benita@pharm.uu.nl Wed Jul 31 08:50:08 2002 From: Y.Benita@pharm.uu.nl (Yair Benita) Date: Wed, 31 Jul 2002 09:50:08 +0200 Subject: [Pythonmac-SIG] The signal module Message-ID: Hi all, I am trying to compile biopython for the mac but I get an import error for the signal module (no module error). Can anybody tell me what is the signal module and how do I get it? I use python 2.2.1 on macos x. Yair -- Yair Benita Pharmaceutical Proteomics Utrecht University From Jack.Jansen@oratrix.com Wed Jul 31 09:49:26 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Wed, 31 Jul 2002 10:49:26 +0200 Subject: [Pythonmac-SIG] PythonLauncher - first stab available In-Reply-To: Message-ID: <6AEE0536-A462-11D6-AFE6-0030655234CE@oratrix.com> On Tuesday, July 30, 2002, at 11:43 , Tony Lownds wrote: > Here are some quick notes, before I leave on vacation (returning at end > of August). > > - My .py files already had a preferential application; PythonLauncher > didn't get called when I tried clicking for the first time. Unless > PythonLauncher can magically take care of enforcing a preference, > perhaps the following blurb could be added to the readme: > > Users of Python.app in previous versions of Python should use the > Finder to create the association between .py files and PythonLauncher. > Do this by selecting a .py file, choose the "Show Info" menu option > under the "File" menu, and make the change in the "Open with > Application" pane. Click the "Change All" button and apply it to all > files with extension "py". Good idea. Alternatively the IDE or PythonLauncher has a way to set those default applications. I'm not sure how to do this, though, maybe the old Internet Config module can still do the trick. > > - Is the File > New menu item one of the menu options that will be > removed? If not I don't really understand what it does. Yes, it should go. Together with "Print" and a couple of other ones. But I have no idea yet how to remove these, there doesn't seem to be a way to disable them in IB, and I haven't yet figured out how to use the automatic-menu-enabling API. > - One way to do the terminal window bit is to make a temporary file > named something.command then using the "open" command: > > def run_in_terminal(interpreter, script, args): > # untested. > filename = '/tmp/RunPythonInTerminal.command' > handle = open(filename, 'w') > handle.write('''#!/bin/sh > exec %s %s %s > ''' % (interpreter, script, ' '.join(args))) > handle.close() > os.system("open "+filename) Yes, but I'll only do that if all else fails. I just found out that the reason I couldn't find a Cocoa OSA client API is simple: there isn't any. There's a server API but no client API. So I'll just use the Carbon OSA client API. > - Are the preferences stored in a per-user area? I didn't get a chance > to search thoroughly. Uhm.... I guess so. It all happens behind my back (NSUserSettings). >> If PythonLauncher wasn't running it does its thing for one script and >> exits. >> If it was manually started before a dialog is presented where the user >> can set the options to use, etc. > > Since one can option-click to open the interactive dialog, and there is > a menu item to open the interactive dialog, I'd suggest dropping the > modal behavior described above. Basically, double-clicking should > always do the same thing. Good idea, *if* we get option-clicking to work. I still have no idea how to proceed. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Wed Jul 31 09:58:45 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 31 Jul 2002 10:58:45 +0200 Subject: [Pythonmac-SIG] The signal module In-Reply-To: Message-ID: On Wednesday, July 31, 2002, at 09:50 , Yair Benita wrote: > Hi all, > I am trying to compile biopython for the mac but I get an import error > for > the signal module (no module error). > Can anybody tell me what is the signal module and how do I get it? > I use python 2.2.1 on macos x. Yair, the signal module is used on unix to catch OS-generated exception conditions. This ranges from "user pressed control-C" (SIGINT) via "floating overflow" (SIGFPE) to signals for programming errors (illegal instruction, access violation). if you're using unix-Python (also known as MachoPython or command-line Python) you should have the signal module. If you don't there's something strange going on with your Python. If you're using MacPython then you don't have the signal module: the concept of "signal" doesn't exist in the Classic/Carbon world that MacPython lives in. How to fix this depends on how the signal module is used. If it's used to detect "unexpected" errors you may be able to simply do away with it (or add a lookalike module that does nothing). If it is used to detect "expected" errors (like floating overflow or underflow) you may have more of a problem. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From ianjones@purgatory.healthmedia.umich.edu Wed Jul 31 14:33:51 2002 From: ianjones@purgatory.healthmedia.umich.edu (Ian McLaury) Date: Wed, 31 Jul 2002 09:33:51 -0400 Subject: [Pythonmac-SIG] PythonLauncher - first stab available In-Reply-To: <6AEE0536-A462-11D6-AFE6-0030655234CE@oratrix.com> References: <6AEE0536-A462-11D6-AFE6-0030655234CE@oratrix.com> Message-ID: At 10:49 AM +0200 7/31/02, Jack Jansen wrote: >Yes, it should go. Together with "Print" and a couple of other ones. >But I have no idea yet how to remove these, there doesn't seem to be >a way to disable them in IB, and I haven't yet figured out how to >use the automatic-menu-enabling API. Open MainMenu.nib in IB, click once on (say) the File menu to open it, once on (say) the New item to select it, and press the delete key. [..] > *if* we get option-clicking to work. I still have no idea how to proceed. In your application delegate, implement the application:openFile: method. From the application parameter, get the current event and check for the option key ('NSAlternateKeyMask'). eg: - (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename { if (([[anApplication currentEvent] modifierFlags] & NSAlternateKeyMask) == 0) { // might also check for whether app is launching if that's important // handle file open here // ... } return YES; } Warning, I just typed this into my mailer. There's more info in a cocoa-dev thread starting here: http://cocoa.mamasam.com/COCOADEV/2002/02/1/25098.php Ian From ianjones@purgatory.healthmedia.umich.edu Wed Jul 31 14:38:33 2002 From: ianjones@purgatory.healthmedia.umich.edu (Ian McLaury) Date: Wed, 31 Jul 2002 09:38:33 -0400 Subject: [Pythonmac-SIG] PythonLauncher - first stab available In-Reply-To: References: <6AEE0536-A462-11D6-AFE6-0030655234CE@oratrix.com> Message-ID: At 9:33 AM -0400 7/31/02, Ian McLaury wrote: >- (BOOL)application:(NSApplication *)theApplication >openFile:(NSString *)filename { > if (([[anApplication currentEvent] modifierFlags] & >NSAlternateKeyMask) == 0) { D'oh, copy & paste error! 'anApplication' on the second line should of course be 'theApplication'. Also, on the thread I pointed out, the most useful Cocoa response comes from Michael Peirce, although a couple people mention Carbon ways to do it. From zbir@urbanape.com Wed Jul 31 17:53:21 2002 From: zbir@urbanape.com (Zachery Bir) Date: Wed, 31 Jul 2002 12:53:21 -0400 Subject: [Pythonmac-SIG] Build of pyobjc and pyobjc-nib failures Message-ID: <055980D4-A4A6-11D6-A99F-000393178DEC@urbanape.com> Hey, all. I'm using a Python2.3 built from CVS, and I get the following failure when trying to build PyObjC: cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double -no-cpp-precomp -I/opt/include/python2.3 -c OC_PythonBundle.m -o build/temp.darwin-5.5-Power Macintosh-2.3/OC_PythonBundle.o -g In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:33, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation. h:5, from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:7, from ObjC.h:31, from OC_PythonBundle.m:17: /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore. framework/Headers/MacTypes.h:291: warning: function declaration isn't a prototype /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore. framework/Headers/MacTypes.h:292: warning: function declaration isn't a prototype OC_PythonBundle.m: In function `+[OC_PythonBundle mainBundle]': OC_PythonBundle.m:75: conflicting types for `getcwd' /usr/include/unistd.h:103: previous declaration of `getcwd' OC_PythonBundle.m:75: warning: extern declaration of `getcwd' doesn't match global one Traceback (most recent call last): File "setup.py", line 26, in ? package_dir = { '':'Examples' } File "/opt/lib/python2.3/distutils/core.py", line 159, in setup raise SystemExit, "error: " + str(msg) SystemExit: error: command 'cc' failed with exit status 1 Running 10.1.5 with the April Dev Tools (but not gcc 3.0) I've installed the 2.3 into /opt Zac From oussoren@cistron.nl Wed Jul 31 18:59:09 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Wed, 31 Jul 2002 19:59:09 +0200 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] Build of pyobjc and pyobjc-nib failures In-Reply-To: <055980D4-A4A6-11D6-A99F-000393178DEC@urbanape.com> Message-ID: <36A3CE2C-A4AF-11D6-8E16-0003931CFE24@cistron.nl> I suppose your building pyobjc 0.6.1. If you remove the prototype for getcwd in OC_PythonBundle it will compile and build. One thing though, you'll probably need a framework install of python if you actually want to use this. At the very least you'll have to start the scripts with an absolute path (some part of Cocoa directly accesses argv[0] and fails if that is not an absolute path). If you're adventurous you could try my version of pyobjc from http://www.cistron/~oussoren/pyobjc. That version is a lot more usefull when you want to play with the combination of Interface Builder and python. That version definitly requires a framework install of python 2.3. Ronald From zbir@urbanape.com Wed Jul 31 19:21:19 2002 From: zbir@urbanape.com (Zachery Bir) Date: Wed, 31 Jul 2002 14:21:19 -0400 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] Build of pyobjc and pyobjc-nib failures In-Reply-To: <36A3CE2C-A4AF-11D6-8E16-0003931CFE24@cistron.nl> Message-ID: <4F3155E2-A4B2-11D6-A99F-000393178DEC@urbanape.com> On Wednesday, July 31, 2002, at 01:59 , Ronald Oussoren wrote: > I suppose your building pyobjc 0.6.1. If you remove the prototype > for getcwd in OC_PythonBundle it will compile and build. I have both the pyobjc and your pyobjc-nib - both break similarly. > One thing though, you'll probably need a framework install of > python if you actually want to use this. At the very least you'll > have to start the scripts with an absolute path (some part of > Cocoa directly accesses argv[0] and fails if that is not an > absolute path). This elusive "framework install". I see this in pyobjc's INSTALL: *** *** NOTE: You must build Python with Objective-C enabled by *** specifying --with-objc to the configure script to use this. *** *** *** NOTE: This no longer seems to be true under OSX Final Candidate *** (and future versions, I would suspect). A build of python *** configured with './configure --with-suffix=.exe --with-threads *** --with-dyld' worked fine! *** I don't think I did anything special when building the 2.3, but I can try to specify those specifically at configure time. What else is required to get the "framework install"? > If you're adventurous you could try my version of pyobjc from > http://www.cistron/~oussoren/pyobjc. That version is a lot more > usefull when you want to play with the combination of Interface > Builder and python. That version definitly requires a framework > install of python 2.3. I've also got your -nib version of the pyobjc, and it breaks similarly. Zac From oussoren@cistron.nl Wed Jul 31 19:39:36 2002 From: oussoren@cistron.nl (Ronald Oussoren) Date: Wed, 31 Jul 2002 20:39:36 +0200 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] Build of pyobjc and pyobjc-nib failures In-Reply-To: <4F3155E2-A4B2-11D6-A99F-000393178DEC@urbanape.com> Message-ID: On Wednesday, July 31, 2002, at 08:21 , Zachery Bir wrote: > On Wednesday, July 31, 2002, at 01:59 , Ronald Oussoren wrote: > >> I suppose your building pyobjc 0.6.1. If you remove the prototype for >> getcwd in OC_PythonBundle it will compile and build. > > I have both the pyobjc and your pyobjc-nib - both break similarly. That's odd. My version doesn't include OC_PythonBundle.m. Could you send the output of setup.py for my version to me (either directly or to the pyobjc-dev list). > > This elusive "framework install". I see this in pyobjc's INSTALL: > > *** > *** NOTE: You must build Python with Objective-C enabled by > *** specifying --with-objc to the configure script to use this. > *** That is another issue, apperently python must be build with an objective-C compiler to be able to use PyObjC. As the next note says, you don't have to do anything special on MacOS X to enable that (the reason is probably that 'cc' on MacOS X is an objective-C compiler). The framework install refers to a special build of python that creates a 'Python.framework' in /Library/Frameworks. Frameworks are basically Apple's solution for shipping shared libraries with supporting files. To build a framework install call configure like this: ./configure --enable-framework. Check out the readme in Mac/OSX for more information. Ronald