🌐 Mailman 3 June 2002 - Pythonmac-SIG - python.org

MacPython vs. Python
by Curtis Galloway June 14, 2002

June 14, 2002

Hi all. I am a longtime Python user on various flavors of UNIX but am relatively new to the Mac world. My only experience has been with OS X, so I am somewhat ignorant about the OS 9 world. I'm interested in wrapping OS X frameworks like CoreFoundation so I can use them from Python. I see that MacPython has wrapped versions, and I also saw something somewhere that said people are working on merging MacPython into the rest of Python. Who's working on that? What's the status? Can I help? I apologize if this is a frequently asked question. --Curtis

2 1

machopython crash on MOSX
by lists June 14, 2002

June 14, 2002

Yo, I'm not sure wether I should post this directly to the list of enter a as bug somewhere. If it needs to be filed as a bug I'd gladly to it, if someone would be kind enough to point me to instructions on how to do it. I've just had a crash (segmentation fault) in machopython. I'm using version 2.2.1 compiled (on MOSX 10.1.4) from source and installed as a framework. I've upgraded to 10.1.5 but dunno if it's related. The crash is totally reproducible OMM. At the python prompt type: help() modules dbm It crashes while generating the list of dbm modules: --- cut help> modules dbm Here is a list of matching modules. Enter any module name to get more help. anydbm - Generic interface to all dbm clones. dbhash - Provide a (g)dbm-compatible interface to bsdhash.hashopen. dumbdbm - A dumb and slow but simple dbm clone. test.test_dbm - Test script for the dbm module test.test_dumbdbm - Test script for the dumbdbm module test.test_gdbm - Test script for the gdbm module dbm Segmentation fault --- cut I'm including the crash log below (the crash was triggered twice). HTH = tmk = --- cut Date/Time: 2002-06-06 09:24:01 +0200 OS Version: 10.1.5 (Build 5S60) Host: localhost Command: python PID: 614 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x031e8dcc Thread 0 Crashed: #0 0x031e8dcc in 0x31e8dcc #1 0x41108ab4 in call_image_init_routines #2 0x41110318 in link_in_need_modules #3 0x41111bc4 in _dyld_link_module #4 0x70015b5c in NSLinkModule #5 0x004470dc in _PyImport_GetDynLoadFunc #6 0x0043c9c8 in _PyImport_LoadDynamicModule #7 0x0043a5e0 in load_module #8 0x0043c554 in imp_load_module #9 0x003f5fb0 in PyCFunction_Call #10 0x00423ef8 in eval_frame #11 0x004253d8 in PyEval_EvalCodeEx #12 0x004269c0 in fast_function #13 0x00423ffc in eval_frame #14 0x004253d8 in PyEval_EvalCodeEx #15 0x004269c0 in fast_function #16 0x00423ffc in eval_frame #17 0x004253d8 in PyEval_EvalCodeEx #18 0x004269c0 in fast_function #19 0x00423ffc in eval_frame #20 0x004253d8 in PyEval_EvalCodeEx #21 0x004269c0 in fast_function #22 0x00423ffc in eval_frame #23 0x004253d8 in PyEval_EvalCodeEx #24 0x004269c0 in fast_function #25 0x00423ffc in eval_frame #26 0x004253d8 in PyEval_EvalCodeEx #27 0x004269c0 in fast_function #28 0x00423ffc in eval_frame #29 0x004253d8 in PyEval_EvalCodeEx #30 0x003e83a0 in function_call #31 0x003d5d30 in PyObject_Call #32 0x003dd934 in instancemethod_call #33 0x003d5d30 in PyObject_Call #34 0x003dce3c in instance_call #35 0x003d5d30 in PyObject_Call #36 0x0042702c in ext_do_call #37 0x00424198 in eval_frame #38 0x004253d8 in PyEval_EvalCodeEx #39 0x003e83a0 in function_call #40 0x003d5d30 in PyObject_Call #41 0x003dd934 in instancemethod_call #42 0x003d5d30 in PyObject_Call #43 0x003dce3c in instance_call #44 0x003d5d30 in PyObject_Call #45 0x00426dcc in do_call #46 0x00424014 in eval_frame #47 0x004253d8 in PyEval_EvalCodeEx #48 0x004205bc in PyEval_EvalCode #49 0x00443480 in run_node #50 0x004421ec in PyRun_InteractiveOneFlags #51 0x00441fb4 in PyRun_InteractiveLoopFlags #52 0x00441e54 in PyRun_AnyFileExFlags #53 0x0044c650 in Py_Main #54 0x00001e1c in _start #55 0x00001c4c in start PPC Thread State: srr0: 0x031e8dcc srr1: 0x4000f030 vrsave: 0x00000000 xer: 0x00000020 lr: 0x41108ac0 ctr: 0x031e8dcc mq: 0x00000000 r0: 0x41108ab4 r1: 0xbfffdf10 r2: 0x00010410 r3: 0x41146060 r4: 0x00000000 r5: 0x00000000 r6: 0x00000000 r7: 0x03115510 r8: 0x03115724 r9: 0x411463a8 r10: 0x03115000 r11: 0x00001ce8 r12: 0x031e8dcc r13: 0x0016647c r14: 0x00000083 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x000535c0 r20: 0x000b32f2 r21: 0x001664a0 r22: 0x00000004 r23: 0x00000000 r24: 0x41148f74 r25: 0x00000001 r26: 0x66000000 r27: 0x41148f98 r28: 0x00000032 r29: 0x031e8dcc r30: 0x41148f70 r31: 0x4110891c ********** Date/Time: 2002-06-06 09:29:15 +0200 OS Version: 10.1.5 (Build 5S60) Host: localhost Command: python PID: 619 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x031a4dcc Thread 0 Crashed: #0 0x031a4dcc in 0x31a4dcc #1 0x41108ab4 in call_image_init_routines #2 0x41110318 in link_in_need_modules #3 0x41111bc4 in _dyld_link_module #4 0x70015b5c in NSLinkModule #5 0x004470dc in _PyImport_GetDynLoadFunc #6 0x0043c9c8 in _PyImport_LoadDynamicModule #7 0x0043a5e0 in load_module #8 0x0043c554 in imp_load_module #9 0x003f5fb0 in PyCFunction_Call #10 0x00423ef8 in eval_frame #11 0x004253d8 in PyEval_EvalCodeEx #12 0x004269c0 in fast_function #13 0x00423ffc in eval_frame #14 0x004253d8 in PyEval_EvalCodeEx #15 0x004269c0 in fast_function #16 0x00423ffc in eval_frame #17 0x004253d8 in PyEval_EvalCodeEx #18 0x004269c0 in fast_function #19 0x00423ffc in eval_frame #20 0x004253d8 in PyEval_EvalCodeEx #21 0x004269c0 in fast_function #22 0x00423ffc in eval_frame #23 0x004253d8 in PyEval_EvalCodeEx #24 0x004269c0 in fast_function #25 0x00423ffc in eval_frame #26 0x004253d8 in PyEval_EvalCodeEx #27 0x004269c0 in fast_function #28 0x00423ffc in eval_frame #29 0x004253d8 in PyEval_EvalCodeEx #30 0x003e83a0 in function_call #31 0x003d5d30 in PyObject_Call #32 0x003dd934 in instancemethod_call #33 0x003d5d30 in PyObject_Call #34 0x003dce3c in instance_call #35 0x003d5d30 in PyObject_Call #36 0x0042702c in ext_do_call #37 0x00424198 in eval_frame #38 0x004253d8 in PyEval_EvalCodeEx #39 0x003e83a0 in function_call #40 0x003d5d30 in PyObject_Call #41 0x003dd934 in instancemethod_call #42 0x003d5d30 in PyObject_Call #43 0x003dce3c in instance_call #44 0x003d5d30 in PyObject_Call #45 0x00426dcc in do_call #46 0x00424014 in eval_frame #47 0x004253d8 in PyEval_EvalCodeEx #48 0x004205bc in PyEval_EvalCode #49 0x00443480 in run_node #50 0x004421ec in PyRun_InteractiveOneFlags #51 0x00441fb4 in PyRun_InteractiveLoopFlags #52 0x00441e54 in PyRun_AnyFileExFlags #53 0x0044c650 in Py_Main #54 0x00001e1c in _start #55 0x00001c4c in start PPC Thread State: srr0: 0x031a4dcc srr1: 0x4000f030 vrsave: 0x00000000 xer: 0x00000020 lr: 0x41108ac0 ctr: 0x031a4dcc mq: 0x00000000 r0: 0x41108ab4 r1: 0xbfffdf10 r2: 0x00010410 r3: 0x41146060 r4: 0x00000000 r5: 0x00000000 r6: 0x00000000 r7: 0x030d1510 r8: 0x030d1724 r9: 0x411463a8 r10: 0x030d1000 r11: 0x00001ce8 r12: 0x031a4dcc r13: 0x001480ac r14: 0x00000083 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x000535c0 r20: 0x000b32f2 r21: 0x001480d0 r22: 0x00000004 r23: 0x00000000 r24: 0x41148f74 r25: 0x00000001 r26: 0x66000000 r27: 0x41148f98 r28: 0x00000032 r29: 0x031a4dcc r30: 0x41148f70 r31: 0x4110891c **********

