Mailman 3 April 2006 - Pythonmac-SIG

on a tangent from new icons
by Jacob Rus Sept. 25, 2006

Sept. 25, 2006

While we're adding a bunch of icons to Mac Python, and editing Info.plist files, and so on, I think we might as well make a few other changes: 1. If it doesn't already, I think Mac Python should ship with a python spotlight importer (I got one somewhere else, but should be default) 2. Let's export some UTI's for .pyc/.pyo files and .egg files (maybe public.python-bytecode and public.python-egg or something, or maybe they need to be org.python.python-bytecode, etc.) 3. Let's make sure that python files get useful "kMDItemKind" names. Right now, if I associate one with PythonIDE.app, I get "plain text file" for .pyc, and "Document" for .pyo, which is not useful. 4. Let's add some spaces in the names of things like PythonIDE.app, BuildApplet.app, PythonLauncher.app and PackageManager.app. Some other questions: * What's the difference between PythonIDE.app and IDLE.app? Should they get different icons? Is one of them preferred to the other? I just use TextMate and iPython from terminal, so I don't really know what all they do. * What exactly do python eggs do? Are they just extra modules packaged up, or can you run them as standalone apps? * If the latter, how exactly do eggs differ from the applet's created by BuildApplet.app? * Do we want different icons for py2applet.app and BuildApplet.app? What exactly is the difference between these? Basically, I'm confused by the seemingly endless official or semi-official ways to package up python code and edit it on the Mac. Are any of these deprecated? -Jacob

8 10

Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
by Christopher Barker July 15, 2006

July 15, 2006

Bob Ippolito wrote: > The libs should all be statically linked to the extensions, they > shouldn't be separate in the installer. Ronald Oussoren wrote: > I'd prefer to have fully self contained packages, and preferably > eggs at that. Having a shared libary makes it *harder* to independendly > update extensions using libpng or libfreetype. No one answered my question directly, but both Bob and Ronald have spoken: It's better for each package to statically link any libs it needs (unless Apple provides them), even though that means that a given python program may well end up using three copies of the same lib. Just to be totally clear: Is there any problem with the same program using three slightly different versions of the same lib? > I'll have to package up my package build script one of these days ;-) What does it do? Something different than bdist_mpkg ? Daniel Lord wrote: > I built Universal jpeg-6b, freetype2, and zlib for my current project > of Universal PIL. I can add libpng in easily so I'll do it. > So that makes jpeg, png, freetype, and zlib. What else? Those are the ones I need at the moment. Thanks! I guess a zip archive of the collection would be the best way to get it out there. > I have successfully packaged up a Universal PIL for 2.4 (thanks for > the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am > closer to releasing it. Post a link to it here when you are ready so we can test it. Maybe it would be helpful to have a standard way to link static libs with our packages. What I've done for matplotlib is create a "StaticLibs" directory at the same level as the setup./py, then hacked the setup.py to include it in the linking (and header) paths. I'll probably create one that has all of the above libs in it, then I can add a symlink to it for each package I'm trying to build. If anyone has any better ideas, I'd be glad to hear them. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

3 4

ical.py loose in the wild
by skip＠pobox.com May 10, 2006

May 10, 2006

My little iCal event/todo manipulator is loose and available from my Python Bits page: http://orca.mojam.com/~skip/python/ It allows you to add or print iCal events and todos from the command line. You can also feed appropriately formatted email messages to it and turn them into todos or events. Skip

3 2

Python based apps woes on MacOs X (was :Re: [Pythoncard-users] Re: PythonCard on OS X 10.4 with Python 2.4.1)
by catonano＠inwind.it May 7, 2006

May 7, 2006

> >There's a current thread about this in the PythonCard-users group, > >under the non-clear subject name: > > > > Re: update (was: Re: [Pythoncard-users] supposed bug in > >PythonCard) > > > > > >Yes I originated the thread. I found a bug in Pythoncard with python 2.4.1 and wxPython 2.6.1.0 and > >PythonCard 0.8.1 > > > >It's not "supposed". It's a quite clearly a bug. > > > > > > > Adriano - > the only reason the subject line says "supposed bug ..." is because > that's the subject line you chose for your initial posting to the > Pythoncard list on this topic :-) Yes, Alex, you're right. It was a supposed bug when I opened the thread, so the subject line was quite good at the moment. Later it became a bit obscure ;-) > Something appears to have changed wrt the path that Python's sys.modules > reports for imported files. >As far as I know, no-one has yet verified > for sure whether it is a Python bug or merely a platform-specific change > that Pythoncard will need to adjust for. (Nor do I know how we'll be > able to adjust - but I'm hoping that some of the PythonCard / Mac users > are investigating ....) That python user could be me ! Alex, would you discuss a bit more about this Python issue ? sys.modules reportings about the imported files has changed ? Since when ? Does this affect the Apple installed python or the "third parties" ones ? Thanks! Bye Adriano ____________________________________________________________ Libero Flat, sempre a 4 Mega a 19,95 euro al mese! Abbonati subito su http://www.libero.it

