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] [newbie] install PyObjc under EPD Python ?
On 2009-12-21 11:39 AM, Christopher Barker wrote: I wonder when Enthought is going to go to 2.6 for EPD? The betas are out now and are available to subscribers. I'm not sure exactly when the final release will be out (and freely available for the academic license), but soon. -- 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-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 wxPython and wx-config during build of 3rd party lib
newbie73 wrote: I am attempting to build parts of the Enthought Tool Suite and am running into some trouble with a package that uses wxPython (and wx-config). My system has two versions of wx-config, the one that comes with Leopard and the one I installed. I believe the problem with the installation is the use of the wrong wx-config, though I am not sure how to correct the problem. And neither does this list, most likely. It's my code that's causing issues. Let's keep this on enthought-dev. -- 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?
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?
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 -- 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?
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: > 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] 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: > 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 "", 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] 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=80706&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=1161866270&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] 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] 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] Wrapping CoreGraphics with Universal Python?
Zachery Bir wrote: > Has anyone taken a shot at wrapping CoreGraphics for Universal Python? > > I know Apple's CG bindings invent new, undocumented APIs for dealing > with the underlying libraries, but I don't have any experience > wrapping libraries with Python, and since CoreGraphics isn't Cocoa, > it's not a simple operation for PyObjC. > > Where to begin? Here: http://svn.enthought.com/enthought/browser/trunk/src/lib/enthought/kiva/mac I haven't tried it with Universal Python, yet, and some work needs to be done to connect it up to Cocoa NSViews, but most of the CoreGraphics API is wrapped. -- 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] add other Python distros to the downloads page?
Bill Janssen wrote: > I was thinking of adding a section at the bottom with pointers to the > ActiveState Python along with the fink and DarwinPorts Python > downloads. Are there others we might mention? Isn't there a big > SciPy installer, too. You are probably thinking of MacEnthon. It was just a bunch of bdist_mpkg's tied together by a single mpkg. It is quite old and is not being updated. -- 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] 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] Mac Python and eggs...
Christopher Barker wrote: > No, you didn't misinterpret my post, but according to Bob, you could > easily upload the eggs directly to cheeseshop -- why not do that? Because he's not finished testing it, yet? These particular packages are somewhat complicated and only recently have been eggified. -- 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 Python and eggs...
Bob Ippolito wrote: > Well if they can build an egg, they can upload it to Cheese Shop with > one command. They probably just haven't invested the five minutes to > read over the setuptools documentation to see that it has an upload > feature. *Believe me,* I've spent more than five minutes reading the setuptools docs and getting these package buildable as eggs. What I haven't done is spend the time to convince the other maintainers to distribute via PyPI in addition to Sourceforge. One must have priorities. -- 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] Non-Qt basic question
Chris Barker wrote: > Terry Jones wrote: > >>Ok, thanks for looking. I've been putting off moving to 10.4 because I will >>need to rebuild many things. Now it looks like I have a good reason. > > Well, perhaps, but as far as I can tell, there is still some open-source > software that doesn't work so well on 10.4 (gcc 4.0 issues). Maybe the > situation is good enough now, I'm not sure. You don't have to use gcc-4.0 on 10.4. gcc-3.3 is still there and perfectly functional. -- 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. > > > > > 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] troubles with distutils
andrea valle wrote: > (Thanks for your help) > >>Are you sure you're getting active Python with "python" at the command >>line? > > Yes > 2.4 is only active state. > I will try your suggestions. > > In any case, I tested with python2.3 (macpython) > > apples-Computer:~ apple$ python2.3 > /Users/apple/Desktop/PyRTF-0.45/setup.py install > running install > running build > running build_py > error: package directory './PyRTF' does not exist You have to be in the directory with the setup.py . $ cd Desktop/PyRTF-0.45 $ python setup.py install -- 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] 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] CoreGraphics module for python 2.4.1
Robert Kern wrote:
> 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
And I forgot to mention that you will need Pyrex and setuptools to build
from source. You will also need Numeric to run it and also PIL if you
want to save bitmap images to a file.
Here is a small example of its use:
In [1]: import ABCGI
In [2]: gc = ABCGI.CGBitmapContext(256,256)
In [3]: gc.move_to(0,0)
In [4]: gc.line_to(128,128)
In [5]: gc.stroke_path()
In [6]: gc.save('foo.png')
--
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: > I found this advice before, but as someone who doesn't have a unix > background, it took me a long time to figure out exactly HOW to change > my $Path variable permanently. Can I suggest that a tutorial be linked > to the pythonmac or undefined.org/packages sites detailing this > process? You can suggest all you like. It's much more effective, however, to write such a tutorial and ask that it be placed on the site. > Alternatively, can the path be modified by the 2.4 install script? No. Installers that do that kind of thing garner well-earned derision. -- 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
Christofer "Boz" Jennings wrote: > Hi, > > I'm a newbie to this list and to Python who has messed up Python on > Tiger :-( > > I'm on an eMac, G4 1.25 GHz. > > I installed Python 2.4 with TigerPython24Fix. Then I installed PIL. I > wanted to build Skencil but the build failed to find the Imaging > package. Looking for that package I noticed the build expected it in / > System/Library/... instead of /Library/... (where Python 2.4 got > installed) so ... and this is where I messed things up ... I started > changing symlinks and so forth. Now I'm hopelessly messed up. I've > clobbered Python of any version on my Mac. ... HELP!!! That's bad. You'll probably want to reinstall the OS. Don't remove the Apple-installed Python. The OS depends on it. > The TigerPython24Fix installer now says that my hard drive not a > valid target, even though it worked before. > > I think I want to have Python 2.4 as the only version. Any help would > be much appreciated. No, you don't. What you do want to do is put /usr/local/bin in your $PATH before /usr/bin so typing $ python gives you 2.4.1. That was probably your problem with building Skencil. -- 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 2.4.1 not replacing earlier versions.
Kevin Dangoor wrote: > #!/usr/bin/env python > > is actually saying to invoke the "env" command (you can type 'man env' > to see what that command's all about). This particular usage of env > does not actually do anything of value, as far as I can see. It selects the first executable named "python" in the PATH. The shebang line requires an explicit executable. For example, #!python does not work. -- 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] 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] 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] 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] 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] 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] urllib2 error
Alastair Rankine wrote:
> Hi,
>
> I just installed MacPython 2.4.1 and TigerPython24Fix from
> http://undefined.org/python/ onto my Tiger system. All is not well with
> the urllib2 module:
>
> $ python
> Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import urllib2
> >>> urllib2.urlopen("http://www.python.org";)
> Traceback (most recent call last):
> File "", line 1, in ?
> File
> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/urllib2.py",
> line 130, in urlopen
> return _opener.open(url, data)
[snip]
Works for me.
[~]$ python
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> urllib2.urlopen('http://www.python.org')
>
>>>
--
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] Boa stability issues
Geoff Canyon wrote: > On Jun 21, 2005, at 8:37 AM, Bob Ippolito wrote: > >>If you actually did remove every trace of Python 2.3, then you >>broke some Apple stuff (at least some of the print workflows and >>fax cover pages) and several third party applications. Don't touch >>anything that Mac OS X comes with. If I were you, I'd go ahead and >>just reinstall before you start running into those problems. >> >>/System and /usr (except /usr/local, of course) should not be >>touched except under extreme circumstances when you know what >>you're doing. > > (getting back on topic) Are you saying that there is some aspect of > the older Python install that comes with Tiger that Boa needs, > despite the fact that the documentation specifically requires the > most recent version? *OS X* needs the older Python. Since the semi-official binaries for 2.4.1 install alongside the OS X binaries, there's no need to rip out the operating system's components. -- 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] 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] 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] 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: > 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] 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] 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] 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] 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] 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 "", 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] Re: ANN: MacEnthon 0.1
Tom Pollard wrote: Actually, I was wondering how safe it would be to install MacEnthon if I already had a significant number of these packages installed? Everything I have was either built locally against the standard system Python 2.3 or installed from one of Bob Ippolito's binary packages. Will MacEnthon overwrite my existing packages? It will overwrite pre-existing packages. It won't delete anything, though. You'll just end up with some straggler files that were in your version but not in mine. I believe this is more-or-less safe (that is, if you want my version and not your own). Best, of course, is to move the packages you have out of the way. Or get installed alongside them somehow? Will I be able to select which MacEnthon packages are installed? Yes, look for the "Custom Install" button after you select the drive to install to. -- 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] Re: ANN: MacEnthon 0.1
[Someday, I'll figure out how to work a mail program. Sorry for the repeats, Russell.] Russell E. Owen wrote: > In article <[EMAIL PROTECTED]>, Robert Kern <[EMAIL PROTECTED]> wrote: > > >> 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. > > This looks amazing. Thank you very much. > > I have a lot of this stuff installed already and am wondering if I > should risk it now or not, but I"ll certainly be using it in the > future. I'm pretty sure that installing MacEnthon over top won't do much harm, but some of the stragglers might cause some weird but rare bugs (especially if there's code that does "try: import _something_old; except ImportError: etc."). It would be best if you moved the stuff already installed out of the way first. If they were installed from bdist_mpkg installers, you can use enthonbegone.py to remove them. $ pwd /Volumes/MacEnthon-0.1/Uninstaller $ ./enthonbegone.py -s /Library/Receipts/Numeric-platlib-23.7.pkg Starting MacEnthon Uninstaller Directories to delete: /Library/Python/2.3/Numeric Directories that will not be deleted: /Library/Python/2.3 $ sudo ./enthonbegone.py --logfile uninstall.log \ /Library/Receipts/Numeric-platlib-23.7.pkg ... -- 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] 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
Re: [Pythonmac-SIG] bdist_mpkg with C sources
Jonathan Peirce wrote: I'm wanting to make a mac installer for a python library I maintain that contains some C extensions and I'm not clear how to go about it since setup for bdist_mpkg doesn't accept ext_module. Does anyone have a simple-ish example of how to do this? Or will it be that bdist_mpkg will one day just act like the regular distutils bdist? Obviously ideally I would like not to have a separate setup.py for each platform I support - would be much nicer to have a single script like the one below (which does successfully build a mac binary distribution using bdist, just not the double-clickable installer) I have built upwards of 40-ish packages with extension modules and packaged them with bdist_mpkg. I have found no such problem. Can you describe the actual problem that you are seeing in more detail? -- 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
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] 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 ...
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] 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] 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
[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] Re: Pythonmac-SIG Digest, Vol 23, Issue 42
Jon Schull wrote: *MacEnthon 0.0 Prerelease* This looks great. Have you considered adding vpython to this package? It uses numarray, plays well with ipython, and is of unsurpassed simplicity and elegance. I am not taking package requests at this time. I did consider vpython at one time, but it has a strong presumption against it because of the X11 requirement. -- 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] 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
[Pythonmac-SIG] MacEnthon ...
... is not here, yet! But it will be! I have one more issue to work out before cutting a pre-release. Sadly, I must get some science done today. 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. Almost all of the packages are built using bdist_mpkg. A few are made by PackageMaker.app. Another few (MacPython extras and wxPython, notably) come from their original, non-bdist_mpkg packagers. Assume that you can have a list of packages to check for hard-coded. Everything gets installed somewhere under - /Developer/Documentation/Enthon - /Developer/Python - /Library/Python/2.3 - /usr/local - /Applications/MacPython-2.3 In return for your generosity, you get my eternal gratitude[1], the beverage of your choice should we happen to be in the same city somewhen, and a brand spankin' new MacEnthon by Monday. wxPython has a CLI uninstaller for itself that you can steal from. Attached is the current MacEnthon ReadMe thingy. Yell at me if there's something obviously bogus in it (but no package requests, please. We'll talk about adding to this 157Mib behemoth later). [1] Which I imagine will be somewhat tricky to fulfill once I die, but that just makes it *so* much more valuable. -- Robert Kern [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter Title: MacEnthon Readme MacEnthon 0.0 Prerelease Welcome to MacEnthon! As you can tell from the version number, this is an unpolished prerelease. A fair number of things are broken, undocumented, or suboptimal. Some packages are in development, others don't work as well on the Mac as on other platforms, and sometimes I'm just a bozo. A copy of this document will be installed to /Developer/Documentation/Enthon/ReadMe.html for future reference. Please report all bugs to the Enthon issue tracker. Add the topic "MacEnthon" and assign the bug to the user "rkern" to each issue, please. At this time, the installer targets OS X 10.3 (Panther) and the pre-installed "framework" build of Python 2.3.0. Jaguar is not supported. Other Pythons, such as those from Fink, Darwinports, or a self-installed Python, are not supported. I have tried to collect the documentation for each package. Some packages are not documented for reasons ranging from "the OS X package was made by someone else who didn't include the documentation" to "I was too lazy to track it down." Where possible, the documentation was placed into package-specific folders under /Developer/Documentation/Enthon. A few packages place their documentation into /Developer/Python because that is where their packagers decided to place them. The real release will probably rationalize this setup. Command-line scripts have been placed into /usr/local/bin. If you wish to use these scripts, please add /usr/local/bin to your PATH environment variable. I would like to thank Bob Ippolito for his ground-breaking work on py2app which has made this distribution possible. Software Note: the licenses listed here are sometimes only approximate. Many projects use trivial variants of well-known licenses (for example, the BSD and X/MIT licenses). I use the term "BSD-like" below to signify such licenses (and probably some authentic BSD licenses, too). Also, many projects include code under several different licenses. If you need to know the license of a piece of code precisely, please see the corresponding package's documentation. Ususally, the license is in a file named COPYING, License.txt, legal.txt and the like. If you cannot identify the license, please file a bug report. To the best of my ability to determine, all of the code here is open source and free to use. If you intend to redistribute these packages or develop software that uses these packages, you should read the licenses of those packages. Most have requirements that you are obliged to follow. The source code that I used to build these packages is available on request. Package License Tracked Version Scipy BSD-like CVS as of 2005-03-25 (using ATLAS) Numeric BSD-like 23.8 (using vecLib for LinearAlgebra) numarray BSD-like 1.2.3 ScientificPython BSD-like 2.4.9 (no MPI support at this time) PIL BSD-like 1.1.5c1 readline GPL 2.3.5 (from the Python standard library) bsddb PSF 2.3.5 (from the Python standard library) IPython BSD-like CVS as of 2005-03-24 wxPython wxPython license (LGPL with exception) 2.4.2.4 and 2.5.4.1-unicode; we use multi-version installs with a default of the 2.5 version; change the contents of /Library/Python/2.3/wx.pth to point to the 2.4 directory if you want to use 2.4 as the default
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
[Pythonmac-SIG] bdist_mpkg zipdist and unzip(1) (was ANN: pygame 1.7.0 for Mac OS X 10.3)
Robert Kern wrote: Using /usr/bin/unzip to unzip the package seems to strip the executable flags from these files. Stuffit Expander seems to work fine. I've traced the problem to a deficiency in Python's zipfile (well, one could equally say that there is a deficiency in Info-Zip's code, but Python is still wrong regardless). I have attached a workaround patch to py2app. -- Robert Kern [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter Index: src/bdist_mpkg/cmd_bdist_mpkg.py === --- src/bdist_mpkg/cmd_bdist_mpkg.py(revision 426) +++ src/bdist_mpkg/cmd_bdist_mpkg.py(working copy) @@ -434,6 +434,15 @@ if os.path.splitext(fn)[1] == '.gz': compression= zipfile.ZIP_STORED z.write(fn, arcfn, compression) + +# ZipFile always marks the files' attributes to be interpreted as if +# they came from a Windows host. This interferes with some software +# (namely unzip(1) from Info-Zip) from extracting executables with the +# proper file attributes. So manually fix the appropriate attributes on +# each of the ZipInfo's to specify the host system as a UNIX. +for zinfo in z.filelist: +zinfo.create_system = 3 # UNIX + z.close() def copy_tree(self, infile, outfile, ___ 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] ANN: py2app 0.1.8
Robert Kern wrote: Dave Opstad wrote: Any ideas what could be causing it to not find the init.tcl bundled in the app? I have occasionally run into a similar problem with py2app'd Tkinter programs. Unfortunately I haven't had the time to track it down and submit a bug report. I believe the culprit is a missing symlink in the included Tcl.framework. And I can't reproduce said condition with 0.1.8. Do check the included framework for missing symlinks, though. -- 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: py2app 0.1.8
Dave Opstad wrote:
Well, the good news is that I was able to build and launch my app with 0.1.8
where I wasn't with 0.1.7 (see my posting to this list on March 7). On my
development system I double-click the app and it launches and runs fine.
The bad news, though, is that the app doesn't launch on a system that
doesn't have Tcl already installed, even though the Tcl framework got
correctly bundled in the app itself. The same error ("Can't find a usable
init.tcl") is happening as I described back on the 7th. I checked, and the
init.tcl is indeed in the Tcl.framework within the app's Contents directory.
Any ideas what could be causing it to not find the init.tcl bundled in the
app?
I have occasionally run into a similar problem with py2app'd Tkinter
programs. Unfortunately I haven't had the time to track it down and
submit a bug report. I believe the culprit is a missing symlink in the
included Tcl.framework.
--
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
Re: [Pythonmac-SIG] Mac User Python Newbies
Louis Pecora wrote: Interesting comment. I do know that there is a lot of interest in Python in the scientific community. Some SIAM (Society for Industrial and Applied Mathematics -- BIG coverage there) conferences have had special minisymposia on using Python for numerical coding. But most people just have no idea where to start or are put off by all the packages out there and the need to find one's way through the forest. I suspect a simple "all-in-one" package of Python for Scientists, Mathematicians, and Engineers (a la MATLAB) would be a hit. Given the existence of Matplotlib in Python that might be a reasonable target. Even if it were just a "poor man's MATLAB" that would be fine. Just so long as it installed in one shot and was reasonable easy to use. But maybe that's asking a lot. I don't know. It's called "Enthon." There will be a new release (for Windows and Linux) with more stuff, like matplotlib, Soon(TM). http://www.enthought.com/downloads/downloads.htm There will be a Mac release A Little Later Than Soon(TM). http://www.scipy.org/wikis/featurerequests/MacEnthon -- 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 User Python Newbies
Bob Ippolito wrote: However, it would be entirely possible to build an "Enthought Python" type distribution for Mac OS X using these facilities as-is. At least one person is interested in creating such a distribution <http://www.scipy.org/wikis/featurerequests/MacEnthon>, but it's not ready yet as far as I know. All the packages in the main list build and install cleanly. Now I'm working on packaging up the documentation for each package, and unfortunately, Real Life annoyances are taking up too much time. Maybe next week there will be a beta release. -- 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] Fink, DarwinPorts vs py2app
Chris Barker wrote: I really think we can get a complete set of OS-X friendly packages out for all to use. it's really not all that hard, once you've got the tricks figured out. We'll have a MUCH easier time getting folks to use python on OS-X if we have nice friendly binaries for them to install. By the way, what is the status of Package Manger, and the two repositories (Jack's and Bob's) Are they being maintained? should I submit matplotlib to them? If anyone want to help with my SciPy on OS-X project, please let me know. There is some real momentum in the NumPy/SciPy crowd to make SciPy easier to install right now. Scipy is actually one of the easier packages for me to bdist_mpkg up. OTOH, I've been building scipy regularly for *years* now. http://www.scipy.org/wikis/featurerequests/MacEnthon I was hoping to have some beta packages out this week, but personal annoyances are probably going to push it out of the way right now. -- 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] Re: [Matplotlib-users] matplotlib OS-X binary problems.
Chris Barker wrote: Robert Kern wrote: 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. Except that the *.a and *.dylib are put in the same place. Darn. Copy (and re-ranlib) the static library and headers to another place. -- 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. 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