2 1

RE: [Pythonmac-SIG] proper include for bundled h files
by Magladry, Stephen June 13, 2002

June 13, 2002

Thanks for the reply. I can access the <Python.h> file after adding the access path to the header files. Case appears to be insignificant. I guess this leads to a bigger question on whether what I'm trying to attempt is doable. Here's what we are trying to accomplish. Currently we are developing a product. On the PC side, we use Python as our executable and call out to platform specific stuff and potential Python bottlenecks in c libraries. We have a system setup the generates the interface files so that the Python code and C code stay in sync and are callable back and forth. With Apple's drive to Mach-O and the fact that a single package would help to simplify distribution, I wanted to use the Python Bundle as our app and store the C libraries in the appropriate folder within the bundle and load them from there. Would this be advisable with the current state of the Python bundled app? With the current state of Python Mach-O, should I just fall back to Python CFM and cut my loses now? Thanks for you feedback, Stephen Magladry -----Original Message----- From: Jack Jansen [mailto:Jack.Jansen@oratrix.com] Sent: Tuesday, June 11, 2002 1:19 PM To: Magladry, Stephen Cc: 'pythonmac-sig(a)python.org' Subject: Re: [Pythonmac-SIG] proper include for bundled h files On dinsdag, juni 11, 2002, at 08:38 , Magladry, Stephen wrote: > I am having problems getting the h file recognized from my CW compiles, > using a bundled Python. Here are the steps I have done. > > 1. Downloaded the Python-2.2.1.tgz from python.org > 2. Followed the directions in Mac/OSX folder to build bundled > version of > Python in the default location /Library/Frameworks. > 3. Use CodeWarrior stationary to build a C++ Toolbox Mach-O project. > 4. Add the python.framework to the newly created project. > 5. add a #include <python.h> line to the MyFramework.cp file. > 6. Try to compile. Get a, "The file "python.h" cannot be > opened." error. This will not work with the current state of the Python framework, for a number of reasons. The main reason is that Python.framework is not a full-fledged framework. It is from the execution point of view (i.e. linking against it will do the right thing) but not from the compilation point of view. If it was a full framework you should be able to do #include <Python/Python.h> (the capitalisation may be important), but (a) this hasn't been tested and (b) I strongly advise against this. The reason for advising against this is that all Python extensions in the world do a simple #include "Python.h", and that the organization of the Python directory structure (plus distutils, etc etc etc) is setup to support this usage. If you were to distribute something with the <Python/Python.h> construct it would work only when building for OSX framework installations (and the unix crowds would start slagging us macheads for doing things incompatible, etc etc). The solution is rather simple, though. You not only add the "-framework Python" option to your build, but also "-I/Library/Frameworks/Python.framework/Headers" (or, in CW-speak, add that directory to your search path), and do #include "Python.h" everywhere. Note that there's a precedent for this from Apple too: a similar trick is needed for OpenGL programs that use GLUT (or GLU, I forget). All that said, I haven't tried using the CW Mach-O compiler to build MachoPython extensions (always used the unix tools for MachoPython), so you may run into other snags as well. Please report back here if you get it to work (or not:-). -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