4 5

Universal installation of Tcl/Tk Aqua--for Tkinter developers
by Kevin Walzer April 28, 2006

April 28, 2006

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For Tkinter developers: I've put together a universal installation package of the Tcl/Tk Aqua frameworks, based on Tcl/Tk 8.4.13. This package should work with the universal build of Python that's been released. You can download the package at http://tk-components.sourceforge.net/installer/. Be sure to look for the "Aqua" package--there is also a universal build of Tcl/Tk for X11 at the site, which will probably be less useful. Thanks. - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUiLirTC5hIgjqTMRAqoOAJ9Gj5IOmYy/ANDkT8nEI5D9CcRJTQCgh2ew cL9ib5Zfpxooa1vcyJvmV2I= =F/qz -----END PGP SIGNATURE-----

2 3

/Applications/MacPython 2.4/Extras/Tools missing from Universal build?
by Frank Niessink April 28, 2006

April 28, 2006

Hi all, Maybe I'm missing something (pun not intended), but I'm missing /Applications/MacPython 2.4/Extras/Tools and contents from the Universal build. Are those tools put somewhere else? Cheers, Frank

2 2

Re: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so!
by Alex Martelli April 27, 2006

April 27, 2006

On Apr 22, 2006, at 1:59 AM, pythonmac-sig-request(a)python.org wrote: > No arbitrary precison math on Mac-tel say it ain't so! It ain't so. > The analog of a single gene pool in nature has come to pass for > arbitrary precison math (APM) for OS X (native not Python). > GMP is 'it' for APM as far as I can tell unless I want to write my > own. I believe intel also has libraries (they offered them for beta at some point, but I didn't follow through on that), but that's not the key point. > And GMP doesn't compile on Mac-tel and won't for some time: > > The current release is 4.2, released 2006-03-26. It fixes all bugs > found in 4.1.4, as well as several portability problems. It also > adds several new features. Note that we chose not to work around > all new GCC bugs in this release. Never forget to do a make check > after building the library to make likely it was not miscompiled! > > Issues with GMP 4.2: > > Miscompilation on several platforms using several different > compilers. Remember to run make check! > GMP does not build on MacInteltoch machines. Since Apple uses their > own, creative assembly syntax, it is not trivial to fix this. Nope. The current maintainer of GMP is apparently Apple-hostile AND by his own admission no expert on autoconf/libtools and similar blackmagic -- and apparently unable to admit it when he's dead wrong. Apple's assembly syntax is totally irrelevant here. The reason make check fails is Apple's creative *ld semantics*: an object file inside a library file is NOT brought in if the only symbols it satisfies are DATA ones. Make check makes an executable with unresolved symbols because of this strange "optimization" in Apple's ld (I dimly remember from the past other linkers with this kind of strangeness), that's all. Enrico Franchi posted to gmp-bugs, two weeks ago, a patch to gmp 4.2 which I had sent him -- it's a TINY patch (aparts from comments explaining why it exists, it's just *THREE* bedraggled lines...!!!): http://swox.com/list-archives/gmp-bugs/attachments/20060407/f364005b/ patch-0001.obj GMP's maintainer rejected it as "THis is a too ugly patch for inclusion in GMP." (!!!). Anyway, download and apply that patch, and make check passes with flying colors. Then, I had the deadline for the 2nd ed of the Nutshell, then a week's vacation at the Grand Canyon, and have been catching up on things, so I haven't done any further followthrough - yet. Once this idiocy is solved, there is another problem: I STILL can't link gmpy.so beause I can't make libgmp.a to build properly for linkage into a -bundle. Specifically (with gmpy.sf.net's current CVS contents): brain:~/alex/gmpy alex$ python setup.py build_ext -i running build_ext building 'gmpy' extension creating build/temp.macosx-10.4-fat-2.4 creating build/temp.macosx-10.4-fat-2.4/src 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./src -I/usr/local/include -I/ Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/gmpy.c -o build/temp.macosx-10.4-fat-2.4/src/gmpy.o gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/src/ gmpy.o -L/usr/local/lib -lgmp -o gmpy.so /usr/bin/ld: for architecture i386 /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation entries in non-writable section (__TEXT,__text) /usr/bin/ld: for architecture ppc /usr/bin/ld: warning /usr/local/lib/libgmp.a archive's cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (can't load from it) collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccGbVJa4.out (No such file or directory) error: command 'gcc' failed with exit status 1 brain:~/alex/gmpy alex$ Don't worry about the failure on the ppc branch, that's just because the .a is not universal and would presumably result in making a non- universal .so -- could be fixed later. I've tried with a nonuniversal 2.4.3 (from Activestate) and THAT halfbug goes away. It's yet another TODO item, with lower priority than "the biggie" below. The biggie is the like: /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation entries in non-writable section (__TEXT,__text) I've tried ("manually", i.e. with CFLAGS=... on the ./configure of GMP 4.2) various -f flags to try to make libgmp.a PIC (which I assume is what's the error's complaining about?) -- -fPIC, -fno-common, others; no luck so far. I've explored every mention on the web of this errorcode about "local relocation entries in non-writable section", but, no luck so far. It may be trivial for people more deeply familiar with Apple's toolchain (ld most of all) than I am, and I do have several at work I can consult on that, but, as I said, I didn't yet have much time for followup. Once I understand how to fix it with CFLAGS=..., then I must understand how to embed the fix via autoconf/configure/libtools, which is scary (MY knowledge of that part being very scarce). Finally, there will be the political fight to make the maintainer accept the resulting patches. BTW, the biggie is fully reproducible on PPC Macs, too, so GMP 4.2 builds on those in a state which still doesn't let gmpy.so link (it may feel less urgent just because GMP 4.1.* does build fine;-). I've even tried using 4.1.* on mac-intel but it breaks in different ways and it seems to me that there's no point fighting with that one, I might well focus my limited time and energy on 4.2!-) BTW**2, any advice from ANYbody with better grasp of Apple's ld, the significance of -bundle vs -dylib, autoconf and friends, etc, etc, will be most welcome!-) Alex

4 13

Re: [Pythonmac-SIG] Appscript, adding files to iTunes
by has April 27, 2006

April 27, 2006

Daniel Thorpe wrote: >Hi, I'm wondering if anyone can help me with an Appscript / iTunes >utility I'm trying to write. Does anyone know how I add m4a files to >my iTunes library using appscript? > >So far, I have a list of filenames, which I want to add to my library >(which I've got a reference to). According to app('iTunes').add.help >() I have to pass the function a list of Alias(s). I think this means >Finder alias files, but I can't seem to be able to create them using >app('Finder').make(). Nope, no relation to Finder. 'Alias' is an AE type. Ch.6 of the appscript manual lists the common AE type <-> Python mappings. Example: from appscript import * from macfile import * files = [Alias(u'/Users/foo/some.mp3'), Alias(u'/Users/foo/another.mp3'), ...] itunes = app('iTunes') itunes.add(files, to=itunes.playlists['Library']) HTH has -- http://freespace.virgin.net/hamish.sanderson/

1 0

Why dynload_next.c rather than dynload_shlib.c?
by Phil Thompson April 27, 2006

April 27, 2006

Apple's Python seems to be built with dynload_shlib.c which allows it to handle extension modules built as bundles and dynamic libraries. python.org Python uses dynload_next.c which means that extension modules must be built as bundles. Is there any particular reason for this (I'm new to MacOS)? Thanks, Phil

2 1

PIL 1.1.5 universal package currently broken
by Bob Ippolito April 27, 2006

April 27, 2006

It seems that the PIL build is missing freetype *and* it's not even linked to a dynamic version of it. Very strange. >>> import _imagingft Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: Failure linking new module: /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages/PIL/ _imagingft.so: Symbol not found: _FT_New_Face Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/PIL/_imagingft.so Expected in: flat namespace $ otool -L /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/PIL/_imagingft.so /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/PIL/_imagingft.so: /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.3)

1 0