Re: [Pythonmac-SIG] Crossfold Validation
On 2010-02-19 18:29 PM, Aahz wrote: On Fri, Feb 19, 2010, Mark Livingstone wrote: I am looking for suggestions! I am doing some experimentation and want to know if there are any utilities available that will take a file as input, get the num folds and num times, and do the slice and dice file operation ready then for training / testing? You will need to expand your jargon if you want anyone unfamiliar with this specific operation to provide assistance. (I.e. I have no clue what you're talking about.) It's really off-topic for this list, but K-fold cross-validation is a way of testing how well some prediction method will perform. Roughly, you split up the data into K chunks. You use K-1 chunks to train your method and test on the remaining chunk. You then repeat this K times with each chunk playing the role of the test chunk exactly once. Then you average the performance of your prediction method over each of the K tests. Mark, I recommend that you join the scipy-users mailing list. We'll be happy to field your data analysis questions over there. These kinds of questions really are unrelated to the Apple platform even if you intend to do the analysis on an Apple machine. http://www.scipy.org/Mailing_Lists You may also want to check the SpamBayes project. Their validation framework might be applicable to your problem set. http://spambayes.sourceforge.net/ -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Unwanted PPC build in setuptools
On 2009-10-22 07:02 AM, Ronald Oussoren wrote: On 21 Oct, 2009, at 22:14, Dave Peterson wrote: Ronald Oussoren wrote: On 19 Oct, 2009, at 23:20, Robert Kern wrote: I presume he's using the Enthought Python Distribution (disclosure: I work for Enthought), which does have such a version number. It's basically a not-entirely-palatable hack to make sure that users can install and uninstall EPD in order to try it out without breaking their previously installed Pythons. Wouldn't it be better to use '--with-framework-name', IIRC I introduced that in 2.6: ./configure --enable-framework --with-framework-name=EPD This will create a framework named 'EPD.framework' instead of 'Python.framework'. (I also work for Enthought) EPD is still using Python 2.5 as its base, though we expect to be on 2.6 shortly. I'm not clear on what the name of the framework effects. Would you be able to install pre-built binary distributions, built against an EPD framework, into a Python framework? And vice-versa? If not, then this probably isn't a usable solution for us. Extensions are not linked to the framework, extensions build for a Python.framework should therefore work unchanged in a EPD.framework. That said, I haven't checked yet if 3th party tools work with a renamed Python framework, I know that py2app hardcodes the name Python.framework and IIRC virtualenv does the same. Both could and should be changed, and that's something on my todo list for various reasons. One of which is that I want to have side-by-side installs of a couple of build variations of Python on my machine. It would be great to see more support for alternative framework names. It would be a much better alternative. There are also other packages, primary non-Python ones like VTK, that still expect Python.framework. With enough effort, I assume we can make them work, though. At the time we did this, the version number change seemed like an easier alternative. It tends to only generate a couple of WTF? moments rather than real problems, and we are the ones who usually get the support emails. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Unwanted PPC build in setuptools
On 2009-10-21 14:59 PM, Ronald Oussoren wrote: On 19 Oct, 2009, at 23:20, Robert Kern wrote: Edit /Library/Frameworks/.../lib/python2.5/config/Makefile to remove the occurrences of -arch ppc if you never want to build PPC versions of stuff again. More recent versions of EPD should have that done already. Patching the installation is evil. I would agree that patching the *code* is evil, but the Makefile is really just a datastore for the default configuration information for distutils. If you know what you're doing, I say feel free. distutils doesn't give us another way to change this default configuration. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Unwanted PPC build in setuptools
On 2009-10-19 15:59 PM, Ronald Oussoren wrote: On 19 Oct, 2009, at 22:47, Chris Fonnesbeck wrote: Is there any way of convincing setuptools to *not* build for PPC? For some reason, it tries to build a universal binary by default: g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk ...etc Which results in errors: ld warning: in /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/Python.framework/Versions/4.3.0/lib/libz.dylib, file is not of required architecture ld: in /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/Python.framework/Versions/4.3.0/lib/libz.1.dylib, file is not of required architecture for architecture ppc I have no interest in building universals -- how can I switch this off? I already tried putting -arch i386 in my LDFLAGS, but to no avail. Edit /Library/Frameworks/.../lib/python2.5/config/Makefile to remove the occurrences of -arch ppc if you never want to build PPC versions of stuff again. More recent versions of EPD should have that done already. Add ['-arch', 'i386'] to both extra_compile_args and extra_link args of the Extension objects. Will that get rid of the pre-existing -arch ppc flags? BTW. The path's in the error-messages above are fishy, there shouldn't be a '4.3.0' version in Python.framework. I presume he's using the Enthought Python Distribution (disclosure: I work for Enthought), which does have such a version number. It's basically a not-entirely-palatable hack to make sure that users can install and uninstall EPD in order to try it out without breaking their previously installed Pythons. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PIL and Snow Leopard
On 2009-10-04 15:19 PM, Christopher Barker wrote: Clearly building PIL is an issue for you, but what about the other two? In particular, what wxPython issues are you having? I don't have Snow Leopard, but I'd like to know if there are wxPython issues for the future, and for when I distribute apps for others to run. OS X's 64-bit subsystem, now standard in Snow Leopard, does not have Carbon for UIs, only Cocoa. wxPython is still built against Carbon. wxCocoa is still in development. 32-bit builds of Python can still work with wxPython on Snow Leopard, though. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Problem with numpy on Leopard
Christopher Barker wrote: Ned Deily wrote: The easiest way is to use the install_requires keyword in setup.py. See the setuptools documentation here: http://peak.telecommunity.com/DevCenter/setuptools That appears to handle dependencies: install_requires A string or list of strings specifying what other distributions need to be installed when this one is. See the section below on Declaring Dependencies for details and examples of the format of this argument. Which looks quite dangerous, as a matter of fact. For example, I do easy_install foo foo has install_requires(numpy==1.0.3) now setuptools will download and install numpy1.0.3, but it won't get used, 'cause there is an older numpy earlier on the pythonpath. This is incorrect. sys.path gets modified appropriately. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] readline support for OS X Leopard
Robert Kern wrote: Boyd Waters wrote: On Oct 26, 2007, at 7:50 PM, [EMAIL PROTECTED] wrote: It right there in my original message (and in the python man page). You have to use EditLine syntax: readline.parse_and_bind (bind ^I rl_complete) Edward's example of using EditLine syntax works for my raw python test: $ python import rlcompleter import readline readline.parse_and_bind (bind ^I rl_complete) readline.[TAB KEY PRESSED] readline.__class__ readline.__class__ readline.__class__ readline.__delattr__ readline.__delattr__ readline.__dict__ ... Try typing b. Sorry, I misread your post. I meant that trying that with a readline module compiled against GNU readline interferes with typing b. So, unfortunately, you can't just issue both commands hoping that the library will just ignore the wrong one. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
Christopher Barker wrote: So does that mean we can build Universal binaries of Scipy now? With some fiddling, probably. And back to the original question -- is the binary at python mac (only 2.4 at my last look) Universal? Almost certainly not. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
Robert Kern wrote: Robert Kern wrote: Christopher Barker wrote: So does that mean we can build Universal binaries of Scipy now? With some fiddling, probably. Namely, $ LDFLAGS=-undefined dynamic_lookup -bundle -arch i386 -arch ppc python setup.py config_fc --fcompiler=gnu95 --arch=-arch i386 -arch ppc build And, if you copy the libgfortran.a file to somewhere else, say ~/staticlibs/, you can force the linker to use it instead of the .dylib such that your users don't need to install gfortran. $ export LDFLAGS=-undefined dynamic_lookup -bundle -arch i386 -arch ppc -Wl,-search_paths_first $ python setup.py config_fc --fcompiler=gnu95 --arch=-arch i386 -arch ppc build_ext -L ~/staticlibs/ build ... $ file build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so: Mach-O universal binary with 2 architectures build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so (for architecture i386): Mach-O bundle i386 build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so (for architecture ppc): Mach-O bundle ppc $ otool -L build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so: /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0) /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.7) The pointer to /usr/local/lib/libgcc_s.1.dylib is innocuous. That's just the first place it will look for that library at runtime. There's one in /usr/lib that appears to be picked up and used just fine. Problem solved. Finally. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
Christopher Barker wrote: Rob J Goedman wrote: Hope this helps a bit, not much, but I don't need to get how R works. It seems there is still no Fortran compiler for OS-X that build universal binary libs -- too bad. The gfortran binary that Paul pointed you to does make Universal binaries. I don't know why you think it doesn't. If you want an explicit statement to that effect: http://r.research.att.com/tools/ If you want a demonstration: [fitpack]$ gfortran -arch i386 -arch ppc -c bispev.f [fitpack]$ file bispev.o bispev.o: Mach-O universal binary with 2 architectures bispev.o (for architecture i386): Mach-O object i386 bispev.o (for architecture ppc):Mach-O object ppc -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] easy_install question
Ronald Oussoren wrote: On Monday, April 23, 2007, at 02:46PM, Ulysses Known [EMAIL PROTECTED] wrote: Perhaps this is not possible, however I do see the following egg names through google so I wonder if it is possible: numpy-1.0.2.dev3507-py2.5-macosx-10.4-i386.egg Thanks for your help. I'm not sure why numpy doesn't distribute a universal binary egg, that's rather user unfriendly if you ask me. Universal binaries are the best way to package software, users shouldn't have to worry about what CPU type they have in their machine. Please be careful with accusations of user-unfriendliness. Whatever reference Ulysses found, it certainly wasn't to any officially distributed egg. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] numpy in python 2.4 vs 2.5
William Kyngesburye wrote: I'm trying to build a python extension that uses numpy. When I build with python 2.4.[whatever the last one was] and the current numpy 1.0.1 package, it succeeds with no problem. When I try python 2.5 and the matching numpy 1.0.1: building '_gdal' extension creating build/temp.macosx-10.3-fat-2.5 gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - fno-common -dynamic -DNDEBUG -g -O3 -I../../port -I../../gcore - I../../alg -I../../ogr -I../../macosx/GDAL/gdal -I/Library/Frameworks/ Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/ include -I/Library/Frameworks/Python.framework/Versions/2.5/include/ python2.5 -c gdal_wrap.cpp -o build/temp.macosx-10.3-fat-2.5/gdal_wrap.o gdal_wrap.cpp: In function 'int SWIG_Python_ConvertFunctionPtr (PyObject*, void**, swig_type_info*)': gdal_wrap.cpp:2051: error: invalid conversion from 'const char*' to 'char*'gdal_wrap.cpp: In function 'int SWIG_Python_ConvertFunctionPtr (PyObject*, void**, swig_type_info*)': gdal_wrap.cpp:2051: error: invalid conversion from 'const char*' to 'char*' any ideas? This has nothing to do with numpy. The wrapper source was generated from a slightly-old version of SWIG that generates non-const-correct C++ code. Python 2.5 uses a version of gcc that's a bit pickier than the 2.4 build that you used. Get the latest version of SWIG (1.3.31 should be fine, I think), regenerate the gdal_wrap.cpp, and recompile. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4?
Christopher Barker wrote: Robert Kern wrote: Yup. -framework Accelerate Robert, just so we're clear here. If one does a straight setup.py build with numpy 1.0.1, do you get a version that uses Veclib? I do understand that that is the Fortran-compatible version, and thus may result in some extra copying to shift between row and column major ordering. By the way, if one were to take care to use Fortran ordered numpy arrays, would you avoid that copying? Yes. Both with numpy and scipy. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4?
David Warde-Farley wrote: When I compile Numpy Scipy from source (on a G5 running 10.4.8) I run into these sorts of snags: from scipy import sparse Traceback (most recent call last): File stdin, line 1, in ? File /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/scipy/sparse/__init__.py, line 5, in ? from sparse import * File /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/scipy/sparse/sparse.py, line 12, in ? import sparsetools ImportError: Failure linking new module: /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/ sparse/sparsetools.so: Symbol not found: _fprintf$LDBLStub Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/scipy/sparse/sparsetools.so Expected in: dynamic lookup Originally there were problems with libg2c.a and such, solved by putting symlinks in /usr/local/lib to those libraries as offered by the HPC g77 distribution. I can't seem to figure out how to get around this, nor can I find a binary distribution of scipy. Any help? With Universal Python 2.4, you need to be using gcc 4 and gfortran. Please see the instructions that I wrote here: http://projects.scipy.org/pipermail/numpy-discussion/2007-January/025368.html If that doesn't solve the problem, try adding -lSystemStubs to the build_ext command: $ python setup.py build_src build_clib --fcompiler=gnu95 build_ext -lSystemStubs --fcompiler=gnu95 build -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4?
David Warde-Farley wrote: On 11-Jan-07, at 8:29 PM, Bob Ippolito wrote: Well I'm back in the country now and I just got my mbp back from applecare today... so if someone sends me updated binaries I'll gladly sync them to pythonmac.org. I would do it but again, I'm not sure my binaries are good i.e. completely universal, I get a number of can't figure out architecture warnings for stuff when I build numpy, nor am I really sure how to do all of that .mpkg packaging stuff (much less in a way that alerts users of the gfortran dependency of SciPy). Yes, this is a problem. The builds of numpy and scipy are not Universal. I don't see a reason why numpy *shouldn't* be, but distutils thinks it isn't, so it isn't. scipy *can't* be Universal until gfortran grows that capability. That and I'm still not sure my NumPy/SciPy are linking properly against Apple's veclib for fast linear algebra goodness. scipy.test() tells me that the module cblas is empty, and that it's using fblas. Well, it's linking just fine, but vecLib removed the ATLAS version information that the scipy build system uses to determine whether or not to build the wrappers for the C versions of the BLAS subroutines that ATLAS and vecLib provide. And the C versions of LAPACK subroutines are simply missing. Neither are necessary, though, just nice to have. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4?
David Warde-Farley wrote: On 11-Jan-07, at 11:18 PM, Robert Kern wrote: Well, it's linking just fine, but vecLib removed the ATLAS version information that the scipy build system uses to determine whether or not to build the wrappers for the C versions of the BLAS subroutines that ATLAS and vecLib provide. And the C versions of LAPACK subroutines are simply missing. Neither are necessary, though, just nice to have. Eh, am I missing something or aren't the C versions of the BLAS subroutines a good bit faster? Okay, let me clarify. ATLAS is implemented entirely in C. vecLib is a slightly modified version of ATLAS. ATLAS provides both the standard BLAS interface which uses the FORTRAN calling conventions in terms of the names of symbols and column-major arrays. It also provides versions which uses C calling conventions and row-major arrays. The latter is what I am referring to when I say C versions of the BLAS subroutines. If you only have the FORTRAN versions of the subroutines, then you will incur the cost of copying the numpy arrays (row major) to the column major format. While that may not be negligible, it's not huge, either. Can/does gfortran take advance of AltiVec/vecLib? Yup. -framework Accelerate -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] eggs and extraction
belinda thom wrote: Now I can't figure out how to access the documentation. Part of the problem is that I'm pretty confused about what an egg is (I've scanned easy_install and distutil related stuff, but learned little; I'm not even sure where to look; Google often brings up content that deals w/chicken eggs :-) The documentation and examples were not included in the binary distribution that you installed. You can get them from the source distribution. http://sourceforge.net/project/showfiles.php?group_id=80706 The first 7 or so hits on a Google search for python eggs are all on-topic and tell you what you want to know about eggs (although they won't tell you where to get matplotlib documentation and examples). -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] eggs and extraction
belinda thom wrote: I had thought perhaps: easy_install -editable matplotlib-0.87.7-py2.4.egg-info/ would do the trick, but it complains: error: No urls, filenames, or requirements specified (see --help) And the appropriate form for this command is the following: [src]$ easy_install --editable -b . matplotlib Searching for matplotlib Reading http://www.python.org/pypi/matplotlib/ Reading http://matplotlib.sourceforge.net Reading http://sourceforge.net/project/showfiles.php?group_id=80706amp;package_id=82474 Reading http://www.python.org/pypi/matplotlib/0.87.7 Best match: matplotlib 0.87.7 Downloading http://downloads.sourceforge.net/matplotlib/matplotlib-0.87.7.tar.gz?modtime=1161866270amp;big_mirror=0 Processing matplotlib-0.87.7.tar.gz Extracted editable version of matplotlib to ./matplotlib If it uses setuptools in its setup script, you can activate it in development mode by going to that directory and running:: /Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python setup.py develop See the setuptools documentation for the develop command for more info. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] using matplotlib, ipython, etc. w/MacPython
belinda thom wrote: I do not want to compile code myself unless absolutely necessary. I was wondering what was up with the MacEnton suite; clicking on the link described at the above web page informs me that the MacEnthon page does not exist. Umm, ignore it. It targetted a now-old Python distribution, and I don't have time to update it anymore. References recommending it should be removed. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] In need of an OS 10.4.8-compatible Universal binary built w/ gcc 3.3 (NOT 4.0)
David L Goldsmith wrote: Hi! I'm experiencing a problem with scipy; its install notes say that it is not yet fully compatible with OSX and further say that in OSX one should ensure that one's gcc selection is set to 3.3. Mine is, but I noticed that the Universal build Python binary I downloaded and am using was built w/ gcc 4.0.1. Accordingly, I suspect this might be the basis of my problem - any idea where I might obtain an OSX-compatible Python built w/ gcc 3.3? Thanks! You can't do it. Universal binary capability was only added to gcc 4.0. You are looking at somewhat old instructions. While there are still some problems with gfortran (which only supports gcc 4.0 rather than g77 with only supports gcc 3.x), they are few and minor. Install a gfortran binary from this page: http://hpc.sourceforge.net Then build scipy using --fcompiler=gnu95 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Packaging numpy with py2app
Josh Marshall wrote: so it seems like the entire purpose of PackageLoader is to make life difficult for me, just to save a few lines of typing. :) Seriously, can a numpy developer tell me why PackageLoader is necessary? I can't think of a good reason why it's used in __init__.py the way it is (it used to have postpone=True). If Pearu, who wrote that bit of code, doesn't speak up by Thursday, I'll have it removed in favor of regular imports for the beta. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Compiling Numeric for OSX-intel
Bob Ippolito wrote: On Apr 23, 2006, at 4:28 PM, Jeremy Gore wrote: I use the old Numeric package quite a bit (numpy is just not ready for primetime) and stupid me, I didn't check if it was available before I installed the Universal binary package for python 2.4.3. Rather than moving backwards, I'd like to try getting it to compile. However, I can't seem to find the cvs/svn with the most recent configuration files. Where are those? I'd also like to install numarray, numpy, and scipy. (numpy won't compile due to can't locate file for : -lcc_dynamic; this was also a problem for the sources of numarray and Numeric) I'm running a MacBookPro with 10.4.6. Are you sure you have the latest Xcode installed with the 10.4u SDK? -lcc_dynamic sounds like compiler mismatch or something. It's a scipy-specific issue. We add that library when compiling against g77-built libraries, and up until recently, it also showed up when using gfortran. It should be fixed now in recent SVN checkouts of numpy. -- Robert Kern [EMAIL PROTECTED] I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] readline: where and how installed?
Bill Janssen wrote: Just curious... Is there really a need for the readline library? On Mac, I always run Python shells in either (1) Terminal, or (2) xterm, or (3) an Emacs shell buffer. All of them have readline capability built in. I never need Python to have readline capability. What's the use case here? 1) and 2) certainly don't have any readline capability built in to them. The Emacs shell buffer does, but it's not the same thing as the readline module, which IPython accesses to add its own completer functions. -- Robert Kern [EMAIL PROTECTED] I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Numpy Scipy and Darwinports
David M. Cooke wrote: Jaonary Rabarisoa [EMAIL PROTECTED] writes: Hi all, I'd like to build numpy and scipy with the gcc 4.1 provided by darwinport (I fact, they need a fortran compiler). How can I do to change the compiler to be used with distutils ? I've tried something like this : python setup.py build --compiler=gcc-dp-4.1 ( all the file installed with darwinports have the suffix -dp-4.1) but I didn't work. Use the CC environment variable: CC=gcc-dp-4.1 python setup.py build However, note that gfortran will *not* work with scipy: we don't know why, but we believe to be something to do with gfortran not being stable yet. I tested it recently; still no go. IIRC, someone found that gfortran 4.1 will work if d1mach.f is compiled with only -O, not -O2. Possibly -ffloat-store, too, I don't remember. In any case, numpy.distutils doesn't let you set the name of the fortran compiler through an environment variable, I don't think. I recommend making a symlink named gfortran to the actual executable. Then: CC=gcc-dp-4.1 python setup.py config_fc --fcompiler=gnu95 build_src build_clib build_ext build -- Robert Kern [EMAIL PROTECTED] I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Bulding numpy with the Universal Build
Ronald Oussoren wrote: On 28-mrt-2006, at 23:18, Christopher Barker wrote: Hi all, I'm embarking on the project of building the various packages I need with the new Universal Build. I've set up a Wiki page to keep track of what I (and others) have done. Please take a look if you are interested, and add your own work. To answer to the title of the message, the problem with numpy on 10.3.9 is indead caused by numpy patching distutils. This interferes with my changes. I have slightly modified my changes to distutils and numpy now builds correctly. This change will be in the universal build for python 2.4.3. Excellent! Thank you! Is there a source repository where these changes are being checked in? I think numpy can take the responsibility of keeping up with your changes. BTW. from my limited testing it seems that numpy binaries build on 10.4 also work on 10.3.9. I don't actually use numpy myself, so don't know how to properly test it. numpy.test() will run the test suite. -- Robert Kern [EMAIL PROTECTED] I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Problems installing Numpy using Universal MacPython
Ronald Oussoren wrote: On 27-mrt-2006, at 18:00, James Boyle wrote: I posted this to the numpy mailing list - I am re-posting here since it is a more complete description of the situation than my previous post to this list. I am running OX 10.3.9. I installed python 2.4.2 using Universal MacPython 2.4.2.dmg. I am on a PowerPC G4. The Universal build is designed to install on the Mac PPC and Intel machines. When I run the numpy 0.9.6 install it apparently fails on the configure. The whole trace back is at the end of this posting. One thing that I noted was the line: gcc options: '-arch ppc -arch i386 -isysroot /Developer/SDKs/ MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp- precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g' It appears that the configure routines think that I have two architectures - ppc and i386. At my low level of understanding, all I can do is speculate that the Universal install generates some confusion as to the actual cpu. Somewhere numpy is keying on information that is ambiguous in the universal install. The problem is that gcc 3.3 on 10.3.9 doesn't support some of these options. Specifcally it doesn't know '-isysroot' and also doesn't support the i386 architecture. I'm pretty sure that I had implemented support for stripping these arguments on a 10.3 system. Hopefully I'll have time to boot into 10.3 tomorrow. numpy extends distutils, so it may be overriding certain changes you've made to distutils. We may have to duplicate those changes in numpy.distutils. -- Robert Kern [EMAIL PROTECTED] I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Unix-amateur question
W. R. Wing wrote: At 8:05 PM -0500 3/7/06, Charles Hartman wrote: (Sorry! How simple can they get? But I don't know of a better place to ask -- does anyone?) How do I execute a Mac application from the Terminal command line? Use the open command - as in: $open /Applications/GoogleEarth.app In this particular case, IPython executes $EDITOR temp_file and waits for the process to exit. open starts the application and exits immediately, so IPython thinks the user has finished editing the file. As Ed Leafe mentioned, BBEdit comes with a convenient command-line executable for just this use. Since this is a common idiom for programs that start external editors, this executable ought to have the desired behavior (possibly available through a command line option). One should use this executable instead. -- Robert Kern [EMAIL PROTECTED] I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonw and VPython and Fink
Dethe Elza wrote: I think the solution is for VPython to be ported to Aqua instead of using X11 (so it can use regular OS X Python, not Fink, among other good things). Framework builds of Python can use X11 just fine. I'm not sure that's the holdup. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] strange #!/usr/bin/pythonw behavior...
[EMAIL PROTECTED] wrote: #!/usr/bin/pythonw Bob Sounds like you're using OS X 10.3. It shipped with pythonw as a Bob shell script, not an executable. skip Yes, thanks. Shoulda thought to actually look at skip /usr/bin/pythonw... Alas, explicitly specifying the long path didn't work either. It bombs on import of appscript: Try #!/usr/bin/env /usr/bin/pythonw -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Experiences with 64 bit on PowerMac G5s?
David M. Cooke wrote: I don't know specifically about the G5, but Numeric, numarray, and numpy are routinely compiled and run on 64-bit Athlon machines, so a lot of the bugs and such have already been shaken out. If possible, you should move from Numeric to numpy; one of the goals for numpy was better 64-bit handling. But numarray may still be better for extremely large arrays; haven't checked recently. Well, numarray won't be updating much any more, and almost certainly won't be addressing the fundamental problems with 32-bit arrays like numpy has. So go for numpy. http://numeric.scipy.org/ That said, I don't think many people have actually been using 32-bit arrays with numpy, yet, so there are probably still some issues to be worked out. Disclaimer: I am a numpy developer. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] python2.4 crashes (bus error)
Chris Fonnesbeck wrote: Thread 0 Crashed: 0 0x 0 + 0 1 flib.so 0x031b9690 array_from_pyobj + 1180 (fortranobject.c:689) 2 flib.so 0x031b4d4c f2py_rout_flib_poisson + 168 (flibmodule.c:843) It's a problem with f2py; nothing Mac-specific here. You'll want to ask on scipy-dev. We'll need to know what versions of f2py and Numeric (scipy_core?) you are using. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] pygame binaries
Mathew James Oakes wrote: unable to install pygame binaries on osx 10.3... get the following message from the pygame-1.7.0.mpkg installer: The Installer package pygame-1.7.0 cannot be opened. The InstallationCheck tool was either not executable or not readable. OK I've checked md5 is right, and even gone in and modified the permissions on /Contents/Resources/InstallationCheck to make it readable writable and executable. It's an mpkg, so you need to do the same for all of the subpackages, too. has anone else had the same problem? Yes, see the thread titled ANN: pygame 1.7.0 for Mac OS X 10.3 .zip files created by Python's ZipFile don't interact well with unzip(1). bdist_mpkg got patched with a workaround, but apparently the pygame installer .zip never got updated. Unzipping with StuffIt Expander will set the appropriate permissions. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] pth file location
Scott Frankel wrote: Still bad magic. Where should .pth files be placed for 3rd party modules to be found? My attempts (latest: /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/my_3rd_party.pth) is still leading to bad magic errors. The path printed by the err msg does not correspond to the path specified in the .pth file. Could you actually show us the error messages? -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CoreGraphics module for python 2.4.1
Ronald Oussoren wrote: I'm pretty sure someone mentioned they had written their own CoreGraphics wrappers some time back on this list. That would be me. I've extracted it from the Kiva tree as a standalone module. This is just a very preliminary release, so there's no documentation beyond the source. It's released under the BSD license. http://starship.python.net/crew/kernr/source/ABCGI-0.0.0.tar.gz http://starship.python.net/crew/kernr/source/ABCGI-0.0.0-py2.4-macosx-10.4-ppc.egg I haven't yet adapted to the new scheme for getting a CoreGraphics context in PyObjC. Patches are welcome, of course. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] messed up Tiger python install
Brendan Simons wrote: On 12-Sep-05, at 6:00 AM, Bob Ippolito wrote: Patches accepted at http://sourceforge.net/projects/python :) -bob ok, point taken. I'm going to have to brush up on my distutils skills before I can approach that. The Python interpreter's installer isn't built with distutils. Look at Mac/OSX/Dist/README.txt in the source distribution. But please consider writing clear documentation telling people how to modify their $PATH, instead. That's far more likely to be a robust approach. AFAICT, this is an issue that only affects people running python from the terminal. Such people need to know something as basic as the $PATH anyways. The best part of this approach is that you don't have to brush up on anything. ;-) -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Hello; F2PY
Andreas Voellmy wrote: Hello, I'm new to the list. I'm wondering if anyone on the list has any experience using f2py (http://cens.ioc.ee/projects/f2py2e/) on the mac os x? I would like to use it so that I can access functions written in fortran in python. I'm having trouble getting it working on tiger. I'm just working on the hello world example and haven't gotten it to compile correctly yet. gcc in mac os x apparently has the fortran compiler removed or turned off. So I am using a port of gfortran to compile my fortran. i've gotten f2py to compile a shared library using gfortran, but when I load it into python it has a fatal error and suggests that i may not have compiled the library under the right version. This makes sense. I compiled with gfortran, part of gcc 4.0, while python on my mac is compiled under gcc 3.4. I haven't yet been able to get around this issue. It works very well using g77-3.4 from http://hpc.sf.net with gcc-3.3 on Tiger. The gfortran support is a little flaky, I believe. Hell, gfortran is a little flaky. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] late start with tiger
Scott Frankel wrote: I've just migrated a machine to Tiger and have a question about the official unofficial mac version of python.2.4.1. Why would /usr/bin/python still be linked to python2.3 after the install? Because we shouldn't mess with Apple's stuff. /usr/bin is off-limits. The Python 2.4.1 installer installs /usr/local/bin/python /usr/local/bin/python2.4 /usr/local/bin/pythonw /usr/local/bin/pythonw2.4 I downloaded and installed MacPython 2.4.1 from undefined.org. I also downloaded and installed both TigerPython24Fix and TigerPython23Compat. If I execute python 2.4 using an explicit path to /Library/Frameworks/Python.framework/Versions/2.4/bin/python2.4, then python2.4 launches happily (with readlines!). But if I execute the python specified in my env (i.e.: /usr/bin/python), python2.3 launches due to the link. Put /usr/local/bin early in your PATH environment variable. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Solid GUI toolkits for Mac?
Jon Rosebaugh wrote: I'm wondering how many of the many GUI toolkits for python play really well with Mac OS X, including actual native look, instead of just an Aqua theme that doesn't look quite right? wxPython and Tk are so-so in this regard. They use the real thing underneath for most of their widgets. Layout isn't always the best, though. Qt, AFAICT, just uses an Aqua-like theme as you suggest. I know of PyObjC (which scares me, because Interface Builder and Cocoa scare me; come on, a four-page tutorial with dozens of methods to write just to add a freaking toolbar? This is 2005, not 1995, Apple), PyFltk (which works, but the guy giving the compilation instructions admits he doesn't know much about python or compiling, which makes me a little hesitant to spend effort learning it), PySWT (which looks like it would do the job, but doesn't actually have any explicit Mac support yet, and also appears to not be very mature yet), and, um, that's what I've got. So. What are people using? (And if I've got the wrong impression of PyObjC, I'm happy to be enlightened.) PyObjC is *the* way to do GUIs for Mac-only programs. Drink the Kool-Aid. Cocoa is probably the best-designed GUI framework I've yet seen. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Errors with simple_plot in matplotlib: type is wrong for / operator?
Louis Pecora wrote: I got my Python back up and running thanks to help from Bob Impolito and Robert Kern (site packages and .pth files and new system install). * I have installed wxPython and matplotlib. But when I run the simple_plot.py program: #!/usr/bin/pythonw I'm not sure about the rest (ask on the matplotlib list), but this #! line won't work. Instead, use #!/usr/bin/env pythonw -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Can't get re-installed python to recognize old paths.
Louis Pecora wrote: After a lot of hair pulling (long story) I re-installed OS X 10.3 (archive and install) and then upgraded to 10.3.9. Python seems to work and other problems seem to be gone, but when I try to import my original modules it can't find them. I looked in the folder .MacOSX and see that Enviroment.plist is still there and it has the original paths that once worked (two weeks ago). Here it is: Can't say much about setting PYTHONPATH, but an option you should consider is to make a .pth file in your site-packages directory that lists all of these directories, one per line. For example: # mystuff.pth /users/louispecora/Code/python/general /users/louispecora/Code/python/stats /users/louispecora/Code/python/stats/BayesProb /users/louispecora/Code/python/time_series /users/louispecora/Code/python/plotwindow /users/louispecora/Code/AddedPackagesfiles -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] not MacPython - right place?
William K wrote: I figured it out, partly. While the site-packages is linked to / Library/Python, headers are still put into the /System/Library Python framework. So I used --install-headers=/Library/Python/2.3/site- include. Is there a standard name for a site headers folder in / Library/Python? The problem is, there is no option in bdist to specify an install- headers location, at least not in the package I'm looking at (Numeric). Don't worry overmuch about it. If you installed the headers elsewhere, it would be difficult to tell packages which need those headers where to find them. If it does worry you so much, then install Python 2.4.1, which places its files in /Library/Frameworks/Python.framework and be done with it. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] not MacPython - right place?
William K wrote: [Bob:] If you put the headers anywhere else, they're useless because nothing will find them. Take the purist hat off, or install a non- System distro of Python (e.g. Python 2.4.1). Is that a Python thing, or a slipup by Apple in their distro of Python? That seems a bit limiting if you can put libraries/modules where you want, but force headers to be in one location to be usable (while still letting you install them anywhere). It's a Python thing mostly. [Chris:] unless you really want to do things yourself, the best bet is to first look and see if the package you need is at: www.pythonmac.org/packages No Numeric for Tiger. Use the Panther one. See below. [Me:] If it does worry you so much, then install Python 2.4.1, which places its files in /Library/Frameworks/Python.framework and be done with it. You mean MacPython, right? Is there a separate MacPython installer for Tiger? The one I found (from March) says it's for Panther, and I'm a bit cautious of installing something meant for Panther on Tiger. Are there any problems running that one on Tiger? The Panther build works just fine on Tiger. Usually, Python packages built on Panther will also work on Tiger. I am currently using the semi-official Python 2.4.1 build from www.python.org on Tiger. The packages at pythonmac.org for 2.4.1 work just fine on Tiger. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] 2.4.1 Installed and roughly working, but modules missing.
Louis Pecora wrote: I installed Bob I.'s 2.4.1 version and I can get it up and running in Terminal using /usr/local/bin/python. But in running it from Terminal or BBEdit Python cannot find the module 'kinds'. At first it couldn't find the Numeric module, but I installed that and then the 'kinds' problem came up. Any ideas? It's not in the main Numeric package any more. Get it from CVS. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] OS X C API bug?
Gary Robinson wrote: Hello, The attached file contains a c module with 4 versions of the same extremely simple function. All they do is return a float double to python. The zip also contains the setup.py to build it. Data point: fun3 gives me a bus error on Tiger with Python 2.4.1 and gcc 3.3. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python VTK shared libraries
Vladimir Shapovalov wrote: Recently I had to install Python interface for VTK. One of the problems I ran into was that the shared libraries built for VTK would not be seen by Python whatever path I put them into. The only way I found to make them visible was to make links in the site-pckages/ vtk_python directory. In addition, the link to libvtkRenderingPythonTkWidgets.dylib had to be named libvtkRenderingPythonTkWidgets.so to make it work (otherwise python complained it could not find the .so file). The Python modules should already be .so files that have symbolic links to them (made by python setup.py install). libvtkRenderingPythonTkWidgets.dylib isn't a Python module as far as I can tell. Is there a more graceful solution to keeping the libraries in a more appropriate place and still having python find them? .pth file perhaps, but symbolic links are fine. Note that there other problems. The .so's and .dylib's point back to the build directory for the library dependencies. I used macholib from py2app to rewrite the headers to point to the installation directory. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Where to go for wxPython help tutorials?
Louis Pecora wrote: Because matplotlib presents the plot at the end of the program. My programs are written to be interactive and continue running, i.e. calculate something or massage data, plot the result, close the plot window, do more stuff, check another plot, or other options not in any particular order. I do interactive plotting with matplotlib all the time exactly as you describe. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Where to go for wxPython help tutorials?
Chris Barker wrote: Robert Kern wrote: I do interactive plotting with matplotlib all the time exactly as you describe. Robert, do you have any small demo programs that do this? I think it would be a good thing to have out there. Perhaps the embedded_in_wx examples already do this, but I haven't checked them out. At the moment I primarily use matplotlib for generating PNGs for the web. Not particularly. I use ipython in pylab mode. Louis's original request (to open some simple windows and draw/plot figures from data) fits matplotlib's interactive mode particularly well. Unfortunately, it doesn't make for good examples. The best thing to do is to install ipython and run ipython -pylab and play around a bit. The important bit, of course, is ipython's GUI thread management. PyCrust also works (although you give up on ipython's other magnificent goodies). scipy's gui_thread might also work, but it has been obsoleted by ipython. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How do you install TkInter for python 2.4 (on 10.3)
Chris Barker wrote:
Thanks Bob.
Bob Ippolito wrote:
On Jun 16, 2005, at 4:46 PM, Chris Barker wrote:
Is it part of the standard install now?
Yes, from http://undefined.org/python/#python:
Unlike typical builds, this one has all the stock goodies:
readline 5.0.005 (static)
BerkeleyDB 4.3.27 (static)
waste (static)
Tcl/Tk Aqua 8.4.9 (dynamic - you'll need TclTkAqua to use Tkinter if
using on Mac OS X 10.3)
Does that mean that TclTkAqua comes with 10.4 ?
Yes.
[~] kern$ ls -d /System/Library/Frameworks/{Tcl,Tk}.framework/
/System/Library/Frameworks/Tcl.framework/
/System/Library/Frameworks/Tk.framework/
I'd still like to know why you haven't put this on pythonmac.org . I'm a
big believer in one-stop shopping.
I'm writing up instructions for building matplotlib, so I wanted to know
what to tell people that wanted matpotlib to work with TK.
I'll be sending you new matplotlib installers soon, one for 2.3.0, and
one for 2.4 (built on 10.3)
I have had problems with matplotlib/Tk/Python2.4 on Tiger with both the
Apple-installed frameworks and freshly downloaded ones. Python freezes
for a long time (I haven't timed it; maybe for a half-hour?) and then
drops a nice crash window with a stack trace in the Tcl internals. I
haven't been able to track down the problem, but it is
matplotlib-specific. I recommend wxPython 2.6.1 on Tiger for matplotlib.
--
Robert Kern
[EMAIL PROTECTED]
In the fields of hell where the grass grows high
Are the graves of dreams allowed to die.
-- Richard Harter
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app data files
Charles Moad wrote: py2app-0.2 sticks the data files for matplotlib in /usr/local/ share/share/matplotlib instead of /System/Library/Frameworks/ Python.framework/Versions/2.3/share/matplotlib when running bdist_mpkg then installing the created package. Any clues??? (basemap files go to the wrong place too) Use --install-data=/usr/local . matplotlib will look in /usr/local/share/matplotlib . You will need to edit a line somewhere in basemap to look for data in /usr/local/share/basemap . It's better this way; trust me. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Apple's python extensions into Quartz2D
Chris Barker wrote: Robert Kern wrote: I disliked the implementation (undocumented, closed source SWIG bindings are largely unusable), so I wrote my own using Pyrex. I call it, unimaginatively, ABCGI, A Better CoreGraphics Interface. It is part of Kiva, Enthought's graphics library, and has served as ground truth for the other backends. When I get some time, I'll break it out as a separate package. While we're on the topic, could Kiva be ripped out and used by itself? Certainly. To rip it out, all you do is not import Chaco. ;-) It could be a pretty cool lib for things other than Chaco. Also, what's the status of Chaco on Linux and OX-X? It looked so promising, but has kind of disappeared off the radar. Neglected. :-) Enthought's primary target has been wxPython 2.4 on Windows. However, there were some recent changes that should improve its outlook on OS X, at least. I haven't had a chance to try them out, yet. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Apple's python extensions into Quartz2D
nickg wrote: thanks for the reply. Odd, the Python API is nearly 1-1 with the CoreGraphics C API so I wouldn't expect any hacks. Oh well. I disliked the implementation (undocumented, closed source SWIG bindings are largely unusable), so I wrote my own using Pyrex. I call it, unimaginatively, ABCGI, A Better CoreGraphics Interface. It is part of Kiva, Enthought's graphics library, and has served as ground truth for the other backends. When I get some time, I'll break it out as a separate package. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] donation
Lee Cullens wrote: Maybe, for those of us that won't use PayPal, Bob could note a desired payee and address for a check. I made a donation with PayPal sometime last year and when several months ago they sent me something about updating my account, and I ignored it, their emails became more frequent and frantic (now they are saying I have to update my account because it is being misused in Europe ). Their tactics turned me off and they were demoted to junk mail. All of those are spam not sent by PayPal. They are phishing attacks designed to get you to give the senders your financial information. Check the URLs of the links; they don't go to www.paypal.com. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] donation
Lee Cullens wrote: Even so, (especially with the volume that is evident) a good organization should warn anyone doing business with them that such is occurring. My bank and my brokerage have both sent me such warnings in the past when their was just a hint of phishing scams that I never saw. You mean like https://www.paypal.com/cgi-bin/webscr?cmd=xpt/general/SecuritySpoof-outside linked from the homepage? -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1
Lee Cullens wrote: Clean Tiger install and all other applications reinstalled. All running well. Slowly getting there. So far I have the following up and haven't encountered a problem yet. MacPython-OSX-2.4.1-1.dmg TigerPython24Fix-r2.zip TigerPython23Compat.pkg RegexPlor-20050503-Tiger.zip Next steps - are the following appropriate? wxPython-2.6unicode-py2.4-macosx10.3.zip(assuming this will work on 10.4) I believe so. TclTkAquaBI-8.4.9.1.dmg Tiger comes with TclTkAqua, but not the Batteries Included version, I believe. I'd say, don't bother unless you know that you need a particular battery, like Tix. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app and CLI Python programs
David Reed wrote: I've got a command line Python app that I tried packaging up with py2app. It worked ok - t could cd into the subdir of the .app containing the executable and run it from the command line, but I'm not certain what its current working directory was since when I tried to specify a file on the command line, it didn't find it. I had to specify the full path to the file to make it work. Is there a simple workaround for command line versions - I didn't see anything in the documentation. [/some/path] $ /Applications/MyApp.app/Contents/MacOS/MyApp will usually have /some/path as the cwd. However, .app bundles are probably not what you want for CLI apps. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Spotlight and Python
Jacob Kaplan-Moss wrote: On May 10, 2005, at 2:00 PM, Jonathan Wight wrote: I'm not sure how useful it is to index function class names though. Oh, I disagree -- I've got over 100K lines of code, and I would *kill* to be able to find everywhere a particular symbol is used. And yes, I know grep -r will do it for me -- but the more ways to sift through data, the better. *cough* ctags *cough* http://ctags.sourceforge.net/ -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] mac newbie... Tix . What is wrong?
Eric Texier wrote: Here is a simple example that works on linux, but not on MacOSX tigger. Thanks Eric pythonw Python 2.4.1 (#2, Apr 27 2005, 22:11:31) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type help, copyright, credits or license for more information. import Tix def selectedFile(inFile): ...print inFile ... root = Tix.Tk() d = Tix.FileSelectDialog(root,command=selectedFile) Traceback (most recent call last): File stdin, line 1, in ? File /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-tk/Tix.py, line 815, in __init__ ['options'], cnf, kw) File /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-tk/Tix.py, line 307, in __init__ self.tk.call(widgetName, self._w, *extra) _tkinter.TclError: invalid command name tix You don't have the Tcl package Tix installed. The Tiger-provided TclTkAqua installation does not come with Tix. I'm not sure, but you can try installing the Batteries Included version of TclTkAqua from http://tcltkaqua.sourceforge.net -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] problems with installing scipy on mac
Benjamin Abecassis wrote: Hi all, I had to re-install macosX and i'm struggling to re)install scipy... I think i have installed everything necessary but the installation exits with sh: line 1: f95: command not found sh: line 1: f95: command not found error: Command f95 -fixed -O4 -c -c Lib/fftpack/dfftpack/dcosqb.f -o build/temp.darwin-7.3.1-Power_Macintosh-2.3/Lib/fftpack/dfftpack/dcosqb.o failed with exit status 127 furthermore it says Could not locate executable g77 Could not locate executable f77 whereas g77 is installed and present in usr/local/bin !!!??? another problem is thath gnuplot does not start when i simply type 'gnuplot' in a terminal window i have to type 'usr/local/bin/gnuplot' for it to work. May these problem be related ?? Probably you don't have /usr/local/bin in your PATH environment variable. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] ANN: MacEnthon 0.1
MacEnthon is the OS X counterpart to the popular Enthought Edition of Python: a convenient bundling of a number of packages geared for the scientific community. Right now, it targets the Apple-installed Python 2.3.0. Once I am satisfied with this release, I will consider cutting a release for Python 2.4.1. This is still just a test release. Please do not tell newbies to go install it, yet. New in this release: - some updates to packages from CVS/SVN - all documentation is now under /Developer/Python - enthonutil.py, a module that allows you to easily make your own sumo distribution; see /Developer/Python/MacEnthon/enthonutil-example.py For a full list of packages, please see the ReadMe: http://download.enthought.com/MacEnthon/ReadMe.html To download: http://download.enthought.com/MacEnthon/MacEnthon-0.1.dmg Included is a CLI uninstaller, enthonbegone.py . It may leave a few empty directories some .pyc's hanging about, but otherwise it works fairly well. See its help for more information. When you encounter problems, packaging/build bugs, or missing documentation, please log it on the Enthon issue tracker and assign the issue to rkern: https://www.enthought.com/roundup/enthon/ I haven't gotten much feedback, so I can only assume that it's perfect. Barring anything particularly idiotic that I've done, I will probably only make one more final MacEnthon for Python 2.3.0. When I recover from that, I'll start thinking about 2.4.1. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens
Lee Cullens wrote: On Apr 5, 2005, at 1:01 AM, Robert Kern wrote: Lee Cullens wrote: I try not to get too far off on a tangent, but little things like this are good learning exercises and you have shortened the time it will take me to get through it. Allow me to shorten it further: Look in Mac/OSX/Doc of the source distribution. Thanks Robert - you mean SorceForge I assume but I can't seem to find what you mean. I was going to download the HTML version of the 2.4 docs from the Python site. No, I mean the source code tarball. http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tar.bz2 -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] MacEnthon 0.0 testing release
I am pleased to announce the availability of MacEnthon 0.0! MacEnthon is the OS X counterpart to the popular Enthought Edition of Python: a convenient bundling of a number of packages geared for the scientific community. Right now, it targets the Apple-installed Python 2.3.0. Once I am satisfied with this release, I will consider cutting a release for Python 2.4.1. This is currently just a test release. Please do not tell newbies to go install it, yet. For a full list of packages, please see the ReadMe: http://download.enthought.com/MacEnthon/ReadMe.html To download: http://download.enthought.com/MacEnthon/MacEnthon-0.0.dmg Included is a CLI uninstaller, enthonbegone.py . It may leave a few empty directories hanging about, but otherwise it works fairly well. See its help for more information. When you encounter problems, packaging/build bugs, or missing documentation, please log it on the Enthon issue tracker and assign the issue to rkern: https://www.enthought.com/roundup/enthon/ Thank you all. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacEnthon 0.0 testing release
Robert Kern wrote: I am pleased to announce the availability of MacEnthon 0.0! I should add that the disk image is 158 MiB large and that the installed files take up... I'm not actually sure, but it's under 700 MiB, I believe. Zip archives of individual packages will be available when I get around to it. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacEnthon 0.0 testing release
Bob Ippolito wrote: On Apr 3, 2005, at 21:03, Robert Kern wrote: I am pleased to announce the availability of MacEnthon 0.0! MacEnthon is the OS X counterpart to the popular Enthought Edition of Python: a convenient bundling of a number of packages geared for the scientific community. Right now, it targets the Apple-installed Python 2.3.0. Once I am satisfied with this release, I will consider cutting a release for Python 2.4.1. This is currently just a test release. Please do not tell newbies to go install it, yet. Excellent. You should probably be using PyProtocols CVS. Works for me. Which revision of PyObjC is in there? I made some commits today... Hopefully you didn't pick something up while I was in the midst of working on the new Xcode templates... Apparently I did. I touched a 00README.txt to get it to build. I'll rebuild tomorrow or whenever you guys think it's wise. I've been following the PyObjC list and the str-unicode issues. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ...
OpenMacNews wrote: /Volumes/Projects/ports/Python-2.4.1/Mac/OSX/PythonLauncher/build/Pytho nLauncher.build/PythonLauncher.build/Objects-normal/LinkFileList -arch ppc -s -prebind -Wl,-no_arch_warnings -framework Cocoa -framework Carbon ld: warning prebinding disabled because dependent library: /usr/lib/libz.1.dylib is not prebound ld: warning can't open dynamic library: /usr/lib/libxml2.2.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: Undefined symbols: _xmlSAXUserParseMemory referenced from Foundation expected to be defined in /usr/lib/libxml2.2.dylib ...failed StandaloneExecutable.LinkUsingFileList ///Applications/MacPython-2.4/PythonLauncher.app/Contents/MacOS/PythonLaunc her ... ** BUILD FAILED ** make[1]: *** [install_PythonLauncher] Error 1 make: *** [frameworkinstallapps] Error 2 *something's* expecting libxml2 to be there ... I'll bet that it's either Cocoa or Carbon. In that case, you definitely *don't* want it to use your own libxml2. Leave it be. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ...
OpenMacNews wrote: hi robert, *something's* expecting libxml2 to be there ... I'll bet that it's either Cocoa or Carbon. In that case, you definitely *don't* want it to use your own libxml2. makes possible sense in that there's a reference to 'Foundation', which given your suspicion, refers to the OSX FoundationClass(es)? I.e., Cocoa/Carbon? Foundation is its own framework (see /System/Library/Frameworks) which is implicitly linked in by Cocoa and Carbon. ld: Undefined symbols: _xmlSAXUserParseMemory referenced from Foundation expected to be defined in /usr/lib/libxml2.2.dylib thought i'd be very hard pressed to prove or disprove ... Leave it be. Which is certainly good advice if that IS the case ... yet I'm still a little foggy on the whole matter given Bob's earlier comment: either Python itself, nor any extension in the standard library, links to libxml. What the heck are you talking about? which, iiuc, would suggest no dependence whatsoever on libxml -- either direct or indirect via Cocoa/Carbon. No, he only meant directly, I'm sure. so, again, Leave it be. seems to be good advice. what concerns me a bit is that 'other' apps i'm building depend on my *external* libxml, and will -- eventually -- 'touch' some Python, which will depend 'still' on the native (cocoa/carbon related) libxml ... Will this 'version incompatibility' come back to bite me in the ass? i simply dunno. short of understanding/resolving the libxml dependence i *am* seeing, I guess I'll just have to wait and see when i get there =) Always a good idea. Don't fix it until it breaks. And it probably won't. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ...
Bob Ippolito wrote: On Apr 3, 2005, at 23:52, OpenMacNews wrote: Foundation is its own framework (see /System/Library/Frameworks) yup. which is implicitly linked in by Cocoa and Carbon. Actually no, Carbon doesn't link to Foundation. Everything written in Objective-C does, though. You're probably thinking of CoreFoundation. Ah, yes, you're right. Thank you. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacEnthon ...
Bob Ippolito wrote: On Mar 25, 2005, at 1:45 PM, Robert Kern wrote: So I issue a challenge to the PythonMac masses: Write me an uninstaller. Standalone GUI is a plus, although I can live with a CLI script. For now, it only needs to be run by the intrepid testers. One ought to be able to uninstall indivdual packages. Is this http://www.osxgnu.org/software/Utils/OSXGNU/ usable? No, it assumes things about the naming conventions of the BOM file. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacEnthon ...
Bill Janssen wrote: What the heck *is* MacEnthon? The README didn't give me a clue. Oh, sorry! I've mostly talked about it on the Scipy lists. Enthought, Inc. has been distributing a sumo distribution of the Python interpreter for the Windows platform with many third-party packages (particularly those geared towards scientific development) built, tested and ready to go all in one installer. It has been nick-named Enthon. Enthought will be rolling out a Windows Enthon in the next week or so with a Linux release to follow. MacEnthon is the same thing, more or less, for OS X. Right now, I just target the stock 2.3.0 interpreter. When Python 2.4.1 gets released, I might target that as well. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Having trouble installing Panther python packages
Bob Ippolito wrote: On Mar 24, 2005, at 6:14 PM, Martina Oefelein wrote: Everytime I unzip the file and install the .mpkg file, I get the following error: The InstallationCheck tool is either not exectutable or not readable. did you use unzip to decompress the archive? Apparently unzip doesn't preserve execute rights. Try another decompressor. Stuffit Expander seems to work fine. That was stated in the question. What *particularly* bothers me is that he said it STILL COMPLAINS after he *removed InstallationCheck* (I suggested this -- it is perfectly valid to do, as it is only there to disallow = 10.2 users from attempting an install). That is bizarre. I talked with him offlist. He didn't do the chmod on *all* of the InstallationCheck's in each of the sub-packages. Doing that fixed the problem. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] ANN: pygame 1.7.0 for Mac OS X 10.3
Bob Ippolito wrote: On Mar 11, 2005, at 9:04, Troy Rollins wrote: I've packaged what should be pygame 1.7.0 for Mac OS X 10.3 users. It is available from pythonmac.org packages at: http://pythonmac.org/packages/ On my OSX.3.8, the installer starts with a dialog which says The installationCheck tool was either not readable or not executable. And then it offers only to close, but will not complete running the installer. Works here, don't know what your problem is. Using /usr/bin/unzip to unzip the package seems to strip the executable flags from these files. Stuffit Expander seems to work fine. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] package manager.
Kim Branson wrote: HI all, this is probably a question that has been answered on the wiki, but i can't seem to find it. I decided to try and upgrade my version of Numeric (currently 23.1) (building the latest Biopython was causing errors) but the packagmanager gives me a 404 errror opening http://www.python.org/packman/version-0.3/darwin-7.80- Power_Macintosh.plist. These package repositories are pretty much unmaintained now. An up-to-date Installer.app-type package is available thanks to Bob Ippolito. http://undefined.org/python/packages.html -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Matplotlib-users] matplotlib OS-X binary problems.
Chris Barker wrote: However, that doesn't seem to work if I have libfreetype.dylib somewhere standard, and I certainly don't want to remove it! (Maybe I could temporarily, but that's hardly the robust solution I'm looking for) Change the paths that distutils will add to the link line. They're at the top of setupext.py . Remove the ones you don't need. By the way, it would also be good to get this to work with TK and/or GTK. Has anyone done that successfully that would like to help out with this? With TclTkAqua, it Just Works. Also, as far as PyGTK is concerned. Can you run it without running Fink? That's the only way I've seen it done. If it is a Fink only option, then this is moot, as I'm looking for a Fink free approach, and someone else has put together a fink matplotlib package. You could try Darwinports. Set Darwinports' prefix to /usr/local, and use port(1) to make Installer.app packages for GTK et al. Bundle them with your bdist_mpkg metapackage. My strategy for building matplotlib (and I've done it *a lot* in the past few weeks) is as follows: I have Darwinports with a prefix in a GNU Stow repository. What Stow does is it allows you to install stuff into it's own directory (/usr/local/stow/darwinports, which has bin/, lib/, share/ et al.) and then makes symlinks such that everything appears to be installed to /usr/local. So I have Darwinports install libpng and libfreetype. I have a script that will remove the symlinks to the dylibs for libpng, libfreetype, and libz (I could probably resolve this by changing the order of search). I build matplotlib and double-check the dylib dependencies with otool -L. I do not bother with GTK at this time. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] pychecker
Bob Ippolito wrote: On Jan 3, 2005, at 11:58 PM, Robert Kern wrote: Okay. At some point, that symlink got blown away on my machine, so I put in the install-*lib entries. fixing up the symlink now If that symlink got blown away, /Library/Python/2.3 shouldn't have ended up in sys.path (unless you jigger that in elsewhere). I don't *think* I did, and I can't think of any places to do so that I haven't already checked. wxPython is the likely culprit. Some of the wxPython installers seem to enjoy breaking Python :) I'm pretty sure this has been fixed since, though. Yeah, I'm pretty sure that was the one, too. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