6 6

proper include for bundled h files
by Magladry, Stephen June 11, 2002

June 11, 2002

I am having problems getting the h file recognized from my CW compiles, using a bundled Python. Here are the steps I have done. 1. Downloaded the Python-2.2.1.tgz from python.org 2. Followed the directions in Mac/OSX folder to build bundled version of Python in the default location /Library/Frameworks. 3. Use CodeWarrior stationary to build a C++ Toolbox Mach-O project. 4. Add the python.framework to the newly created project. 5. add a #include <python.h> line to the MyFramework.cp file. 6. Try to compile. Get a, "The file "python.h" cannot be opened." error. I have also tried variations such as <Python.h>, <python/python.h>, not requiring framework style includes. nothing seems to work. Someone see what I am doing wrong?

2 1

Re: Anonymous CVS downloads on OS X
by Andy Wright June 11, 2002

June 11, 2002

On Monday, June 10, 2002, at 12:00 PM, Dan Shafer <dan(a)gui.com> wrote: > I am attempting a completely virgin install of PythonCard on my G3 > laptop under OS X. > > I got machopython and wxpython-mac to install and run just fine. I > wanted to get the cvs on PythonCard, so I ... > ... go into my python code working directory (called pycode), and > type the code from the pythoncard cvs site that is supposed to set up > anonymous access. I just copy and paste it, so I'm sure the syntax is > right. I've done this a few times. > > I get the following error in terminal: > > cvs can't open library: /usr/lib/:libgssapi_krb5.2.2.dylib (No such > file or directory, errno = 2) > > My working hypothesis is that I need to install Dev Tools on this box > to get CVS to work correctly. Dan -- I followed the same procedure you reported above a week ago to get PythonCard 0.6.7 source and got some non-network error as you did. I have the developer tools installed. I also have a copy of the freeware GUI CVS program wrapper AnonymousGet . So I used it, following as a prototype one of its preset sourceForge bookmarks. No problems. Possibly the problem is compatibility of the pythoncard cvs site's recommended anonymous CVS options? BTW, big thanks for your efforts in pythonCard documentation, it counts. -- Andy Wright

2 1

Re: Update feature of BuildApplet - does anyone use it?
by Russell E Owen June 11, 2002

June 11, 2002

>Does anyone use the update feature of BuildApplet? This is the >feature that you can drop an existing applet (of a previous version >of Python, for instance) on BuildApplet, and it will convert it to >the current version of Python. I never even knew this feature existed. I'm happy to update my applets by dragging the source (though I wish the source could optionally be included with the applet, so everything was in one place and I didn't risk losing the source or guessing wrong which source file went with which version of the applet). -- Russell

2 1

Re: [Pythonmac-SIG] problems compiling Python 2.2.1 from source - pyexpat.c module failure
by Bill Bug June 10, 2002

June 10, 2002

Many thanks to Bill F. & Jack for the helpful suggestions. Following Bill's instructions to the letter did the trick. I'd also add the reminder to follow the Python README instructions to the letter. In particular, if you fail to obey the advice below, you will not get through the regression tests: "Mac OS X 10: One of the regular expression tests fails with a SEGV due to the small stack size used by default, if you do "limit stacksize 2048" before "make test" it should work." With that pre-requisite, I know get the following result from running the regression tests: "168 tests OK. 19 tests skipped: test_al test_cd test_cl test_curses test_dl test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_nis test_ntpath test_poll test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 1 skip unexpected on darwin: test_locale" Now, the only module the python configure/setup.py process can't pick-up automagically is the one required to run the localization tests. This is something I believe I can live without, though I'll find out for certain after testing my connection to Apache, MySQL and postgreSQL. I may also end up needing some of the other modules that are not typically loaded in a Darwin install - e.g., socket_ssl, unicode_file, imgfile, etc. I assume this can be done *relatively* easily by placing the proper lines in the Modules/Setup.local file prior to running 'configure'. It sounds like expat will be included as a part of the Python 2.3 source tree, which will definitely make this process go a little easier. Thanks again for the help. Cheers, Bill On Saturday, June 8, 2002, at 06:31 PM, bill fancher wrote: > If you've got the support files, everything Just Works (tm). Here's the > complete drill for installing 2.2.1 with readline (can't live without > this) > and pyexpat: > > #download and install readline > curl -O ftp://ftp.gnu.org/gnu/readline/readline-4.2a.tar.gz > gnutar xzf readline*.gz > cd readline-4.2a > ./configure > make > make install > cd .. > #download and install expat > curl -O > http://telia.dl.sourceforge.net/sourceforge/expat/expat-1.95.3.tar. > gz > tar xzf expat-1.95.3.tar.gz > cd expat-1.95.3 > ./configure > make > make install > cd .. > #download and install python > curl -O ftp://ftp.python.org/pub/python/2.2.1/Python-2.2.1.tgz > tar xzf Python-2.2.1.tgz > cd Python-2.2.1 > # The following line prevents some warnings (maybe) and turns off debug > symbols > # which makes the installation much smaller (~25MB as opposed to ~65MB). > setenv OPT '-no-cpp-precomp -O3' > ./configure > make > make install > cd .. > > To build as a framework, change the last four lines to: > > ./configure --enable-framework > make > make frameworkinstall > cd .. > > HTH, > > -- > bill > > On Saturday, June 8, 2002, at 09:25 AM, John Miller wrote: > >> I first want to thank Bill for submitting this detailed information, >> and second, I want to confirm that exactly the same happened with me >> on both my desktop and laptop MacOS X machines (except that I didn't >> '--enable-framework'). If anyone can tell us how to fix this, I'd be >> very appreciative. I'm glad that Just told us the workaround, but I'm >> more interested in having the installation process work 'out of the >> box', if possible. >> >> John Miller >> >> >> On Friday, June 7, 2002, at 12:00 PM, Bill Bug <bbug(a)speakeasy.org> >> wrote: >> >>> >>> Hi All, >>> >>> I've gotten stuck in my attempt to compile Python 2.2.1 from the >>> source >>> tarball on my 10.1.5 OS X machine that has the Apple Dev Suite >>> installed >>> with a functional gcc compiler. >>> >>> Any help/corrections y'all could provide would be greatly appreciated. >>> >>> Following the very clear README instructions on how to compile for Mac >>> OS X, I built the Python core and most all the modules just fine using >>> the recommended configure command: >>> >>> ./configure --enable-framework >>> >>> I was even able to get my installed build to pass most all the >>> <tests>.py. >>> >>> All, that is, except for one module I know I need to use - and that >>> the >>> 'smart' compile test suite knows should be functional under Darwin & >>> OS >>> X. The module in question is pyexpat.o - the Python EXPAT-based XML >>> Parser module. The SAX module is also not created, since it requires >>> an >>> XML parser, which it expects will be coming via pyexpat.o. >>> >>> I hunted through the Setup files in the /Modules directory and >>> uncovered >>> the line used by setup.py to create the compiler call designed to >>> build >>> this package. >>> >>> #EXPAT_DIR=/usr/local/src/expat >>> #pyexpat pyexpat.c -I$(EXPAT_DIR)/xmlparse -L$(EXPAT_DIR) -lexpat >>> >>> Unfortunately, my version of OS X does not contain that path, though >>> it >>> does contain EXPAT at /usr/local/expat. >>> >>> To make a long story a bit shorter, I downloaded the EXPAT source and >>> compiled it, just to make certain I had all the components required by >>> pyexpat.c. That placed the files the Python expat module requires - >>> expat.h & libexpat.a - at /usr/local/include and /usr/local/lib, >>> respectively. That installation tested just fine. >>> >>> I then added the following lines to my >>> <PYTHON_HOME>/Modules/Setup.local >>> file: >>> EXPAT_DIR=/usr/local/ >>> pyexpat pyexpat.c -I$(EXPAT_DIR)/include -L$(EXPAT_DIR)/lib -lexpat >>> >>> This info is used by the following code in setup.py to create the call >>> to the gcc: >>> >>> expat_defs = [] >>> expat_incs = find_file('expat.h', inc_dirs, []) >>> if expat_incs is not None: >>> # expat.h was found >>> expat_defs = [('HAVE_EXPAT_H', 1)] >>> else: >>> expat_incs = find_file('xmlparse.h', inc_dirs, []) >>> >>> if (expat_incs is not None and >>> self.compiler.find_library_file(lib_dirs, 'expat')): >>> exts.append( Extension('pyexpat', ['pyexpat.c'], >>> define_macros = expat_defs, >>> libraries = ['expat']) ) >>> >>> The following lines in the 'find_file(filename, std_dirs, paths) >>> function ultimately define whether the proper gcc call will get >>> constructed: >>> >>> f = os.path.join(dir, filename) >>> if os.path.exists(f): return [] >>> >>> Based on these lines, the call expat_incs = find_file('expat.h', >>> inc_dirs, []) returns an empty array when it finds the 'expat.h' file >>> at >>> one of the include paths in 'inc_dirs'. Because of this, the line >>> 'expat_defs = [('HAVE_EXPAT_H', 1)]' is never run and the >>> 'HAVE_EXPAT_H' >>> macro is not defined during compilation. >>> >>> This creates the following line in the makefile: >>> cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -fno-common >>> -dynamic -I. -I./Include -DHAVE_CONFIG_H -I/usr/local/include -c >>> ./Modules/pyexpat.c -o Modules/pyexpat.o >>> >>> which leads to the following stderr msg during compilation: >>> ./Modules/pyexpat.c:20: xmlparse.h: No such file or directory >>> make: *** [Modules/pyexpat.o] Error 1 >>> >>> Examining the pyexpat.c source file shows this line is nested >>> amongst a >>> set of pre-proc directives. I've listed these nested booleans below >>> with the offending line marked with an arrow. >>> >>> #ifdef HAVE_EXPAT_H >>> #include "expat.h" >>> #ifdef XML_MAJOR_VERSION >>> #define EXPAT_VERSION (0x10000 * XML_MAJOR_VERSION \ >>> + 0x100 * XML_MINOR_VERSION \ >>> + XML_MICRO_VERSION) >>> #else >>> /* Assume the oldest Expat that used expat.h and did not >>> have version info */ >>> #define EXPAT_VERSION 0x015f00 >>> #endif >>> #else /* !defined(HAVE_EXPAT_H) */ >>> ---> #include "xmlparse.h" >>> /* Assume Expat 1.1 unless told otherwise */ >>> #ifndef EXPAT_VERSION >>> #define EXPAT_VERSION 0x010100 >>> #endif >>> #endif /* !defined(HAVE_EXPAT_H) */ >>> >>> A quick scan of the logic confirms what I believe I see in setup.py - >>> the 'HAVE_EXPAT_H' macro is not getting defined, because 'find_file'() >>> in setup.py DOES find 'expat.h' at one of the paths in the INCLUDED >>> directories variable sent into setup.py. >>> >>> Have I misunderstood the compiler call in the makefile? Have I >>> misunderstood what setup.py doing? I can't imagine why it would fail >>> for this one module and work for all the others. Does that relate to >>> the fact that the this is the only module being defined via >>> Setup.local? >>> >>> Not surprisingly, the following lines then show up when running the >>> installation tests, along with many other statements: >>> ... >>> test test_pyexpat skipped -- No module named pyexpat >>> test test_sax skipped -- no XML parsers available >>> ... >>> 3 skips unexpected on darwin: >>> test_sax test_locale test_pyexpat >>> ... >>> >>> Once again, thanks very much for any assistance you can offer. >>> >>> Cheers, >>> Bill Bug >>> Senior Analyst >>> Computer Vision Lab for Vertebrate Brain Mapping >>> MCP/Hahnemann University >>> Philadelphia, PA, USA 19129 >> >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > Bill Bug Senior Analyst/Ontological Engineer Computer Vision Laboratory for Vertebrate Brain Mapping (CVLVBM) MCP/Hahnemann University 2900 Queen Lane Philadelphia, PA 19129 William.Bug(a)drexel.edu

1 0

Update feature of BuildApplet - does anyone use it?
by Jack Jansen June 10, 2002

June 10, 2002

Does anyone use the update feature of BuildApplet? This is the feature that you can drop an existing applet (of a previous version of Python, for instance) on BuildApplet, and it will convert it to the current version of Python. I'm asking because (a) I suspect that it doesn't work, and hasn't worked for a long time and (b) it complicates the code, so I want to get rid of it. -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

6 5

Does CVS Require dev Tools?
by Dan Shafer June 10, 2002

June 10, 2002

I am attempting a completely virgin install of PythonCard on my G3 laptop under OS X. I got machopython and wxpython-mac to install and run just fine. I wanted to get the cvs on PythonCard, so I went into terminal and typed which cvs to be sure I had it. I do. It's at /usr/bin/cvs Cool. So I go into my python code working directory (called pycode), and type the code from the pythoncard cvs site that is supposed to set up anonymous access. I just copy and paste it, so I'm sure the syntax is right. I've done this a few times. I get the following error in terminal: cvs can't open library: /usr/lib/:libgssapi_krb5.2.2.dylib (No such file or directory, errno = 2) My working hypothesis is that I need to install Dev Tools on this box to get CVS to work correctly. is that the case? If not, what am I missing or doing wrong here? Just for completeness, the code to activate cvs I'm running, taken from the site, is: cvs -d:pserver:anonymous@cvs.pythoncard.sourceforge.net:/cvsroot/pythoncard login Thanks for the help. -- Dan Shafer, Product Development Expert Helping you turn your best ideas into products that sell http://www.danshafer.com

2 2

problems compiling Python 2.2.1 from source - pyexpat.c module failure
by Bill Bug June 9, 2002

June 9, 2002

Hi All, I've gotten stuck in my attempt to compile Python 2.2.1 from the source tarball on my 10.1.5 OS X machine that has the Apple Dev Suite installed with a functional gcc compiler. Any help/corrections y'all could provide would be greatly appreciated. Following the very clear README instructions on how to compile for Mac OS X, I built the Python core and most all the modules just fine using the recommended configure command: ./configure --enable-framework I was even able to get my installed build to pass most all the <tests>.py. All, that is, except for one module I know I need to use - and that the 'smart' compile test suite knows should be functional under Darwin & OS X. The module in question is pyexpat.o - the Python EXPAT-based XML Parser module. The SAX module is also not created, since it requires an XML parser, which it expects will be coming via pyexpat.o. I hunted through the Setup files in the /Modules directory and uncovered the line used by setup.py to create the compiler call designed to build this package. #EXPAT_DIR=/usr/local/src/expat #pyexpat pyexpat.c -I$(EXPAT_DIR)/xmlparse -L$(EXPAT_DIR) -lexpat Unfortunately, my version of OS X does not contain that path, though it does contain EXPAT at /usr/local/expat. To make a long story a bit shorter, I downloaded the EXPAT source and compiled it, just to make certain I had all the components required by pyexpat.c. That placed the files the Python expat module requires - expat.h & libexpat.a - at /usr/local/include and /usr/local/lib, respectively. That installation tested just fine. I then added the following lines to my <PYTHON_HOME>/Modules/Setup.local file: EXPAT_DIR=/usr/local/ pyexpat pyexpat.c -I$(EXPAT_DIR)/include -L$(EXPAT_DIR)/lib -lexpat This info is used by the following code in setup.py to create the call to the gcc: expat_defs = [] expat_incs = find_file('expat.h', inc_dirs, []) if expat_incs is not None: # expat.h was found expat_defs = [('HAVE_EXPAT_H', 1)] else: expat_incs = find_file('xmlparse.h', inc_dirs, []) if (expat_incs is not None and self.compiler.find_library_file(lib_dirs, 'expat')): exts.append( Extension('pyexpat', ['pyexpat.c'], define_macros = expat_defs, libraries = ['expat']) ) The following lines in the 'find_file(filename, std_dirs, paths) function ultimately define whether the proper gcc call will get constructed: f = os.path.join(dir, filename) if os.path.exists(f): return [] Based on these lines, the call expat_incs = find_file('expat.h', inc_dirs, []) returns an empty array when it finds the 'expat.h' file at one of the include paths in 'inc_dirs'. Because of this, the line 'expat_defs = [('HAVE_EXPAT_H', 1)]' is never run and the 'HAVE_EXPAT_H' macro is not defined during compilation. This creates the following line in the makefile: cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -fno-common -dynamic -I. -I./Include -DHAVE_CONFIG_H -I/usr/local/include -c ./Modules/pyexpat.c -o Modules/pyexpat.o which leads to the following stderr msg during compilation: ./Modules/pyexpat.c:20: xmlparse.h: No such file or directory make: *** [Modules/pyexpat.o] Error 1 Examining the pyexpat.c source file shows this line is nested amongst a set of pre-proc directives. I've listed these nested booleans below with the offending line marked with an arrow. #ifdef HAVE_EXPAT_H #include "expat.h" #ifdef XML_MAJOR_VERSION #define EXPAT_VERSION (0x10000 * XML_MAJOR_VERSION \ + 0x100 * XML_MINOR_VERSION \ + XML_MICRO_VERSION) #else /* Assume the oldest Expat that used expat.h and did not have version info */ #define EXPAT_VERSION 0x015f00 #endif #else /* !defined(HAVE_EXPAT_H) */ ---> #include "xmlparse.h" /* Assume Expat 1.1 unless told otherwise */ #ifndef EXPAT_VERSION #define EXPAT_VERSION 0x010100 #endif #endif /* !defined(HAVE_EXPAT_H) */ A quick scan of the logic confirms what I believe I see in setup.py - the 'HAVE_EXPAT_H' macro is not getting defined, because 'find_file'() in setup.py DOES find 'expat.h' at one of the paths in the INCLUDED directories variable sent into setup.py. Have I misunderstood the compiler call in the makefile? Have I misunderstood what setup.py doing? I can't imagine why it would fail for this one module and work for all the others. Does that relate to the fact that the this is the only module being defined via Setup.local? Not surprisingly, the following lines then show up when running the installation tests, along with many other statements: ... test test_pyexpat skipped -- No module named pyexpat test test_sax skipped -- no XML parsers available ... 3 skips unexpected on darwin: test_sax test_locale test_pyexpat ... Once again, thanks very much for any assistance you can offer. Cheers, Bill Bug Senior Analyst Computer Vision Lab for Vertebrate Brain Mapping MCP/Hahnemann University Philadelphia, PA, USA 19129

3 2